"If DirectWrite supports all color formats, how come not all browsers support them?"

Peter Constable

Somebody asked me this question and found my answer helpful, so I thought I'd share it here. As a reminder, the OpenType spec defines four formats for colour glyph, using the COLR table, the SVG table, the CBDT table, or the 'sbix' table.

In traditional, non-colour text display, a layout engine resolves a string to an array of glyphs that then get rasterized (by a TrueType or CFF/CFF2 rasterizer), and then the resulting bitmap will get a single colour property assigned and passed to a graphics layer to present on some surface. (There may be some font-smoothing filtering somewhere along the way, but we an skip that for this discussion.) So, let's consider what changes when using a colour font: The different colour formats require different implementations with different interactions between text layout and graphics libraries.

The COLR format is in one sense the simplest for an existing text layout / graphics interaction: instead of a single array of (TT or CFF) glyphs that get rasterized and presented in one colour (which could be any colour), there is an array of glyph arrays that each get drawn with different colours and layered on top of each other. So, it's very similar to drawing different single-colour strings.

The CBDT and sbix formats are conceptually simple, but require a little more of a change in the implementation: from a glyph array, you divide this into two different glyph arrays (not unlike splitting into layers for COLR), but then also send these down two different paths: one set of glyphs will be handled normally, using the rasterizer pipeline, but the other will be handled in an entirely different manner -- not sent to the rasterizer but directly to a 2D graphics/imaging library. (Fortunately, because CBDT and sbix use commonly-used bitmap formats, the graphics/imaging library will undoubtedly support those bitmaps.)

The SVG format is even more different: The glyph array is divided into two different arrays as for CBDT/sbix and sent through different pipelines. But now instead of commonly-supported bitmap formats, you need a graphics library capable of displaying SVG documents.

DirectWrite does have support for all of the colour formats, but for CBDT, sbix and SVG, DirectWrite is actually doing very limited work: it can reports which glyphs are handled with normal rasterization versus the glyphs that use an alternate format, and it can provide the separate glyph arrays corresponding to each format, and it can return to the app the CBDT/sbix/SVG data from the font. But the app then needs to call into an appropriate graphics library to display those other data formats. Direct2D does provide support for those other formats, including SVG, but apps would need to be updated specifically to handle processing with those other formats -- it doesn't just happen unilaterally by the platform.

So, if some browser supports one format but not others, that will be because it hasn't explicitly been updated to support those other formats.

Thomas Phinney

Feel free to correct me if I am wrong, but I just wanted to make a “short version”:

It is not “free” for a Windows app to support color fonts. Not only must it handle several very different types of data being returned, but it must also handle rendering of different glyph formats. For b&w fonts, such glyph rendering can be entirely handled by the OS, but not so for color fonts.

Grzegorz Luk (gluk)

Peter Constable said:

The SVG format is even more different: The glyph array is divided into two different arrays as for CBDT/sbix and sent through different pipelines. But now instead of commonly-supported bitmap formats, you need a graphics library capable of displaying SVG documents.

I saw this question as "Edge and Chrome on Windows 10 use DirectWrite, which supports all four color font formats, yet in Chrome only one format is rendered. Why?"
As far as I know Chrome use already a library capable of displaying SVG documents.
It's simple way to support OpenTypeSVG?

Roel Nieskens

All the stuff needed to draw SVG or bitmaps is indeed present in a browser, and a non-browser-developer like me wonders why they just don't tie these technologies together. But when asking browser developers or reading feature requests/tracker issues about adding support, the general response is "we've got more important stuff to implement." Hyphenation, CSS for variable font, updating the SVG libraries to the latest spec, etc.

Maybe making some noise would speed up development?

Peter Constable

gluk said:

[snip]

I saw this question as "Edge and Chrome on Windows 10 use DirectWrite, which supports all four color font formats, yet in Chrome only one format is rendered. Why?"
As far as I know Chrome use already a library capable of displaying SVG documents.
It's simple way to support OpenTypeSVG?

We might suppose it wouldn't be a huge task, given that they have SVG support already. But it doesn't just happen for free, which was what I was explaining.

Sergey Malkin

If you use D2D for rendering, this is not huge task at all. I implemented support for color fonts in Edge, so I know . Depending on how you format your code, this will be only 100 lines of code. And this is done on the lowest level of glyph rendering, so no other code in layout or rendering is affected.

DWrite/D2D does almost everything for you: instead of just rendering glyph run with solid color you call once to break it into pieces of the same format and then loop through pieces drawing each with appropriate D2D function call.

Re: implementing SVG color fonts in Chrome. Don't forget that almost every browser vendor is also OS vendor and operating system, being it Windows, Android, or iOS, is likely to require consistent support for SVG outside of browser. So they need to factor out this code carefully for any application to use. With this requirement, reusing existing SVG layout from browser may not be as simple as it seems. It is integrated with html parser, object model, layout, or rendering, so simple SVG rendering may bring too many dependencies into OS graphics layer. 

Thanks,
Sergey