List of epub formatting "don'ts"

[dwig]

Originally Posted by Turtle91

wow - one quarter the size!! That is impressive. I've been using photoshop ...

Don't ever use a JPEG or PNG that was saved from Photoshop using the "File>Save..." or "File>Save as ..." menu options, period. These are as "evil" as Word HTML files. Always use PS's "File>Save for Web and devices..." option which omits tons of PS specific extra editing info.

[AlPe]

For maximum compatibility with eReaders, my suggestion is to always "convert" the images using ImageMagick (i.e., "convert" in linux).

[Turtle91]

Originally Posted by AlPe

For maximum compatibility with eReaders, my suggestion is to always "convert" the images using ImageMagick (i.e., "convert" in linux).

"Convert" the image to what? If it's already a .jpg what would you convert it to?

[JSWolf]

Originally Posted by dwig

Don't ever use a JPEG or PNG that was saved from Photoshop using the "File>Save..." or "File>Save as ..." menu options, period. These are as "evil" as Word HTML files. Always use PS's "File>Save for Web and devices..." option which omits tons of PS specific extra editing info.

That I never knew. Thanks.

[AlPe]

Originally Posted by Turtle91

"Convert" the image to what? If it's already a .jpg what would you convert it to?

"Convert" to JPEG nonetheless (adjusting compression, if desired). Doing so, all the info added (e.g., by Photoshop) will be removed. In particular, in the past I saw that (eink) devices might run into troubles with JPEGs containing color space profiles.

Example:

$ identify original.jpg 
original.jpg JPEG 900x1200 900x1200+0+0 8-bit DirectClass 439KB 0.010u 0:00.019

$ convert original.jpg clean.jpg

$ identify clean.jpg 
clean.jpg JPEG 900x1200 900x1200+0+0 8-bit DirectClass 411KB 0.010u 0:00.000

[Turtle91]

hmmm...that's interesting...I appreciate it!

It's amazing how much work I do to get all the bloat out of the html/CSS, but never realized it was in the image as well!!

Thanks!

[elibrarian]

Erm ... I just tried the imagemagick convert jpg to jpg, and the file grew from 721 KB (saved with Photoshops save-to-web) to 756 KB ...

Any explanations?

Regards,

Kim

[DaleDe]

Originally Posted by elibrarian

Erm ... I just tried the imagemagick convert jpg to jpg, and the file grew from 721 KB (saved with Photoshops save-to-web) to 756 KB ...

Any explanations?

Regards,

Kim

Jpeg is tricky. The biggest thing that affects the size of the resultant file is the Quality factor. This can be changed when the file is saved to compare the visual image versus the size. This is why JPG is considered a lossy format. Each time it is saved a new image is generated from the displayed view. It is not really a copy. It is fresh conversion of the displayed image.

Dale

[dgatwood]

Originally Posted by Man Eating Duck

* Don't ever adjust line-height. Leave it at default. Readers will render a sensible default, many can override it if desired, but a silly value here can make it difficult to hit the correct value if you adjust the view.

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.

Originally Posted by Ripplinger

* Don't use huge uncompressed images within the book or for the cover. Run them through a decent graphic program to compress them, if done properly, you will not see any difference on your reading device's screen.

This one, I also tend to disagree with, for two reasons.

First, you can't include uncompressed images in a valid EPUB book. The EPUB spec only allows you to include GIF, JPEG, PNG, and SVG images. The first three are compressed bitmap formats. The fourth is a vector graphics format, and if an SVG image contains any bitmapped content (in the context of EPUB), that bitmapped content must be in one of the first three formats, AFAIK.

Second, some people read books on laptops and iPads that have retina displays. If, for example, you read a book on a 15" laptop with a retina display (2880×1800 resolution), you will see the difference if your cover image is significantly less than 1800 pixels tall.

And if your content has text (which most covers do), reducing the JPEG compression quality below a certain point will result in ringing around the sharp edges. Using PNG avoids this, but then you have no real way to increase the compression; it is what it is.

I recognize that older, slower readers might struggle with large images. If enough people are having trouble with this, you might use an image with a low-res image by default, then use media queries so that if the device has a higher resolution, that image goes away and a background-image property on the enclosing div provides a higher-resolution image, confident that any device that supports media queries also supports background-image.... That said, it is probably better to just ship with a future-proof high resolution copy and let people with ancient, slow devices either upgrade their hardware or shrink the cover image themselves.

Originally Posted by dwig

Don't ever use a JPEG or PNG that was saved from Photoshop using the "File>Save..." or "File>Save as ..." menu options, period. These are as "evil" as Word HTML files. Always use PS's "File>Save for Web and devices..." option which omits tons of PS specific extra editing info.

Like. +1

Originally Posted by Turtle91

"Convert" the image to what? If it's already a .jpg what would you convert it to?

Unless the original is a photo that is starting out as JPEG, don't do that. Always tell Photoshop or Illustrator or whatever to export a PNG or TIFF file so that you have a lossless starting point. Then convert to JPEG from there.

[Toxaris]

There actually is something like lossless jpeg. It generates huge files, but it does exist.

[Tex2002ans]

Originally Posted by elibrarian

Erm ... I just tried the imagemagick convert jpg to jpg, and the file grew from 721 KB (saved with Photoshops save-to-web) to 756 KB ...

