The UI state is stored in the file but also in the file attributes (something like the resource fork in old macOS) as it can store more then just the string. If it finds the attributes, those are read. To get rid of it, send the file with email to yourself or put it on a ftp server. Or find a tool that can access the attributes directly.
Ouch - that’s pretty terrible, So IOW you’re storing data redundantly in two places, in case the file somehow loses it’s attributes.
For years you’ve been trying to convince me and others to use the Glyphs file format by saying it’s an open, reliable, readable format. But then you don’t respect your own format, and store potentially conflicting data in a fragile, easily lost file attribute that is not open, reliable, nor readable. If the DisplayStrings were purely there as a UI state (like the dimensions of the window), then it should have never been written to the file in the first place.
File attribute data should never be used to store data that users may want to preserve if the file is moved around, sent to someone else, checked into a repository, etc. My experience says that users put a lot of effort into their DisplayStrings, and really want to preserve them. Since manually editing them in Glyphs is cumbersome, and adding unencoded glyphs seems is a real pain, it would be useful to be able to edit the strings in some other way.
Can you suggest a better method for managing these test strings, especially for unencoded glyphs?
Can you say what specific file attribute needs to be removed, such as with xattr? I’m assuming that if that file attribute is removed then Glyphs will look to the file data for the DisplayStrings. Is that correct?
There several layers of UI restoration. If you close the app with some documents open, the system will store the state of the UI somewhere. If you manually reopen a file, that info is lost and you loose what tab was open and some selection states and such. I just keep my own copy of the same data and use it when the system is not handling it. Textmate is doing something similar, when you reopen a file, the cursor is still in the same spot.
Storing the open tabs in the file is somehow strange in the first place as it is not really font data.
You are on the right track. The xattr tool will show you what attributes are attached to a file.
xattr path/to/font.glyphs
There should be a com.schriftgestalt.UIStore entry. Remove is like this:
OK - I’ll admit that tab contents may not have been intended to be permanent font data. However, most designers I know use them that way. And unlike other more normal UI file attributes they are effectively preserved in the font data if I send the file to someone else. So they have become font source data, even in your treatment of them.
They now live as pseudo font data that you can never reliably touch outside of Glyphs itself, as altering them may or may not result in a real change. IOW if you look at the data in Schrödinger.glyphs from outside the app and see ‘cat’ you can never know what’s really in there - it may be ‘cat’ or ‘deadcat’. The only way to see is to go into the app and look.
Maybe the real solution is to have a more robust mechanism in Glyphs for storing sample strings than what is in Preferences. Strings could be stored in the file, with a method for constructing tabs from those strings.
The Glyphs interface for editing tab display strings works fine if all the glyphs you want to see are easily typed by your keyboard or wired up with working OpenType code. But if you have encoded characters and yet no easy way to type them (without switching keyboards, using Keyman, Unicode Hex Input, etc.) - or if you have unencoded glyphs - it can be a real pain.
For example, say you have an alternate lowercase a that’s not encoded. Unless you have it wired up to an OT feature (which is BTW either off or on for the whole string) then you have to:
Open a new tab by double clicking on some random glyph
Switch to the T tool and edit the string to set some context
Switch back to the font window and open a new tab by double-clicking the alternate a (a.alt)
Select the text in the tab, copy
Switch tabs, click where you want it, paste
Someday go back and close that extra tab
There may be minor shortcuts that could make that a bit easier, but it’s still a pain.
I can add it trivially in the Glyphs file by clicking in the list at the top of the file, typing ‘/a.alt’ (or at least I though I should be able to, as the data is right there!)
And if you want to test three a alternates in context, such as ‘nanananan’ and see them all then you have to do that multiple times.
In addition, I may have more sets of strings than I want to have tabs open for. The sample text string mechanism in Glyphs if fine but is app- not font-specific. I’m not about to try and put all my texts from various projects in there. Such things are easier to manage in a text file. And I may actually want to automate them, too, but not in a way that locks me into only ever using Glyphs, such as writing internal app python scripts.
My main frustration is with the deceptive nature of the display strings in the Glyphs data that are often ignored in favour of strings hidden away in fragile file attributes. What other such things are there? If I pass my Glyphs file to a colleague what else will disappear? Or a few years from now after file systems change will I suddenly fine that tiny bits of data are missing that I was expecting to be preserved? (Sorry - I’ve just lived long enough to have been bitten badly by lost Mac resource forks)
It convinces me more of the value of less-fragile, documented source formats. I can run a one-line command to convert from UFO+designspace to Glyphs when I want to use Glyphs to edit, make change, save, run another one-liner to get good UFOs back.
You could just hit Cmd+F and type the glyph name and select the glyph from the list. While typing, you can select the arrow up/down keys to select a glyph from the list. So you can type some part of the glyph name and the arrow down to the glyph you need. You can select several glyphs, too.