allow GLIF image to store an SVG file?

[anthrotype]

We're trying to design a workflow for generating color emoji or icon fonts from a set of SVG files.
I was thinking if we could re-purpose the current <image> element of the UFO GLIF spec so that it can contain SVGs in addition to the current PNG files.
Currently the GLIF spec says

All images must be in Portable Network Graphics (PNG) format

I suggest to rephrase this as

Images can be either in Portable Network Graphics (PNG) or in Scalable Vector Graphics (SVG) formats.

Doing this will make it easier to link together a GLIF to an SVG file that contains coloured vector outlines that can then be used to compile COLR/CPAL or OT-SVG fonts.

[typemytype]

This means an implementation should be able to show a full length embedded movie.

maybe "public.*" glyph.lib keys is something to look at

but actually the data directory is build for this: http://unifiedfontobject.org/versions/ufo3/data/
a public data filename could also be an option "public.svg."

[behdad]

This means an implementation should be able to show a full length embedded movie.

Why? Implementations choose what to support. SVG has various profiles. No JS, no animation, no CSS, etc are all widely in use....

Ignore all Cosimo said about building color fonts. I think it makes sense to allow SVG where PNG is allowed, just for images.

[justvanrossum]

The image element stems from needing template images in the background, so the designer can trace them.

While I don't agree that to allow SVG automatically implies that all clients must support all of SVG, I'm not convinced the image element is the right place for any SVG source images. What if you'd need an SVG source and a template image to trace?

I would also suggest a combination of glyph.lib and the data folder. If this workflow becomes very popular, we can consider making it more native to the UFO format.

[behdad]

That's what I said "ignore what Cosimo said about building color fonts".

I'm suggesting that the template image can be in SVG. It's unreasonable limitation to specify in UFO spec that only PNG is accepted.

[justvanrossum]

We cannot not consider the use case... The current use case is for template images, which typically are scans. SVG makes no sense for that. (JPEG on the other hand...)

[behdad]

We seem to have different approaches to what standards are or should do. You seem to prefer a policing approach. I prefer a expressiveness approach.

[typemytype]

The only use case for SVG in a glyph is for building a specific color font table. SVG support is not the same as support for plain image data, as it is specific to color fonts.

A public data file name scheme is a good working solution for this specific problem.

[anthrotype]

"image" felt like the most natural place for me. The spec currently only says that it should "always be considered to be behind the outline element", but doesn't explicitly say that these are meant as background images for tracing.

What if you'd need an SVG source and a template image to trace?

we could relax the requirement that only one <image> element be specified, and add a template="1" attribute to means "use the image only as background".

Anyway, I don't want to push this too much, I can work with with data folder and glyph.lib for now.

[anthrotype]

certainly one can already use the glif <image> elements to reference PNGs from which to build some sbix or CBLT/CBDT color font. Hence the idea of extending it to SVG (an image format)...

[justvanrossum]

Btw. if the goal is to parse SVG and compile it to COLR/CPAL: why not import it as UFO layers? I think a COLR/CPAL compiler that takes UFO layers as input would be a useful thing. I am planning to look into the implications of adding such functionality to ufo2ft. If – big if – the intended SVG data should be expressible as color layers anyway, going back and forth from layers to SVG shouldn't be a huge deal.

[justvanrossum]

I just noticed that http://unifiedfontobject.org/roadmap/ has a section on SVG. I think we should just add that to the spec. I'm not entirely convinced of the requirement that there should be a layer named public.openTypeSVG, though.

[anthrotype]

Let's proceed with that then.

I'm not entirely convinced of the requirement that there should be a layer named public.openTypeSVG

Yea, I don't know what the use would be for a distinct layer. The glyphs from the default layers could just point directly to the svg file as stored in data/public.openTypeSVGGlyphs.

We also need to think how to allow multiple glyphs to point to the same svg document that may contain multiple glyph definitions. In the OT-SVG spec, these have an id attribute with the glyph index. However in UFO we don't have glyph indexes yet, only glyph names.

[anthrotype]

maybe this id attribute could store the glyph name inside the UFO, and the compiler would replace it with glyphX with X being the glyph ID.

[anthrotype]

instead of openTypeSVGGlyphs, maybe openTypeSVGDocuments would be better, to decouple the N:1 map between glyphs and svg files.

[justvanrossum]

