07-12-2011, 05:20 PM | #1 |
Junior Member
Posts: 9
Karma: 10
Join Date: Jul 2011
Device: iPad / iPhone
|
Letters Split over Two Pages on iPad / iPhone
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 | #2 |
Addict
Posts: 351
Karma: 70000
Join Date: Jul 2010
Location: Australia
Device: ADE, iPad
|
Have you tried viewing it on another NON-apple reader?
|
Advert | |
|
07-12-2011, 07:48 PM | #3 |
Media Bloke
Posts: 2,381
Karma: 113956855
Join Date: Sep 2010
Location: NSW - Australia
Device: iOS
|
Or a 3rd party app on the apple device. It's probably iBooks specific.
|
07-12-2011, 11:10 PM | #4 |
Junior Member
Posts: 9
Karma: 10
Join Date: Jul 2011
Device: iPad / iPhone
|
Found a solution.
Hi all. I fixed my problem. 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. Last edited by coldplayplayer; 07-13-2011 at 01:24 AM. |
07-13-2011, 04:47 AM | #5 |
Media Bloke
Posts: 2,381
Karma: 113956855
Join Date: Sep 2010
Location: NSW - Australia
Device: iOS
|
So your CSS was forcing the text height and when you removed the height size all was OK?
|
Advert | |
|
07-13-2011, 03:42 PM | #6 | |
Junior Member
Posts: 9
Karma: 10
Join Date: Jul 2011
Device: iPad / iPhone
|
Quote:
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 | #7 |
Media Bloke
Posts: 2,381
Karma: 113956855
Join Date: Sep 2010
Location: NSW - Australia
Device: iOS
|
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 | #8 |
Wizard
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
|
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 | #9 |
frumious Bandersnatch
Posts: 7,514
Karma: 18512745
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
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 | #10 |
Wizard
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
|
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 | #11 |
Wizard
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
|
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 | #12 |
frumious Bandersnatch
Posts: 7,514
Karma: 18512745
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
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 | #13 |
Wizard
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
|
It seems this isn't restricted to specialist fonts either, see http://typophile.com/node/19130.
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. |
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Classic Split PDF pages into smaller pages (images into tiles) | Astro | Barnes & Noble NOOK | 4 | 06-12-2020 10:56 AM |
Plugin to split pages down the middle | metafractal | Plugins | 5 | 12-12-2010 10:21 AM |
How do I split two pages into one? | Christopher888 | 4 | 11-20-2010 02:21 PM | |
Split pdf pages down the middle | Blue_Alien | Calibre | 3 | 08-15-2010 11:12 PM |
Is there a tool to split pdf pages? | MosFet | Sony Reader | 3 | 06-19-2007 09:48 AM |