Support needed for variable-COLRv1

[vv-monsalve]

@SophiaDesign reported

I am still puzzled with the same problem. Report (in github actions) says there should be exported font files, but there is nothing there still. Instead of a build script I have the makefile from the Google Fonts template.

Could you please point out (provide a link as a comment here) the Report where this has been said?. When inspecting the Actions tab, everything looks like they are working.

On the other hand, it is always helpful to run the exporting process directly from the Glyphs app to validate it is working from there. After trying to do so as a VF, Glyphs reports an issue regarding active instances.

And when trying to export static TTF there are other issues reported.

You would like to fix all the above to have exported fonts from the app and then try to run the make build again from the repo.

[SophiaDesign]

@vv-monsalve

Actions tab: Yes, it seems to all be working, which is what makes me think there should be font files in a Font folder, but I see none.

Exporting from Glyphs: I don't get any issues exporting any OTF, TTF or VF files from GF-Foldit.glyphs directly within Glyphs3. What did you use?

The VF instance in Glyphs file was disabled to avoid this ZeroDivisionError in build: https://github.com/SophiaDesign/GF-Foldit/runs/5888354333?check_suite_focus=true

[SophiaDesign]

FYI: Glyphs3 doesn't yet support exporting COLRv1 stuff.

[vv-monsalve]

Exporting from Glyphs: I don't get any issues exporting any OTF, TTF or VF files from GF-Foldit.glyphs directly within Glyphs3. What did you use?

Glyphs 3.0.5 (3120). Are you exporting VF from Glyphs app without any problem?

I've pulled now the files at commit 117f55b, and I'm still receiving the same instance warning trying to export the VF and the overlapping issues for the TTF.

Please fix the overlaps issue and update the sources so that I can run some local tests.

[SophiaDesign]

@vv-monsalve For the instance warning, you need to tick "active" on the variable instance in Font Info panel (Exports tab). After that it should export a variable font just fine.

Interesting, I tried a few times with and without exporting those two characters, but no overlap issues on my end.
I am using Glyphs 3.0.4. at the moment.

Link to Action tab "build" where it confirms output of font files succesful -- still don't see anything. Maybe I was wrong? I expected a Font folder to appear with the font outputs placed in it. Is that what was supposed to happen?

[vv-monsalve]

I've changed the config file to produce the VF, run the make build command locally, and I'm receiving this vf.
GF-Foldit[colr,wght].ttf.zip

