View Full Version : List of epub formatting "don'ts"


Man Eating Duck
04-28-2013, 06:16 PM
In my library of 619 books, about 300 of which are retail productions, there are very few in which I haven't touched the code at all. Many changes I do are due to personal preference, for instance I prefer indented paragraphs to spacing. Some common formatting decisions, however, are just plain wrong, and should never be used in a straightforward novel for general consumption, because they will break rendering or functionality on some software and devices.

I'd like your help in compiling a short list of absolute don'ts when formatting epubs, with a short description of why this is a bad idea. I know there are a lot of epub tutorials out there, but the scope of this list is a lot smaller.

Please contribute your viewpoints, also comment on mine if you feel that I'm mistaken. Please avoid points which vary with personal preference, I'm after the things that probably never should be done. I've also tried not to be too nitpicky, for such a list to have any value it shouldn't be too long.

I'll start with a few points:

* Don't use fixed units like in, pt, or px for anything. When text size is adjusted the spacing will often stay fixed. The 0.8in text-indent or 1.5in margins might look fine on your computer screen, but will look very silly on a phone. Use em for indents (I prefer 1.2em myself, but 1-2 em is acceptable). Use % or em for margins, or leave margins to the renderer defaults. This includes blockquotes.

* Don't specify color for body text. Color:#000 might be detrimental to night reading modes on some readers. Also avoid grey, as it might render text almost unreadable on some e-ink screens, and usually adds little to the presentation. For charts and diagrams, don't rely on color to convey information, as it will be lost on b/w screens.

* Don't adjust font size in body text. If you need other sizes for things like quotes or headings, use % or size names. Around 70% is the smallest text you should use, and only sparingly.

* Don't 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. Edit: One exception is in span styles for superscript, here a line height of 0 avoids extra spacing to the above line.

* Don't use inline styling, or <style type="text/css"> in each html file. This makes your job of styling the epub more complicated, and is annoying to those of us who actually tweak our epubs ourselves. It might also break text resize on some ADE-based devices. Instead, put all your definitions in a css file.

* Don't use any html/css whatsoever generated by MS Word. This should be obvious to anyone familiar with its output, but I still see a lot of mso-something styles and endlessly nested spans for no reason :)
Some devices will choke on the overly complex and often invalid code.

* Don't use empty paragraphs for spacing, or &nbsp; for indents. Specify the values in css. For section separators, consider inserting * * * or similar in it's own paragraph. Since you don't control where page breaks occur, a blank section separator might not always be apparent.

* Don't use margins that are huge. If you want margins so the text doesn't bump the edge of the screen, use 5-9pt (no need for a bottom margin) and in this case, it's OK to to use pt as you want the margins to always stay the same.I believe that this should be left as default - Man Eating Duck

JSWolf
04-28-2013, 06:22 PM
* Don't use a line space between paragraphs as that causes the eye to have to stop and try to find the next paragraph plus, it just looks awful.

* Don't use margins that are huge. If you want margins so the text doesn't bump the edge of the screen, use 5-9pt (no need for a bottom margin) and in this case, it's OK to to use pt as you want the margins to always stay the same.

Man Eating Duck
04-28-2013, 06:36 PM
* Don't use a line space between paragraphs as that causes the eye to have to stop and try to find the next paragraph plus, it just looks awful.By this, you mean spacing between paragraphs as opposed to text-indent and no spacing? I tend to agree with you, as I stated, but this comes down to personal preference. It may look awkward to you and me, but it won't break an epub if done properly. Some people prefer it, and you'll also occasionally see it in paper books.

* Don't use margins that are huge. If you want margins so the text doesn't bump the edge of the screen, use 5-9pt (no need for a bottom margin) and in this case, it's OK to to use pt as you want the margins to always stay the same.This also borders on personal preference, some people like a bit of space around the body text. I think it's best left as default. Since it's still a bad practice IMO (depending on the value of "huge"), I'll include it. Thanks!

JSWolf
04-28-2013, 08:43 PM
I've never actually tried the default margins. I shall give it a go and see what I get.

Toxaris
04-29-2013, 03:11 AM
Some of these I agree with, others not that much. I do believe in the credo 'less is more' in the e-book creating world, but I have very few 'must not' credos. I do use empty paragraphs though, because it is much easier to maintain for me. However, I only use it in the text itself, not for spacing around headers and so.

Ripplinger
04-29-2013, 03:22 AM
Two other things that bug me to no end:

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

* Don't use a different image for each chapter for decorative purposes when the images are all identical. Use the same one image for all the chapters.

Turtle91
04-29-2013, 03:53 AM
Two other things that bug me to no end:

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


The only methods I've seen to compress images are to:
- reduce the dimensions
- reduce the color bit depth

With Amazon and Apple (B&N ?) having a minimum dimension, that leaves reducing the bit depth. That affects the quality if the image. Is there some other process to compress images I'm missing??


