List of epub formatting "don'ts"

[JSWolf]

Originally Posted by dgatwood

This one, I disagree with. Here's why. Setting line height can make certain things possible. For example, drop caps. If you don't set the line height, it becomes highly dependent on the font, which means that changes to your font result in severe formatting breakage.

Also, for some fonts, the calculated line height ends up being less than 1.2, and if you don't force it up to 1.2 either by redesigning the font or by setting line-height, you'll end up with different layout in different readers. (Oops.)

So instead of saying "don't set it", I would say that if you are going to set the line height, never set it to less than 1.2 (many readers will ignore it if you do) or more than about 1.5.

I would also add that the typical calculated line height for 99% of fonts is approximately 1.2, so if the font you're using requires a much larger spacing to be readable, you probably chose a lousy font.

I have to disagree with you here. 1.2 for a line-height can be just too large and make the lines look too spaced. A good line height depends on the font in use. Also, Kobo defaults to a line height of 1.3 which is even worse then 1.2. So you have to set a line height there or you get large gaps. I actually like Charis SIL set at a line height of 1.0 which is the default for most ADE versions (Desktop and Sony). I do remove line height when it makes the text too big or I adjust it if needed to make the lines closer.

[JSWolf]

Originally Posted by Man Eating Duck

If your font is broken, I suppose you might correct that, but that sounds like a very badly wrought font which you maybe should avoid in the first place.

The metrics for a font have multiple values which can be used for rendering the space between the lines. For example, ADE (Desktop and Sony) uses a different value then the KF8 does on eInk Kindles. So I can adjust a font to have different lines heights based on ADE or KF8.

[Man Eating Duck]

Originally Posted by JSWolf

The metrics for a font have multiple values which can be used for rendering the space between the lines. For example, ADE (Desktop and Sony) uses a different value then the KF8 does on eInk Kindles. So I can adjust a font to have different lines heights based on ADE or KF8.

Ok, maybe I'm a bit sensitive to line height, as I've worked with a lot of print books.

I've never seen an epub where re-setting the line height to default didn't yield a pleasant result, though. And to me, increasing the height with something so drastic as 20+ % looks very strange, hence my advice would still be to leave it at default.

[Toxaris]

Originally Posted by Tex2002ans

There are a few, like JPEG2000.... but they are very poorly supported (and no way that they would work in EPUBs).

Oh, I would be very surprised if it would work. It was just for the sake of argument that JPEG is not always lossy.

[DaleDe]

Not in every case. You can just strip EXIF data without effecting the actual image, but yes... in most cases (and when most people open in an image editing program/save again), this is what happens. Lossy formats should ONLY belong to the very end of the production chain, and never anywhere in between.

Regarding my comment on how jpeg works. I would agree that strip EXIF data is capable of being done without changing the image file. It can also be added as can comments to the file. However, the instructions talked about saving as a web picture which is saving the jpg file itself, not just stripping the data. so I stand by my statement that in the context of the recommendation you should be aware that when you save a jpg you are creating a new one. I was answering a question as to why the file got bigger and it was taken out of context.

Dale

[Agama]

Originally Posted by Man Eating Duck

I don't agree with the point made by Agama in reply to your post either. Even if you have occasional superscripts which can erroneously cause a few lines to be rendered with too much space on some readers (my prs-650 does this), that's no reason to style *every* line wrongly. No, this one definitely stays in the list

I wasn't referring to occasional superscripts but something like the Bible which has verse references as superscripts throughout. For such an exceptional case of superscripting it is definitely worth specifying a line height, otherwise the text just looks a mess.

[SBT]

Originally Posted by Agama

I wasn't referring to occasional superscripts but something like the Bible which has verse references as superscripts throughout. For such an exceptional case of superscripting it is definitely worth specifying a line height, otherwise the text just looks a mess.

I've ended up instead redefining superscripts, something like

font-size:0.6em;
vertical-align:top;

[Man Eating Duck]

Originally Posted by Agama

I wasn't referring to occasional superscripts but something like the Bible which has verse references as superscripts throughout. For such an exceptional case of superscripting it is definitely worth specifying a line height, otherwise the text just looks a mess.

Ok, granted, but formatting a bible is a pretty exceptional use case. As implied in my OP, the target group for my list is the "cookie-cutter" creators of retail epubs, for which I still recommend not changing those values. For highly specialised tasks you will of course have to make your own decisions, and not just regarding line height

There are also CSS tricks you can employ to make superscripts behave better, but AFAIK you won't get them to render completely correctly regarding line height.

