Glyphs Panel on Figma

Giuseppe Salerno
Giuseppe Salerno Posts: 5
edited August 6 in Miscellaneous News

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

Tagged:

Comments

  • John Hudson
    John Hudson Posts: 3,487
    edited August 6
    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.
  • Thomas Phinney
    Thomas Phinney Posts: 3,063
    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.)
  • John Hudson
    John Hudson Posts: 3,487
    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.
  • Thomas Phinney
    Thomas Phinney Posts: 3,063
    edited August 6
    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.
  • Kent Lew
    Kent Lew Posts: 1,008
    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.
  • Thomas Phinney
    Thomas Phinney Posts: 3,063
    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).
  • Peter Constable
    Peter Constable Posts: 264
    edited August 12
    Thomas Phinney said:
    Glyph IDs won’t even necessarily be consistent between different members of the same family. 
    Glyph IDs won't even necessarily be consistent between different versions of the very same font!

    The only way to store data in a file reliably would be to store character data and some combination of font features.

Categories