Do you sort your glyphs in any particular order during development and/or in the final output file?
If so, do you sort by Unicode or according to a custom order (alphabetically, logically). What about unencoded glyphs?
Or are you not bothered by this at all, since it technically doesn’t affect the user’s experience (all that much... or does it? I know the order will be used in InDesign’s Glyphs panel, and... might it affect the font’s performance somehow?).
Comments
Same here.
There are assorted technical implications of glyph ordering.
Some tools will display glyphs in glyph ID (GID) order. Besides the InDesign Glyphs panel, most tools that poke at the insides of fonts show the glyphs in GID order.
If you are generating a font in OpenType CFF (PostScript outlines, .otf), AND you are using CFF and not CFF2, AND you keep the first several hundred glyphs in the order specified in the CFF spec, you can save on file size because glyph names won’t be needed. Of course, this only works to the extent you have those same standard glyphs with the same names. Character set is ~ Adobe Latin 1 + Adobe CE as I recall. I think it is something like ~ 340 glyphs.
Keeping matching glyphs in contiguous blocks helps with writing OT code in AFDKO syntax, for things such as mapping caps to small caps, or lining numerals to oldstyle numerals.
I can’t think of any other benefits of glyph ordering offhand, but I may well be forgetting something.
In large projects that are updated over a period of years, which is typical of the work we've done for Microsoft, the idea of logical and intuitive ordering breaks down because new additions are appended to the end of the existing glyph set, not inserted into the sequence where they would logically belong. But this is a situation in which controlling the glyph ordering is, if anything, even more important, since we want to avoid reordering existing glyphs after a font has shipped.
Mostly, for purely typographic variants, such as Small Caps, case-specific punctuation and currency symbols, etc., is there a sort of standard on where to order them (at the end of the file?).
• Basic alphabetic uppercase (e.g. A–Z for Latin)
• Uppercase diacritics, sorted according to basic alphabetic, followed by specials such as Eth and Thorn
• Basic alphabetic lowercase
• Lowercase diacritics etc.
[Smallcaps, following same ordering as above, and ligature forms inserted here if present.]
• Combining marks
• Punctuation
• General symbols (pilcrow, section mark etc.)
• Currency symbols
• Default numerals
• Additional numeral styles
• Math operators
Within each of these groups, I have a conventional order I use, e.g. for diacritics: grave, acute, circumflex, caron, tilde, diaeresis, dot, and so forth.
The approach for complex script is similar, e.g. for Northern Indian scripts
• Independent vowel letters
• Consonant letters
• Dependent vowel signs
• Other marks (candrabindu, virama, etc.)
• Consonant + vowel sign ligature forms
• Consonant conjunct forms (sorted alphabetically)
• Punctuation and symbols
• Numerals
Also, Unicode based sorting has some odd effects in terms of how some writing systems get broken up between basic and extended blocks, with other stuff in between. And also how basic ASCII separates from other stuff. For example, my custom sorting keeps typographic curly quotes right after the ASCII typewriter quote marks, and keeps superscript 1, 2 and 3 next to the other superscripts, etc.
https://forum.fontlab.com/fontlab-vi/exporting-custom-encoding/
- A-Z
- any caps that are not automated away or require adjustment, so Ą Ɓ, Ɔ, etc.
- a-z
- the same for LC
- punctuation, numerals, operators, symbols, currencies, you name it
- combining marks
and only nowFrom uni0000 up to /longs uni017F, excluding the control characters uni0001-uni001F and uni007f-uni009F (Type 1 Adobe Standard encoding), there's 338 glyphs, so that seems about right. That magnitude of file size saving must be only relevant in embedded systems though, right? Or maybe webfonts.
But the syntax only has ranges based on glyph names, e.g A-Z or uni2000-uni2009 (doesn't even work with hex numbers, so it breaks at uni200A — and in FontLab even decimal fails most of the time)... right? It doesn't depend on glyph order. Maybe it can affect the conciseness of the compiled features though?
My recollection is that in order for the AFDKO code to actually compile and function as expected, the glyphs have to be ordered appropriately in the input font. But even if not, certainly it would make for smaller compiled code.
Now, with Minion 3, I can just apply the same font to all text if the correct Unicode was used. But manually browsing for the right character got slower.
1) No, sorry I wasn’t clear enough in the follow-up. Just that set, and only if they are in that order, etc.
2) Cool that it compiles. The resulting font will be the tiniest bit larger, then, is all.
It would be definitely handy to have it included as a default functionality in the next Fontlab 7 update…
"ЀЁЂЃЄЅІЇЈЉЊЋЌЍЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюяѐёђѓєѕіїјљњћќѝўџѠѡѢѣѤѥѦѧѨѩѪѫѬѭѮѯѰѱѲѳѴѵѶѷѸѹѺѻѼѽѾѿҀҁ҂҃҄҅҆҇҈҉ҊҋҌҍҎҏҐґҒғҔҕҖҗҘҙҚқҜҝҞҟҠҡҢңҤҥҦҧҨҩҪҫҬҭҮүҰұҲҳҴҵҶҷҸҹҺһҼҽҾҿӀӁӂӃӄӅӆӇӈӉӊӋӌӍӎӏӐӑӒӓӔӕӖӗӘәӚӛӜӝӞӟӠӡӢӣӤӥӦӧӨөӪӫӬӭӮӯӰӱӲӳӴӵӶӷӸӹӺӻӼӽӾӿ"
.split('')
.sort((a,b) => a.localeCompare(b, 'ru-Cyrl', { caseFirst: 'upper' }))
.join('')
yields
"҈҉҆҅҄҇҃҂АаӐӑӒӓӘәӚӛӔӕБбВвГгЃѓҐґҒғӺӻҔҕӶӷДдЂђҘҙЕеЀѐӖӗЁёЄєЖжӁӂӜӝҖҗЗзӞӟЅѕӠӡИиЍѝӤӥӢӣҊҋІіЇїЙйЈјКкЌќҚқӃӄҠҡҞҟҜҝЛлӅӆЉљМмӍӎНнӉӊҢңӇӈҤҥЊњОоӦӧӨөӪӫПпҦҧҀҁРрҎҏСсҪҫТтҬҭЋћУуЎўӰӱӲӳӮӯҮүҰұѸѹФфХхӼӽӾӿҲҳҺһѠѡѾѿѼѽѺѻЦцҴҵЧчӴӵҶҷӋӌҸҹҼҽҾҿЏџШшЩщЪъЫыӸӹЬьҌҍѢѣЭэӬӭЮюЯяѤѥѦѧѪѫѨѩѬѭѮѯѰѱѲѳѴѵѶѷҨҩӀӏ"