COLR, SVG tables: sharing color palettes

[Sairus Patel]

As part of what seemed to be a growing consensus at TypeCon and in the community around the co-existence of both scalable color font proposals (SVG and COLR) within the OFF/OT specs, representatives from both proposals have been looking into having both color font technologies share the same color palettes (the CPAL table).

This way, CSS markup (for example) can simply refer to the palette-index to be used for the text, instead of separate COLR-palette-index and SVG-palette-index values.

And this way, any extensions to the CPAL, e.g. name IDs for color palette entries (in the current SVG table spec), or perhaps non-sRGB color spaces in the future can be equally available to both technologies.

This kind of sharing of course is what OFF/OT is very good at, with the cmap and GSUB for example being shared across glyph technologies and the text engine dispatching the positioned glyph IDs at the very last moment, as it were, to either a CFF or TT (or SVG) renderer.

So the CPAL is able be shared, but its worth noting the following technical differences in color platte approach:

- With COLR, the CPAL table is required. It contains *all colors* used by multicolored glyphs, with a special notation for foreground color (no alpha) in the COLR table itself.

- With SVG, the CPAL table would be optional. If present it would contain the values of any *color variables* used by the SVG glyph descriptions, with the SVG glyph descriptions being able to express their own explicit or "hard-coded" colors as well. These "hard-coded" colors do not vary by palette selection and would not be in the CPAL table. Foreground color is expressed by the context-fill and context-fill-opacity (alpha) attributes in the SVG glyph descriptions.

Sharing the CPAL would mean the SVG table spec would need to be adjusted, but disruption should be minimal: we'll simply rename the offsetToColorPalettes ULONG to be 'reserved;­ set to 0'; it could perhaps be used as a flags field in the future. This way, current implementations would not try to read off the end of the revised table, though of course they'd need to be updated to support CPAL.

Thanks to all those who've encouraged this shared approach. We'll have more details about this for your review shortly.

Sairus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20130906/180416e4/attachment.html>