Any explanations?

I would NOT recommend Imagemagick to your normal user. It is an extremely powerful image tool, and it does make assumptions about input data.

Your typical image does have lots of worthless metadata called EXIF data, which can be easily tossed out to save some space:

https://en.wikipedia.org/wiki/Exif

This is somewhat what the "Save Image for Web" does in many programs.

Originally Posted by DaleDe

Each time it is saved a new image is generated from the displayed view. It is not really a copy. It is fresh conversion of the displayed image.Dale

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.

Originally Posted by dgatwood

Unless the original is a photo that is starting out as JPEG, don't do that. Always tell Photoshop or Illustrator or whatever to export a PNG or TIFF file so that you have a lossless starting point. Then convert to JPEG from there.

Indeed. Lossy formats should ALWAYS be a final step. Always try to keep it lossless all the way up until the last possible point.

Originally Posted by Toxaris

There actually is something like lossless jpeg. It generates huge files, but it does exist.

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

Originally Posted by dgatwood

That said, it is probably better to just ship with a future-proof high resolution copy and let people with ancient, slow devices either upgrade their hardware or shrink the cover image themselves.

I would go with the mid-resolution image (works well on the older/weaker devices, works well on larger devices as well), and you could always have the source documents/offer something better elsewhere (like directly on your site). No need to bloat the EPUBs with some overly large image file/s (I hate those EPUBs with about 100 KBs of text, and a 1.5 MBs cover).

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

Hopefully the next ebook format will be able to handle SVG much better, so that a lot of computer generated images (charts/tables/graphs) can auto-scale.

Originally Posted by dgatwood

Using PNG avoids this, but then you have no real way to increase the compression; it is what it is.

The greatness about lossless encoding is that the compression parameters can be changed, and you still get the same exact output (just smaller file size).

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:

http://css-ig.net/scriptpng

Also, if you wanted to go the lossy PNG route, you could do things like drop from 24-bit encoding to 8-bit.

I consider 800x1200 a "Mid-resolution" (works well on older devices I tested on, also works well/looks good on PC).

You could always offer the much higher quality resolution cover directly on your site, for those of us who want to hunt it down and replace it ourselves.

For B/W or Grayscale images though, I go PNG all the way. If it is something that is a few colors (such as a table/charts/graphs), I go with PNG. You can easily Index all the colors and make a VERY small file size (with much higher quality when compared to JPG).

In the future, if better lossless compression algorithms come out, you could always just recompress your images to get better filesize, with zero loss in quality.

Example: In February 2013, Google released the Zoplfi algorithm, which allows ~3-8% better PNG compression than previous algorithms:

http://googledevelopers.blogspot.com...th-zopfli.html

If I ever go back to fix up little typos, or make tiny changes to the EPUB, I make sure to recompress the PNG images in the books I previously worked on, and am able to save a lot more space (for example, this book that I just fixed a few nights ago, I saved ~42 KBs from recompression).

Here is a sample Chart of different compressions I attached.

#1: GIMP, saved as "85 quality" JPG.

(LOSSLESS)
#2: GIMP, saved as PNG (max compression)
#3: Image #2 through ScriptPNG (~31% smaller)

(LOSSY)
#4: GIMP, saved as Indexed PNG (256 colors)
#5: Image #4 thorugh ScriptPNG (~11% smaller)

The JPG is ~130 KBs while the Indexed/ScriptPNG is 44.5 KBs (and looks WAY cleaner). You can really tell if you super zoom in on the solid color bars. In JPG, you can see the artifacting with different shades of red/blue/yellow, instead of being one solid color.

[SBT]

For ink/pencil b&w sketches I go for fifteen shades of grey. Looks good even on full-colour devices, and makes for smaller png-files than jpg.

[AlPe]

Originally Posted by AlPe

"Convert" to JPEG nonetheless (adjusting compression, if desired). Doing so, all the info added (e.g., by Photoshop) will be removed. In particular, in the past I saw that (eink) devices might run into troubles with JPEGs containing color space profiles.

Please observe that my previous post (quoted above) aimed at suggesting a quick way to get rid of the annoying "extra stuff" from a JPEG file, since the previous commenter said that his material was already in JPEG format.

Clearly I agree that retaining high resolution, lossless resources and "convert" them to lossy resources is the way to go, and I am well aware that PNG works better for line-art, charts and graphs.

[Agama]

Man Eating Duck wrote:

Don't ever adjust line-height. Leave it at default. Readers will render a sensible default, many can override it if desired, but a silly value here can make it difficult to hit the correct value if you adjust the view.

dgatwood wrote:

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.

+1

I have also found it necessary to use a line-height of 1.4 for books with a lot of superscripting, otherwise readers render variable line spacing depending on whether a line has any superscripts or not and this uneveness looks a bit messy.

[Man Eating Duck]

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.)

Line height is something that affects presentation and readability in a big way. Default line heights are not set arbitrarily for fonts and readers, they should be carefully chosen to fit the font. If I got an epub where I realised that the creator chose to *destroy* the whole body text in order to incorporate completely superfluous eye candy like drop caps (which you *can't* do properly in epubs anyway), I would be very annoyed (and correct it). Seriously, get the entire chapter wrong for a drop cap?

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.

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