Windows 8.1 Preview color font support

Si_Daniels's picture

Cross-posting this message from the OpenType / MPEG Open Font Format lists.

Dear OpenType /MPEG OFF List members,

Today at the Microsoft //build conference in San Francisco, Dan McLachlan of our Graphics team will talk about Windows 8.1 approach to color fonts. We'd like to thank P22, Monotype, The Font Bureau and FontFont for providing us with font data that we were able to use to test this approach.

Our implementation uses a base glyph for reference, which would be used for non-color situations. A data structure, implemented as a new 'COLR' table in OpenType, breaks down the base glyph into a separate set of glyphs, each with its own z-order and single color reference. The color references are handled has palette indices, with a separate table, 'CPAL' in OpenType that resolves the RGBA colors actually used for the glyph.

We plan to submit documentation on this approach for standardization through the ISO MPEG process (for inclusion in the Open Font Format) within the next few weeks. However, if you'd like to see the approach in practice you can download the Windows 8.1 Preview and see a color font (Segoe UI Emoji) used on the touch enabled keyboard.

I'll also be giving a talk at TypeCon on this, hope to see some of you there.

Thanks, Michelle

A video of the session should be posted here at some point... http://channel9.msdn.com/Events/Build/2013/3-191

Cheers, Si

hrant's picture

{To Follow}
{With Glee}

Grant Hutchinson's picture

Si, is there a link available for the original mailing list post?

MichellePerham's picture

Here is a link:
http://tech.groups.yahoo.com/group/mpeg-OTspec/message/986

But you probably need to be a member of the group to see it.

Grant Hutchinson's picture

Thanks, Michelle. That’s what it looks like.

John Hudson's picture

A data structure, implemented as a new 'COLR' table in OpenType, breaks down the base glyph into a separate set of glyphs, each with its own z-order and single color reference. The color references are handled [as] palette indices, with a separate table, 'CPAL' in OpenType that resolves the RGBA colors actually used for the glyph.

That sounds tidy.

How are the separate colour glyphs combined and aligned correctly?

Transparency levels would be cool, so designers could do funky things with overlaying shapes. Any support for that, or are all CPAL values solid colours?

Si_Daniels's picture

We'll post full specs soon. We hoped to have them to coincide with the event but Greg Hitchcock is on vacation and we had other higher priorities before he left.

John Hudson's picture

Here, with thanks to Si, is an illustration of the basic approach, as implemented in the MS colour emoji font included in the Win8.1 preview. The 'base glyph' is the single-colour representation of the character (in this case U+1F630), and the three COLR table glyphs are mapped from it. Note that each COLR table glyph shares the advance width of the base glyph, and the outlines are arranged so as to appear in the correct positions when the widths are overlayed (presumably a DirectX layout engine operation).


Each of the COLR table glyphs would be assigned a colour reference, mapped to an RGBA value in the CPAL table (I presume this is simply an efficiency, rather than storing the RGBA values directly in the COLR table).

It's an admirably simple system, at least on the font side. I can imagine all sorts of tricky business on the rendering side to deal with the antialiasing.

PabloImpallari's picture

Those new tables COLR and CPAL looks like a very clever solution.

John illustration reminded me of the Underware Sauna dingbats system:
http://underware.nl/fonts/sauna/features/dingbats/dingbats#p5

Rob O. Font's picture

Assuming this uses OT compatible contours, i'm all for new tables.

Are there missing parts off the grab, in that example, or contours being stroked?

John Hudson's picture

No missing parts. The base glyph is an outlined b/w representation of the emoji. The colour version is made up of simple, un-outlined bits. I don't have access to the COLR and CPAL tables, so I'm not sure what the colours used are, but I presume it is something like this:

Si_Daniels's picture

I don't seem to be able to upload a screen grab at this time, but those colors are close to those on the touch keyboard. :-)

John Hudson's picture

This is going to be my first use of the new tables: something I've been waiting to do for 15 years.

[Apologies for any spelling errors; the original manuscript is damaged and some of the characters quite hard to identify.]

Rob O. Font's picture

"The base glyph is an outlined b/w representation of the emoji."

I know but where's the w gonna come from in this emoji. Color has three opponents: size, device and user preferences. So don't we have a MUST for legible b/w from color?

MichellePerham's picture

Dan's demo is now live:
http://channel9.msdn.com/Events/Build/2013/3-191

He starts talking about color fonts about 9 minutes into the talk. I wasn't able to be there in person, so I'm seeing the talk for the first time myself. Very exciting!

John Hudson's picture

I know but where's the w gonna come from in this emoji.

