View Full Version : Letters Split over Two Pages on iPad / iPhone

07-12-2011, 05:20 PM
I've come across a problem I can't solve with an ePub created with In Design. On pages where the last sentence has any of the following letters (g,p,y) the bottom part of each letter is trimmed off and then at the very top of the next page above the first sentence, you can see the remaining parts of the letters. The font used in the CSS is Arial. If you select any of the different fonts on the iPad / iPhone, the problem still exists.

I've uploaded a screen shot to better illustrate my problem. I've tried editing the CSS (margins and padding for style applied to the affected text) to solve this problem but no joy so far. Does anyone out there have a potential solution or come across this before and solved it?

I'll keep chipping away at it in the meantime just in case I work out a solution myself and thanks in advance for any help provided.

07-12-2011, 06:34 PM
Have you tried viewing it on another NON-apple reader?

07-12-2011, 07:48 PM
Or a 3rd party app on the apple device. It's probably iBooks specific.

07-12-2011, 11:10 PM
Hi all. I fixed my problem:o. First part was to wrap my text using the samp element in my XHTML code as I was declaring fonts to be used. An example is:

<p class="BodyText"><samp>All managers and supervisors are responsible for managing HSE in accordance with company policy as an integral and obligatory duty of their position.</samp></p>

Secondly, I then went through the CSS and removed instances where I had set the line-height as in the following example:

line-height : 1;

I've checked my ePub on iPad and iPhone and the problem is fixed. Hopefully this will help someone else in the future.:)

07-13-2011, 04:47 AM
So your CSS was forcing the text height and when you removed the height size all was OK?

07-13-2011, 03:42 PM
So your CSS was forcing the text height and when you removed the height size all was OK?

I did some testing on a few other ePubs first thing this morning that had the same issue. The only thing I did was remove the line-height statements in the CSS. When viewing the ePub in iBooks there were no instances of the letters being split across two pages. So yes I definitely think the answer was to remove all instances in the CSS of line-height.

I created all my ePubs with InDesign and then tweak them with Calibre and Notepad ++. It appears when I'm exporting the InDesign document to ePub, it is applying a line-height value. It isn't too time consuming to manually delete from the CSS.

07-13-2011, 08:40 PM
I just had a word with our web designer. He hand writes the code and doesn't like dreamweaver type programs that add all kinds of "garbage" as he puts it. He never assigns a line height in his CSS unless he needs unusual formatting. InDesign gives everything 1.2em line height.

07-13-2011, 11:39 PM
1.2em is generally the default line-height used by all css UAs, and it's also regarded as the optimal leading for readability, so there's little reason to vary it except in certain special circumstances. InDesign will apply the leading specified in the paragraph style, but if you leave that on Auto (i.e. 12pt text will have a leading listed as (14.4pt) ) then it will produce a line-height of 1.2 and you won't run into problems with line collisions.

07-14-2011, 05:07 AM
The "optimal" value, and whether there will be collisions or overlaps, depends on the particular font used, i.e. how the glyphs are sized and positioned inside the em-boxes.

07-15-2011, 05:57 AM
The "optimal" value, and whether there will be collisions or overlaps, depends on the particular font used, i.e. how the glyphs are sized and positioned inside the em-boxes.

It actually depends on the measure - the length of the line. Longer measures require more leading so that the reader will be able to locate the start of the next line easily when they scan back to the left. A 6" ereader will generally have short measures though, so 1.2em is about right. If your font is causing collisions at that setting then it's very unusual (or maybe just badly designed), though fonts which have an exaggerated x-height may need more leading to maintain adequate white-space between the lines.

07-15-2011, 09:22 PM
Having said all that, I went and looked a bit closer. And you're right, there definitely are fonts that have problems with a leading of 1.2, especially when dealing with capitals with diacritics, which I hadn't considered previously.

A well-behaved font like Minion handles these just fine, without allowing the diacritical marks to collide with descenders (all pics with a leading of 1.2em):

But fonts that are designed to work at really small sizes can make compromises with their heights that cause bad results:
which looks a bit nasty. It seems self-defeating to design a font to allow people to cram as much text into as small a space as possible and then include things like this which will force the typographer to increase the leading, but there you go.

07-18-2011, 02:01 PM
There are font where all glyphs fit in the em-box, so even with a 1em leading there are no collisions. There are other fonts where the ascenders or descenders extend outside the em-box (calligraphic fonts are often in this case), and they need more that 1em leading to absolutely avoid collisions, exactly how much depends on the font

07-19-2011, 01:30 AM
It seems this isn't restricted to specialist fonts either, see

After doing a bit of digging, it seems the real problem is the lack of standards in this area. The best guide I could find for the best practices is this article (, which makes it clear that none of the specifications make any requirement about vertical height: "In fonts with very large ascenders or descenders, the default line distance will be accordingly large. This should be acceptable - designers will set leading manually anyway." So in other words, the specs assume that the font will be set manually, with someone adjusting the leading to suit.

The only spec that provides any guidance on vertical font size for applications in which the leading will not be adjusted manually is provided by Microsoft (

On taking a closer look at the properties of Minion, which like all the Adobe fonts I've used is well-behaved and doesn't spring any surprises, it turns out that it follows the MS spec exactly: OS/2.sTypoAscender = 727, OS/2.sTypoDescender = -273 and OS/2.sTypoAscender - OS/2.sTypoDescender = 1000 = specified UPM with OS/2.sTypoLineGap set to 200 (1.2 x UPM). Lexicon, on the other hand, has a UPM of 1000, but OS/2.sTypoLineGap = 76 (!) and OS/2.sTypoAscender (814) - OS/2.sTypoDescender (-307) = 1121. So the line collision is baked into the font itself.