Name change in GlyphData.xml

I mean why are you trying to establish an new naming system? Why now stick to the one already there? I’m happy to fix issues/add missing pieces.

If you really need use your names (the one without the -ar suffix), you need to overwrite the existing entries. But there are some problems. as without the suffix, there are conflicts with glyph names in other script (e.g., there is a ain that happens to be a latin letter). The main reason to add the suffixes was to be able distinguish similar names from different scripts.

And adding afiiXXXX names as production names is really not a good idea. Please use uni-names.

You changed some names to camel case like hamzaabove-ar > hamzaAbove-ar. That was all lowercase to make compound names easier to read. That each letter part starts with an uppercase (except the first).

And please use this file. As I mentioned a few times, don’t include the hole file, only the entries that you are working on:
GlyphData.xml.zip (36.3 KB)

Thanks for the file.

The name change could be easily avoided had I known the impact. I guess I have to start all over again and that’s not important. Using a capital letter in the middle of a composite name to my eyes makes for a better recognizable name but I’m not a native Roman script reader so I might be wrong. This is not a big deal anyway had I known the impact!

I added a ‘simplified’ version of the above mentioned “Arabic Basic Shapes” which don’t have suffix. This is where the conflict naming such as “ain” that you mentioned may occur. The name can be changed but the concept of a simple name without suffix is very important. I didn’t write any decomposition scheme for these simplified names. I just wanted to have them in the Data to be recognized as RTL letters for my next project in which a lot of OT lookup writing may be involved and for those lookups a short and simple name is necessary. That simplified package is much smaller than the Arabic Basic Shapes and we can work this out to have non-conflicting names.

But there are some other issues that I encountered while reviewing the data one by one. And they are not few. Ranging from a poor choice of decomposition to downright wrong choice. I can bring them up one by one as I go but you’ll get tired of me very quickly! I’ll see what I can do.

Don’t worry about afiiXXXX. I’m done with it years ago. I use uniXXXX only.

There were some afii names in your file.

Maybe you have a look at the most recent file from version 2.4.2. we fixed a lot of the decompositions since your version.

Yes now I know that I worked on the old trial version GlyphData. How can I get the 2.4.2 version? I think I had the old version from the beginning and TimeMachine can only give me the old version. Glyphs doesn’t generate a new GlyphData upon opening. Should I re-install it?

Please always make a copy of the GlyphData file and put it in the Info folder in Application Support/Glyphs. All the details are in the GlyphData tutorial.

And to get the latest version, download the app from the website and activate ‘Show Cutting edge versions’ in Preferences > Uodates.

I would also add to only duplicate items which need to be different for your project. For some projects, it may make sense to put the GlyphData.xml file in the same directory as your .glyphs file.

The GlyphData tutorial that Georg mentions is here: https://glyphsapp.com/tutorials/roll-your-own-glyph-data

Yes thanks. I found that page last night! Now that I look at my TimeMachine I realize that I had that Glyphs folder in Library since 2014 and since I didn’t click the option of ‘Show Cutting edge versions’ it wasn’t updated from the beginning! The application itself is the version 2.4.1 that I bought few weeks ago. I have to go now but I’ll check this later.
I removed the outdated data from my post.

What kind of OpenType programming do you plan to do. Doing all that work on changing the GlyphData only to save a few chars here and there?
Most of the feature code for Arabic is generated automatically if you use the build in names. So you might end up writing more code by hand by trying to optimize it.

Okay I give you an update on this.
I got rid of the old GlyphData xml file and found the new version following the instructions in above mentioned link.
I used the new xml data, removed the non-Arabic part and started all over again, using the names in GlyphData without any modification. The current data is far better than the one I used the first time around. A lot of work was put into it. I didn’t find any error, just a few, mostly related to common mistakes. I updated the list covering the Unicode v10 data. Few addition to existing list, but mostly completing the contextualization of the codes for quite a few. Once I finished, it worked like a charm!
I created a new xml for Arabic part covering the Unicode v10 and although you didn’t want the block U+1EE00 for Arabic math letters, but I did that part too because it was part of my auto-populating scheme.
My first test shows a lot of hits and very few misses (comparatively). The OT tables seem to be generated for all the new entries. I checked these misses and some were related to my typo in the xml file which were corrected. Some other misses I suspect were the result of the mistakes in xml on other items because they are interconnected. The math letter field didn’t work at all but I don’t think I surprised you!
I want to run another test before giving the new xml file. I created three lists. First is the new xml for Arabic. Second is the list of modified items in the original xml. And the third is the list of all things I added to the list and they were not there before.
Once I get a chance to test it again, I’ll get back to you.

1 Like

I’m happy to incorporate your changes into the app. If you could send me your files when you are finished.
I don’t have anything against the Arabic Math part. I add new glyphs/scripts only if a user who is familiar with them requests it. I need qualified feedback to get it right.