Glyphdata.xml disregarded by Glyphs3

Hi there,

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

Same error here as well!

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:
<!ATTLIST glyph
	unicode			CDATA		#IMPLIED
	unicodeLegacy	CDATA		#IMPLIED
	sortName		CDATA		#IMPLIED
	sortNameKeep	CDATA		#IMPLIED
	category		CDATA		#REQUIRED
	subCategory		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 marks.

The script I’m working on doesn’t have cases and is all left-to-right, so I ignored the new case and direction attributes.

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.

Hey @Norbert,

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?