When testing it on Samsa the colr axis seems to not be working yet (it doesn't variate).

Please inspect that file and check if it's working as expected now.

[vv-monsalve]

Link to Action tab "build" where it confirms output of font files succesful -- still don't see anything. Maybe I was wrong? I expected a Font folder to appear with the font outputs placed in it. Is that what was supposed to happen?

They are packaged in a zip file that you can find at the bottom of the Action run.

[SophiaDesign]

I've changed the config file to produce the VF, run the make build command locally, and I'm receiving this vf. GF-Foldit[colr,wght].ttf.zip

@khaledhosny Could you please confirm what you used to generate the working COLRv1 OTFs you sent me a while back? Was it make build? I tried using your Glyphs file (that you created the working COLRv1 OTFs from) for just making static TTF and OTF files, but I'm having the same results as Viviana – it doesn't show any colour features

Is there a reason your export needed to be OTFs? Is it possible to make TTF exports that are COLRv1? Currently there's also an issue to make OTF files via Github Actions. So the only thing working now is TTF export.

When testing it on Samsa the colr axis seems to not be working yet (it doesn't variate).

@vv-monsalve Thanks, we haven't figured out how to variate it yet. First issue to solve is get the color features working in exports.

[SophiaDesign]

Attaching files from Khaled.zip

[SophiaDesign]

Any idea what this could be:
make: *** No rule to make target 'Could', needed by 'build'. Stop.

I'm getting it from Github Actions (build error). Managed to export font files locally once using make build on GF-Foldit.glyphs file, but now having the same error (in terminal) after trying to use make build on GF-Foldit-Khaled.glyphs

[khaledhosny]

I used fontmake, and it still works:

$ fontmake "files from Khaled"/GF-Foldit-Khaled.glyphs -o otf
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs source
INFO:glyphsLib.classes:Parsing "files from Khaled/GF-Foldit-Khaled.glyphs" file into <GSFont>
INFO:fontmake.font_project:Building OTF for Foldit-Thin-Condensed
INFO:ufo2ft:Pre-processing glyphs
INFO:ufo2ft.filters.base:Running EraseOpenCornersFilter on Foldit-Thin-Condensed
INFO:ufo2ft.filters.base:Running DecomposeComponentsFilter on Foldit-Thin-Condensed
INFO:ufo2ft.filters.base:Running RemoveOverlapsFilter on Foldit-Thin-Condensed
INFO:ufo2ft:Building OpenType tables
INFO:ufo2ft.outlineCompiler:The copyright was normalized for storage in the CFF table and consequently some characters were dropped: 'Copyright 2021-2022 The Foldit Project Authors https:www.github.comsophiadesignFoldit'
INFO:ufo2ft.postProcessor:Subroutinizing CFF table with cffsubr
INFO:ufo2ft.postProcessor:Renaming glyphs to final production names
INFO:fontmake.font_project:Saving master_otf/Foldit-Thin-Condensed.otf
INFO:fontmake.font_project:Building OTF for Foldit-ExtraBold-Expanded
INFO:ufo2ft:Pre-processing glyphs
INFO:ufo2ft.filters.base:Running EraseOpenCornersFilter on Foldit-ExtraBold-Expanded
INFO:ufo2ft.filters.base:Running DecomposeComponentsFilter on Foldit-ExtraBold-Expanded
INFO:ufo2ft.filters.base:Running RemoveOverlapsFilter on Foldit-ExtraBold-Expanded
INFO:ufo2ft:Building OpenType tables
INFO:ufo2ft.outlineCompiler:The copyright was normalized for storage in the CFF table and consequently some characters were dropped: 'Copyright 2021-2022 The Foldit Project Authors https:www.github.comsophiadesignFoldit'
INFO:ufo2ft.postProcessor:Subroutinizing CFF table with cffsubr
INFO:ufo2ft.postProcessor:Renaming glyphs to final production names
INFO:fontmake.font_project:Saving master_otf/Foldit-ExtraBold-Expanded.otf

[SophiaDesign]

Variable export is also working with fontmake, but the outcome of the gradients is not as expected. Here is a comparison to the static exports:

Files for reference: Variable-export.zip
@khaledhosny

[vv-monsalve]

I'm getting it from Github Actions (build error). Managed to export font files locally once using make build on GF-Foldit.glyphs file, but now having the same error (in terminal) after trying to use make build on GF-Foldit-Khaled.glyphs

@SophiaDesign I've inspected the latest Action report, and it has the following Error Message on line 36:

fontmake.errors.FontmakeError: In 'GF-Foldit-Khaled-modified.glyphs': Loading Glyphs file failed: [Errno 2] No such file or directory: 'GF-Foldit-Khaled-modified.glyphs'

It means it hasn't found the file or directory.
After pulling the files at commit 12fe204 I've seen that there indeed is no glyphs file in the source directory.

[khaledhosny]

I have not created variable COLRv1 fonts yet, it is quite possible that it does not quite work yet. Best to bring the issue with @anthrotype or open an issue against FontTools.

[SophiaDesign]

Any idea what this could be: make: *** No rule to make target 'Could', needed by 'build'. Stop.

I can export locally now (with some gradient issues on the variable font export), but still receiving this error on Github Actions.

[anthrotype]

There's no support for variable COLRv1 in FontTools yet. Chrome also doesn't support it yet. I'll be working on adding support to fontTools.varLib in the coming weeks, produce a few test fonts so that FreeType/Skia/Chrome devs can start adding support. Thanks for reminding me about this project, I might use this for my own testing

[anthrotype]

Clarification: fonttools can decompile/compile COLRv1 with variations, only that there is no user-friendly API for building those yet. I plan to add support for merging COLRv1 masters in varlib.build similarly to how we do with GPOS

[anthrotype]

Also I'm not sure if FontGoggles supports variable COLRv1 yet, I remember it used to but the the spec was amended and it wasn't updated to match, but maybe that changed. /cc @justvanrossum

[anthrotype]

When testing it on Samsa the colr axis seems to not be working yet

they probably don't support variable COLRv1 either. It might be worth filing an issue upstream /cc @Lorp

[anthrotype]

(i just realised I'm pinging people but this is actually a private repo so I don't think they'll see my pings)

[anthrotype]

For reference, support for variable COLRv1 in fonttools is tracked here:
fonttools/fonttools#2328

this one is for fontgoggles: justvanrossum/fontgoggles#176

[anthrotype]

I see a bunch of .glyphs files in sources/ directory but also some master UFOs+designspace in master_ufo/ directory. Which one is the actual source that I can use to build a VF and test variable COLRv1?

[anthrotype]

well, both the .glyphs files in sources/ throw various errors (coming from glyphsLib), only the .designspace in master_ufo/ seems to build so I'll use that one. Maybe @khaledhosny has some local patches that he hasn't upstreamed yet that make glyphsLib work?

[SophiaDesign]

@anthrotype I can confirm with you that both FontGoggles and Axis-praxis (same as Samsa) support COLRv1 since last year, and since this year Chrome has started supporting it too.

UFO and DesignSpace files were generated locally from GF-Foldit-decomposed.glyphs file using fontmake in my terminal. If I'm honest, I only roughly understand how Github Actions work from working on this project, so I apologise for the messiness and current error on Actions – I just updated the repo, adding the correct source file into Sources folder

[anthrotype]

Yes, I know, I meant support for variable COLRv1, not simply COLRv1. The former is not supported anywhere that I know of right now

[davelab6]

@SophiaDesign maybe it would be good to make the repo public so more folks can participate

[Lorp]

@SophiaDesign just added me. Nice project.

When testing it on Samsa the colr axis seems to not be working yet

Indeed Samsa does not currently support any flavour of COLR. Funds permitting, I am keen to add COLRv0 and COLRv1 including the new variation features such as “component” rotation and variable start/end points for gradients, etc.

[justvanrossum]

Ouch, a typo in fonttools indeed:

https://github.com/fonttools/fonttools/blob/2a07518b700e1301b8b1d2d90fafdc0c6c966b60/Lib/fontTools/varLib/merger.py#L1429

[anthrotype]

Ouch indeed! Sorry!

[anthrotype]

try updating to fonttools 4.34.4 => https://github.com/fonttools/fonttools/releases/tag/4.34.4

[SophiaDesign]

@anthrotype I tested with fontmake and got

fontmake: Error: In 'Foldit-test.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because a list of objects had inconsistent lengths.
This happened while performing the following operation:
COLR.table.BaseGlyphList.BaseGlyphPaintRecord[0].Paint.Layers

The problem is likely to be in Foldit Thin-origin (base glyph 'O'):
Expected to see .Layers==4, instead saw 20

You can see the test file attached. It does not seem to have the identified problem in the Thin master. What could be the issue?
Foldit-test.glyphs.zip

[anthrotype]

The error is saying that glyph 'O' has different number of color layers across masters, isn't that true? It might be that the name of the reported master is not correct, but the underlying issue is the different number of layers, all non default masters have to have the same number of layers as the default master, at the individual glyph level.

[SophiaDesign]

On the Glyphs interface it looks like they all have the same number of layers. Is there any other way I can check this? @anthrotype

[anthrotype]

You could export .glyphs source to UFOs using fontmake -o ufo and then inspect the content of the master UFOs's lib.plist, the key named colorGlyphs, make sure the 'O' glyph has the same number of layers in all masters and if they make sense.. I'm actually on holiday until 18 July.

[justvanrossum]

The glyph /O in the ufo's all expand to four color layers, but somehow it expands to 20 color layers in Foldit-Thin-origin.ufo:

[vv-monsalve]

I wonder if this could be related to the incompatible linear gradient definitions in the various masters that Cosimo mentioned above? Have you inspected/solve this already?

but the underlying issue is the different number of layers, all non default masters have to have the same number of layers as the default master, at the individual glyph level.

And also to this. From what I've seen in the source file, there are only color layers and not a default master layer.

Perhaps @mekkablue could be of any help on how better to handle these Color gradients from the glyphs source file. Beyond what has been already reported in the forum (here, here and related to gradients in here)

[mekkablue]

Excuses for not having read the complete thread (TL). COLR/CPAL should have a fallback layer. In Glyphs, the COLR layers/glyphs derive their widths from the default master layer. Some renderers may require the fallback for reserving pixel space for rendering (otherwise your risk clipping).

COLRv1 support is in the works and will be rolled out in a few months the earliest. You can sign up for the beta tester program, ping me in the Glyphs forum with a DM.

[anthrotype]

COLR/CPAL should have a fallback layer. In Glyphs, the COLR layers/glyphs derive their widths from the default master layer. Some renderers may require the fallback for reserving pixel space for rendering (otherwise your risk clipping).

Yes, that is true for COLR version 0 on Safari / macOS, but for COLR version 1 it's no longer needed since there are distinct clipBox data in the COLRv1 table itself, and even when that is missing the renderers that do support v1, can figure out that at runtime

[SophiaDesign]

I wonder if this could be related to the incompatible linear gradient definitions in the various masters that Cosimo mentioned above? Have you inspected/solve this already?

Yep, all gradients should be compatible based on Cosimo's description.
Each gradient element has:

• the same number of colour stops
• exactly the same colours
• colour stops are pointing in the same direction

[khaledhosny]

@anthrotype I tested with fontmake and got

fontmake: Error: In 'Foldit-test.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because a list of objects had inconsistent lengths.
This happened while performing the following operation:
COLR.table.BaseGlyphList.BaseGlyphPaintRecord[0].Paint.Layers

The problem is likely to be in Foldit Thin-origin (base glyph 'O'):
Expected to see .Layers==4, instead saw 20

You can see the test file attached. It does not seem to have the identified problem in the Thin master. What could be the issue? Foldit-test.glyphs.zip

The Thin master has four extra color layers, these are the source of the error:

[SophiaDesign]

Thanks @khaledhosny, I found this mistake, but after removing these layers, the new exported font was black (no gradient) and did not display on FontGoggles. I wanted to take some time to have a better look, but if you have any ideas what this could be, would be really helpful.
Foldit-VF.ttf.zip

[SophiaDesign]

Jul-14-2022.17-46-39.mp4

[SophiaDesign]

Update: it's working, I just had to get the new FontGoggles (missed the release as I was on holiday until today).

We have a fully functional variable-gradient COLRv1 font here 🎉🎉🎉 Thank you everyone this is truly amazing

Jul-14-2022.18-07-44.mp4

[SophiaDesign]

Hello, just opening this up again, as I worked through the source file and there are a few glyphs left with issues, which I am not able to identify/fix on the Glyphs interface:

• M

fontmake: Error: In 'Foldit-decomposed.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation: COLR.ta
ble.BaseGlyphList.BaseGlyphPaintRecord[97].Paint.Layers[0].Paint.ColorLine.Col
orStop[1].PaletteIndex

The problem is likely to be in Foldit Thin-origin (base glyph 'M'):
Expected to see .PaletteIndex==4, instead saw 2

• circumflexhookabove (and glyphs using this component)

fontmake: Error: In 'Foldit-decomposed.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation: COLR.ta
ble.BaseGlyphList.BaseGlyphPaintRecord[244].Paint.Layers[5].Paint.ColorLine.Co
lorStop[1].PaletteIndex

The problem is likely to be in Foldit Thin-origin (base glyph 'ecircumflexhookabove'):
Expected to see .PaletteIndex==2, instead saw 4

• guillemeright

ERROR:fontmake.compatibility:Fonts had differing number of contours in glyph guillemetright.color0:
ERROR:fontmake.compatibility: * Foldit Thin-origin had 1
ERROR:fontmake.compatibility: * 7 fonts had 2
ERROR:fontmake.compatibility:Fonts had differing number of contours in glyph guillemetright.color1:
ERROR:fontmake.compatibility: * Foldit Thin-origin, Foldit Light had 1
ERROR:fontmake.compatibility: * Foldit Regular, Foldit Medium, Foldit SemiBold, Foldit Bold, Foldit ExtraBold-origin, Foldit Black-origin had 2
ERROR:fontmake.compatibility:Fonts had differing number of contours in glyph guillemetright.color2:
ERROR:fontmake.compatibility: * Foldit Thin-origin had 2
ERROR:fontmake.compatibility: * Foldit Light had 1

• trademark

fontmake: Error: In 'Foldit-decomposed.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation: COLR.ta
ble.BaseGlyphList.BaseGlyphPaintRecord[481].Paint.Layers[0].Paint.ColorLine.Co
lorStop[1].PaletteIndex

The problem is likely to be in Foldit Thin-origin (base glyph 'trademark'):
Expected to see .PaletteIndex==4, instead saw 2

• Won

fontmake: Error: In 'Foldit-decomposed.glyphs' -> 'master_ufo/Foldit.designspace': Generating fonts from Designspace failed: 

Couldn't merge the fonts, because some values were different, but should have
been the same. This happened while performing the following operation: COLR.ta
ble.BaseGlyphList.BaseGlyphPaintRecord[508].Paint.Layers[4].Paint.ColorLine.Co
lorStop[0].PaletteIndex

The problem is likely to be in Foldit Thin-origin (base glyph 'won'):
Expected to see .PaletteIndex==5, instead saw 1

All are marked in red in the Foldit-origin.glyphs file and have been removed from Foldit-decomposed.glyphs file to test the exporting.

I'm looking for any suggestions: What else can I use to find out where and what the compatibility issue is with the glyphs listed above?

Files: Foldit-files-20July2022.zip
These are Source files + Working variable-gradient font (but with missing glyphs)

[khaledhosny]

The problem is likely to be in Foldit Thin-origin (base glyph 'M'):
Expected to see .PaletteIndex==4, instead saw 2

The PaletteIndex errors like these mean there is a mismatch in colors between the masters (even if it is very slight variation). Make sure all colors have the same hex value across layers.

[SophiaDesign]

All glyphs are fixed except Won currency symbol. Could too many colour stops on a single gradient cause an issue?

[SophiaDesign]

Could not find/fix the Won glyph issue in Glyphs app, but I changed the UFO file: Foldit-UFO.zip

I am not able to use the UFOs to create a variable font using fontmake:
fontmake: error: Glyphs or designspace source required for variable font

[vv-monsalve]

I am not able to use the UFOs to create a variable font using fontmake:

You should provide a .designspace file to build a VF. A base one is generated and included by glyphsLibin the master_ufo dir when converting the .glyphs source to master-ufos + designspace.

You would like to read Fontmake's Trubleshooting doc for more details.

[vv-monsalve]

All glyphs are fixed except Won currency symbol. Could too many colour stops on a single gradient cause an issue?

Are you receiving a particular message about it?

In any case, simplifying as much as possible is always helpful. The Won glyph does have many outlines + stop gradients, and there are more masters than ideal in the file, too (as mentioned in the design space issue.) I would suggest first reducing the number of masters, it will also simplify the designspace before you use it to build the font.

Otho, please inspect the comment on the Outlines quality issue.

[SophiaDesign]

@vv-monsalve The issue with Won.glyph remained the same as posted here above. It failed to create a designspace file, so I am left with UFO files.

It suggests the Foldit Thin has an incompatibility issue on one of the color palette index. I modified this manually in the Foldit-Thin-origin.ufo file based on suggestion in the error message. Attached here but I don't know how to go from here unfortunately.

I don't see any colour point differences in the masters using Glyphs. I assume the issue will be in one of the crossbars as there was no issue with W.glyph. It's possible that I simply can't spot the difference as I worked on (and stared at) it for too long.

[vv-monsalve]

@vv-monsalve The issue with Won.glyph remained the same as posted here above. It failed to create a designspace file, so I am left with UFO files.

In that case, there should be the same mismatching colors that Khaled mentioned above.

The link to the error message is not working, so I can't inspect it.

I assume the issue will be in one of the crossbars as there was no issue with W.glyph

You could generate a temporary glyphs file with only that glyph where you can try to confirm the export step by step. Adding one crossbar at a time so that it would tell you which is failing. In this regard, it would be really helpful for you to reduce the number of masters as said in the other issue.

[SophiaDesign]

Thanks @vv-monsalve, Won.glyph is now fixed. The issue was indeed me not being able to see from staring at it for too long, and it was not even in the crossbars, which also means that higher number of color-stops on the gradient is not an issue