In this particular emoji, the only 'white' is the background, which is just the same as for any other glyph. If one were designing a colour font which involved white counters, one would have a couple of different options, depending whether you wanted the counter to be the background colour or explicitly white. For the first, you would need to design the COLR glyphs with knock-through counters. For the second you would create counter outlines as separater COLR glyphs and assign a white colour to them (I'm guessing this is what happens for, e.g. the teeth in grinning face emoji, since you want the teeth to be white regardless of the background colour).

If you're using the knock-through approach to have background colour counters, then of course things may look crap if the glyph is displayed on an inappropriately coloured background, but that's true of regular fonts too.

So don't we have a MUST for legible b/w from color?

The legible b/w is the base glyph. I'm guessing that there be accessibility options to disable colour font display for people with colour-blindness.

This colour font scheme, as I understand, does not allow for user preference in the selection of colours. It's an explicit colour model in which the colour is determined by the font maker, not by the user. That said, the COLR table structure would seem to permit the possibility of CPAL overrides if that were something software makers saw a value in supporting. So, for instance, the COLR table might split representation of a character into three glyphs, assigned colour references of 1, 2 and 3. Those colour references would normally be mapped to specific colours in the CPAL table, but it seems to me that a piece of software could interrupt at that stage and allow the user to specify colour mappings for those references that differ from what the font maker intended. I don't know how likely that is in terms of anyone bothering to do it, but it would seem to be possible.

Sylph's picture

What manuscript is that from?

John Hudson's picture

Interaction between OpenType Layout GSUB features and COLR decompositions could be fun. It would probably require multiple, variant base glyphs with separate decompositions, but then one could do things like contextually changing colours or assigning different colour patterns to Stylistic Sets.

Rob O. Font's picture

Yikes! I see the b/w glyph is complete.

>This colour font scheme, as I understand, does not allow for user preference in the selection of colours.

Along the way on this had a co-worker scramble up the font menu UI to "load up" the cursor with multiple fonts, defining the layering and colors just like any other font menu but with multiple fonts being specced.

That'd work with these color fonts, I think, if there is a color called "user choice" which, with the cooperation of apps, triggered interaction.

But I wonder if interaction just on font color is something software makers might see a value in supporting. Maybe not. But if ANIM and TIME tables were added, then all kinds of support might break out, (and then, once SIZE is surrounded by trouble without coming into being...) :)

John Hudson's picture

But I wonder if interaction just on font color is something software makers might see a value in supporting. Maybe not.

It's troubling, because while I can see making the colouring of something like emoji explicit in the font design, once we get into chromatic letterforms this approach, where the font maker defines the colours to be used, will be unnecessarily limited.

Theunis de Jong's picture

I would hazard that drawing colorized characters is not going to transfer well over to the typesetting area, and will be strictly limited to applications such as web browsers and messaging apps.

You would need a 'toggle' option to switch from B/W to colorized fonts. And then the colors appear as RGB in your output file. Conversion to CMYK should not be a problem in most workflows, but you might want custom spot colors. Perhaps one would want an option to get the 'exploded' emoji -- all separate parts, to be colored individually.

Nevertheless: from a technical point of view, this solution is superior to the ugly scaling bitmaps we've seen so far. Except now the target audience (the Instant Messaging Generation) is going to ask for "eye candy" such as gradients, transparency, animation ... sounds ... 😭 (animated and with "boo-hoo" sound clip).

Rob O. Font's picture

>...colorized characters is not going to transfer well over to the typesetting area...

With all due respect, I estimate having made 678 fonts for chromatic use in the typesetting area, (another 345,789 were abandoned ideas and 65 missing in inaction.) They are hard to use, especially with multiple size masters, but we and 1,000s of others, have made them for print. So maybe I misunderstand your point.

What is true though, is that none of the proposals have room for user choice beyond which font or which glyph. Right? So it's hard not to agree that the web is where this is going to happen for either print or online use. As long as the format can store the separated stack, we can offer a simple interface, they can edit the colors. 3 steps instead of 2.

Without "user choice", I'm thinking of an app that automatically pops a menu, if there's an all white cpal. ;)

Si_Daniels's picture

Two quick clarifications. I believe the lower level DirectWrite APIs give the developer the ability to define their own palette colors. Secondly the Segoe UI Emoji font in the Windows 8.1 Preview includes two palettes, one for when the emoji are displayed on a dark background (eg. the touch keyboard key caps) and one used when they are displayed on a light background. But as with many font related features, building UI and mark up to expose them is the hardest part.

For traditional chromatic fonts, each layer (color) could also be exposed as separate, distinct stylistic sets, which would provide the level of customization needed by the high-end professionals.

Cheers, Si

Arthus's picture

Now this seems like some sleepless nights up ahead... And a pc for testing...

