Glyphs Panel on Figma

Giuseppe Salerno
Posts: 5
Hello,
I came across this post on Figma’s official forum and believe it’s a feature every designer could benefit from.
If you have a moment, please show your support by leaving a comment or a like:
https://forum.figma.com/suggest-a-feature-11/glyphs-per-font-22915
0
Comments
-
This URL works:
https://forum.figma.com/suggest-a-feature-11/glyphs-per-font-22915
Glyph panels are useful but need to be carefully implemented to maximise text interoperability. Inserting raw font glyph IDs for unencoded glyphs into text is never a good idea, so I’d only encourage Figma to do this if they can do it right.2 -
Glyph IDs won’t even necessarily be consistent between different members of the same family. Back-tracking to find a base encoded glyph plus OT features to get to the selected glyph, whenever possible, is a good approach. Then store that in the text, making it more portable between fonts. Only store the glyph ID when the glyph is both unencoded and not accessible via features.
As best as I recall, this is how Adobe does it. (There was an initial implementation that was more glyph ID heavy... I don’t remember if that even shipped. But we later got away from it, thankfully.)1 -
Adobe’s glyph palettes will still occasionally store GIDs. I’ve not taken the time to diagnose when this happens, but suspect there are limits to the parsing of OTL lookups, and can imagine that contextual substitutions may be hard.
The Adobe glyph palettes sometimes function like character pickers, sometimes like character+layout pickers, and sometimes like glyph pickers.1 -
That is true, but to be fair, the choices made are pretty obvious and predictable 99%+ of the time.
That other part of a percent? John has it right. But why is that? Well, if a contextual substitution is involved, there is no guarantee that the current context couldn’t change and no longer get to the desired glyph. If somebody is using the glyph panel to get to it, they presumably want that glyph—even if it is either not available in the current context, or becomes no longer in the current context later. In such cases, at insertion time, if the only feature route to get to the glyph is contextual, Adobe may fall back to a glyph ID. Sigh.
Leastways, that is what I recall. This was probably ~ 20 years ago. Could test it to be certain.0 -
Type creators could assist the situation by including all alternates in {aalt} even if they are only intended to be deployed by a {calt} rule. Then if someone wants to insert *that* glyph regardless of context, as Thomas posits, then the software can fall back on an {aalt} chain to get to a proper base encoding.3
-
Yes, that would work for many things. I would go so far as to say that cases like this are exactly why 'aalt' is needed/helpful.
Although as “aalt” is intended for 1:1 subs, it would not be suitable for contextual ligatures (or equivalent cases).1 -
Thomas Phinney said:Glyph IDs won’t even necessarily be consistent between different members of the same family.
The only way to store data in a file reliably would be to store character data and some combination of font features.0
Categories
- All Categories
- 46 Introductions
- 3.9K Typeface Design
- 480 Type Design Critiques
- 558 Type Design Software
- 1.1K Type Design Technique & Theory
- 648 Type Business
- 841 Font Technology
- 29 Punchcutting
- 514 Typography
- 119 Type Education
- 319 Type History
- 76 Type Resources
- 110 Lettering and Calligraphy
- 31 Lettering Critiques
- 79 Lettering Technique & Theory
- 540 Announcements
- 88 Events
- 112 Job Postings
- 168 Type Releases
- 171 Miscellaneous News
- 275 About TypeDrawers
- 53 TypeDrawers Announcements
- 120 Suggestions and Bug Reports