I know and love the way that Glyphs work with the name of the glyphs.
Right now we can the names both in “nice names” and the unicode names. But neither of these ways are not that pleasant in making complicated Arabic fonts. The reason is that they could be too many similar glyphs with a very cumbersome and long names. Finding, calling up, and writing these names are no fun and hard.
I propose adding a third option for custom names added to Glyphs. This would be in addition to current names. So for example we could also name (tag) glyphs the way that would make sense the best for us. And If we write these names, Glyphs would refer to their original names and use them the way that it should. This could be a big help in finding, sorting using and so on.
This would be a fantastic option and a big help to the designers.
Glyph tags could be useful with Devanagari, too. For example, I have conjuncts containing च. I can’t search for all of them at once in the font tab because that च appears in the name as ca_, c_, and _c. So if I want to search and open them all at once…I can’t. Instead I have to search, select, open a tab, repeat, repeat, copy/paste, copy paste. It would be great if I could just tag every glyph with च. Then I could search for च, select all, and open one tab.
It’s not about names Ilia. In OpenType, each glyph should have a distinguished name. No matter what you do (Adobe used to use ‘nice names’, then changed it to ‘affixxxxxx’ names, then now unixxxxx names I suppose), if the number of glyphs you are dealing with (in OpenType tables and lookup instructions) is overwhelming, no matter what approach you choose, it becomes cumbersome.
The current state of naming pattern in Glyphs is actually very effective in Roman script. Because even if a character takes a very long name, in most cases you never use that name or if you do, you use it once in the lookups and you are done with it.
In Arabic script on the other hand, you are constantly dealing with shaping and re-shaping characters in multiple contextual patterns. So you are constantly using those names… and lots of them!
In my view, this requires a total new approach dealing with Arabic script because it’s not about names. It’s about the way you are making the font and the number of glyphs you are dealing with in contextual scheme.
The problem with lists and filters is that they pile up over time. I have 26 right now and I have scroll through the list to access them. Lists and filters also cannot be shared with collaborators easily, whereas tags would just stay in the .glyphs file.
An advantage of tags over colors is that the meaning can be less ambiguous. If I open a file after six months or a year will I really remember why I made some glyphs purple and others gray? But if the tag says “#unadjusted_obliques” or “च conjuncts” the meaning is obvious.
mekkablue
I’m still in an early stage of mapping my glyphs through ccmp. I will report when I reached the editing stage. But for now, I noticed that I could not choose my preferred name for a glyph if that name interfere with Glyphs names-unicode point database even if I tell Glyphs NOT to use the nicenames. That’s a minor issue for my project but it’s there. I’ll get back to you when I reached GPOS stage. Eager to see how the GUI does it. I’m still on the demo version. Less than 2 weeks left to make a decision!
Why? What are you doing in ccmp? Can you give an example?
Perhaps you can leave this over to the automatic feature generator. Or let me have a look, and send your .glyphs file to res (at) this website without www.
You can have a lot automated. You can, e.g., search and replace, you can autocomplete glyph names. Can you give an example for such a cumbersome and hard situation? What are you trying to achieve?
a version of this that comes after beh-ar.medi (and the similar glypgs), so I name this one: kaf-ar.medi.Beh*.alt
a version of this that comes only after beh-ar.init so I name this one kaf-ar.medi.BehInit*.alt
a version that comes after beh-ar.medi but follows by another Kaf-ar.medi, this one I call; kaf-ar.medi.Beh*KafMedi.alt
a version like the previous one but follows by Kaf-ar.fina. I name this one; kaf-ar.medi.Beh*KafFina.alt
And now I have to do that with another group of letters that come before and after Kaf. As you see, soon I will end up with so many glyphs with long names and keeping track of them become very hard. As you know the complicated Arabic fonts could have a couple of thousands glyphs.
Still I could work with this system if I could search the glyphs by two or three words (like spotlight does), but Glyphs only allows the search of one word. So the other option becomes having some sort of a tag system so I could tag them and search them that way.
As Behnam said, by its nature, anyway you look at it or name these, it is complicated by nature. I only want to make it easier if possible.
If you know a better way, please let me know. Thanks
I thought about suggesting this last night. But it doesn't seem appropriate to the Glyphs user experience. For people like me who are used to the UNIX command line and use Glyphs every dau it would be great because we could just type in complex search strings from memory. But for the art directors who can barely even use a Mac it would require reading the manual every time they create a search string—so they wouldn't do it at all.
I'm a bit thrown in to this discussion a bit early. Not quite ready for it! What I'm doing in ccmp? I'm decomposing to the bone! So far I built a font (in FontLab) with 590 glyphs covering the entire Arabic script in Unicode7, including plain 0800 which is not registered in Glyphs yet! and that number of glyphs includes all the basic presentation forms.
I was about to write that I probably would implement regex support for now. But then I googled it and found out that it is really easy. So now you can search with regular expressions.
And if you search in Name mode (that means select Name in the search field options), you can add more then one term and it will look for all of them. So if you search of “j le”, you will match “jdotless” and “jcircumflex”.
I just added the 0800 range. But I need more information about it (decomposition, anchors …). And it isn’t supported by any don’t on my Mac so I don’t know how it looks.
On my Mac, in Character Viewer the only font presenting those codes is the one I made! But since they are decomposed they don't look good in actual text. They need GPOS done. I'll give you a copy once I have a functional font.
BTW I worked on that GlyphData.xml but I think I didn't do it right because it doesn't affect the outcome. I want my decomposed glyphs (mostly dots and signs) be registered as 'Mark'. The font has problem in contextualization (mostly on Windows) and I suspect it is because it doesn't do 'ignore marks' in the lookups.