I expect the tested glyphs have a slight overlay with each color 'layer' (can't see it on the previews though) to prevent anti aliasing letting other colors seeping through. Or they should be hinted accordingly I guess?

nemo's picture

I’d have liked to have seen an optional ‘interpolate’ flag for some layers, to allow emulation of the kind of smooth shading the bitmap fonts enjoy.

It will be interesting to see how such fonts are used in PDLs such as PDF. I imagine they are deconstructed into separate overlaid glyphs.

lorp's picture

John says: “… the user to specify colour mappings for those references that differ from what the font maker intended. I don't know how likely that is in terms of anyone bothering to do it…”

I think it could prove rather convenient:

http://www.myfonts.com/fonts/hwt/american-chromatic/
http://www.photolettering.com/letterer/
http://www.typography.com/fonts/shades/overview/
http://blog.fontdeck.com/post/8383559711/chromaticfonts
http://www.adobe.com/type/browser/html/readmes/ZebrawoodStdReadMe.pdf

For symbol fonts too, one can easily imagine a colour version of the Maki font that is proving popular in cartography:

http://www.mapbox.com/maki/

In a colour version it would make sense to colour all water (there are 4 glyphs containing water in the font) with the same palette index, such that it could be altered font-wide. An organization having a green or blue in their identity could thereby tint all water in Maki to match.

Implementation in CSS for colour webfonts can be quite easily imagined. For example, to change the background colour of all the emoji faces (which use, say, palette index 3) from yellow to pink across all emoji faces you might do something like:

font-feature-settings: "palette" 3 #ffcccc;

- Laurence

John Hudson's picture

Appropriate to today's holiday in the US, here is a sample of a colour font from 1857, shown in a specimen of types from the Philadelphia firm of L. Johnson & Co. (a copy of this rare specimen is currently available for purchase from Collinge & Clark).

This is another example of a font for which it wouldn't make much sense to use colours other than these. Unless you're Jasper Johns.

nemo's picture

I haven’t seen any documentation of the tables but the contents are mostly straightforward:

The COLR table describes the layers that replace the uncoloured version of a glyph. Three longs hold the number of glyphs, the offset to the glyph array and the offset to the layer array. Then there’s a short holding the number of entries in the layers array.

The glyph array comprises three shorts, the GID to replace, the index into the layer array and the number of layers in this glyph (consecutive entries in the layers array).

The layers array comprises two shorts, the GID representing that layer component glyph and the colour palette index.

The CPAL table holds the colour palette and is slightly more mysterious. The header comprises a long (0x2c), a short (2 – number of shorts per entry or colour format?) and a short which is the number of entries in the palette. Then there’s a long of the offset to the palette array, then that 0x2c long again.

The palette array (for this format?) comprises four bytes – R, G, B, A where A=255 means solid.

So it’s all pretty trivial. Layering must occur after any GSUB substitutions, obviously, not that they’re likely. Other colour formats may be possible (CMYK, Lab etc) but there’s no reason why software can’t decompose the layers and apply whatever colours it likes to the layer glyphs.

A note on efficiency: The Segoe UI Emoji font in Windows 8.1 could be more tightly defined – the repetitions in the palette indicate a lack of automation but more wastefully there are many cases where whole glyphs are repeated – a colour layer being identical to the monochrome original for example, or layer elements being repeated from glyph to glyph.

As can be seen, the COLR table itself doesn’t place any such restrictions on the arrangement or ordering of the glyphs themselves. There’s also some slight inconsistency regarding overprint, or overlap. Some layers overlap quite happily if composed in the correct order, others are designed with knockouts and could be composed in any order. Odd.

I’m not sure the alpha is much use beyond shadows, as any colour effects could have been decomposed and as I said before, I’d have liked to have seen optional interpolation between layers to achieve some degree of smooth shading, but it may be that a more complex format of CPAL would allow gradients to be defined, which may be enough.

Microsoft’s current love affair with flat slabs of colour will not last forever.

lorp's picture

Thanks for the timely example, John. You write “This is another example of a font for which it wouldn't make much sense to use colours other than these”. I disagree. While it might not make much sense to use colours other than “red”, “white” and “blue”, it makes a lot of sense to allow the user to choose the precise shades of each, and to decide whether the white should be (opaque) white or transparent.

dezcom's picture

[follow]

Rob O. Font's picture

A color font format, or a colored font format? In any case, this step at least addresses the issue of coordinate crowding.

russellm's picture

US Federal government colour specifications are defined in a specifications document called "Federal Standard 595B". You can buy their colour swatch fan book(s), but you are still stuck having to approximate with more common Graphic colour standards like Pantone. ADA "Accessible" blue "shall be equal to Color No. 15090 in Federal Standard 595B" Or, Pantone 300 is close enough.

lorp's picture

John wrote: “But surely the white stars and bars are meant to be solid white, and not transparent.”

They’re (nicely) transparent in your own example!

vinceconnare's picture

I made my QuickDraw GX font at Apple GX font Safari out of Compugraphic's Stars&Stripes font and it morphed into a bomb and then exploded. It would make a good colourful font today for an Al Jazeera fourth of July commercial.

Erik and Just won with their typewriter ribbon changing Trixie font but they won a booby prize of a Powerbook 100 that would catch on fire.

erwindenissen's picture

We've just released FontCreator 7.5 which supports the new scalable color font extension ('COLR' and 'CPAL' tables).

So people who like to learn more about this extension, can use FontCreator to see how color fonts work, and how to design/construct them.

You can see a video here:
http://www.high-logic.com/

gasyoun's picture

@John Hudson
Could yo show a small Nagari sample, please, with dandas and bindu's in red ink?

Syndicate content Syndicate content