I am working on a variable design across 2 axes for an Indian script. The design not only has a number of stylistic alternates but also possesses a number of alternate glyphs that switch within the design space.
In order for the files to be legible I have my own naming system. Additionally, I use a custom glyph data.xml, with a specific categories, subcategories and sorting so my file is more legible. In doing so I have not paid any heed to the existing categories, but I have made my own.
This system worked perfectly in Glyphs 2.
However, when I open the same file on Glyphs 3, the glyph data is disregarded and I lose all my file organisation and set-up. Am I doing something wrong? Or is there a simple fix for this little niggle?
Glyphs 3 has changed the format of the GlyphData file a bit. So you might need to adjust it.
Is there any guide to this online? Any idea how to do this within the confines of EditGlyphData?
Working on updating the documentation. Glyph data is on our list. You can figure out most though if you take a peek into the current built-in XML.
You can change the file format by running the code in the macro window of EditGlyphData
Doc.fileVersion = 2
But it doesn’t do the conversion from subcategory=Uppercase too case=upper, yet.
Doc.fileVersion = 2
in EditGlyphData build 5 gives me:
Traceback (most recent call last):
File "macro panel", line 1
AttributeError: 'NSKVONotifying_GSDocument' object attribute 'fileVersion' is read-only
I got my GlyphData.xml to work to some extent in Glyphs 3, with the following changes:
- Replaced the attribute list near the top with:
unicode CDATA #IMPLIED
unicodeLegacy CDATA #IMPLIED
name CDATA #REQUIRED
sortName CDATA #IMPLIED
sortNameKeep CDATA #IMPLIED
category CDATA #REQUIRED
subCategory CDATA #IMPLIED
case CDATA #IMPLIED
direction CDATA #IMPLIED
script CDATA #IMPLIED
description CDATA #IMPLIED
production CDATA #IMPLIED
altNames CDATA #IMPLIED
decompose CDATA #IMPLIED
anchors CDATA #IMPLIED
marks CDATA #IMPLIED>
- Renamed all
accents attributes to
The script I’m working on doesn’t have cases and is all left-to-right, so I ignored the new
Glyphs 3 seems to ignore a GlyphData.xml that’s colocated with the font’s .glyphs file; I only got it to work with one located in
~/Library/Application Support/Glyphs 3/Info.
Glyphs 3 also doesn’t show the mark cloud, despite copious
marks attributes in GlyphData.xml.
Uppercase and lowercase used to be in the subCategory so if you left them there and are having issues with that, it could be the reason.
The script I’m working on doesn’t have uppercase/lowercase, and I don’t have any issues with that.
Understood. Just pointing out the changes.
If Glyphs3 does indeed ignore the xml that’s collocated with the .glyphs file, (and if it is imperative to paste it into ~/Library/Application Support/Glyphs 3/Info), then wouldn’t it be impossible to work on multiple projects/scripts with different glyph data files.
Or is there a way around this now?
That’s more a question for @GeorgSeifert. My workaround was to donate the Batak glyph data for incorporation into Glyphs 3. If your work requires different data for the same glyphs in different fonts, that’s a more complicated situation.
I just tried it and my custom GlyphData was picked up just fine. One think to note is that the Glyph Info window will not show local data, only info from the App Support folder. You need to check if your custom glyphs get the correct info in the font. If you can’t see your data in the font, can you please send me the .glyphs and the .xml file?
GlyphData.xml files that are colocated with the font now work in cutting edge build 3052. Thank you, Georg!
Here is another bug in Glyphs 3: All glyphs I have in my custom GlyphData.xml file get subcategory “Other” even if it is not specified.
I’d expect that if I copy a line from the built-in GlyphData.xml to my custom file and leave it unchanged then it shouldn’t have any effect.
That’s not just a cosmetic bug but it messes up the kerning tool I am currently working on, and it took me very long to find out what went wrong. Would it be possible to fix this?
Are you sure that this wasn’t happening in Glyphs 2, too?