Problems with baseline shift when editing text boxes

[cyclopsdx]

I've had this issue for ages now and still cannot find a solution that doesn't involve editing the Text Frame Options on every single text box on a page.

I am working with supplied artwork templates from a specific client in Germany. Whenever I select the text in a text box to edit it, the baseline shifts downwards, throwing off the templated text.

I have researched online and found, by trial and error, the only solution is to customise using Text Frame Options > Baseline Options, then select 'Use Custom Baseline Grid' and set Offset to 'Cap Height'. This re-sets the baseline again but I'm never confident it is exactly the same as the template I have been supplied as I am, essentially, tampering with a client's approved layout.

Is there a permanent solution to resolving this? I know this has been an issue going back quite a few versions of InDesign now and each update is supposed to have fixed this issue but it never has (and yes, I've used the old Preferences trash/re-set fob-off a number of times but this doesn't work, either).

Will this problem ever be resolved? It's not a good use of time to use the workaround every time I create a new file for this client as there are 20 - 30 text boxes on each artwork, which is a lot of extra unecessary editing that I can't bill onto the client.

I need to understand what is happening. Is it not retaining the custom preferences when I try to edit the text? I'm as at a loss as I was with this problem 2-3 years ago.

[Laubender]

Hi Tibo5CBE,

below a comparison, Google Fonts vs Adobe Fonts.

Opened your document with Roboto not installed. The missing font's version is from 2017:

Here a view on the document where I provided the Google Font's Roboto files. The baseline's position is marked with a guide:

The following happens when I substitute the missing fonts with Adobe Fonts. Baseline is somewhere else and the text frame is running into overset. Also note that the font version is totally different and from 2015 now. A mismatch between the two documents:

Regards,
Uwe Laubender

( ACP )

[cyclopsdx]

Hi Uwe

This is an interesting discovery as the client's templates I am having problems with uses the Roboto family also. I shall do some tests to see if that helps me.

Best regards

Eddie

[Tibo5CBE]

Yes, thank you. I disabled the font in Adobe CS. Thank you very much!

[floaton3]

I wasted about two hours today trying to solve this same problem with my own document.

My document uses a locally saved version of the font Omnes, sitting in an adjacent "Document fonts" folder. What I've realised is that when I go to edit a text box, InDesign replaces my local font with the Adobe version synced from the cloud, and the Adobe version has a different baseline setting that lowers it in the text box. (Or maybe it's activating the Adobe version prior to this.) Anyway this is super frustrating.

My solution is to stop InDesign auto-activating Adobe fonts by turning off this setting in Preferences/File Handling/

This is essentially the solution @cyclopsdx and @Tibo5CBE arrived at. It'd be good if their post could be moved to the correct answer position at the top of the page so people can easily see it.

[cyclopsdx]

I can confirm that my issue does lie with the Roboto font. My workaround is still the original fix suggested by @rob day as I have pre-existing projects I still need to manage, but the other solution will resolve the issue from the get-go. This is just one problem we face with cloud-based asset retention and font activation, but that's a discussion for another thread.

[rob day]

Hi @cyclopsdx I haven’t taken the time to reread this entire thread, but a font’s Ascent line is set by the font’s designer, so the problem could occur with any font, local or cloud based, if font substitution is allowed, or different versions of the same font are substituted.

This thread has a more detailed discussion of how the font’s designer might handle the ascent line, which would affect the First Baseline Offset when the default Ascent is used.

https://community.adobe.com/t5/indesign-discussions/baseling-grid-for-font-different-between-adobe-g...

[Intermac5FF4]

I've also recently started encountering this problem, and it's certainly not trivial for us. I am 90% of the way through a 6-month project building an updated catalogue of approx.130 spreads, averaging about 4-5 text boxes per spread plus a couple of tables with anywhere up to 250 cells. We're hard into the review & editing phase so there are lots of edits to do, including duplicate spreads and copied tables, and the print deadline is approaching. The text boxes can start with any one of about 10 different paragraph styles, the table cells another 6 or 7, so there is no one-size-fits-all text box style that I could apply to make the re-alignment quick & easy.

Every edit, copy or duplication results in all involved text being shifted down, resulting in almost all text boxes and cells being overset. This is costing us weeks worth of man-hours to manually correct, reposition and verify everything - I had considered editing the paragraph styles to suit but then all the as-yet unedited text ends up being too high on the page.

I find it hard to accept that the "Correct Answer" can possibly be to manually customise text boxes using the Text Frame options - it would take weeks to implement and double-check every alignment, a serious threat to our print schedule. Furthermore, the cost of the extra time is coming straight off our bottom line.

It's not just the one document affected, our bi-monthly customer magazine often uses recyled & updated content from prior editions. I'm now having to manually adjust the position of every text-containing element that I paste-in-place into the new document, again costing extra time.

I can't be the only one having this nightmare, please tell me work is being done on a proper fix for this unexpected issue, one that can be applied to my existing documents?

[floaton3]

For me this was a font issue. Adobe was substituting the original font used in the document, stored locally, with their version of the font stored in the cloud. The two versions of the font positioned the first line of text differently in a text box. You can stop Adobe's font being subbed in in your preferences. This should be the "correct answer" to this post.

[rob day]

please tell me work is being done on a proper fix for this unexpected issue, one that can be applied to my existing documents?

Hi @Intermac5FF4 , Nothing can be done at the application level because the font’s Ascent, Cap Height, and x-Height used for choosing the text frame’s First Baseline Offset are set by the type designer, not the application.

Consider a common font like Arial. The OpenType True Type version installed with OSX sets the ascent and cap height positions as the same. Here’s Arial on the right and Avenir Next on the left—both text frames have the First Baseline Offset set to Ascent:

[Deluxeokc]

I'm here in February 2024 researching the same issue — Can also confirm that it's now been an ongoing thing over the last couple of years and many updates. I'm experiencing it with Source Sans Pro, which has been our copororate typeface for going on a decade. It's infuriating to me that Adobe continues to ignore this issue (like so many others that have plagued CS to this point). 

[rob day]

It's infuriating to me that Adobe continues to ignore this issue

Hi @Deluxeokc , Read through this thread and the linked thread in my post above. There is nothing Adobe can do about this because the font’s ascent is determined by the type designer not InDesign. Here are two versions of Source Sans from Google with different ascent lines. Source Sans Pro allows space for diacriticals and some padding while Source Sans 3 sets the line on the ascender with some padding but no space for the diacritical marks:

And a different version (3.006) activated from Adobe Type: