I’ve been working with rather large character sets in Glyphs and have needed to perform the same action on all of them at once. Say, the “Correct Path Direction”, or “Duplicate”. With my character set (over 5000), the pinwheel just spins and spins and spins.
It is hard to know if Glyphs has totally crashed, or if it is still working, or what is going on. I feel it would be useful to have something like a progress bar or other mechanism to tell me that Glyphs is still functional and will recover. And maybe a “kill switch” if the process is taking too long?
Anyway, I’ve had Glyphs become inoperable for >30 minutes trying to process on some of these files. I am currently on 2.2.2 (825).
What operation did you exactly that took so long? Did you really try to duplicate all 5000 glyphs?
I got an endless spinner today, just working on a single glyph. (I was using keyboard shortcuts to select all, delete everything and paste something else in the glyph, going through all the masters quickly caused it to make the spinning ball.)
EDIT: I do have quite a few tabs open, some of which contain many glyphs.
Yes, I did try to duplicate 5000 characters. That said, I tried doing it with a much smaller number (50ish?) and it still spun. It may help to know that this is also a MM font.
The “Correct Path Direction” process worked eventually (as did offset curve), but “Duplicate” died.
In general, though, I find that Glyphs has a hard time handling large character sets. Yesterday I tried generating an OTF of a TTF font with 29,000 characters and got the spinning wheel for 40 minutes before I killed it.
Glyphs takes 20 s to export the font (on my first generation Retina MacBook Pro). What takes so long is makeOTF calculating the subroutines.
If it is for testing only, you can disable subroutines with a parameter, and turn off overlap removal. That should speed it up significantly.
Strange. Not sure why it was totally crashing on my machine then.
What are these subroutines that you’re talking about?
I did have another look and my code is busy for 12 seconds. Then there are 10 seconds of Adobe code that convert the PS font to PFB and then 1.5 second of makeOTF (with subroutines disabled) or several hours with subroutines. I’m a bit proud of this numbers
I should add a warning up front that suggests disabling subroutines for fonts with more then 8000 characters.
Take a look at this
For those of you unfamiliar with the term, CFF stands for Compact Font Format (PDF file) and the compactness of a CFF font is in part achieved via a technique called subroutinization, which is performed when the font file is generated. Subroutinization is a process that surveys all the glyphs in the font looking for path segments that are identical and thus can be replaced by a shared routine/command. The more regularized the glyphs are, the more compact the font will be. The TrueType format also has a mechanism that allows turning a given glyph into a component which can then be reused by other glyphs — think of the glyph representing the letter A being reused in the glyph for the letter Á (A with acute accent). This method will also decrease the font file size, but the reduction is not as significative as with subroutinization.
When subroutinizing smaller fonts, meaning those with relatively few glyphs, there really is no concern that subroutine limits will be reached. When the number of glyphs is significant, such as over 10,000, there is reason to be concerned because there are both implementation-specific and architecture limits on the number of subroutines. The architectural limit is “64K minus 3” (65,533), and there are known implementation-specific limits that are “32K minus 3” (32,765). The known implementations that limit the number of subroutines to “32K minus 3” are Mac OS X Version 10.4 (aka, Tiger) and earlier, and Adobe Acrobat Distiller Version 7.0 and earlier.
When dealing with name-keyed fonts, these subroutine limit figures are applied to the global subroutines, because there are no local ones. Things get a bit more complex with CID-keyed fonts because the number of subroutines is determined by adding the number of local subroutines for each FDArray element with the number of global ones. In other words, the combination of the global subroutines plus those from any one FDArray element (local) cannot exceed the limit.
Interesting. What’s the parameter mechanism for disabling subroutines?
File > Font Info > Instances > (your instance) > Custom Parameter > Disable Subroutinization > Check
Cool, thanks! So how about a progress bar :)?
Most operation only take a second in normal use. So to add a progress indicator for those cases where it might take longer, would be quite a bit of work and would annoy everybody. Every time you find an operation that you need to run more than once and it takes longer than a minute, you send me the font I try to improve the performance. Just last week, I improved the time it tool to Update Glyphs Info for a 10000 glyphs font from several minutes to 2 seconds.
Ok. Running “Correct Path Direction” on a 28,000 glyph font. Currently at 40 minutes and counting. Or “Duplicate” on some 5000+ glyphs.
Perhaps it could be something where, if a process seems it will take longer than a minute that there be some indication to users about how long things might take.