* Don't use a different image for each chapter for decorative purposes when the images are all identical. Use the same one image for all the chapters.
+1

Ripplinger
04-29-2013, 04:47 AM
The only methods I've seen to compress images are to:
- reduce the dimensions
- reduce the color bit depth

With Amazon and Apple (B&N ?) having a minimum dimension, that leaves reducing the bit depth. That affects the quality if the image. Is there some other process to compress images I'm missing??

Any decent graphic program also has a method of compressing the image that doesn't reduce the dimensions or the bit depth. My favorite program is Paint Shop Pro for instance, and when you save as .jpg, before filling in the save name, click on Options and you have a slider bar to change the amount of compression or an optimization button with more options. There's also some plugins you can add that will do the same, an excellent old one I still have is Smart Saver Pro by Ulead.

Here's an example I snagged off Amazon, both of these images are 24 bit, both are 643x1000 pixels. One is not compressed and is 392KB, the other is compressed and is 95KB. If I really scrutinize the images, I can pick up a few white flecks at the edges of the red lettering. And to me, for the size difference and as often as you look at a cover compared to the book, it's perfectly fine being compressed. I've seen much more drastic reduction in file size though on some images in purchased books. Totally unnecessary and it only serves to bloat the size of the epub.

Turtle91
04-29-2013, 05:33 AM
wow - one quarter the size!! That is impressive. I've been using photoshop but am nowhere close to an expert with the software. I've been saving with "high quality" .jpg about an 8. I thought that a lower quality number would change the bit-depth or something, so left it at 8. I'll have to play with those settings a bit. Thanks!

Jellby
04-29-2013, 05:56 AM
Try saving any image as BMP (uncompressed) and PNG (at max, lossless compression). The image should look exactly the same, but typically the PNG one will be much smaller (especially if it's something with large single-color areas).

elibrarian
04-29-2013, 07:15 AM
wow - one quarter the size!! That is impressive. I've been using photoshop but am nowhere close to an expert with the software. I've been saving with "high quality" .jpg about an 8. I thought that a lower quality number would change the bit-depth or something, so left it at 8. I'll have to play with those settings a bit. Thanks!

Both Photoshop, Illustrator and Elements has a "save for web" function, that works quite well (at least in the versions CS2 and Elements 8 - I don't have anything newer, so correct me, if I'm wrong.) Theres a plugin for GIMP that performs the same service

IMHO it is usually not necessary to save in print quality for ebooks.

Regards,

Kim

Man Eating Duck
04-29-2013, 07:21 AM
Some of these I agree with, others not that much. I do believe in the credo 'less is more' in the e-book creating world, but I have very few 'must not' credos.I would be interested in knowing which points you think unnecessary, as I've tried to only include stuff that can actually break rendering or functionality on reading software/devices. I'll consider removing points if they're not really a problem.

I do use empty paragraphs though, because it is much easier to maintain for me. However, I only use it in the text itself, not for spacing around headers and so.I included this one not because it's "incorrect", but because they actually break on some devices (as in not being rendered). That counts as broken in my book, although in this case the devices in question are probably what's broken.

Man Eating Duck
04-29-2013, 07:31 AM
Two other things that bug me to no end:

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

* Don't use a different image for each chapter for decorative purposes when the images are all identical. Use the same one image for all the chapters.While large or redundant image files is annoying, it won't actually break rendering or functionality on anything but the most fragile viewers. That is, unless you're talking about completely ridiculous resolutions like 10000xsomething, but I haven't actually seen that in an epub yet. In addition some distributors demand a relatively large cover file embedded in the ebook itself, making it impossible for creators to use more sensible sizes.

Toxaris
04-29-2013, 09:04 AM
I would be interested in knowing which points you think unnecessary, as I've tried to only include stuff that can actually break rendering or functionality on reading software/devices. I'll consider removing points if they're not really a problem.


It is not so much unnecessary, bot more that there are sometimes merits to things. A lot of these things will actually not break rendering or functionality. They will only cause that when used incorrectly.
For example inline styling can be fine to use in some cases. It can be that a standard stylesheet will not apply and you only have usage for 1 or 2 styles. Of course you can create a new/additional stylesheet, but if it is only for one page I would not mind an inline style.
In general the cases you describe are valid and true, but not always. A few margins (page margins) can be in pt instead of em or percentages. I only create a small margin around my pages and I would not them to scale with font-size.

I included this one not because it's "incorrect", but because they actually break on some devices (as in not being rendered). That counts as broken in my book, although in this case the devices in question are probably what's broken.
It can break, because some readers will ignore the empty line if it is <p></p> or <p><br /></p>. However, all readers I know will honor <p>&nbsp;</p>. I know it is not always pretty or the best way to do it, but it will not break.

JSWolf
04-29-2013, 09:24 PM
Any decent graphic program also has a method of compressing the image that doesn't reduce the dimensions or the bit depth. My favorite program is Paint Shop Pro for instance, and when you save as .jpg, before filling in the save name, click on Options and you have a slider bar to change the amount of compression or an optimization button with more options. There's also some plugins you can add that will do the same, an excellent old one I still have is Smart Saver Pro by Ulead.

Here's an example I snagged off Amazon, both of these images are 24 bit, both are 643x1000 pixels. One is not compressed and is 392KB, the other is compressed and is 95KB. If I really scrutinize the images, I can pick up a few white flecks at the edges of the red lettering. And to me, for the size difference and as often as you look at a cover compared to the book, it's perfectly fine being compressed. I've seen much more drastic reduction in file size though on some images in purchased books. Totally unnecessary and it only serves to bloat the size of the epub.

The second one is the more compressed cover. It's obvious with a quick compare. You can easily see jpeg artifacts. But on an eInk screen, it may not be so obvious.

dwig
04-29-2013, 10:11 PM
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
04-30-2013, 06:56 AM
For maximum compatibility with eReaders, my suggestion is to always "convert" the images using ImageMagick (i.e., "convert" in linux).

Turtle91
04-30-2013, 12:46 PM
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
04-30-2013, 01:08 PM
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
04-30-2013, 03:00 PM
"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
04-30-2013, 03:27 PM
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
04-30-2013, 03:33 PM
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
04-30-2013, 04:38 PM
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
05-01-2013, 02:32 AM
* 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.



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


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



"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
05-01-2013, 03:38 AM
There actually is something like lossless jpeg. It generates huge files, but it does exist.

Tex2002ans
05-01-2013, 04:04 AM
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.

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.

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.

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

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.

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/2013/02/compress-data-more-densely-with-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
05-01-2013, 05:31 AM
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
05-01-2013, 06:35 AM
"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
05-01-2013, 08:32 AM
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
05-01-2013, 10:07 AM
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 :)

