I can’t date since when this appeared (as I did not work on fonts with this setup for a while), but I noticed the following:
Create a component with color layers, add outlines to the color layers. Give the main fallback glyph a different outline.
Place the component in another glyph: Only the first copy of a color is shown correctly, when the color is used more than once, the shape will use the fallback glyph shape instead.
It used to be the case that every layer, regardless of the amount of copies of a color, would be shown correctly. So I guess this is a bug?
Also: Is there a way I can see the patchnotes of cutting edge versions? and skip an update if I believe they might cause a conflict? This disappeared for me a while ago, and now happens automatically.
I think you enabled automatic updates and are thus no longer shown the change log or the option to skip a version. There is currently no UI to disable automatically installing updates once enabled, but you can run the following macro:
I have been working in-Glyphs with COLR layers, and testing in SVG (as it works a bit easier with the Adobe font folder) lately, so I only now noticed another issue which I believe has the same source as my original question.
The first line is a version exported just today, the line below is an older export (before my other issue popped up). Settings are the same. Looking through my backup files, I can see files from 28th April that are still correct, but a file from halfway May has these faults.
As a note what is happening: The top line only shows the fallback layers, using the last color layer of the glyph/component (all other color layers in the glyph probably use the same fallback layer as well, but are hidden by the top one).
The glyphs are all constructed of multiple pre-composed components, goes about 2/3 components deep. I expect the exports can be fixed with decomposing everything (something I already have to do to create variable color fonts), but I rather keep everything streamlined.
Thanks for the fixing the COLR export in the cutting edge version, these works great now! (and saves me from keeping a 450+ mb decomposed version around).
A similar issue persists in Variable Font exports when using color layers and components, but I can work around that (and this was the default before the static COLR export issue popped up anyway, so I have always taken it into account).
And not to bother too much: What is the take on the color-components reuse issue? (see the first post in this thread). Is this a bug or is this a change? I’d like to know as I will be revisiting a design that is built upon reusing color components in different layers soon, and want to know which approach I have to take. Cheers!
It happens in a new file slightly different than in my existing files, but the end result is the same.
I have a file with two color components, each using one color: One with a dot in color and square as a fallback path. The other one with a square in color and a dot in fallback.
Add the color to another glyph and place the components. The first use of the component and the color will be correct.
Add another layer with the same color, duplicate the component. With a new file you will have to switch back and forth to the original color. The component will now be stuck on the fallback path instead of jump to the correct color layer of the component.
You could also save and reopen the file before swapping the colors back and forth which will also make the components jump to the fallback. (which is what happens with my original files).
The only workaround is to make a second color with the same value, which will work correctly.
I would not add color layers to the dot glyphs. Just have a square and a round one and place then as needed. Or I don’t understand what you are trying to achieve.
And the _part suffix is more meant for smart components. You can call the glyphs “_dot.round” and “_dot.quare”.
The dot and square are a simple example to show the issue: For my color fonts I use way more complex components, and compiling these all in sub-components keeps everything tidy, clear and easily adjustable (as many of them have around 10-20 colors at least) A good example is the file I sent earlier (30th of August). The included /A works fine, while the included /Eth has the issue above (due to re-used colours) and needs decompiling for export).
My reason for asking is because the re-using of colours in components used to work fine until an update somewhere in april/may. If the current state is a side-effect of another change and will be kept in place, let me know as I need to restructure some of my older color fonts. If this is seen as a bug and might be fixed: Then I know I can leave them be for the time being.
Cheers, had a look. Your proposed solution of only using base/fallback layers was also my way of working back in 2019, but as things got more complex, I started to combine elements, which worked perfectly, until somewhere earlier this year.
I see. That was a deliberate change to better matsch duplicate color layers. E.g. if you have two of the same colors in the base glyph. I’ll see if I can improve the fallback to pick an existing color layer instead of falling back to the default.
I recently updated to a newer cutting edge version and now it all works perfectly, many thanks! Saves me quite a bit of work restructuring the various typefaces.
