Color glyph data in UFO

[Adam Twardoch (List)]

Hello UFO spec list,

with surge of color font proposals this year (Adobe/Mozilla's SVG, Microsoft's COLR/CPAL, Apple's sbix, Google's CBDT/CBLC), I think we can safely say that the notion of OpenType fonts consisting only of monochrome outline glyphs is a thing of the past.

The Microsoft format can, although somewhat awkwardly, still be expressed in high-level design tools using the existing mechanism -- because, after all, the COLR format is a way to stack regular monochrome outline glyphs onto each other.

But the other formats, though differing in implementation, have one thing in common: the design sources for these formats can no longer be expressed using traditional means.

Fortunately, it seems that precisely TWO kinds of source data are sufficient to describe the glyph source data, regardless of the final implementation:
* one SVG definition per glyph (which can include both vector and bitmap data)
* a series of per-PPM PNG images (at least one, but commonly more)

The GLIF format currently has a mechanism to store monochrome outline data in the outline element, and it has a mechanism to reference one PNG image per glyph.

I think it would be useful to extend the GLIF format to allow:
1. Referencing external SVG files as glyph sources (in a manner similar to the image element)
2. Referencing multiple PNG files as glyph sources. If there is more than one image per glyph, a PPM attribute should be specified.

I think these changes would constitute a major change in GLIF so would probably require bumping the GLIF format version to 3.

What do you think?

I also have a question. The GLIF spec says that for the image element, the fileName attribute is "The image file name, including any file extension, not an absolute or relative path in the file system." -- does it mean that the strong assumption is that the PNG image file must reside in the same folder as its referencing GLIF file?

Best,
Adam

[Dave Crossland]

On 6 December 2013 11:36, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
> I also have a question. The GLIF spec says that for the image element, the fileName attribute is "The image file name, including any file extension, not an absolute or relative path in the file system." -- does it mean that the strong assumption is that the PNG image file must reside in the same folder as its referencing GLIF file?

That would be my interpretation.

[Tal Leming]

On Dec 6, 2013, at 11:36 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:

> with surge of color font proposals this year (Adobe/Mozilla's SVG, Microsoft's COLR/CPAL, Apple's sbix, Google's CBDT/CBLC), I think we can safely say that the notion of OpenType fonts consisting only of monochrome outline glyphs is a thing of the past.

If there is one word to use in the discussion of the color formats, it is not “safely.” This is the most volatile spec proposal process I have ever seen. It’s also turning into one of the most bizarre specifications possible given the needs.

> The GLIF format currently has a mechanism to store monochrome outline data in the outline element

No. Glyphs can be colored via layer colors. This isn’t per contour coloring, but the same effect can be achieved with layers.

> and it has a mechanism to reference one PNG image per glyph.
>
> I think it would be useful to extend the GLIF format to allow:
> 1. Referencing external SVG files as glyph sources (in a manner similar to the image element)

No. If this goes in, font editors that use UFO would then have to support SVG. I *love* SVG, but it is very deep and complex. I don’t want to, via the spec, suddenly declare that font editors supporting the UFO must support either editing or display of SVG.

> 2. Referencing multiple PNG files as glyph sources. If there is more than one image per glyph, a PPM attribute should be specified.

No. This was discussed during the UFO 3 development process. Long story short, multiple images means arbitrarily overlapping images and outlines. From there it is a slippery slope to turning GLIF into the Illustrator file format. Anyway, at that time I suggested a way for multiple images to be used in an editor that wants to support multiple images. I think that discussion was on the RoboFab list.

> What do you think?

I think I want those formats to be approved specs before I start writing support of them into the UFO spec. :-)

> I also have a question. The GLIF spec says that for the image element, the fileName attribute is "The image file name, including any file extension, not an absolute or relative path in the file system." -- does it mean that the strong assumption is that the PNG image file must reside in the same folder as its referencing GLIF file?

No.

"Image files referenced by glyphs in the UFO must be stored in the images directory.”

http://unifiedfontobject.org/versions/ufo3/images.html


Tal