Google Font and Adobe Font line-height Discrepancies

[#1]

I'm a UI designer who works with a team of graphic designers and we have this problem:

When designing pages in XD that use Google Fonts (that my developers will use) there is an inconsistency in leading between Google Fonts directly from Google and Google Fonts that are loaded into Adobe Fonts. I tell our designers to deactivate Adobe Fonts when designing a page that needs to use free Google Fonts because it won't match up for the developers when coding. But it's been difficult to remind all the designers and production artists since they also work on print designs. So my question is, why the change in line-height/leading?

In my screenshot you can see on the left is Roboto Bold activated through Adobe, and on the right is my local copy of Google's version. The reason you can't see the last line of copy is due to the text box being too short for the Adobe version of the font.

I have come across this problem with other Google Fonts as well but can't remember off the top of my head.

Thanks in advance for looking into this!

-Diana

EDIT: Appears to be the baseline instead of leading. Please see comments.

[#2]

I'm a UI designer who works with a team of graphic designers and we have this problem:

When designing pages in XD that use Google Fonts (that my developers will use) there is an inconsistency in leading between Google Fonts directly from Google and Google Fonts that are loaded into Adobe Fonts. I tell our designers to deactivate Adobe Fonts when designing a page that needs to use free Google Fonts because it won't match up for the developers when coding. But it's been difficult to remind all the designers and production artists since they also work on print designs. So my question is, why the change in line-height/leading?

In my screenshot you can see on the left is Roboto Bold activated through Adobe, and on the right is my local copy of Google's version. The reason you can't see the last line of copy is due to the text box being too short for the Adobe version of the font.

I have come across this problem with other Google Fonts as well but can't remember off the top of my head.

Thanks in advance for looking into this!

-Diana

EDIT: Appears to be the baseline instead of leading. Please see comments.

[#3]

I am checking with the team to see if this is a known issue. I will get back to you if the team needs more info.

Thanks,

Preran

[#4]

Thanks, Preran! According to the closer look from Peter below, it appears it may be the baseline instead of leading. I've included more info in my comment to him below.

[#5]

I overlayed the two text parts in Photoshop (one with 70% opacity) to find out how much it differs. But apart from the vertical position being a bit imprecise, and slightly different anti-aliasing of the rendered characters (due to system, tool, and browser differences), I don't see a difference in leading / line height ! The fact that the bounding box (DIV) is cutting off the third line, can have other causes, but line height isn't one of them...

Note: I intentionally offset the parts a tad horizontally, so it's easier to see the vertical differences.

[#6]

I see what you are saying and its probably the baseline. It's a significant shift when turning one set of fonts on or off. It also seems to only apply to certain font sizes. In my original attachment, I cropped the screenshots to focus on the missing line of text but I've attached my original screenshots with a multiplied layer as a GIF and static image below. You will see in areas where Open Sans is used (main headline 'Mowing to Make a Difference" and the green subhead "Rodney Smith Jr. was a...") the fonts do not shift. Everywhere else, Roboto is being used. The DEK copy "A chance encounter..." is 30px regular, the citation is 16px italic, body copy 20px light, and call-out is 30px bold.

So, it's probably the baseline, but only for certain font-size and/or weights? Head-scratcher...

[#7]

To help you out a little more, the baselines might differ a bit between tools (not fonts). So when the first baseline in the text frame starts at a few pixels lower, and the text frame is very tightly measured, then this overshoot might happen. Use a flexible height for the text frame in CSS, or at least some extra height, to accomodate such differences.

[#8]

Judging by the slight but very clear 1 pixel differences in your example, it might have something to do with the rounding off of certain browsers. Font measures and line widths in web browsers are constantly being related and calculated between the intended size and the amount of device pixels. As Eric Meyer already described in this 10 years old article, such measures are being rounded off to integers. This might lead to any kind of slight visual difference in size, line height, et cetera.

Browsers also use different types of font anti-aliasing, which also often causes type to look a tad bolder or lighter than expected.

Stop scratching your head – these are the structural imperfections of the web we need to live with... 😉

[#9]

I think we may not be on the same page, haha. This example is strictly within XD, not in browsers or prototype mode.

[#10]

Diana, you're RIGHT !

I drifted onto the wrong page in the discussion, but I'm back on track, with a vengeance !

I created some text samples (at 64/84) with the Adobe and Google version of Roboto.

First I activated the Adobe CC Fonts version, deactivated it, and then installed the Google TrueType version.

These are the separate samples:

I shortened the lengths of the frames to show exactly the third line, not one pixel extra.

Then I created an overlay with the text aligned, to check once again any difference in leading:

No difference in leading – but the positioning of the frames is completely off !

You can also see that one pixel extra length, the Adobe version requires to show the third line.

When the frames are top-aligned, the difference is totally clear:

I also tested it with another Adobe and Google version of another font combo, the Kaffeesatz:

There's definitely something fishy in the baseline starting point of such fonts...

[#11]

Out of curiosity, I added another OpenType system font to the comparison:

There are differences in character heights, of course. But the baseline starts again at a different height...

[#12]

Hi Peter,

This is such an interesting discussion, and your insights are amazing, although my lack of experience with using Google fonts is a limitation in understanding the whole situation.

Do you thik I whoudl be logging a bug for this issue with the product team? I am not even sure if this is a workflow that the team supports, or intends to support in future.

Thanks,

Preran

[#13]

Wondering when this will be fixed... we're still experiencing this exact same issue using InDesign.