Basic rules of ePubs

[JSWolf]

Originally Posted by HarryT

"1em" is useful, although it is, as you rightly say, the default, because it allows the font size to be easily changed. If you set "1em" as the font size for something, and you later decide that you'd like it to be a little larger, it's easier to change "1em" to "1.2em" than to have to insert a new line into the CSS.

Actually, it's not easier because you first have to insert the 1em and then change it to 1.2em when all you have to do is insert the 1.2em the first time instead of inserting 1em and then having to change it. Doing it wrong the first time just because you might want to change it later is bad practice.

[JSWolf]

Originally Posted by harriska2

JSWolf, do you know of a primer and tool for fixing these issues?

What I do with ePub is load it into the Calibre eBook editor and use the option to remove unused CSS classes. You'd be amazed at the amount of unused CSS entries there can be. Then it's a lot easier to look at the XML/CSS and clean up the mess (which I do by hand). When I find a find some code in the CSS I want to remove, I just do it with a search/replace because usually if it's not wanted in one class, chances are it's not wanted in all the classes it's in. If I make a mistake, I will still have the unmodified XML/CSS to refer back to.

[HarryT]

Originally Posted by JSWolf

Actually, it's not easier because you first have to insert the 1em and then change it to 1.2em when all you have to do is insert the 1.2em the first time instead of inserting 1em and then having to change it. Doing it wrong the first time just because you might want to change it later is bad practice.

I personally prefer to explicitly specify the size of all text elements in the book, even if the size is 1 em. This certainly isn't "wrong".

[JSWolf]

Originally Posted by HarryT

I personally prefer to explicitly specify the size of all text elements in the book, even if the size is 1 em. This certainly isn't "wrong".

There are people to whom this won't matter if the font size is specified or not. But there are people to whom it will matter. And for those people, it should not be specified when the default should be used. That's the purpose of a default. So really, specifying when it's more appropriate for the default to be used is poor coding and whoever does this should never be let in front of eBook code (IMHO).

[Turtle91]

Shouldn't the question be: Does specifying the font size prevent the app/device from changing it?? If so, then it should not be defined in the CSS. e.g. p{font-size:1em}.

However, the way I understand it, setting font-size in ems only means that element's font is relative to the selected display font size. e.g. font-size:1.2em in a header would display 20% larger than the display's selected font size and a 1em for the basic paragraph would be the selected font size. In that case specifying p{font-size:1em} is not wrong, or even detrimental, it is simply being overly specific.

I would prefer someone being overly specific just to be on the safe side.

What I hate to see is when publishers define the basic font size as too small... p {font-size: .8em}

[JSWolf]

If the default is used then you won't have to worry about someone getting it wrong.

[theducks]

Originally Posted by JSWolf

If the default is used then you won't have to worry about someone getting it wrong.

You will if the device default is wrong, which on RMSDK it is.

If you don't force it, those block numbers smear the text on the right, making both unreadable.
If I use
body{
display: block;
font-size: 1.2em;
line-height: 1.2;
page-break-before: always;
margin: 0 16pt 0 2pt;
padding-right: 0;
padding-left: 0;}

With a level 3 zoom (1 being default), those numbers don't smear until the fourth digit

[Turtle91]

Originally Posted by JSWolf

So really, specifying when it's more appropriate for the default to be used is poor coding and whoever does this should never be let in front of eBook code (IMHO).

I'm one to always push for vendors to stick to the spec so my books will look the same no matter on what device they are read. But, as we all know, the reality is that they don't. Some publishers adapt their coding so that it works on more devices... that means they will have extra stuff in their CSS than I would in mine since I only code for my reading app (Marvin) which sticks to the spec in almost all cases. I certainly wouldn't call them wrong, or a bad coder, for including that coding...

[Cinisajoy]

I just picked up a book. I have a new complaint.
Double spaces between every paragraph. That is making it almost impossible to read.

[Purple Lady]

Originally Posted by Turtle91

I'm one to always push for vendors to stick to the spec so my books will look the same no matter on what device they are read. But, as we all know, the reality is that they don't. Some publishers adapt their coding so that it works on more devices... that means they will have extra stuff in their CSS than I would in mine since I only code for my reading app (Marvin) which sticks to the spec in almost all cases. I certainly wouldn't call them wrong, or a bad coder, for including that coding...