maybe this id attribute could store the glyph name inside the UFO, and the compiler would replace it with glyphX with X being the glyph ID.

Yes. Also: if TTX dumps of the SVG table could not use glyph IDs, that would be fantastic.

+1 on openTypeSVGDocuments

[anthrotype]

If one wants to build bitmap color formats (sbix, CBLT/CBDT, OT-SVG with embdedded images), are we allowed to use the <image> element to reference a PNG image stored in the UFO's images subfolder?

I believe so. The counter-argument "what if someone needs both a image source and a background image to trace" doesn't hold here. The default layer that specifies the glyph metrics, unicode value, black-and-white fallback outline, can have its own background image for tracing. But then additional layers will contain glyphs referencing the image sources (one layer per bitmap "strike", i.e. combiantion of PPEM and ppi).

[justvanrossum]

I disagree.

I think we made a mistake by not documenting that <image> is intended for a template image. We should fix that.

To also use it as an SVG or PNG source makes for messy semantics.

• what if the UFO needs a PNG source and an SVG source?
• what if multiple resolutions of PNG images are needed?

Sure, these may be weak arguments, but I really think we need something different for image sources. And that something may be custom lib keys, public lib keys (which we can add without bumping the format version), or a spec upgrade. The latter is the most expensive option, and I really believe the existing lib + data folder machinery is flexible enough to enable such image-source workflows.

[anthrotype]

Pity. It would be much easier to produce such fonts with the existing tools that already allow to drag-and-drop PNG images, position and stretch them, and store them inside the UFO.
We'd only need a way to make explicit that some layers containing references to image sources are intented to be used for generating color fonts, e.g. a special layer name prefix.
Glyphs.app does exactly that with their (admittedly weirdly named) "iColor XX" layers.

[anthrotype]

what if the UFO needs a PNG source and an SVG source?
if if multiple resolutions of PNG images are needed?

both could be handled with separate layers, each referencing different image sources.

[justvanrossum]

It would be much easier to produce such fonts with the existing tools that already allow to drag-and-drop PNG images, position and stretch them, and store them inside the UFO.

True.

both could be handled with separate layers, each referencing different image sources.

True.

[justvanrossum]

Although I wonder if those existing tools really offer a pleasant experience for that particular task out of the box. For example, in RF you won't see such images in the space center, and I don't see any numerical controls for placement and transformation, so it's not an immediately obvious win there.

I'm torn about this. I see your points, and we do indeed have a working piece of infrastructure.

Still, the whole setup of images in UFO is so different from how glyph data is handled. For example, images can have arbitrary file names, and don't adhere to the layer hierarchy. I don't think the images folder allows subfolders.

So, while the infrastructure can be used for image-source purposes, this intended functionality will be more or less tacked-on, and incidental, rather than be a well designed whole. And in this light I think it may be better to build something that is properly designed (with nice parallels to how outline data is handled), but using lib keys and the data folder, and then the actual usage will prove (or not) that this is a good workflow, and from that real experience we can better decide what changes in the UFO format would make this better.

[justvanrossum]

After a little break I revised my opinions:

• Yes, <image> was originally intended for template use
• The spec doesn't say so
• I have no great interest personally in using images as sources, but if people think they can use the <image> element for that purpose, all I will say is "Hm, if you must, whatever floats your boat."

In other words, I don't think the spec should be reworded to discourage this use case. Let's just see what happens.

Now, I'm warming up slightly to the idea of opening up the format of images specified with <image>. My resistance to this has two reasons:

• It's a tool-breaking change (see below)
• I wouldn't want "SVG-in-UFO" to become the de-facto way to build color fonts

I think we are well on our way to agreeing that we need a general layer-based workflow to build color fonts (any format), but I now see that there is also a good use case for using SVG as sources. To me, the latter is for rather specialized tasks (such as building emoji fonts), and the former is more type-designer- and font-editor-friendly.

However:

• Such a change requires a format bump (a minor bump woud be enough, but we don't have that yet: Make formatVersion in metainfo.plist a major/minor #78)
• It is a tool-breaking change, but perhaps this can be made more palatable if we say something like: clients are free to ignore image types they choose not to support, as long as they don't corrupt the data (ie. keep <image> element as it is, and don't remove accompanying files in the images folder)

So far so good.

