Aligning Text Across Facing Pages

[Jellby]

Originally Posted by Interrobang

If specifying line-height, extra spacing between text blocks and any padding around images should be a multiple of the specified line-height to keep text aligned across the spine.

"Should" is not "must", but anyway...

"If specifying line-height". You should not do that, so the rest can be ignored.

"extra spacing between text blocks and any padding around images should be a multiple of the specified line-height". This is easy to comply with. You set line-height to, say, 1.2, and then set extra padding to 0.6... oh, wait, they mean integer multiple. Well, set the padding to 1.2 or 2.4

"to keep text aligned across the spine". Nonsense. This won't happen (except maybe in some very specific broken applications). It might work with some vanilla code, but first, line-height works weirdly (and you should not specify it, and the user can change it), elements with different font size will alter line spacing, then they don't say what's the image size, or what to do with margins.

[Quoth]

Originally Posted by Jellby

"Should" is not "must", but anyway...

"If specifying line-height". You should not do that, so the rest can be ignored.

Exactly. None of the stuff we have on Apple Books has any line-height properties.

Also we use Smashwords/D2D to publish on Apple, Kobo and Barnes & Noble.

[jhowell]

According to the change log that requirement was added to the Assets Guide in version 4.8 dated December 8, 2011. I suspect that it made more sense then given the simpler e-book formatting that was common at that time.

Or perhaps it was added by someone with a print book background and a poor understanding of HTML/CSS.

[Tex2002ans]

Originally Posted by Jellby

It might work with some vanilla code, but first, line-height works weirdly (and you should not specify it, and the user can change it), elements with different font size will alter line spacing, then they don't say what's the image size, or what to do with margins.

Yep. Throw in:

• a formula or two
• + a chart/graph and a caption
• + footnotes
• + superscripts/subscripts
• + all sorts of "weird" things...

If you have entire pages of pure text + an occasional heading—like a Fiction book—it's a little easier.

But deal with Non-Fiction, and trying to enforce grid-based layouts... you'll be pulling your hair out in no time! :P

Originally Posted by jhowell

Or perhaps it was added by someone with a print book background and a poor understanding of HTML/CSS.

Yes, I'd suspect this too.

Even carryovers from a lot of their InDesign->iBooks / physical book workflows.

- - -

And... bleedthrough is one of the big reasons "grid-based" is/was pushed in certain books.

With thin paper (or certain lighting conditions), you could SEE THROUGH the physical pages. So, you might flip open a book and see:

• pages 10 + 11

but "the back" of each page:

• page 9 = back of page 10
• page 12 = back of page 11

you might see page 9/12's "grayish/see-through text" overlapping in-between lines on your current page—this may have gotten distracting to some people.

Aligning all text on the grid would mitigate some of that problem...

But that issue DOES NOT EXIST in ebooks.

- - -

Complete Side Note: Another interesting "grid-based" rabbit hole I've been researching recently is CJK typography.

In CJK text, aligning on a grid becomes much more important, and a heck of a lot more complicated than the simple Western languages.

If you want some technical details, see the fantastic images/discussion in:

• KOReader Issue #6162: "Chinese, Japanese and Korean typography: some questions"
• KOReader Issue #6078: "Character spacing is so large and messy when displaying Chinese"
• W3.org: "CSS and International Text"
• W3.org: "CSS Inline Layout Module Level 3"
• My 2020: "Should Chinese Fonts be Embedded in Ebooks?"
  
  • Especially Post #8 where I linked to layout/typography talks. (LibreOffice/Harfbuzz)
    

Auto-Translation is another reason why I don't like messing too much with overly-complicated book CSS.

If a reader Auto-Translated from English->Japanese, and you implemented all this complicated (and "Western-focused" CSS layouts)... it would interfere with the translated text!

In physical books, you don't have to worry about readers wildly changing the underlying formulas.

But in ebooks, users can be interacting and flipping all sorts of bells and whistles, completely changing the look of your ebook.

(And, as Hitch has previously explained many times—most users ARE NOT "using the Publisher defaults" on their devices.)

For more info on that, also see my recent:

• 2021: "Italics and Bold"
  
  • Where I discussed "emphasis dots" (Japanese) / "stretchy letters" (Arabic) and other language differences.
    
    • Side Note: LibreOffice recently closed this emphasis dots layout bug. You can see how things also get weird depending on horizontal/vertical writing.
      
• 2023: "Semantic markup question!"

[Jellby]

Originally Posted by Tex2002ans

With thin paper (or certain lighting conditions), you could SEE THROUGH the physical pages. [...]

But that issue DOES NOT EXIST in ebooks.

There is ghosting with e-ink, though

[AlanHK]

When laying out a book for print, you do this by making sure that all elements are a whole number of the same unit high. So if the body text is 11 pt with 14pt leading, then a heading may be 16 pts on 28 pt leading, with 14 points top margin. I.e., for this book, everthing is a multiple of 14 points high.

But ebooks, the reader can override or ignore much of your formatting, so it's a lost cause, and few read books two-up anyway.

[Quoth]

Originally Posted by AlanHK

When laying out a book for print, you do this by making sure that all elements are a whole number of the same unit high.

No, you basically do it by Register = True (in Wordprocessor), though obviously the spacing of some styles will be unexpectedly wider depending on the font and margins and line spacing.