Some apps do this too. Scribd used huge margins if you were on a seven inch or larger device. On a six inch device the margins were still a little too large for me, but were smaller. I couldn't fix this even if I restored the version with data from my phone to my tablet.

[JSWolf]

Originally Posted by theducks

You will if the device default is wrong, which on RMSDK it is.

RMDSK is not wrong, the default font size is 1em. You may want a different font size, but the default is not wrong.

If you don't force it, those block numbers smear the text on the right, making both unreadable.
If I use
body{
display: block;
font-size: 1.2em;
line-height: 1.2;
page-break-before: always;
margin: 0 16pt 0 2pt;
padding-right: 0;
padding-left: 0;}

With a level 3 zoom (1 being default), those numbers don't smear until the fourth digit

If you use an old version RMDSK then yes, you will get the numbers on the right side. But that would be a 1.7.2 version ADE and not a 2.0+ version ADE. In some versions RMDSK, you can turn on or off the right margin page numbers. You can on Kobo Readers. Publishers need to stop coding for the right margin page number. It just causes a large margin. And stop using @ page as that can cause such a page number to move away from the bezel more towards the left side of the screen.

[theducks]

Originally Posted by JSWolf

RMDSK is not wrong, the default font size is 1em. You may want a different font size, but the default is not wrong.



If you use an old version RMDSK then yes, you will get the numbers on the right side. But that would be a 1.7.2 version ADE and not a 2.0+ version ADE. In some versions RMDSK, you can turn on or off the right margin page numbers. You can on Kobo Readers. Publishers need to stop coding for the right margin page number. It just causes a large margin. And stop using @ page as that can cause such a page number to move away from the bezel more towards the left side of the screen.

Really? Something that distorts the text is just wrong.
It takes a combination of those margins and that base font to work around this BUG.

BTW Don't tell me all I have to do is Upgrade. There are NO UPGRADES. ASTAK is out of the reader game

[JSWolf]

Originally Posted by theducks

Really? Something that distorts the text is just wrong.
It takes a combination of those margins and that base font to work around this BUG.

BTW Don't tell me all I have to do is Upgrade. There are NO UPGRADES. ASTAK is out of the reader game

The Sony Readers prior to the x50 line also have this page number. I just dealt with it. It wasn't difficult for me to read the text that overlapped the page number on the 505.

But yes, I do see your point. The older devices using a too old RMDSK are an issue.

[crankypants]

> Self-published books are usually okay but almost no big publisher understands one crucial thing: we are using ebook readers, you don't need to set this things!

Hi George, I'm with you. I'm a computer person and I work in the print industry. We provide print and data management services for other publishing companies. The people we work with are the marketing department. I typeset pages, and they provide the data. The marketing people are very nice but are VERY short on computer knowledge, but, they should not have to learn computers and how to typeset, because that's MY job.

I'm competent in designing a different system to meet the needs of any publisher, and I have the experience to back it up. We need the data in certain formats in order to save them money. However, some companies refuse to follow our directions, so we have to manually fix the data they send us, which increases their cost. Then they wonder why our charges are so expensive.

But the state of the industry is, many publishers are tight on money, or at least their budgets are tight in order to meet goals centered around stock value. So their leaders are simply saying "Convert this to an EPUB in the cheapest way possible." And that's what the non-computer marketing department does. You'd be surprised how many companies that distribute print materials have NO computer people to help them publish, they simply have minimal IT guys who are so overworked and stressed the IT guy cannot possibly help them with converting to EPUB.

Your complaints are valid, but, unfortunately, until leadership of the print companies understands the importance of specialty employees (or services like mine), they will continue to issue crappy EPUBs.

The best suggestion I have: make screen shots of crappy ebooks, post them on the internet, and send a copy of the link to the CEO of that company, or the director of the publishing department. Some people just won't listen until you effect their reputation or bottom line (stock price).

[odamizu]

Originally Posted by JSWolf

What I do with ePub is load it into the Calibre eBook editor and use the option to remove unused CSS classes.

Oh wow, I love this! Didn't realize Calibre could strip unused CSS.

Is there a difference doing it via "Edit Book" rather than "Polish books" as far as results go? Or is it the same function/module?