Understanding InDesign's First Baseline Offset: Is Ascent Actually Aligned to the Em Square?

[Ciaran25473599uu11]

In Text Frame Options, Baseline Options there's an option to align the First Baseline Offset to a selection of Ascent, Cap Height, x-height, etc.

Left at the default (Ascent), swapping through typefaces it's clear the offset doesn't align to the ascent. As I understand it, it's meant to be the lowercase 'd'. Though I haven't seen an explanation as to why it doesn't align.

It makes me wonder if it instead is aligned to the top of the Em square defined in the design of the typeface. Would anyone have any confirmation or evidence of this?

<Title renamed by MOD>

[Willi Adelberger]

Ascent uses the highest letter. It is different in different fonts. More reliable results you will get with cap height (= H-height). 

[Scott Falkner]

Agreed. I use Cap Height so often I made it the default. To do that cahnge the first baseline offfset while no document is open. This will become the default nor all new documents you create on that device. It will not affect documents you ahve already made.

[mattk79]

Scott,

Thanks for this. I was wondering how to make it default as it’s not in Preferences. But if it doesn’t affect old docs, if I open an old one and want to make changes and it was set to Ascent as default will it then be reapplied as CapX or just stay the same?

I’ve made some painful alignment changes already, but I have tables and every cell is now affected by this. I’m using Sans Source Pro which is ironic because nothing been updated with this font. This is an ID thing trying to simulate font adjustments as it didn’t happen with all my fonts in the document. But now you can’t get a true text center alignment with Ascent. They always mess up what has worked for decades. That’s why I hate updating anything.

Matt Kornegay

[rob day]

Hi @mattk79 , This has come up before with Google fonts that are included at Adobe Type—the Adobe Type versions can have a different Ascent Line than Google’s version. You can check the version number using Find/Replace Font

https://community.adobe.com/t5/indesign-discussions/schrift-h%C3%BCpft-springt-schrift-ersetzen/m-p/...

[mattk79]

Go figure. Should have known. Wish they could just keep it one way.

Matt Kornegay

[Peter Kahrel]

It's built into the font. Some fonts set the ascent to the highest ascent, others leave some space. This screenshot is from the Minion Pro in a font editor, which shows that its top is a bit below the ascent value set for the font. The ascent is the top horizontal rule labelled A in the light-blue box on the left.

[Ciaran25473599uu11]

Interesting! Peter, thank you.

If I understand that correctly, an ascent value (line A) is listed as part of the fonts' features, which InDesign can read. But it doesn't necessarily refer to the ascenders in the font, nor does it mean the ascenders align to this value.

Is this just one of those odd quirks in font design? 

[Peter Kahrel]

Correct, it is one of those.

[Brad @ Roaring Mouse]

" it's meant to be the lowercase 'd'. "

No. Ascent is the designed distance from the baseline to the top of any potential glyphs (accents, etc). Yes, in the old days, ascents were based on the tallest ascender (and any accented glyphs were placed above this line). Nowadays, the ascent is much larger to enclose these glyphs, and have become even bigger as fonts are getting more glyph support; they increase the ascent to accomoodate the new glyphs above the ascenders. Open source fonts are especially bad at this as they keep "tinkering" with the offsets, so the, say, Open Sans you used 2 years ago can be quite different than the one you can download today. This is troublesome for InDesign documents composed based on Ascent if they are opened by somoen using differently designed fonts.

Baselines are also all over the map due to the design of the font, so yes, in the traditional EM square sense, a font with larger descenders will have a higher baseline relative to a font with shorter descenders.

[Peter Kahrel · Accepted solution]

> Nowadays, the ascent is much larger to enclose these glyphs, and have become even bigger as fonts are getting more glyph support; they increase the ascent to accomoodate the new glyphs above the ascenders.

Not exactly. In most fonts (that I have seen) some diacritics, especially complex ones, are above the font's ascender value:

[Laubender]

@Ciaran25473599uu11 asked: "… Is Ascent Actually Aligned to the Em Square?"

Well, the only thing I have to add is that there is also an option to the First Baseline Offset that is not available through the user interface; it can be assigned by scripting with e.g. ExtendScript (JavaScript). Here all the possible options for scripting:

https://www.indesignjs.de/extendscriptAPI/indesign-latest/#FirstBaseline.html#d1e76521

The one that is missing in the user interface is: FirstBaseline.EMBOX_HEIGHT

If one selects a text frame (not the text, the frame itself) one could apply the value with the following script code:

app.selection[0].textFramePreferences.firstBaselineOffset = FirstBaseline.EMBOX_HEIGHT;

From my German InDesign 2024 where the selected text frame is showing first baseline set to EMBOX height. No idea why this option is not available in the user interface, when applied you see an empty field for "Offset" ("Versatz" in German):

Regards,
Uwe Laubender
( Adobe Community Expert )

[Peter Kahrel]

O, yes, that one. I've never found any use for it. It's available also for anchored frames (to position them vertically relative to the anchor point). InDesign's em corresponds to the point size, so in 10-points text the em is 10 points.

[Peter Kahrel]

Just in case you want to align the first line's ascent with the top of the text frame, first get the real ascent's value. You can use the following script. Select an ascender letter and run the script. Note the value.

Then set the text frame's first baseline offset to Fixed and the Min: value to the value you recorded.

if (app.selection.length === 0 
			|| !(app.selection[0] instanceof Character)) {
	alert ('Please select a single character', '', true);
	exit();
}

