Since almost all components are automatic made, why not have the same routine for lcaron, dcaron (caron.alt) and the commaccent for gcommaaccent (comma accent.alt)?
Which is the most easy way to do this as it is now?
They should just work. The component glyphs need to exist before adding the glyph for the first time. Try this:
- Create glyphs for:
l, d, caron.alt, g, commaaccent - Create lcaron, dcaron, gcommaaccent
You may want to add a step in between of setting default anchors in each glyph with Option-Command-U (in the Layers menu).
One way to create the glyphs is via Shift-Command-G (Font->Add Glyphs…). Then, enter “lcaron, dcaron, gcommaaccent”, for example.
You may also want to look at GlyphData.xml. Glyphs that have a decompose attribute should be automatically made if those glyphs already exist when you add that glyph. This is also where anchors and such are defined. Some info on this is here:
http://www.glyphsapp.com/tutorials/roll-your-own-glyph-data
You can also see that decompose component detail in Windows->Glyph Info. Also, take a look at:
http://www.glyphsapp.com/tutorials/recipes
Even though Eric describes the dcaron as being added as: d+caron.alt=dcaron
it’ll work with just dcaron (as long as the components already exist).
Hope that helps. Or was something not working when you tried that?
This is a bug in the GlyphData.xml file. The naming there is inconsistent: sometimtes it is caron.half, sometimes caron.alt. Also, the anchors="_topleft" should be anchors="_topright". gcommaaccent should be name=“gcommaaccent” decompose=“g, commaturnedabovecomb”.
I already reported all these to Georg, who said he’d fix it.
Maybe I should just share my own GlyphData.xml file:
https://www.dropbox.com/s/tyjo7tkilw14bp9/GlyphData.xml.zip
I made a number of other tweaks, you can use a diff tool such as TextWrangler to see what I changed. Feel free to discuss.
While I’m at it, this is a FontLab .nam file that corresponds to Glyphs’ GlyphData.xml file:
https://www.dropbox.com/s/waylfir0q5adl1j/standard.nam.zip
I am using it when I am opening Glyphs-generated fonts in FontLab.
Those have already been fixed, maybe in 1.3.24, but definitely by the 1.3.26 (531) release candidate beta.
The gcommaaccent should still be fixed, though. I forgot about that since I’d been working in all caps, recently.
My GlyphData.xml file ends up being a subset instead of a copy of the entire file. Periodically, I see if the ones I have changed have been updated in the Glyphs copy and delete them, when those changes are incorporated. So, my file has those changed glyphs between tags. That way, when Georg changes the GlyphData.xml file for glyphs I haven’t touched, the correction will be available.
About the gcommaaccent: the idea is that you activate the commaaccent and mirror it horizontally and vertically (easiest via the Palette), then the bottom accent will move to the top position. This way, you can reuse the same component.
Thanks all, I’ll have a go at this.
Perhaps in the future, a god thing would be to include caron.alt and commaaccent.alt in ”Categories > Mark” so they will be visible as missing glyphs?
Tim, thanks for sharing your files.
mekkablue:
I doubt that the method you describe is quicker than setting up a separate accent. Plus, rotated components are not possible in TrueType. And rotated components get messed up very easily if you change (i.e. move) the original, I try not to use them too much.
Yes, second that. No rotated accents, please 
- Mirrored (i.e. scaled) components are possible in TTF.
- Rotated components get decomposed automatically at TTF export.
- Placement is no problem if you use anchors.
- Handling only one commaaccent instead of two, in my experience, is much more convenient for the design process. And last time I checked, doing one thing once instead of twice, was also quicker. (SCNR)
But of course, you are free to pick any workflow you like.
Now, this is a bit confusing.
If I mirror a component vertically and horizontally the, instead of showing -100%, -100%, 0°, Glyphs displays 100%, 100%, -180° (with minus). The component is indeed exported to TTF like you said.
If I rotate a component left by 180° then, Glyphs displays 100%, 100%, 180° (without minus). The component is decomposed on TTF export.
Now the fun begins: If I rotate a component to the right by 180° then Glyphs displays 100%, 100%, -180° (with minus, just like after h-v-flipping). But the component is still decomposed on TTF export!
So, there is some hidden bit of information stored that indicates whether Glyphs considers the glyph rotated?
In practice, however, rotated components may be possible but you end up with rendering inconsistencies, at least if hinting comes into play. I don’t know how exactly the rendering behaviour of flipped components is defined but you don’t have control over it, it seems. It is practically impossible to work with flipped components in TrueType.
Yes, thank you Tim for sharing files.
The transform matrix of a component rotated 180° CW (through the Palette, that is) may look like this:
(-1.0, -1.2246467991473532e-16, 1.2246467991473532e-16, -1.0, 600.0, 700.0)
You see, super-small (i.e. negligible) 2nd and 3rd values, whereas flipped components have these values set to 0, as you would expect it from a simply scaled object:
(-1.0, 0.0, -0.0, -1.0, 600.0, 700.0)
Georg, I agree you should correct the GlyphData.xml related to caron.alt:
While “d” and “l” is now correct (topright + caron.alt), “L” and “t” are still wrong (top + caron).
I also recommend to correct “l” to use acute.case instead of acute:
I always use “commaaccent.alt” for “g”, I would love to see it in the XML file as well.