Broken Font/Naming Preview in Design Tools

[alexkaessner]

When using the actual variable font in design tools, the preview of the font is broken. This appears in different levels of severity in common tools like shown below. Strangely some letters appear to have a fallback, while most of them are empty.

I'd expect that the tools ideally show the icons itself. Or alternatively at least fall back to a basic set of letters. Other fonts like Wingdings do this as well.

Figma

Sketch

Affinity Designer

[tphinney]

Oh dear! Thanks for flagging this. The Material Symbols fonts do not have proper alphabetic characters. But they do have placeholders, lowercase slots that are present but empty (like spaces), so they can be typed to create ligatures.

This is confusing your apps. Some are smart enough to sub in Helvetica (or something like that) for the caps which are REALLY missing. But they see the lowercase slots are there, so they try to use them.

I am not instantly convinced it makes sense to fill in all those placeholders with real glyphs (would they get full variation and we would have to support them as full glyphs?). But yes, that is an unpleasant problem and we should see if we can come up with a solution.

[alexkaessner]

@tphinney Thanks for the clarification! Interesting to see that they are used for ligatures. Just for curiosity, do you have an example of such a ligature? I was wondering what ligatures are used for in an icon font.

I am not instantly convinced it makes sense to fill in all those placeholders with real glyphs (would they get full variation and we would have to support them as full glyphs?).

Makes sense. Other icon fonts also don't include the normal characters. Maybe it's possible to use the ligatures with some other characters?

[tphinney]

Clarification: Material Symbols has the problem. Are you saying that Wingdings does not? What about Material Icons (the non-variable fonts)?

It may be there is some metadata we can change that will cause apps to not attempt a WYSIWYG preview, even though the codepoints are nominally supported (but “not really”—admittedly a wonky thing about the font). Specifically, we have been setting the bit Unicode range bit for “basic Latin” support in the OS/2 table. I am going to try turning that off in a test build after the one that is currently underway. See what happens! 👀

As for how/why we have ligatures and what they do… these are not what most users would think of as ligatures, because they are not a merging of multiple letters into one more elegant shape, like the classic “fi” and “fl” ligatures in many western fonts. In Google Symbols, you may notice that you can type an icon name, and it turns into the icon. That is accomplished through the OpenType font feature of “required ligatures” or ('rlig' for us font nerds) so it works in pretty much all apps and is always on without a toggle. At a technical level, a ligature takes a string of two or more characters, and represents them with a single glyph.

[tphinney]

I sent you a DM on Twitter to see about sharing some test fonts. It happens that I have exactly none of the particular apps you are using, and Adobe apps are smart enough to not have any trouble even with the current fonts. (InDesign just uses a fallback font for the name; Illustrator does that, AND manages to find and display icons for the font-showing part.)

(Yes, “Thomas should go license some of these apps that are commonly used by web designers” is a perfectly reasonable idea here. I may well do that in the near future, if app-specific issues not shown in my usual apps become a recurring theme.)

[tphinney]

Shared test files. I am not terribly optimistic that this will do the trick (or quite possibly will help some but not all cases), but it is worth a try.

[alexkaessner]

Are you saying that Wingdings does not?

No Webdings and Wingdings don't have this issue.

Sketch

Figma

Affinity Designer

---

What about Material Icons (the non-variable fonts)?

They have the same issue as the variable font. Here's the example from Sketch, but it's the same for all the other apps.

---

@tphinney Thanks for the clarifications and response. I've checked the Twitter DMs now and will give it a try. 🤙

[alexkaessner]

@tphinney Okay, I gave the updated font from your Twitter DM a shot now. No change – still the same issue.

[tphinney]

Thanks for checking that out for me. Too bad it didn’t help, but that was not a shock. Just wanted to be sure there was no easy solution.

Obviously we can’t drop support for the ligature behavior, as a lot of users are using it.

The obvious solution is to put glyphs into those placeholder empty character slots, the a-z lowercase. We could source them from Roboto.

Although less critical, we could also add the few caps we actually need to do the names of the fonts (I G M O R S T). If we do not do that, those caps will display in font menus in a fallback font, and the lowercase in whatever we put in the icon font, for a more jumbled appearance.

For all these glyphs, any existing glyph width won’t be ideal. The existing placeholders are the same width as the icons, which is to say the full width of the em square. I would suggest for each glyph, using whichever is wider between Roboto and Roboto Mono. Don’t bother varying them on any axis (which also makes their data compress better).

@seasehee1 let me know what you think, or if we should discuss with a broader set of interested parties.

Looks to me like everything involved is Apache licensed, so no complications from that.

[tphinney]

I’ll just add that I realized today that, because of the need for compatibility with existing metrics, probably the added glyphs would have to be caps-only designs. That is, even in the lower-case slots. Because the icons do not have descenders, they do not extend as far below the baseline as letters like gjpqy would. sigh.

[tphinney]

Built, about to test.

It occurs to me that each of the two possible approaches has different tradeoffs.

1) Make lowercase characters real marking glyphs, but do not include uppercase.

• This will have no effect on apps that were doing fine with the font before (e.g. Adobe & Microsoft apps); these apps will still not display the font using its own letters, because they only try to do that if all the needed letters are supported. This is why they did not have problems before.
• Apps that showed fallback for the uppercase slots, and blanks for the rest, would still get fallback for the uppercase, with the font’s glyphs for the lowercase. This might be a bit of a “ransom note” effect and the uppercase might well be sized and spaced differently.

2) Make both caps and lowercase real marking glyphs. This involves adding support for caps to the font.

• Apps that did not try to show WYSIWYG before (e.g. Microsoft Office, Adobe apps) will now use the font’s glyphs. Not sure this is a plus?
• Apps that showed fallback for the uppercase slots, and blanks for the rest, would show real glyphs for all. Definitely improved.

Overall, I think (2) is better which is why I built that—but obviously it is not as simple as one might like.

[tphinney]

I did approach (2) above. After an initial false start, I got something that works OK.

@seasehee1 saw the result and is good with it.

This should be in the next release of Material Symbols. :)

[tphinney]

Done and shipped