Line-height or H align

[jlami]

I have a problem with the vertical alignment of the characters. This is most obvious when changing the line-height to align the text vertically in block elements. I have made a preview to show the problem: http://jsfiddle.net/Lepsnvy9/1/ The fonts used are from google and I know there have been updates, but when I tried the new versions of the font they all showed this error.

What I expect is that the font would line the middle of the H with the red line. Most other fonts do this. But Crimson I guess has wrong Ascent or Descent? I don't really know how to fix this myself. I will try, but you might have more insight.

[skosch]

jlami, thanks for your message! I'm not entirely sure how to fix this—I've spent too much time already fiddling with ascent/descent values, and still I can't find a combination that doesn't cause problems on at least one device/platform/application combination. I'll take another look at this when I have a free minute or two; if you find a solution please let me know!

[adrientetar]

According to Adobe tables:

• For cross-platform consistency, OS/2.TypoAscender and |OS/2.TypoDescender| must add up to the font's UPM value
• hhea ascender (descender) must match OS/2.winAscent (Descent) for cross-platform consistency

I do not know if it's the case already or not with Crimson.

[jlami]

I do see that hhead ascent does not match the winAscent, but instead matches the TypoAscent.

I also seems to be that woff files (and probably other fonts) exported by FontForge are correct, but when using fontsquirrel something is messed up. And I would like to be able to use fontsquirrel for subsetting (or do you know an easy way to do this with FontForge?)

This is tested with corrected ascents, that is the same settings across different .sdf files and hhead matching win.

[jlami]

I believe the problem with fontsquirrel is that they try to fix the vertical metrics if you don't specify you don't want that to happen. With "Fix Vertical Metrics" off the output seems better. But that begs the question: Is the output now normalized across browsers without that fix? Because they explain that option with "Normalize across browsers"...

The bounding box of Crimson might be a little bit of a problem. But in FontForge I don't know how to check it.

Hopefully since I only need some basic latin (English and French), I don't get any problems. But would like to know what you think.

[adrientetar]

pyftsubset is a good subsetting tool. I too have had issues with Fontsquirrel output in the past.

[jlami]

The problem I have with using custom tools, is that I need a ton to do what Fontsquirrel does in one step. I guess a good toolchain only requires a one time setup, but I'm hesitant to start if Fontsquirrel does work ;)

I do have a uniform line-height now, will do a pull-request soon so you can test it. I don't have a mac to try the fix on, so hopefully one of you can try it there?

[skosch]

@adrientetar, did you have a particular way of building the fonts from the sources? Anything I should be aware of? I'm happy to merge the changes and see if it makes a difference

[jlami]

It might also be worth noting that using the new uniform ascent/descent across the fonts might give a bit of tall line-height. I used this to change to proof/test whether the line-height would be uniform, which it is. But it might be better to find a better/smaller total line-height.

I was reading some google font wiki entries and this one might be good to look at further: https://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations It mentions that all ascent/descent should be equal, while I left the Typo ones the same. And maybe setting the linegap to 0 is also worth trying for consistency.

A bit off-topic: I was wondering how google webfonts make their font files so small in file size. But maybe fontsquirrel has different priorities? They might try optimizing look and feel, and insert/keep other data?

[adrientetar]

did you have a particular way of building the fonts from the sources?

No, I just generated them from FontForge. [Eventually you can reverse path directions, export as UFO and build with the AFDKO.]

[adrientetar]

For #10 it might be good to do remove overlap and round to int before generating, which can be done easily from a script.

[adrientetar]

@jlami According to this document, Win and OS/2 metrics should not be uniform:

http://kltf.de/downloads/FontMetrics-kltf.pdf

[jlami]

Maybe not, but as I read it, the metrics should be the same across the font styles. And for Crimson each style has it's own values now. Which makes it inconsistent for the webfonts when changing font-weight and font-style.

And my pull-request has just these uniform things your document mentions: win and hhea match, Typo is different.

[jlami]

You might want to check the actual win and hhea values with the 'recalculate' button from your pdf. I used values from Fontforge as I did not have the fontlab(?) tools. I think Fontforge might come up with similar values when setting to 'offset' mode and setting to 0, but I'm not sure.