ch = app.selection[0]
bline = ch.baseline;
x = ch.createOutlines()[0];
realAscent = bline - x.geometricBounds[0];
app.activeDocument.undo();
alert (realAscent.toPrecision(4), 'Real ascent');

[rob day]

Hi @Ciaran25473599uu11 , Also, you can see that the ascender line is determined by the font’s designer (not InDesign), by comparing different versions of the same named font.

Here is the cloud activated Adobe Type version of Roboto compared to the Google freeware version, which I have installed in my user Fonts folder. The AdobeType version sets the Ascender line above the diacritic marks plus some padding, while the Google version sets it on the lowercase ascender:

[Ciaran25473599uu11]

Thank you Rob, another good point in the discussion around this subject.

Seems the answer is another maddening quirk between the design of a typeface (occasionally arbitary position of the ascent) and the function of the program like InDesign.

Perhaps I should put in a feature request for programs like InDesign, Illustrator etc to allow the program to visualise the various constructions line: Baseline, x-height, cap height, ascent and descent. As well as their overhangs and overshoots.

[rob day]

If you are looking for more consistency use Cap or x-height—those lines are less ambiguous.

[Brad @ Roaring Mouse]

What's particularly confusing to some users (who unkowingly have diffferent versions of the same font) is why a document they received from someone else will look fine when they open it, but the moment they attempt any edits, the first line will change position. It's because InDesign (and PageMaker before it) only recomposes the text when it needs to. So, the file has been composed and saved according to the first user's font, and any edits will elicit a recompose to the current user's fonts.

Speaking of PageMaker, this is kinda how we got here. When PM first came out, there was only one opton; the first line of text was always positioned according to the baseline of the first line's leading(line space). This annoyed most of us because there was always space above the characters at the top of stories, making it nigh impossible to line up the tops of stories on a page to the top margin. In later versions, PM tried to address that by coming up with what they called Proportional spacing, where the assumption was made that, on average, 2/3 of the linespace was above the baseline and 1/3 below, so this brought the first line up to eliminate* the space (*depending on the design of the typeface). This became PM's new default, and it annoyed even MORE people, particularly if Auto line spacing (ick) was used.  (There was also a Cap height option, but most usage fell between the other two.)  Thankfully, Proportional spacing didn't carry over to InDesign, but when I had to convert clients' old legacy PM files to InDesign who used Proportional, to make the layouts match, I needed to apply a Fixed space with a minimum equal to 2/3 of the first line leading and everything popped back into place.

[mattk79]

This is what I'm encountering. I've been updating the same document with the same fonts for the last 5 years. Now when I go to edit the same text It drops the First basedline down causing everything to be misaligned. Paragraphs are now showing overflow text. This is now very frustrating as I now have to go and change every text box to a CapX or realign everything in my booklet. This is a total time waste and I never had an issue before now. I can't stand this. 

[Brad @ Roaring Mouse]

I feel your pain. Unfortunately, the rules of type design have changed since these baseline methods were first designed. Back then, it was very rare to have a font with a different ascent definition. Now, that's not at all the case, again, epecially with Open Source fonts; these are made by both legitimate foundries, but also "everybody and their dog" who may not have the discipline of the bigger more established foundries. there's a reason most of these are free.  Open Source fonts are the bane of my existence.

[mattk79]

Oh I’m sure and the difference between TrueType and OpenType adds another nuance.

Matt Kornegay

[rob day]

difference between TrueType and OpenType adds another nuance.

The position of the first Ascent line (as well as the Cap and X Heights) is determined by the font’s designer not the font’s Type (Opentype, Type 1, True Type, etc.).

There tends to be more variance in the Ascent line position—should the ascent line include the diacritics? There is not a lot of agreement among designers—Google’s Open Sans (version 3.003) includes the diacritics, Adobe’s (version 1.1) does not. You have to be careful with different versions of "free" fonts using the same name.

[Brad @ Roaring Mouse]

Old prepress guy trivia:

Anyone who lived through prepress during the period of the beginning of OSX soon discovered there WERE differences between the ascents on some fonts between Type 1 and TrueType... Helvetica being the biggest problem. The ascent on the TrueType version available in OSX (replacing the Type 1 version previously included in the OS) was taller than the Type 1 version, so any client's file* that used Type 1 reflowed when opened on our OSX system that used the TrueType version. It wasn't so much an issue for (then) PageMaker, which calculated type relative to the baseline, but it WAS an issue with InDesign and, even more so, Quark (which (then) infamously calculated all their type relative to the ascent)

* this was back before PDF became a thing for prepress so we were always using native files.

[mattk79]

I can only imagine this. I mean this small seeming insignificant issue caused my two column with 12pt to get pushed outside my text box and then I had to go down to 11.5pt just to barely squeeze it in my page margins. That can be the difference in the readability of the text as 10-12pt is usually the defining line. Otherwise it’s just too small to read.

The frustrating part is I didn’t change the font. I just added the same one to a computer from another computer that it was missing from. Now IND wants to change it or recalculate it when I click on the text or do anything regarding vertical alignment. If I leave it alone it’s fine. Either way, not cool.

Matt Kornegay

[rob day]

...caused my two column with 12pt to get pushed outside my text box...

There are many cases where the text might set outside the text frame. Here I have the First Baseline set to Fixed, which sets the first baseline on top of the frame, and Optical Margin Alignment set to 12 pt, which hangs punctuation outside of the frame

If it realy mattered to me I could do this (the Min amount is font dependent):