I’ve been trying to find workflows for working with colorfonts, and I find that there doesn’t seem a good way to create layers that are the same across all glyphs.
The COLR layers don’t even seem to carry over into component glyphs.
For this font I’ve designed all the component glyphs and would like to create a layer for each .001 and .002 version of that particular glyphs with a specific COLR setting, but the monkey work is just gruelling at the moment.
When I select one glyph where I know it has five layers, it shows the layers, but if I make a selection where I still know all the different glyphs have five layers, I see nothing, I can’t set any of the layers to a specific color in the COLR palette either when I select many because it doesn’t show the layers in the layer panel.
The components should get the colors on export. But if you like the same two or tree colors per glyph, try this: Creating a layered color font | Glyphs .
It’s doesn’t work for me for a some reason. All the components become just fallback black color. Exported from both Glyphs 3.1.2 and Glyphs 3.2. Tested on Photoshop, Firefox, Safari, Chrome. Glyphs without components are fine but composites doesn’t get the colors. I also tried to export only SVG or only COLR/CPAL, result the same.
What may be a reason?
This issue is related only to Color Palette layers (COLR/CPAL).
And there is no issue with Color layer (OpenType-SVG).
Here’s an export settings to cover both tables:
For example, /oacute composed from /o that have Color Palette layers 12, 15, 8, 1, and from /acutecomb that have Color Palette layer 13. So on export it should be combined to layers 12, 15, 8, 1, 13, so far I understand. But it doesn’t.
I also tried to manually add the Color Palette layers to /oacute. So when I added layers from /o (12, 15, 8, 1), they are was automatically filled with their color components. Fine. But when I added the layer from /acutecomb (13) it was just empty. In general, it works better on export (components are exported in color just without acutecomb), but then the sense of components itself is gone. So not sure it is a right way.
Does the (for example) /oacute have exactly the same color layers as the separate components? Do you use any stroke effects (only causes issues with variable exports).
And the colours preview properly in Glyphs? And when exported, how about with the font-preview, or through a third-party program such as Fontgoggles?
Can you send me a sample file?
Sent in a private message.
Hi Arthur. There are no strokes or effects, just solid fill colors.
I tried same Color Palette layers (see an option 3 below).
Here’s a few different ways I tried (in Glyphs 3.1.2):
Glyph → Create Composite. Important moment – base glyph and mark glyph have different Color Palette layers and their count, not the same. The result was just base Master layer in a black color. That mean, the Color Palette layers are not translated automatically to composed glyph. And I don’t know if they should.A glyphs builded with components are displayed in a black in the Font tab preview and Preview panel, however the glyphs without components are displayed in color.
The font file preview (I saw it on macOS in Finder, and also checked in the Font Book) show just English alphabet and default numbers (which doesn’t have components), and these glyphs are in color in preview. But I can’t check the preview for components ones, so I checked their render directly on the web browsers and Adobe applications.
Here’s how the layers looks.
“Color” is the master used as a fallback and contains black version. Every Color Palette layer contains one path, copied from the fallback master. This is a screenshots where I just generated the composite glyph Abreve.
A (base glyph):
brevecomb (mark – has different bunch of colors from the same palette):
Abreve (components) created from menu Glyph → Create Composite:
And their preview in the Font tab:
Please try the latest cutting edge version. It should work there.
Seeing your examples, the only way to be sure the colours will export correctly is to include all the colours used as layers in the composite as well (so Abreve needs to have the same layers as A and brevecomb).
If there is a change for this in the new cutting edge version, that would be great, otherwise, the above is the solution.
I already tried it (also in Glyphs 3.2) in the option 3 of my comment above. Looks like it’s not necessary and an issue is somewhere else (please read below).
Just checked the Glyphs 3.2 cutting edge and looks like the Glyphs version is not a reason. Result the same. But I did the new tests (please read below) and it give new different results. Maybe the glyphs order matter or something like that.
For purity of test, I removed almost all the glyphs and features and left just the following ones:
/a– Color Palette layers.
/acutecomb– Color Palette layers.
/aacute– two components with just the master layer in layers list.
/aringbelow– Color Palette layers.
And exported it (both SVG and CPAL tables) in Glyphs 3.2 (macOS 10.13.6).
Adobe 2020 – display all glyphs in black (I think Adobe work with SVG table).
Safari 13.1.2 – render simple glyphs in color but composites are black.
Firefox 115.2 – don’t render the font at all and print the following error in the console:
downloadable font: COLR: Base glyph record for glyph ID 2 out of order (font-family: "Test" style:normal weight:400 stretch:100 src index:0) source: file:///.../Test-Color.woff
The glyph id the Firefox is referencing is the first glyph in the font which contains components. In this case it was /aacute.
Here the source file with 4 glyphs I tested: Test-four-glyphs.glyphs (26.3 KB)
In the second test I removed the /aringbelow glyph which has no components but has the Color Palette layers (just like /a). So I only left the following ones:
/a– Color Palette layers.
/acutecomb– Color Palette layers.
/aacute– two components with just the master layer in layers list.
It give the better result (except of Adobe):
Adobe 2020 – display a in color (I think it’s from SVG table) but aacute in black.
Safari 13.1.2 – render all three glyphs in color.
Firefox 115.2 – finally start to render the font without any errors, all three glyphs in color.
So, if a glyph with a components is followed by a glyph without components, it causes some kind of error for the entire font. Interesting.
Shouldn’t it work as intended this way? (see attached file).
Test.glyphs (28.1 KB)
I do know browsers have their quirks when loading/not loading colours, sometimes this can depend on not defining the weight class in the css.
@Arthus Thanks for help, it works!
Adobe, Safari, Firefox – displayed all the glyphs in color.
I made a script for this. It goes through all the glyphs that contains components and add an appropriate Color Palette layers with a component parts. Just like you proposed.
font = Glyphs.font
id = font.selectedFontMaster.id
for glyph in font.glyphs:
layer = glyph.layers[id]
if layer.components:
for component in layer.components:
source = component.component.layers[layer.associatedMasterId].parent
for sourceLayer in source.layers:
if sourceLayer.attributes['colorPalette'] or sourceLayer.attributes['colorPalette'] == 0:
newLayer = GSLayer()
newLayer.associatedMasterId = id
newLayer.attributes['colorPalette'] = sourceLayer.attributes['colorPalette']
colorComponent = GSComponent(source)
colorComponent.automaticAlignment = False
colorComponent.x = component.x
colorComponent.y = component.y
newLayer.components.append(colorComponent)
layer.parent.layers.append(newLayer)
newLayer.syncMetrics()
One important moment I noticed in the process. An added components on these new Color Palette layers appears automatically aligned. That set the layer width to auto (600). It is not equal to master width, but equal to some default width that is 600. Arthur, when you sent me corrected file, I didn’t noticed that, because the master width of that glyph was exactly 600.
So, if I disable automatic alignment, the Color Palette layer width get correct width (equal to the master width), as expected, however it is not auto anymore. Don’t know if this is a bug or not but I disabled automatic alignment for all added components in this script.
Yeah, I made a quick and dirty example, but each final component-composite needs to have the proper layers in place to export. There are of course drawbacks, but this way does give you fill control of the final glyph, allowing you to drop or switch color layers.
Good solution by the way with the script, as keeping color layers in check can be a hassle.
That 600 value would have to come from somewhere I suspect, but it sounds to me like a bug, as color layers should default to the master width.
I was surprised by such behavior (in both Glyphs 3.1.2 and 3.2) that really looks like a bug. Here’s an example.
Master width of this /Iota is auto (320)
Source is /I and its master (and all the nested Color Palettes layers) width is 320
So far so good.
Color Palette layer (with Automatic Alignment) width is auto (600)
Why 600? And the right sidebearing is auto but incorrect too.
Same Color Palette layer (without Automatic Alignment) width is 320
So it loosing auto () for width and sidebearings, but the width and sidebearings itself are correct this way.