If we indeed choose to allow SVG, how should positioning work? With PNG images, the reference point is the lower left corner of the image. SVG has flipped y coordinates, but I think the lower left corner of the media box should be used for positioning anyway. Would that match your expectations?

A more complex question: if your workflow needs to support storing multiple glyphs in a single SVG file, how would that affect the <image> element? I would presume that aspect to be out of scope for the UFO spec. The workflow can implement it in any way it desires, but displaying such glyphs correctly is then impossible without knowledge about the workflow, which reduces the advantage of using the existing <image> machinery for this.

[behdad]

Positioning should stay same.

If URI syntax can be allowed, we can use something like "faces.svg#blushing" to reference part of an SVG document.

[ctrlcctrlv]

Sorry to bump such an old thread, but as I've written over on the Norad bugtracker, it really doesn't matter what the spec intended…it's been long enough that <image> has had this dual use that now users cannot safely use it as a template image. Ergo, they must assume that it will land in an output font if handled by some software. Ergo, because that is its purpose sometimes, to be on the safe side, we must assume that's always its purpose.

My comment from there:

It's clear that the way <image> works isn't only thinking about tracing. If so, the limitation to one image, and the bizarre procedure for colored images, (which I've implemented in glifparser,) is superfluous.

The CBLC table contains a u32 field, colorRef, which I think was envisioned to have a purpose equal to .glif <image> color.

Furthermore, discussions on using <image> to support SVG, currently open (#104), make no sense if it's not for emoji/color fonts.

The reason I made the sweeping statement is because think about it…there's no way to set an image as a background image/invisible, right? So, that means, if you include an image for tracing, and fontmake or whatever UFO compiler you use compiles your font, it has no way of knowing your intent. Both options are bad: ① throw away the image assuming it was meant for tracing ② keep the image, assuming it was meant for emoji. You can't use the existence of outlines to help, either, because sbix table contains a way to draw outlines over images in its flags bit 1. So no heuristic is gonna work here for all cases.

So, given this is the case, no sane user is going to use the <image> tag for anything but output images, especially in the default glyphs directory. If a dual use was envisioned, the UFO spec should have specified!

[benkiel]

Copying my comment from that thread here. What @ctrlcctrlv brings up points to the need for UFO4 to do something about color fonts, as time goes on this will become more ambiguous, better to have a way to know what is for what in the spec.

Disagree with @ctrlcctrlv's conclusion; if you look at it either from an ahistorical view or by not looking at what other tools that use the UFO do, then that could be a valid conclusion. But viewed by common practice and what was going on when UFO3 was specified: right now the main use of <image> is for things in the background for drawing on top of.

Use of <image> for color fonts is possible (I've done it), but not well supported and depends on a custom toolchain/knowlege that the font intends for this. Going by common use, best to assume for tracing, not for font making.

This is a blindspot in the UFO format that needs correction, spec language for UFO4 very welcome here; especially as it now seems like specs for color fonts have settled down and are unlikely to change much in the future.

[cmyr]

I think if UFO explicitly wants to support being used as a source format for colour fonts, there needs to be an unambiguous decision made around how that use-case is represented in the data.

Some assumptions I have:

• A font is either a colour font, with glyphs represented in some image format, or an outline font, with glyphs represented as a sequence of points
• A colour font is either represented as SVG or as some bitmap format

Working from these assumptions, I can think of a few possible ways to disambiguate between an outline glyph with a background image for tracing, and a glyph with an image that is part of the glyph content:

• a per-glyph object lib key indicating the "type" of the glyph, which influences how <image> is interpreted
• a per-layer lib key that basically says "all glyphs in this layer are svgs/bitmaps"
• a per-font lib key that basically says "this is a colour font, and glyphs are x/y/z format".

... The first option feels bad because it would allow mixing colour/outline glyphs within a layer, which is a headache, and also because objectLib in general is fiddly. The second two options... feel maybe progressively better?

I do think it is worth stepping back, though, and deciding if colour formats are really something that UFO wants to support explicitly or not. If the answer is 'no', which might be a very reasonable answer, then authors who really want to use UFO in this way can figure out their own set of lib keys to communicate what they need to communicate.

finally, to touch on a much earlier thread in this discussion: I personally think it is fine for UFO to say that tracing images must be pngs. If a particular editing tool wants to support other formats, it can convert them.