Edit: Ninja'd by SBT

Originally Posted by SBT

I've ended up instead redefining superscripts, something like

font-size:0.6em;
vertical-align:top;

I might add that some very quick testing in ADE seems to indicate that it might render even better with a superscript span with line height of zero (So much for my crusade against ever changing line-height...):

span.ebook-superscript { 
    vertical-align: super; 
    font-size: 0.6em; 
    line-height:0;
}

and html

a footnote after the following word<span class="ebook-superscript">1<span>

I shall add this as an exception in my list

[Agama]

Originally Posted by SBT

I've ended up instead redefining superscripts, something like

font-size:0.6em;
vertical-align:top;

I ended up using

font-size:0.7em; vertical-align:0.25em

to get slightly larger text for the superscripts but dropping down the vertical align to avoid a very large line height to accomodate them. (This allows me to use paragraph line-height of 1.4)

[Jellby]

I often use "line-height:0" for superscript, so they don't mess with actual line heights (there may be some collision from time to time, but I can live with that).

[JSWolf]

Originally Posted by Man Eating Duck

Ok, maybe I'm a bit sensitive to line height, as I've worked with a lot of print books.

I've never seen an epub where re-setting the line height to default didn't yield a pleasant result, though. And to me, increasing the height with something so drastic as 20+ % looks very strange, hence my advice would still be to leave it at default.

When you work with print, you can lay it out as you want and set the line height as you feel appropriate.

Now, when you work with an ePub, if you do not set a line-height specifically, you are at the mercy of the font's metrics and the reading apps default value. For example, Sony uses a default line height of 1em. Kobo uses 1.3em. So the same book with no set line-height will be different because of the default settings. And then even on the same device, the metrics of the font also dictate how the line height comes out.

So if I was to move my ePub over to a Kobo, I would have to set a line-height in CSS or end up with a line-height too big for my liking.

[JSWolf]

Originally Posted by Agama

(This allows me to use paragraph line-height of 1.4)

Do you mean 1.4em between paragraphs or 1.4em between lines? In either case, I'm going to have to take that out. Way too large.

[Agama]

I mean P { line-height:1.4em } but this is measured from the top of one line in the paragraph to the top of the next line in the same paragraph, (i.e. it is not the space between the bottom of one line and the top of the next), so given that the font accounts for 1.0em this doesn't lead to too much space between the lines and it stops uneven spacing due to the superscripts on some lines and not on others.

As I mentioned earlier this is only for books with lots of superscripting such as the Bible, otherwise I would use a smaller value as it does use up more screen space than is ideal.

Image attached shows a small sample from the ESV Bible, (as permitted in the copyright notice), with paragraph line-height:1.4em, and superscripts font-size:0.7em; vertical-align:0.25em. (Margin between paragraphs is 0.8em)

[GrannyGrump]

Tex2002ans said:

There are multiple PNG compression programs out there, I personally use ScriptPNG (There is also OptiPNG, PNGCrush, etc. etc.). This allows easy, drag and drop the files onto the batch file:

I've tried OptiPNG and PNGCrush, got no better results than my trusty old PaintShopPro, but I will give ScriptPNG a try. Thanks for that!

Tex2002ans said:

I usually keep the book covers as JPG. I shoot for is a MAX of ~300-400 KBs covers, with a 800x1200 resolution.

I hope this isn't considered too much of a hijack, but slipping back to images...

This thread interested me in future-proofing illustrated books.

Everyone has been discussing cover images, or books with only a handful of illustrations and charts.

I'm currently working on a Mark Twain book with over *300* quarter-, half-, and full-page illustrations, and I use max of 600x800px. I fully expect the final book size to exceed 15mb, probably more. If I increase resolution to 800x1200, the book will double in size.

I hesitate to split this book into multiple volumes. Perhaps I should only consider higher resolution images when there aren't hundreds of them?

What are your thoughts?

[Tex2002ans]

Originally Posted by grannyGrumpy

I've tried OptiPNG and PNGCrush, got no better results than my trusty old PaintShopPro, but I will give ScriptPNG a try. Thanks for that!

(I sent you a PM about the Mark Twain book)

I tried all of the PNG compression programs out there (I used OptiPNG for a long time as that worked well with my automated commandline setup), but once I found ScriptPNG, I was sold.

Here is also his compression tests and a lists 11 different PNG compression programs. Feel free to download them all and use whichever one you like best:

http://css-ig.net/png-test-corpus

DO: Compress PNGs to the best of your ability.
DO: Use PNG for images with few colors/grayscale/B&W.