Cannot open a glyph in a tab

I encountered the following issue:

Steps to Reproduce:

  1. Open the .glyphs file: ManyTabsTest.glyphs (685.5 KB)
  2. Try to open cid11037 in a new tab.

Expected Result:

The new tab containing cid11037 should open.

Actual Result:

An empty tab opens instead. For workaround, close all tabs and save/reopen the file, and then the issue will be gone.

Reproducible both on 2.6.6 (1352) and 3.0.4 (3100).

Is there any sort of limit on the number of tabs, or on the number of unencoded glyphs in tabs? Or is it a bug?

Not on my Mac now. But does it work with fewer tabs open?

Correct. Tested on macOS 10.15.7. After I close the tabs, any glyph will start to open without the issue. If I leave the tabs open, some glyphs will open as usual, but some (e.g. cid11037) will become an empty tab.

I received this file from my colleague, and at first I checked if there were no duplicated unicodes or structural/syntactic problems in .glyphs plist. At the end of the day I came to the conclusion that it had something to do with the the opened tabs. The attached data are emptied except the displayString key, and the issue still reproduces on my side. I know the takeaway here is not to leave too many tabs open, but it still looks to me a bit random and unexpected…

It is a bug. I’ll have a look.

I had a look. It is the combination of a lot unencoded glyphs and many tabs. Can’t easily fix this right now.

Thank you so much for taking the time and clarifying the cause. We’ll keep our tabs tidy for now to stay away from the issue!

Why do you use the glyphs without an unicode?

Part of the reason for that is because we often develop fonts targeting Adobe-Japan1, which contains a large chunk of unencoded glyphs that can only be accessed from the GSUB tags. Thus, it is kinda unavoidable situation I think.

But Glyphs has nice name for most of them. So you don’t need to deal with those pesky “CIDs”.

Add a custom parameter “ROS” and set it to “AdobeJapan-1.X”. Then run the following script in the Macro panel:

from AppKit import NSBundle
	
def applyROS(ROS):
	Elements = ROS.split("-")
	Font.disableUpdateInterface()
	if len(Elements) == 3:
		Name = "MapFile%s-%s" % (Elements[0], Elements[1])
		coreBundle = NSBundle.bundleForClass_(type(GSFont))
		Path = coreBundle.pathForResource_ofType_(Name, "txt")
		if Path:
			with open(Path) as f:
				Lines = f.readlines()
				print(len(Lines))
			for Line in Lines:
				Elements = Line.split("\t")
				if len(Elements) > 2:
					CID = "cid%.5d" % int(Elements[0])
					glyph = Font.glyphs[CID]
					if glyph:
						glyph.name = Elements[1]
	Font.enableUpdateInterface()

ROS = Font.customParameters["ROS"]
if ROS is None:
	Message("Please add custom parameter 'ROS' and set it up as needed")
else:
	applyROS(ROS)

1 Like

Thanks for the script! We use both nice names and cid names depending on the workflow. Peskiness may vary, but we tend to use the former at a design phase, and the latter convention is still often used to integrate with our AFDKO-based production pipeline. Even if I stick to the nice names, I think such unencoded glyphs cannot be eliminated, so there should be a small possibility that they won’t open in a tab. The issue here sounds avoidable for now if tabs are manually garbage-collected in an appropriate cycle, so I don’t see it’s critical so far.