TrueType font glyph positioning

[BobDickinson]

The glyphs in the TrueType font are positioned oddly, which makes them very hard to use in conjunction with other text (such as when trying to place an icon next to some text). The glyph icon should fill the box from the baseline to the cap height line. When done this way (as all other symbol fonts are), it makes it easy both the baseline align the symbol with text of comparable size, or to center align the symbol with text of any size.

With the glyph jammed up at the top of the box (the top of the glyph seems to be above the cap height line, and the bottom is well above the baseline), it's pretty much impossible to align the symbol with text without manually tweaking it. This turns out to be a huge pain (the amount of padding you have to add to fix it is proportional to the height of the font, so you have to do second/deferred layout pass to compute that).

Attached is a screen shot showing the font box and how normal text, normal symbols, and the Material Design icon symbols occupy it (I did this in Microsoft Word, so none of that oddness is due to code - that's how the font presents).

[BobDickinson]

I looked through the repo to see if I could find the script/tool used to generate the ttf (and other) fonts, but could not find anything. If everything used to generate the fonts was in the repo, then I'd be happy to take a look at it.

[jestelle]

Thanks for the feedback @BobDickinson

We actually thought about this some when designing this font, and made the choice that we wanted our icons to behave as similarly to images as possible (for better or worse, w.r.t., text alignment).

I'm not sure it'd be possible to accomplish this and have the kind of font metrics required to allow the icons to also naturally align with text.

I tested this in an experiment here: http://output.jsbin.com/xovopa which also elaborates on what I'm describing here.

@davelab6 is this something you could help advise us on? cc @shyndman and I will discuss and see what we could do.

Re: tooling We have considered releasing our toolchain that we used to create the font. We generally like the idea of doing that, just haven't had the time to poke at it.

[davelab6]

Perhaps you could have another set of opentype substitution triggers, similar to those used already, that call repositioned glyphs.

[shyndman]

Would that mean duplicating glyph definitions, or is there a leaner way?

[davelab6]

The outline data wouldn't be duplicated, the 'child' glyphs would be components of their 'parents' with offsets

[shyndman]

Neat!

[davelab6]

There might also be a possibility in vertical kerning - that is, GPOS rules instead of GSUB rules - but that is advanced magic. :)

[BobDickinson]

@jestelle - Thanks for the explanation.

I am trying to use these icons to create push buttons with an icon and a text label, in a horizontal layout with the icon on the left and the text on the right (think the Facebook "Like" button). This is a pretty common use-case of icons in mobile. I am doing this for our mobile app development platform, meaning I'm doing it on iOS, Android, Windows, and Web/HTML. Android and iOS were pretty easy using the images. Windows and Web (both using fonts) were both somewhat painful, and require fairly ugly workarounds that still don't produce perfectly aligned elements.

FWIW, when I had this problem with web, I looked at #121 and #206 to get some hints. Both of those issues could benefit from your positioning workaround (from your jsbin):

.with-text {
  vertical-align:middle;
  transform: translateY(-.1em);
}

That transform is certainly better than using padding-bottom to cheat it up (the fixed padding approach didn't scale well).

The problem I filed this issue on was with using the TrueType fonts in a Windows Universal app (which seems to me to behave a bit differently than your web font example - not sure if it's the font or the way Windows renders the font). In my case, when I create a text control with the TTF, it renders the glyph inside of the text box element similar to what I showed in my screen grab. It looks like the image is padded on the top and bottom, with the bottom of the padding extending to the baseline. So unlike the web font, where you get a tight box you could use to position the text as a graphic, what I get on Windows with the TTF is a box with the glyph sort of "in the upper part". If I had font metrics I could compute distance from the baseline to the top bearing line, subtract the ratio of padding (assuming I knew what it was), and compute the top/middle/bottom position of the glyph within the control for positioning. Note that getting access to font metrics on Windows is a moderate pain if I go down that path.

I'll qualify this to say that I don't know your use cases for the current way the symbol fonts are constructed, and those may very well be valid and more important than mine.

But I will say that, on Windows, icon presentation is generally done using symbol fonts (as opposed to iOS and Android, which are mainly bitmap/image-based). All of the layout tools and techniques on Windows assume a TrueType symbol font with the glyph in the cap height area (such as the default Windows app symbol font - Segoe). I did a quick review of symbol fonts installed on my Windows and Mac machines, and they all seem to place their glyphs in the same way.

I sort of feel like using the TTF in a Windows app as a text element, and using the web font in text elements (such as button elements with an icon and text) are pretty mainstream cases for using the icon fonts, and I personally wish the alignment with text worked out of the box. I might argue that if that's not what you want, you've got the SVG sprite sheet option (which is pretty comparable, and will work in a way that's unsurprising if what you really want is a package of compact, scalable images).

[farwayer]

I had the same problem with mobile development. It can simply (but still ugly) be fixed with some type of align. But sometimes it is not possible to manipulate glyph offset: (i3 status bar). All ok with other icon fonts (FontAwesome, Ionicons) but not with Meterial Icons. It will be nice to have correct positioning out of box.

[cami-dev]

Seems this still isn't solved quite important for web developement that the icons align easily with the text. Seems it's only material icons who have this issue so can't be hard to solve. Just look at what others do like fontawesome or something. Does anyone have a good workaround other than overwriting the css manually for each icon?

[mil-ad]

is there a workaround for desktop applications (as opposed to web/css)?

[tphinney]

The ideal shift amount will vary based on:

• the current point size
• what typeface you are aligning Material Icons with
• whether you are aligning the icons with caps, or with lowercase

CSS on the web allows you to get around things varying by point size (by using scaling based on the em), but the other factors do not go away completely, I don’t think.

Cap heights of fonts commonly vary by +/- 10% or more from a theoretical average height (of about 2/3 the point size), and a minority vary by quite a bit more.

[tphinney]

I think this is as resolved as it is going to get. I will note that the icons are essentially centered on a central point, like ideographic characters, rather than having a baseline like western fonts.

If folks think there is more to be done here, please let me know, but I am closing this for now.

[tphinney]

I keep on thinking about this. A standard shift of about -.145 of the em to match with Roboto, or somewhere around -.14 to -.18 to match with an average random other font, would work to center the icons against the cap height. Of course, cap height is not standardized across fonts, and commonly varies by as much as 10% from the average.

You’d still need a different shift to align with lowercase. Would aligning with caps be the right thing? Would it be handy if there were a built-in way to call the right amount of shift to match Roboto caps, in the font?