Hi,
I’m looking to the possibilities of changing the glyph names (to a different extend depending the case) in GlyphData.xml (only the Arabic portion) and I’m wondering what is the ‘red line’ in modifying the names? where the functionality of the editor is compromised?
It can be changing for example ‘threedotshorizontalbelow-ar’ to ‘threeDotsHorizontalBelow-ar’ (for a visually more recognizable segments of a composite name) or it can be shortening the names of frequently used glyphs such as ‘alef’ instead of ‘alef-ar’, ‘beh’ without the suffix etc… Also, it can be totally a new name like ‘strokeSingle’ or ‘strokeDouble’ while preserving the Arabic script directionality and ‘Mark’ category.
Can I go ahead and do whatever I want?
I would say just try it. All of that should work.
You may break some automatic OT features (the Automator may expect the -ar suffix, for instance), so be prepared to write some of those yourself.
Thanks. I’ll give it a try. I’ll try to keep the functionality intact.
Hi again,
Suppose the glyph already has a ‘decompose=x, ˆ’ (a base letter and a mark for example). And x already has anchors definition “top, bottom” or whatever. Does it need an anchors definition in GlyphData.xml for itself or the component definition is enough?
Glyphs with a decompose attribute are likely compounds. Compounds do not need anchors unless you want to do something very special. Anchors from components usually shine through in the compounds.
Thanks. This is what I thought. The Arabic portion of the GlyphData needs a major update. I’m on it since I need it for my current project anyway.
BTW about the ‘sortName= …’ number, is it unique to this database and I can change it or is it hardwired to other data?
sortName is not hardwired. You can have your own system. Just be sure it doesn’t conflict with the master file.
Okay thanks. No this is not an issue for me because I don’t start anything before finishing this. But now I realize this is a major issue for others if they wanted to use my modified GlyphData.
You are right about others using it. I wish we had a UI feature to allow selecting a Custom user data file when working on a particular font. That would solve the issue you mention.
Even now there is an awkward solution. I was thinking that if I had the old Glyphs files, I could change the name of the current Zip file of GlyphData to ‘GlyphData_old’ for example, and put another Zip file for the new GlyphData.xml, and delete the xml file and open each Zip file according to which project I am working with. But you are quite right, this can be simplified through the UI.
You can put the GlyphData file next to the .glyphs file to only use it for that file.
That is so much better than my idea! so I take it different .glyphs files (with different GlyphData) should not be placed in the same folder. (which usually aren’t anyway)
It will only pick up a local GlyphData.xml file if the file name is exactly like this.
Hi,
Okay. 2600 lines later, I finished the new GlyphData with updated Arabic data.
It doesn’t work. I put it in a separate folder, I put it in main folder in the Applications Support. I cleared the cache. Rebooted several times. It simply doesn’t want to work.
So since I don’t have anything to show for it, let me explain what I did and what my intention was.
I reviewed all GlyphData line by line, and added missing codes from Unicode version 10, and I defined all presentations forms using the suffix -ar.fina, -ar.medi and -ar.init.
I also added some identifier marks that are needed for decomposing all the letters.
I created a list of Arabic Basic Shapes and Arabic Basic Identifier Marks.
The way the whole GlyphData is written, all the glyphs of Arabic script in Unicode 10 [excluding the Unicode blocks for Arabic Presentation Forms A & B and non-letter items] can be populated if the glyphs of those two lists are created.
I created a couple of list filters based on the glyph names in those two lists. I generated those glyphs and I made the character outlines in each of them. With these glyphs ready, and based on the decomposition scheme in the new GlyphData file, Glyphs should be able to populate any glyph added to this font. But it is not working.
This is the screenshot of the Arabic Basic Shapes:
I built all the glyphs of that list because it’s my baby! But you only need to create the shapes that you need for your font. As you can see they are not many and quite a few of them are not necessary for an average font. So basically the idea is to focus on the design and contextual formation of the letters and let the font editor do the repetitive tasks.
When I replaced the GlyphData with the new one, Glyphs was still randomly doing some decomposition. It seems that it uses sources other than the GlyphData, and in its other sources, wherever the name was fully compatible and there was a decomposition instruction, Glyphs did the decomposition. But since it is not based on an expected workflow, it is practically useless.
I attach the lists and the GlyphData if you want to look at it.
[REMOVED. SEE THE LATEST VERSION DOWN BELOW]
I had a look at your xml file. There are several xml errors. Use a XML validation to find them. And please only add the entries you are actually changing. We update/fix some entries and you would keep the old version. And it takes longer to start the app.
I’m not a programmer. I don’t understand the developer tools. I just replicated the pattern I saw in the xml file. I should have removed those subdivision lines though. Those were for my own use. Now I removed them on my copy. I’m afraid the change was not selective. The whole data was changed to some degree. Basically I started blank, searching the codes one by one, cutting and pasting in the blank xml file, and if I didn’t find the code in the original, I added it myself replicating the pattern. The decomposition is also interconnected and based on slightly or heavily name change or previously non-existent items. So it cannot be taken out selectively. You should have warned me when I started this topic!
Yes I noticed Glyphs opens very slowly when my xml file is in the library. When the original is there and my copy is in the Glyphs file’s own folder, it opens faster.
if you use Textmate.app, you can use the build in XML validation tool (Bundles > XML > Validation Syntax).
Wow thanks! That was somewhat easier than I thought! I cleaned up a few misplaced ‘space’ and a couple of cut and paste ‘incidents’. It no longer find any error up to the last line of ending tag of the xml which I didn’t touch. It may have something to do with the number of entries in the file that has been changed but I don’t know how to fix it. It says: “error on line 24144 at column 18: Opening and ending tag mismatch: glyph line 0 and glyphData” but it doesn’t report the first error so I take it it’s good up to the ending tag. Here is the cleaned-up file.
[REMOVED]
I’m also worried about mistakenly entering duplicate Unicode points.
All the error messages I get are easily fixable. The most opaque are the once about the ‘error: Premature end of data in tag glyph line’ that means that you missed the / at the end of the line.
But why are you doing all this work?
And from what version of Glyphs did you get the GlyphData file from?
Thank you so much. Yes this / was the bugger. I fixed a few and finally I got the mark of approval at the end of file. I removed the old files and I place the latest here.
Why am I doing this? because it is necessary!
I just bought Glyphs a couple of weeks ago so the GlyphData file must be the latest. But now that you mentioned I remembered that I used Glyphs trial version a couple of years ago and maybe there was some residue left in the library. So I cleared everything in the library to be sure. But when I re-opened Glyphs, it doesn’t seem to generate new files!
Oh well, I have TimeMachine!
The new package with fixed xml file is here:
[REMOVED BECAUSE OF OUTDATED DATA SOURCE]