JSWolf
05-01-2013, 10:15 AM
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
05-01-2013, 10:19 AM
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
05-01-2013, 11:01 AM
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
05-01-2013, 11:07 AM
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.:D It was just for the sake of argument that JPEG is not always lossy.

DaleDe
05-01-2013, 12:01 PM
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
05-02-2013, 03:52 AM
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
05-02-2013, 06:34 AM
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
05-02-2013, 06:39 AM
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 :)
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
05-02-2013, 08:24 AM
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
05-02-2013, 10:04 AM
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
05-02-2013, 12:14 PM
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
05-02-2013, 12:17 PM
(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
05-02-2013, 06:45 PM
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
05-03-2013, 01:51 AM
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
05-03-2013, 03:13 AM
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.

dgatwood
05-03-2013, 04:02 PM
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.

Well, a line height of 1.2 is the absolute minimum that Kindles will allow, so in the more broad world of eBook publishing, using a smaller value is probably a bad idea. :)

Man Eating Duck
05-03-2013, 06:02 PM
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)Maybe you'd like to try setting line-height:0 in the superscript span style, and reset the p line height? I had good results on a couple of our academic books which also contains a lot of superscript. You could probably also raise the superscript a little if you did that, it doesn't seem like it would overlap with the line above.

JSWolf
05-03-2013, 06:21 PM
Well, a line height of 1.2 is the absolute minimum that Kindles will allow, so in the more broad world of eBook publishing, using a smaller value is probably a bad idea. :)

We are going backwards here. We have Kindles with 1.2 and Kobos with 1.3. Both which are too large. The Kobo can be fixed via CSS and the only way Kindles can be fixed is to edit the metrics of the font so it has a smaller line height. I've done that for the Kindle (for KF8) using Charis SIL and it worked very well.

It's disgraceful when a Reader and/or app has defaults that cannot easily be overridden and those defaults are obnoxious.

dgatwood
05-03-2013, 06:56 PM
We are going backwards here. We have Kindles with 1.2 and Kobos with 1.3. Both which are too large. The Kobo can be fixed via CSS and the only way Kindles can be fixed is to edit the metrics of the font so it has a smaller line height. I've done that for the Kindle (for KF8) using Charis SIL and it worked very well.

It's disgraceful when a Reader and/or app has defaults that cannot easily be overridden and those defaults are obnoxious.

Indeed. Lots of things the Kindle KF8 readers do are obnoxious. That particular one, though, is so badly done that fonts whose metrics specify a smaller-than-1.2 line height actually get forced up to a 1.2 line height, resulting in the layout of the content changing. To get a line height less than 1.2, AFAIK, the only thing you can really do is lie in your metrics and extend the ascenders and descenders past the specified limits. :eek:

So yes, no disagreement here. What Amazon has done with KF8 is broken. Badly. Embarrassingly.

Agama
05-04-2013, 02:48 PM
Maybe you'd like to try setting line-height:0 in the superscript span style, and reset the p line height? I had good results on a couple of our academic books which also contains a lot of superscript. You could probably also raise the superscript a little if you did that, it doesn't seem like it would overlap with the line above.

