Next chapter in the saga of poor ebook formatting

[DiapDealer]

Originally Posted by Barty

I haven't actually tried this so I don't know if it is correct or how well it is supported.

Pseudo elements won't work on most RMSDK-based renderers. Which means the majority of eink epub devices.

[JSWolf]

Originally Posted by GERGE

Then download the epub from Kobo, they are untouched. Kobo is just trying to fix one of the biggest problems with epubs, ignorant publishers.

You have it all wrong here. Kobo is NOT trying to fix problems with ePub. What Kobo are doing is converting to kepub for use with Access. Anything stripped out is not due to fixing anything that has to do with poor formatting. It has to do with all of the setting options working. Please stop spreading such misinformation.

[GERGE]

Those settings doesn't work because of poor formating.

[Little.Egret]

Originally Posted by Joques

Murg, is there an easy way to add text/graphics/asterisks to scene breaks using CSS? I'm guessing no, or it would have been mentioned already

Even if there isn't, a CSS class defined for scene breaks will make it a lot easier to find and alter the glyphs used.

[Turtle91]

Another method for scene break:

<p>before break</p>

<div class="SecBrk">***</div>

<p>after break</p>


css:
div.SecBrk {
    text-indent: 0;
    text-align: center;
    margin: 1em auto}

div.SecBrk + p {text-indent:0}

I've heard that there are some old/obsolete devices that might not support the "div.SecBrk + p" but I figure that if the user can't get a decent reader then they can deal with an indented paragraph after the visible section break.


edit:
Of course you could easily replace the *** with a fleuron by replacing it with an <img> and customizing the css:

<div class="SecBrk"><img alt="" src="../Images/fleuron.jpg" /></div>

css:
div.SecBrk img {
   width: 20%;
   max-width: 25px; (I put the width of the actual img here so it doesn't fuzz out)
}

[Joques]

Turtle91, you would still have to manually insert <div class="SecBrk">***</div> at every relevant point in the book, right? So at that point, why not simply manually paste "***" into those points instead? What do you gain by creating and using that SecBrk class?

[JSWolf]

Originally Posted by Joques

Turtle91, you would still have to manually insert <div class="SecBrk">***</div> at every relevant point in the book, right? So at that point, why not simply manually paste "***" into those points instead? What do you gain by creating and using that SecBrk class?

Because you can easily change the spacing, the text size, the color, the centering, and anything else you want to adjust that you can.

I've recently seen a book that uses symbols in the space break, but they are setup as a grey color so they are visible, but do not stand out so much. I kind of like it that way.

[MacEachaidh]

Originally Posted by JSWolf

I've recently seen a book that uses symbols in the space break, but they are setup as a grey color so they are visible, but do not stand out so much. I kind of like it that way.

That's what I do myself with my fiction books. It's a nice way to go, I think, because it gives the visual cue of a section break without dominating the text. There's not really any good reason an e.book should look like a barely-formatted .txt file.

[GERGE]

I have seen one of the most terrible design choices just now. I downloaded Silkworm as an epub3 from Kobo. Book was very well designed at first look. But I realized something after changing some pages, spacing between words were very uneven, there were no hyphenations.

It turned out the publisher had hyphenations disabled from the css. Why? Oh, God why! How could anyone ever have a reason to do this?

[JSWolf]

Originally Posted by GERGE

I have seen one of the most terrible design choices just now. I downloaded Silkworm as an epub3 from Kobo. Book was very well designed at first look. But I realized something after changing some pages, spacing between words were very uneven, there were no hyphenations.

It turned out the published had hyphenations disabled from the css. Why? Oh, God why! How could anyone ever have a reason to do this?

That's an easy question to answer. It's because devices like nook Readers go crazy and over hyphenate.

[GERGE]

I thought Nook used RMSDK?

[GeoffR]

The book I'm reading now, published by Open Road Media, has the body margins set like this:

body
{
margin-left:1.5%;
margin-right:20px;
}

So if you happen to be reading on a device with a horizontal resolution of about 1333px then you'll get nice even 20px left/right margins, but if your device has a horizontal resolution of anything other than about 1333px, then one margin will be bigger than the other.

[DiapDealer]

Originally Posted by GeoffR

The book I'm reading now, published by Open Road Media, has the body margins set like this:

body
{
margin-left:1.5%;
margin-right:20px;
}

So if you happen to be reading on a device with a horizontal resolution of about 1333px then you'll get nice even 20px left/right margins, but if your device has a horizontal resolution of anything other than about 1333px, then one margin will be bigger than the other.

I see the "one margin greater than the other" thing quite a bit (even in big-league publishing). I would think that equal left/right margins would be pretty-much a no-brainer at this point.

[GERGE]

All WotC books are like that. I opened a topic about it now at the Candlekeep.

[j.p.s]

Originally Posted by DiapDealer

I see the "one margin greater than the other" thing quite a bit (even in big-league publishing). I would think that equal left/right margins would be pretty-much a no-brainer at this point.

What justification is there for specifying one in % and the other in px?