Cairo Play glyphmapping issue

[RosaWagner]

Weirdest glyphmapping in Cairo Play: for example A -> AEacute, é -> ebreve. Happens in VF from upstream repo + VF in GF zip.
Although when typing in GF specimen page, the font behaves correctly.
The issue cannot be reproduced with Cairo although the fonts are built from the same source.

cc @yanone @m4rc1e

[m4rc1e]

I don't understand the issue. Are you saying that the "A" glyph is mapped to the "Aacute" unicode? If I check the font, that isn't the case.

Are you checking the fonts in applications which support COLR tables?

[RosaWagner]

Yeah by glyphmapping I meant, I type a letter and another one is displayed. To be more precise, it sometimes displays the next glyph ID of the one typed. This is the basic alphabet:

I checked it in different apps in Mac; textEdit, Indesign, Word. I know some don't support the COLR table, but they are supposed to display the proper glyphs with or without color. Nabla doesn't have this issue, that is why I think something is happening with Cairo Play.

[yanone]

I made these on my old computer which is at home. I can check soon when I'm back. Though I didn't check for macOS compatibility explicitly, I have a feeling I should have seen that while working on it, which would suggest a macOS issue. I'll let you know.

[yanone]

FLTR: Brave on latest macOS, Safari on latest macOS, latest Edge on Windows. Only Safari shows the anomaly (and all other native macOS apps).

[yanone]

Although when typing in GF specimen page, the font behaves correctly.

Not in Safari. This is a legitimate bus crash:

[yanone]

Although the behaviour above is actually different from Rosalie's report where COLR glyphs were showing the wrong GID. In the Safari screenshot, the glyphs are actually the correct ones but rendered wrong.

Basically here, COLR glyphs are shown in Regular weight with no variations applied. (The color in the second letter from right is a separate mark while all letters with red dots are complete COLR glyphs)

[RosaWagner]

I am no expert in color font, but I wouldn't be surprised if one reads the COLR table and the other one the SVG table. The SVG table was added using maximum_color script; can it be that there is something wrong with that particular process creating inconsistencies?

[yanone]

It gets worse. This is Safari on 10.15.7 Catalina, accidentally in dark mode because we use this computer at home to watch movies:

So not a newer macOS bug. Can't say more at the moment. Could be our fault, or Apple's.

[anthrotype]

it might be the SVG table (generated by nanoemoji's maximum_color) that is at fault. Try to see if by removing 'SVG ' table, the font works.
Cairo Play looks like a COLR version 0 (only flat colors) font, so in theory I would not expect it to also have an SVG table, because COLRv0 should work mostly everywhere as SVG also works, and is more compact, variable-friendly, just better for flat-only colors.

I thought we added a fontbakery check that only COLRv1 fonts should go through maximum_color, no?

[anthrotype]

Ouch, yes. it's the SVG table...

BTW, to quickly strip a table using ttx do:

$ ttx -x 'SVG ' -o CairoPlay-Regular_nosvg.ttx CairoPlay-Regular.ttf
$ ttx -o CairoPlay-Regular_nosvg.ttf CairoPlay-Regular_nosvg.ttx

[yanone]

I thought we added a fontbakery check that only COLRv1 fonts should go through maximum_color, no?

Yes, but those checks and the Arabic color fonts were produced around the same time, so it's not certain that the checks were already in place for Cairo. Also, some of the fonts were messed with by Rod in my absence during last summer and uploaded bypassing our review process. Not impossible that Cairo was one of them.

@RosaWagner @m4rc1e I'll attempt an update asap as I'm already familiar with the project.

[anthrotype]

To fix this issue, I'd recommend that you rebuild the fonts from source and this time not use maximum_color at all, because we do not want COLRv0 fonts like these to also have an SVG table, even more so when they are variable (for SVG is not)

[m4rc1e]

gftools builder should only add svg tables to fonts with colr v1 tables, https://github.com/googlefonts/gftools/blob/main/Lib/gftools/fix.py#L694-L709

You may need to update Cairo Play's dependencies if this isn't happening.

[anthrotype]

I just cloned the Cairo repository and it looks like the variable font in this directory of pre-built fonts does have an SVG table, which Yanone committed so this time it doesn't look like the fonts were post-processed by us:
https://github.com/Gue3bara/Cairo/tree/master/fonts/CairoPlay/variable

by the way, I couldn't find a CairoPlay.glyphs source file in that repo... How do I build it?