Well that's rather neat: it worked a treat. Thanks for the suggestion. So now it appears there is no need for 1.4em line-heights after all. :)

Man Eating Duck
05-04-2013, 07:34 PM
Well that's rather neat: it worked a treat. Thanks for the suggestion. So now it appears there is no need for 1.4em line-heights after all. :)Glad to hear it. I wasn't aware of that trick myself a while ago, and now I'll have to amend our entire backlog of epubs in order to be able to sleep at night :)

JSWolf
05-04-2013, 10:13 PM
Well that's rather neat: it worked a treat. Thanks for the suggestion. So now it appears there is no need for 1.4em line-heights after all. :)

There never was a need for 1.4em. It's just too big and will always be too big.

JSWolf
05-04-2013, 10:14 PM
Indeed. Lots of things the Kindle KF8 readers do are obnoxious. That particular one, though, is so badly done that fonts whose metrics specify a smaller-than-1.2 line height actually get forced up to a 1.2 line height, resulting in the layout of the content changing. To get a line height less than 1.2, AFAIK, the only thing you can really do is lie in your metrics and extend the ascenders and descenders past the specified limits. :eek:

So yes, no disagreement here. What Amazon has done with KF8 is broken. Badly. Embarrassingly.

So what else is broken with KF8 besides the line height?

m00min
05-06-2013, 07:17 AM
We are going backwards here. We have Kindles with 1.2 and Kobos with 1.3. Both which are too large. The Kobo can be fixed via CSS and the only way Kindles can be fixed is to edit the metrics of the font so it has a smaller line height. I've done that for the Kindle (for KF8) using Charis SIL and it worked very well.

As someone said earlier in this thread, 1.2 is pretty much a default or common setting for most fonts. For most people it will make the text more legible to be set to 1.2 rather than 1.0. The only time I'd consider using 1em for text is on titles or short bits of text (maybe links on websites). I think you're an edge case in preferring it for reading large quantities of text. :)


It's disgraceful when a Reader and/or app has defaults that cannot easily be overridden and those defaults are obnoxious.

Definitely agree with this, I've just got myself a Kobo Mini and its driving me mad that I can't switch off the hyphenation without forcing it in the CSS.

JSWolf
05-06-2013, 06:04 PM
As someone said earlier in this thread, 1.2 is pretty much a default or common setting for most fonts. For most people it will make the text more legible to be set to 1.2 rather than 1.0. The only time I'd consider using 1em for text is on titles or short bits of text (maybe links on websites). I think you're an edge case in preferring it for reading large quantities of text. :)

1.2em is too large a line height. It is not a default. 1em is actually the default (if there is one).

Don't use 1.2em. It's too big.

Agama
05-07-2013, 08:33 AM
ADE and calibre viewer almost certainly use a default in the region of 1.2em for paragraph line-height. This is a very sensible value to use and ensures that letters with "descenders", (g p q y), don't bump into tall letters on the next line. 1.0em is definitely NOT the default for line-height on all readers.

