Closed Bug 1788945 Opened 2 years ago Closed 2 years ago

Duplicate CPAL palette makes COLR font display incorrectly


(Core :: Graphics: Text, defect)

Firefox 104





(Reporter: cosimo, Unassigned)




(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36

Steps to reproduce:

I loaded the sample html page of "Bungee Color" font, a popular COLR/CPAL font by David Jonathan Ross. Before I contributed a patch to fix this upstream, this font contained a CPAL table with two duplicate color palettes (containing the same colors). Below are the commands to clone the project from my github fork and checkout the fonts and the sample.html file to open up in FireFox.
I tested FireFox 104.0.1 on macOS 12.5.1, as well as the latest FireFox Nightly 106.0a1 (2022-09-01). Both reproduce the issue described below:

$ git clone
$ cd Bungee
$ git checkout bb29250e
$ open -a FireFox fonts/Bungee_Color_Fonts/COLRv0/sample.html

Actual results:

The Bungee Color (COLR version 0) font renders all grey, using colors that are not specified in its CPAL table.

Expected results:

Bungee's default CPAL color palette should render the font in red, with a white hairline along the skeleton of the glyphs.

To see the expected results, you can load the fixed fonts (without the duplicate CPAL palette) from the same anthrotype/Bungee git repository, by switching to the "colrv0-ff-bug" branch and reloading the same "sample.html (I find that I need to quit and relaunch FireFox otherwise it doesn't reload the updated local font).

$ git checkout colrv0-ff-bug
$ open -a FireFox fonts/Bungee_Color_Fonts/COLRv0/sample.html

Correction: I cannot reproduce the issue when using the latest FireFox Nightly 106.0a1 (2022-09-01). I was under the impression I did, but tried again to double check and could not reproduce this time, apologies. The issue still stands for the stable FF 104.0.1.

Turns out this was fixed in bug 1740530. One of the things I noticed when updating the color font code to add COLRv1 support was that the CPAL table validation we do (as part of determining whether a font has usable color glyphs) was somewhat broken.

In the font with the duplicate palette, what's actually happening is that both palettes point to the same color records (i.e. they're overlapping); you can tell this because listing the font tables with ttx -l shows that the CPAL in the "bad" font is only 2 bytes larger than the "fixed" version. The old CPAL validation code didn't account for that properly, so it believed the table to be invalid, and we didn't treat it as a color font.

The grayscale rendering is what happens in that case, because Core Text still tries to render color glyphs but we composite them as grayscale.

So -- interesting example, thanks! Fortunately, it's already fixed for FF105.

I'm closing this as Fixed (specifically, by bug 1740530 patch 4) rather than marking as Duplicate, as that bug was about implementing COLRv1 whereas this was a pre-existing defect affecting COLRv0 fonts.

Closed: 2 years ago
Depends on: 1740530
Resolution: --- → FIXED

Excellent, thank you!

You need to log in before you can comment on or make changes to this bug.