Skip to main content
Participant
February 2, 2022
Question

Baseling grid for font different between Adobe/Google font

  • February 2, 2022
  • 5 replies
  • 1974 views
The baseline grid start value for Open Sans is different if the font is used from Adobe than if it's used from Google.
This results in changes in layout which is very annoying. Also, when telling indesign to for the box to text, the box is unnecesary larger at the top.
Before the 17.0 InDesign update that wasn't the case. Is anyone else experiencing this?
This topic has been closed for replies.

5 replies

Community Expert
February 7, 2022

Hi Brad and Rob,

thank you both for looking into this issue.

I'll revisit another case with the Roboto font family we had last year.

 

Regards,
Uwe Laubender

( ACP )

rob day
Community Expert
Community Expert
February 7, 2022

Hi Uwe, it looks like Roboto is using the font’s total ascent. Here it is compared to Robert Slimbach’s Acumin Variable, which has it set at the lowercase ascender:

 

Brad @ Roaring Mouse
Community Expert
Community Expert
February 6, 2022

I have cracked open each version to take a look at their internal specs. There is indeed a difference in the ascent defined within each. It's much smaller in the version available from Adobe. Although that is also Google font, it's only v1.00/1.10. The version that Google is supplying directly is currently v3.000 with a much larger ascent specified. Since, normally, the acsent defined in a font takes into account for the glyphs with accents, etc, my guess is Google tweaked the ascent between versions.

Hence Indesign is reacting appropriately according to which version you are using. As said by others, stick with one set and be done with it. Better yet, never use Ascending as the default baseline.

Also of note: The AF-supplied version has different underline specs (v1.10 is fatter) and diacriticals are in slightly different positions.

rob day
Community Expert
Community Expert
February 6, 2022

Hi Brad it looks like some type designers choose to include diacritics, while others define the ascent as the top of the lowercase characters. Seems like most Adobe designed fonts (Minion, Myriad, Adobe Garamond, Caslon, etc.) do not include the diacritics:

 

Brad @ Roaring Mouse
Community Expert
Community Expert
February 6, 2022

Oh, they're in there (in the Adobe-supplied version). My guess is they original designer (Ascender) didn't account for them in their first version, but that has been since corrected.

This is the second time i've seen differences in the Google fonts that were given to Adobe and the ones Google supplies directly, and it comes down to the the fact the Adobe supplied ones were older versions. Why they aren't keeping up to date is beyond my understanding of the licensing agreements between them, but, yah, this is causing issues!!

Another issue I found with Open Sans, is that the Plain "Regular" font has a different internal name between Adobe and Google, so they can accidentally be activated at the same time, which is nerver a good thing

rob day
Community Expert
Community Expert
February 5, 2022

It looks like Adobe licensed Open Sans from Google and converted it to Open Type. The Adobe OTF version’s ascender line is at the lower case ascent, and the Google TT version has the ascender line to include diacritical marks:

 

 

 

 

Community Expert
February 5, 2022

Hi Friederike,

I know. What version of font repository will fail depends of the font of the repository you start out.

If you start out with Google Fonts' Open Sans, the version of Adobe Fonts will fail. If you start out with Adobe Fonts' Open Sans and substitute Open Sans with the Google Fonts version, the Google Fonts version will fail.

 

Simply a bug with the default value "Ascent" for the Start First Baseline Offset in a default text frame.

 

What can one do?

[1] Never substitute fonts.

[2] Use a different setting for Start First Baseline Offset in your text frames.

Never use "Ascent", instead use perhaps "Cap Height".

 

FWIW: I assume my post in this other thread is marked as "Solved", because I detected the cause and showed a workaround. My answer was not meant as a bug fixing attempt. I'm not part of the devoper team; just an InDesign user like you are.

 

Regards,
Uwe Laubender

( ACP )

rob day
Community Expert
Community Expert
February 5, 2022

Hi Uwe, I’m also seeing it in CC2021, but it looks more like a problem with the Google TT font than an InDesign bug:

 

Here the Adobe OTF version behaves as expected, the text‘s Leading is set to 14, so the first baseline aligns to my 14pt baseline grid. The x-Height and Ascent Offsets also align as expected:

 

 

 

 

 

The Google TT version seems to have a different Ascent metric:

 

 

 

 

 

 

 

But the Ascent line is dependent on the font:

 

Participant
February 2, 2022

Someone else complained about this in november - https://community.adobe.com/t5/indesign-discussions/text-boxes-need-to-be-enlarged-after-update/m-p/12550243#M455201 - the issue there is marked as solved, but it wasn't solved actually.

 

but the issue started with 17.0, actually i was really hoping it would have been addresses in this recent 17.1, update, but unfortunately it wasn't fixed.

Randy Hagan
Community Expert
Community Expert
February 5, 2022

Please don't take this badly, but what's to fix?

 

One font from one type house works consistently one way. That font, named the same, created and distributed by another type foundry, consistently works another way.

 

Both fonts work fine. But they don't work the same way. The only "fix" needed is to use just one version of the font, from just one type source, and there will be nothing further that needs "fixing."

 

Jus' sayin' ...

 

Randy