Do use 1.2em, or 1.1em or even 1.0em, (though this one really is a bit tight), or simply leave it to default as the OP suggested, (and you'll get something in the region of 1.2em on ADE based readers.)

Jellby
05-07-2013, 09:33 AM
This is a very sensible value to use and ensures that letters with "descenders", (g p q y), don't bump into tall letters on the next line.

Unfortunately, that's very much font-dependent (meaning that for some fonts 1.2 will be "too much" and for others it will be "not enough"). It depends on how the different glyphs (letters) are drawn in the containing block. Some fonts have containing block very well adjusted to the glyph shapes, some fonts have lots of white space in the containing block, some fonts have large parts of the glyphs outside the containing block... There's no fixed solution for every font.

(see Figure 5-9 here (http://www.thecorner.org/book1/css_guide/0596527330/csstdg3-CHP-5-SECT-3.html))

Toxaris
05-07-2013, 10:51 AM
I keep it on the value 'normal'. That way a good reader can decide for themselves.

JSWolf
05-07-2013, 01:06 PM
ADE and calibre viewer almost certainly use a default in the region of 1.2em for paragraph line-height. This is a very sensible value to use and ensures that letters with "descenders", (g p q y), don't bump into tall letters on the next line. 1.0em is definitely NOT the default for line-height on all readers.

Do use 1.2em, or 1.1em or even 1.0em, (though this one really is a bit tight), or simply leave it to default as the OP suggested, (and you'll get something in the region of 1.2em on ADE based readers.)

Your assumption is very wrong. You do not get 1.2em on ADE based readers. Most are actually 1.0em and the Kobo is 1.3em. There are no ADE based readers that give a default of 1.2em that I know of. Desktop ADE is 1.0em. So if you do want a specific line height, you have to specify it. But please don't make it 1.2em or higher. Too big. 1.1em might be OK for most people.

theducks
05-07-2013, 01:21 PM
Unfortunately, that's very much font-dependent (meaning that for some fonts 1.2 will be "too much" and for others it will be "not enough"). It depends on how the different glyphs (letters) are drawn in the containing block. Some fonts have containing block very well adjusted to the glyph shapes, some fonts have lots of white space in the containing block, some fonts have large parts of the glyphs outside the containing block... There's no fixed solution for every font.

(see Figure 5-9 here (http://www.thecorner.org/book1/css_guide/0596527330/csstdg3-CHP-5-SECT-3.html))

Agreed.
Most time I don't specify a line height.
In a few font cases, I have to specify 1.2 as the default space seems overly (screen) wasteful of space :rolleyes:

The only other time I use it, is when I mix fonts on a line and the inherited space prevailes (probably due to bad coding on my part)

Agama
05-07-2013, 04:17 PM
Your assumption is very wrong. You do not get 1.2em on ADE based readers. Most are actually 1.0em and the Kobo is 1.3em. There are no ADE based readers that give a default of 1.2em that I know of. Desktop ADE is 1.0em. So if you do want a specific line height, you have to specify it. But please don't make it 1.2em or higher. Too big. 1.1em might be OK for most people.

This isn't an assumption, it's based on actual results using ADE. Attached pics show a couple of paragraphs in Desktop ADE with paragraph line-heights of: 1.0em, (LH10em.gif), 1.1em, (LH11em.gif) and 1.2em, (LH12em.gif). The final picture, (LHDEF.gif), is that obtained using default line-height, (i.e. not specified) and this is closest to 1.2em.

Agama
05-07-2013, 04:22 PM
Unfortunately, that's very much font-dependent (meaning that for some fonts 1.2 will be "too much" and for others it will be "not enough"). It depends on how the different glyphs (letters) are drawn in the containing block. Some fonts have containing block very well adjusted to the glyph shapes, some fonts have lots of white space in the containing block, some fonts have large parts of the glyphs outside the containing block... There's no fixed solution for every font.

(see Figure 5-9 here (http://www.thecorner.org/book1/css_guide/0596527330/csstdg3-CHP-5-SECT-3.html))

Interesting. Perhaps this shows why there is some difference in opinion in this thread as to what makes a reasonable line-height. My font testing has been limited to those displayed on my PRS-300.

Arios
05-07-2013, 08:21 PM
Thanks Agama,

Your suggestions are very helpful and I like the way you do shared it, without stiff statements like: "Do it!" I do not like it, "You are wrong".

We are in a free world, is it not (so people can like and do what they want to)?

Tex2002ans
05-08-2013, 12:39 AM
This isn't an assumption, it's based on actual results using ADE. Attached pics show a couple of paragraphs in Desktop ADE with paragraph line-heights of: 1.0em, (LH10em.gif), 1.1em, (LH11em.gif) and 1.2em, (LH12em.gif). The final picture, (LHDEF.gif), is that obtained using default line-height, (i.e. not specified) and this is closest to 1.2em.

Great! Actual scientific comparison screenshots trumps silliness! (Now now my friend Agama, why did you use that crappy GIF format and not PNG?:rofl:)

Now, back to the "Do's and Don'ts of EPUB Formatting":

Do: Use a pleasing default line-height (~1-1.2em (MAYBE 1.3em)), or leave on defaults so user can choose whatever his heart desires.

Don't: Use a line-height of OVER 9000!!!!!

Man Eating Duck
05-08-2013, 07:55 AM
Now, back to the "Do's and Don'ts of EPUB Formatting":

Do: Use a pleasing default line-height (~1-1.2em (MAYBE 1.3em)), or leave on defaults so user can choose whatever his heart desires.

Don't: Use a line-height of OVER 9000!!!!!That is actually close to what I put in the original post, my advice was to leave it default. Even (especially?) after all these posts about line-height, I think I'll let it stand :)
* Don't 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. Edit: One exception is in span styles for superscript, here a line height of 0 avoids extra spacing to the above line.

m00min
05-08-2013, 10:33 AM
1.2em is too large a line height. It is not a default. 1em is actually the default (if there is one).

Don't use 1.2em. It's too big.

The general rule of thumb found in typography for setting the leading is to set at 120%. Of course different typefaces need different values, but anything less than 1.2em risks clashing ascenders and descenders, and that looks awful.

You might personally prefer it, that's fine, but typographically it's wrong.

Zetetic
05-09-2013, 02:40 PM
I believe that 1.2em (-ish) is certainly the default for many desktop renderers.

As a wider point, this does seem like something that would be best left up to the user agent as the original poster suggests.

Man Eating Duck
05-09-2013, 06:45 PM
I believe that 1.2em (-ish) is certainly the default for many desktop renderers. Yes, I've heard 1.25em or 125%. Still, I checked computed values for Firefox and Chrome via developer tools. All values are for font-size:normal.

Firefox line-height:
normal: 20px
1em: 16px
1.2em: 19.2px
1.25em: 20px
100%: 16px
120%: 19.2px
125%: 20px

Chrome line-height:
normal: 20px
1em: 16px
1.2em: 19.1875px
1.25em: 20px
100%: 16px
120%: 19px
125%: 20px

ADE line-height (measured with screen ruler, 10 lines/10):
normal: 19px
1em: 16px
1.2em: 19.1px
1.25em: 20px
100%: 15.9px
120%: 19.2px
125%: 20px


Curiously, ADE has a slightly smaller normal value (118.75%). The next time I upload a batch of books to my prs-650 I'll measure the test-epub with a ruler, I believe it is similar. I find the normal line-height with the default font to be very pleasant on my device. Like the majority of those who have spoken up about it, 1em seems too small for me.

Edit: The font rendered was the default fonts, this could explain the different values in ADE. Firefox and Chrome both used Times New Roman. If I can find the time tomorrow I'll update my test epub to reflect this and see if the value changes. I could also embed a few different fonts for comparison of "normal" line height rendering, suggestions are welcome.

JSWolf
05-09-2013, 07:01 PM
Agreed.
Most time I don't specify a line height.
In a few font cases, I have to specify 1.2 as the default space seems overly (screen) wasteful of space :rolleyes:

The only other time I use it, is when I mix fonts on a line and the inherited space prevails (probably due to bad coding on my part)

It could be due to the different fonts. The metrics in the fonts can control how the line height works in ADE. So if you change the numbers, you change the line height without specifically specifying a set height.

JSWolf
05-09-2013, 08:11 PM
From what I've seen, the line height of ADE is maybe 1.15em. It's larger then 1.1em and smaller then 1.2em.

dgatwood
05-11-2013, 02:26 AM
I believe that 1.2em (-ish) is certainly the default for many desktop renderers.


According to:

https://github.com/h5bp/html5-boilerplate/issues/825

The default for IE is about 1.125, and pretty much all other browsers (Firefox/Chrome/Safari/Webkit) use 1.1875. But most of the time we just say 1.2, because that's close enough for government work. :D

William Ockham
05-16-2013, 11:47 AM
Wow, there is an enormous amount of misinformation about line-height on this thread. Let's clear a few things up.

1. Fonts DO NOT contain any information about line-height. Font files describe how to draw glyphs in relation to the em square. If you are seeing line-height change based on font selection, you are seeing the result of a (very broken) user agent.

2. Line-height will ALWAYS be rendered in a whole number of device pixels. This is a fairly obvious physical constraint.

3. The equation of 1em = 16px is just a convention. It's a long story and not really relevant.

None of this stuff really matters as long as, if you are going to specify line-height, you do it in ems. Just realize that the value you specify will get rounded to the nearest number of device pixels, which isn't the same thing as the CSS px measurement.

Man Eating Duck
05-16-2013, 12:53 PM
Wow, there is an enormous amount of misinformation about line-height on this thread. Let's clear a few things up.

2. Line-height will ALWAYS be rendered in a whole number of device pixels. This is a fairly obvious physical constraint.
Yes, I realised that my measurements necessarily had some (~6%) margin of error after writing that post, but figured that it wasn't really important. I think that the distinction whether 1em/100% or 1.2/120% is the regular "normal" value was relevant, though, as there seemed to be some confusion about which values constitute a large deviance from default.

None of this stuff really matters as long as, if you are going to specify line-height, you do it in ems. Just realize that the value you specify will get rounded to the nearest number of device pixels, which isn't the same thing as the CSS px measurement.

Thanks for chiming in, appreciated :)

JSWolf
05-17-2013, 10:30 PM
1. Fonts DO NOT contain any information about line-height. Font files describe how to draw glyphs in relation to the em square. If you are seeing line-height change based on font selection, you are seeing the result of a (very broken) user agent.

It's nothing to do with the user agent. It's not actually line height information in the font, but the metrics. I can change the metrics and change the amount of space between lines. I've done this for ADE & Kindle (KF8) and it's worked. So while technically correct that there is no line height information in a font, there are metrics that say how to render the space between lines and that can be changed.

William Ockham
05-19-2013, 07:50 PM
It's nothing to do with the user agent. It's not actually line height information in the font, but the metrics. I can change the metrics and change the amount of space between lines. I've done this for ADE & Kindle (KF8) and it's worked. So while technically correct that there is no line height information in a font, there are metrics that say how to render the space between lines and that can be changed.

No, you are wrong. The line-height measures the baseline to baseline difference between two lines of text at the same em size. There is absolutely nothing you can do to a font to change that. You can change the metrics of the font to make it take up more of that space, but you really can't change the distance between the baselines. This is not some trivial disagreement. If I take rubber band with a diameter of 1 inch and stretch it across two posts that are 2 inches apart, I haven't decreased the distance between the posts. I've just distorted the shape of the rubber band. If you are changing the metrics of the font, you are just distorting the font and that's not anything related to changing line height.

Jellby
05-20-2013, 04:55 AM
You cannot change (in the font) the line-spacing in relation to the em-size. But you can change the glyph sizes in relation to the em-size, and therefore change the line-spacing in relation to the glyph sizes.

William Ockham
05-20-2013, 10:39 AM
You cannot change (in the font) the line-spacing in relation to the em-size. But you can change the glyph sizes in relation to the em-size, and therefore change the line-spacing in relation to the glyph sizes.

That's crazy. Let's say the distance between the floor and the ceiling in my house is three meters. Let's say my child is 1 meter tall at age 3. Fifteen years later, my child is 2 meters tall. Would you say that the height of my ceiling has changed in relation to my child? The distance between the ceiling and the bottom of the child's feet is the same. The distance between his head and the ceiling has changed, but that's not the definition of the height of the ceiling.

It doesn't matter whether you call it line-height, line-spacing, or leading, it does not change based on the metrics of the font.

DiapDealer
05-20-2013, 11:52 AM
You're arguing semantics, while others are describing changes to certain fonts that will make lines of text rendered in that font appear to have less empty space between them. The visual effect that the "font metric changers" are able to achieve is quantifiable. Call it whatever the hell you want.

William Ockham
05-20-2013, 12:43 PM
You're arguing semantics, while others are describing changes to certain fonts that will make lines of text rendered in that font appear to have less empty space between them. The visual effect that the "font metric changers" are able to achieve is quantifiable. Call it whatever the hell you want.

No, we don't get to call it whatever the hell we want. We don't get to retreat from verifiably false claims by moving the goalposts. Specific claims were made and those claims are false.

It's nothing to do with the user agent. It's not actually line height information in the font, but the metrics. I can change the metrics and change the amount of space between lines. I've done this for ADE & Kindle (KF8) and it's worked. So while technically correct that there is no line height information in a font, there are metrics that say how to render the space between lines and that can be changed.

It is not possible to "change the amount of space between the lines" by altering any of the font metrics. You cannot make that statement true by altering the definitions of the words involved. Whether we call it line-height, line spacing, or leading, the concept has had the same definition for 500 years. It's the distance from baseline to baseline. Understanding that is foundational to understanding the use of typography. Folks who don't understand line-height shouldn't be messing with font metrics.

DiapDealer
05-20-2013, 01:15 PM
Whatever. You're being overly obtuse. Have at it.

JSWolf
05-20-2013, 02:33 PM
It is not possible to "change the amount of space between the lines" by altering any of the font metrics.

Yes you can. I've done it. Take a look at the two attached images. Both are the same font with the only difference being the metrics that I've edited.

So what would you call the fact that one has a grater space between the lines the other and all that was changed was some of the font metrics?

Jellby
05-20-2013, 04:41 PM
Would you say that the height of my ceiling has changed in relation to my child?

Yes, exactly :)

If I were your child I would indeed say that what was before a very high ceiling for me is now not high enough. Note that a reader (the human one) will often set the font size so that it looks right, he/she won't really care or notice if the nominal size is 12pt or 20pt, as long as the glyphs have the right size...

William Ockham
05-20-2013, 05:09 PM
JSWolf, what font metrics did change to achieve that effect? I will happily admit that I'm wrong if you can send me a font that behaves this way.

JSWolf
05-20-2013, 05:51 PM
JSWolf, what font metrics did change to achieve that effect? I will happily admit that I'm wrong if you can send me a font that behaves this way.

I changed Typo Line Gap and Line Gap. The original value was 0 for the first image and I changed it to 200 for the second image. These value work for ADE.

For KF8 I changed Typo Ascender/Typo Descender, Win Ascent/Win Descent, and Ascender/Descender.

All it takes is some experimenting to get the values you want so you don't have to use line height in CSS. It also makes KF8 usable as the line height displayed won't be too large.

Take a look at my modified Charis SIL versions. They have two different line heights when used on a Kindle with KF8.

http://www.mediafire.com/download.php?64cse2dshispx08

abeonis
06-03-2013, 05:30 AM
The align attribute for img to define the vertical alignment doesn't pass FlightCrew ePub check. I use it in HTML coding to align a formula with the text: Exemple:

<p>La potencia <img src="potencia.gif" alt="Cálculo de potencia" align="middle" /> en vatios </p>

Generates an error message: "Attribute align is not declared for element img"

Doitsu
06-03-2013, 06:28 AM
The align attribute for img to define the vertical alignment doesn't pass FlightCrew ePub check. I use it in HTML coding to align a formula with the text: Exemple:

<p>La potencia <img src="potencia.gif" alt="Cálculo de potencia" align="middle" /> en vatios </p>

Generates an error message: "Attribute align is not declared for element img"

If you want to use inline styles, you'll have to use style="vertical-align:middle" instead of align="middle".

abeonis
06-03-2013, 10:45 AM
If you want to use inline styles, you'll have to use style="vertical-align:middle" instead of align="middle".

It works.

So ... WIDTH and HEIGHT attributes are supported. ALIGN attribute is not. Is there a place in internet where I can find all this information? I didn't find it with Google.

theducks
06-03-2013, 11:28 AM
It works.

So ... WIDTH and HEIGHT attributes are supported. ALIGN attribute is not. Is there a place in internet where I can find all this information? I didn't find it with Google.

width and height give the same kind of error for me in flight crew and have the same in line solution. Me, I just use a class=blalblah instead of a long multi-attribute inline

abeonis
06-03-2013, 12:15 PM
width and height attributes don't give me any error in FliightCrew. I am OK to put everything in a class except for width and height, I don't want to create a class each time I use an image with different dimensions.

SBT
06-03-2013, 12:26 PM
I am OK to put everything in a class except for width and height, I don't want to create a class each time I use an image with different dimensions.

Personally, I prefer to create an id for every image, and specify the size in the style sheet. Then nobody can accuse me of not separating content and display attributes ;) Somehow it also seems tidier to lump all image attributes together in one corner of the stylesheet.

abeonis
06-03-2013, 01:30 PM
Personally, I prefer to create an id for every image, and specify the size in the style sheet. Then nobody can accuse me of not separating content and display attributes ;) Somehow it also seems tidier to lump all image attributes together in one corner of the stylesheet.

I am curious to know who can accuse you to "not separate content and display attributes" and how they control what you do. Damned, Big Brother is an ePub reader.

My flow doesn´t work this way. I use always the same css (various) for all my eBooks. I have defined one presentation model with specifc styles I always use. If I discover a need for another class, I include it in my master css. This didn't happen for a while now.

But I am sure your way of doing things works fine for you. Chacun fait ce qui lui plaît.

SBT
06-03-2013, 03:29 PM
I am curious to know who can accuse you to "not separate content and display attributes" and how they control what you do. Damned, Big Brother is an ePub reader.


Well, I don't want to end up as the bad guy in the next episode of "CSS Miami" :p

So do you only use class selectors in your stylesheet, and no id selectors?

JSWolf
06-03-2013, 03:32 PM
Well, I don't want to end up as the bad guy in the next episode of "CSS Miami" :p

So do you only use class selectors in your stylesheet, and no id selectors?

Not possible to be a bad guy in the next episode of CSI Miami as the show's been cancelled.

As for the stylesheet, you use classes and not ids.

Doitsu
06-03-2013, 03:44 PM
Not possible to be a bad guy in the next episode of CSI Miami as the show's been cancelled.

As for the stylesheet, you use classes and not ids.

Actually, you can use both.

SBT
06-03-2013, 03:47 PM
From the w3cschools (http://www.w3schools.com/css/css_id_class.asp) site:
The id selector is used to specify a style for a single, unique element.
...
The class selector is used to specify a style for a group of elements. Unlike the id selector, the class selector is most often used on several elements.

JSWolf
06-03-2013, 04:04 PM
This is the ePub forum. It won't work in ADE. So what I said is correct for ePub. In fact, if you try it with ADE, ADE will take it as an error and none of the CSS will be applied.

SBT
06-03-2013, 04:13 PM
This is the ePub forum. It won't work in ADE. So what I said is correct for ePub.

Incorrect on two counts. Firstly, ADE is not fully epub-compliant, so that if it does not work in ADE does not necessarily imply invalid epub.
Secondly, it does work in ADE, and is according to spec.

JSWolf
06-03-2013, 04:14 PM
I was mistaken. It does work in ADE. I had a typo in the CSS that caused it not to work. User error. But to be honest, I don't actually see the use for defining an ID in CSS instead of a class.

Turtle91
06-03-2013, 04:40 PM
But to be honest, I don't actually see the use for defining an ID in CSS instead of a class.:thumbsup:

I would surmise that "those who create the specs" wanted to keep things ordered and logical when they defined a group style vs. an individual style. In practice things don't always get used as intended, hence we have deprecated styles and tags.

I think it's just a matter of technique. I have used the tag selectors to change the way a particular item class is styled...if the change is minor, or if i need to do it to achieve specific functionality.

For example to not take up space on a page, but to get sigil to put it in the TOC.

h2[title="Copyright Page"] {display:none; margin:0}

<h2 title="Copyright Page"></h2>

Jellby
06-04-2013, 04:21 AM
But to be honest, I don't actually see the use for defining an ID in CSS instead of a class.

Sometimes you need special values for one particular instance, and images are a common case.

Have a look at my Tom Sawyer ePub, the chapter title illustrations have a code to wrap the text around them, and since every image is a different size, the code needs to be different.

Of course, I could have created a class for each image, but creating a class for something that will never ever have more than one member is as wrong as creating a different id for things that are no different at all ;)

So, in general I agree, classes are to be preferred, but ids have their uses too.