Kobo Bug thread

[JSWolf]

Originally Posted by Rev. Bob

I am staunchly opposed to any set of standards designed around any one company's platform.

The programs I've seen for iOS have these options and some have more. So if we go with that set of options as the base minimum, then we'll be good to go.

Taking these one at a time:

- "No margins." On anything? Bad idea. If nothing else, the existing HTML specs define certain default margins; devices should adhere to those rather than defining a new set of defaults that results in contradictions. We'd have the browser wars all over again.

No margins is left/right of 0. This means that the software can set the margins. If you have the main margins set to something, you cannot unset and go back. You can only add to it. So 0 means you can have the margins you want using the software's margin settings.

- "No excessive space." Useless, since "excessive" is a subjective definition.

No excessive space is not always subjective. I've seen plenty of eBooks with a wasted space of 14% or similar for the chapter header. That is a waste of space.

- "No line-height." Setting line-height to zero instantly makes all text unreadable, if strictly implemented. Omitting the parameter for standard-size text is something I can get on board with, but particularly with Kobo, not setting line-height when changing font size is a recipe for disaster. (Ever seen headers that overlap when the text wraps to a second line? That's why that happens. Setting line-height to "normal" when resizing text fixes that.)

No line-height is not specifying a line-height and letting the software defaults (along with the font) to handle that. If the program has an option to set the line-height, then the user can increase that if wanted.

- "No embedded fonts except as needed." Please define "need." It's one thing to define it functionally ("I need to display some emoji characters."), but some people will define it cosmetically ("I need to use this font to convey this style.").

No embedded fonts The problem with most embedded fonts is that they don't display well on an eInk screen. They are too light. An example of a very poorly made eBook is The Martian A very good book but poorly made because of the embedded fonts. The fonts used are free serif, free sans-serif, and free monospace. All of those fonts are terrible on eInk because they are way too light. On a Carta screen, they looked very thin and light. I had to remove them because they did not work. That is an example of not needed.

- "No paragraph spaces." Back to the browser wars, I see.

No paragraph spaces I've seen some programs that have the ability to set the spacing between paragraphs. Not all programs do. But, given that there is no standard for eBooks, might as well go with no paragraph spaces.

- "Indents of 1.2-1.5em." A range is not a number, so here you're getting into "best practices." I agree that paragraph indents should be around that mark - I use 1.5em, myself - but I would strongly resist making that a default value in the reader.

Indents of 1.2em-1.5em is a good idea. I've seen indents as bad as 5% and as bad as 0. When you get paragraph spaces and no indent, it looks like section breaks. That makes it harder to read comfortably.

[sherman]

Originally Posted by JSWolf

No excessive space is not always subjective. I've seen plenty of eBooks with a wasted space of 14% or similar for the chapter header. That is a waste of space.

For once, I actually agree with most of your points, but this is the one I do not agree with. A chapter heading space is in fact very subjective.

I personally find 10%-30% top margin for a chapter heading pleasing to the eye, and helps emphasize a new chapter. I do not consider it "waste of space".

Believe it or not, some of us actually like a bit of white space when reading, despite the fact that the Gospel of Jon states "Thou shalt not include any whitespace in a book..."

[JSWolf]

Originally Posted by sherman

For once, I actually agree with most of your points, but this is the one I do not agree with. A chapter heading space is in fact very subjective.

I personally find 10%-30% top margin for a chapter heading pleasing to the eye, and helps emphasize a new chapter. I do not consider it "waste of space".

Believe it or not, some of us actually like a bit of white space when reading, despite the fact that the Gospel of Jon states "Thou shalt not include any whitespace in a book..."

I know it's subjective, but I find an overly large space for chapter headings to look awful. I know what I prefer is not what everyone prefers. But there are ways to compromise. For chapter headers, I think a 2em top and a 2em bottom would be a good compromise.

[Rev. Bob]

Originally Posted by JSWolf

No embedded fonts The problem with most embedded fonts is that they don't display well on an eInk screen. They are too light. An example of a very poorly made eBook is The Martian A very good book but poorly made because of the embedded fonts. The fonts used are free serif, free sans-serif, and free monospace. All of those fonts are terrible on eInk because they are way too light. On a Carta screen, they looked very thin and light. I had to remove them because they did not work. That is an example of not needed.

"Badly chosen" ≠ "not needed." In a different forum, someone has brought up the case of a book that, when originally published, used three different fonts to switch between three different viewpoints. When it was translated to ebook, all the fonts got stripped out and key information was therefore lost.

Originally Posted by JSWolf

No paragraph spaces I've seen some programs that have the ability to set the spacing between paragraphs. Not all programs do. But, given that there is no standard for eBooks, might as well go with no paragraph spaces.

There IS a standard for ebooks. 1em top and bottom, 0 left and right. It comes from HTML.

Originally Posted by JSWolf

I know it's subjective, but I find an overly large space for chapter headings to look awful. I know what I prefer is not what everyone prefers. But there are ways to compromise. For chapter headers, I think a 2em top and a 2em bottom would be a good compromise.

Here again, the Hn elements already have default margins. Like paragraphs, that default is "skip a line above and below."

The whole rationale for building ebooks with web technologies is to use those technologies, not to redefine them. Sure, it's mildly inconvenient to put a "no margins for body paragraphs" rule into individual ebooks - but that's a much better option than redefining how HTML should be displayed and hoping individual manufacturers all switch over to that new set of definitions at the same time - and magically update every old device and piece of software along the way.

Establishing a basic stylesheet that could serve as the skeleton for new ebooks, that's one thing. Trying to redefine long-standing standards in one particular context is very, very different.

[JSWolf]

Originally Posted by Rev. Bob

"Badly chosen" ≠ "not needed." In a different forum, someone has brought up the case of a book that, when originally published, used three different fonts to switch between three different viewpoints. When it was translated to ebook, all the fonts got stripped out and key information was therefore lost.

That example shows that the embedded fonts were needed. But I've seen many eBooks where the embedded fonts did not work well with eInk and were actually not needed.

There IS a standard for ebooks. 1em top and bottom, 0 left and right. It comes from HTML.

I've never seen a standard for eBooks being 1em top & 1em bottom. In fact, I've seen no standard at all. I've seen eBooks with way too much space between paragraphs and those with no paragraph spaces and some with .3em between paragraphs. So as for standards for how the space between paragraphs is done, there's no standard. I prefer no space between paragraphs, but if there is to be some space, .3em is not all that bad. 1em is all that bad.

Here again, the Hn elements already have default margins. Like paragraphs, that default is "skip a line above and below."

And also p defaults to no margins. But we have CSS to be able to define how p works and we can define other classes to modify p from how p is defaulting or defined.

The whole rationale for building ebooks with web technologies is to use those technologies, not to redefine them. Sure, it's mildly inconvenient to put a "no margins for body paragraphs" rule into individual ebooks - but that's a much better option than redefining how HTML should be displayed and hoping individual manufacturers all switch over to that new set of definitions at the same time - and magically update every old device and piece of software along the way.

Establishing a basic stylesheet that could serve as the skeleton for new ebooks, that's one thing. Trying to redefine long-standing standards in one particular context is very, very different.

I'm not trying to redefine how the defaults for HTML work. I'm trying to define the defaults for how eBooks should be formatted. That means using CSS to define how some things work aka p. By default, p's defaults don't work for eBooks. So CSS is needed to change how p works. be it redefining p or using a class.

[Rev. Bob]

Originally Posted by JSWolf

I've never seen a standard for [restoring antecedent: PARAGRAPHS IN] eBooks being 1em top & 1em bottom. In fact, I've seen no standard at all.

Then you have not read the EPUB spec, which imports the existing HTML and CSS specifications. That's where P gets its default margins from.

Are those "good" defaults for body text in a novel? I agree that they are not - but changing the rendering defaults is what you'd call a Really Horrifically Awful Plan.

Originally Posted by JSWolf

I've seen eBooks with way too much space between paragraphs and those with no paragraph spaces and some with .3em between paragraphs. So as for standards for how the space between paragraphs is done, there's no standard. I prefer no space between paragraphs, but if there is to be some space, .3em is not all that bad. 1em is all that bad.

See, the problem is that we're talking about technical specs (HTML/CSS) alongside aesthetic standards, and we really need to differentiate those for this to be a meaningful conversation. Right here, you're talking about an aesthetic point that I happen to agree with, but in such a way that it sounds like you're saying no technical standards exist - which is very, very incorrect.

Originally Posted by JSWolf

And also p defaults to no margins. But we have CSS to be able to define how p works and we can define other classes to modify p from how p is defaulting or defined.

I'm not trying to redefine how the defaults for HTML work.

Um, you just did that very thing.

Saying "p defaults to no margins" makes an assertion related to the technical spec, and it is incorrect. The P element defaults to "margin: 1em 0;" - that is, one blank line above and below, with no empty space on the sides. Either you're trying to redefine the spec, or you're expressing yourself rather badly in talking about what the aesthetic standard ought to be.

Originally Posted by JSWolf

By default, p's defaults don't work for eBooks. So CSS is needed to change how p works. be it redefining p or using a class.

Your focus is so narrow that it does you a disservice here; you have apparently overlooked that the P element is used for things besides body text, and in those circumstances, the HTML defaults can work quite well.

Do you notice how I take care to differentiate between semantic elements of a book ("body text" or "body paragraphs" and "chapter headers") and technical elements used to render those elements ("the P element" and "Hn elements")? It's not accidental, and it gets frustrating when you haphazardly blend them together after I've taken great care to distinguish them.

Ultimately, it matters little to the reader whether an ebook achieves "no vertical margin between body paragraphs" by applying corrective CSS to P elements or by using DIV elements which default to having no vertical margins. The latter makes me cringe a bit because of the "semantic markup" aspect that's getting thrown away, but they're both valid approaches.

[JSWolf]

Originally Posted by Rev. Bob

Then you have not read the EPUB spec, which imports the existing HTML and CSS specifications. That's where P gets its default margins from.

I know that ePub gets defaults from HTML but, I'm talking about the formatting. p does have defaults and for eBooks, those defaults don't work. eBooks should have a standard set of formatting rules such that the options can then be used so the user can set the eBook to look how he/she wants.

There is a difference between the defaults of HTML and the defaults of formatting. I'm talking formatting, with some HTML defaults but not all. I'd go with the default font size and the default line-height. But I would not go with the default text-indent or the default paragraph space.

Are those "good" defaults for body text in a novel? I agree that they are not - but changing the rendering defaults is what you'd call a Really Horrifically Awful Plan.

The problem is that most reading software cannot subtract but only add. So when you have left/right margins of 1em you can only make them larger, not smaller. So yes, we need CSS to help change some of the defaults of p.

See, the problem is that we're talking about technical specs (HTML/CSS) alongside aesthetic standards, and we really need to differentiate those for this to be a meaningful conversation. Right here, you're talking about an aesthetic point that I happen to agree with, but in such a way that it sounds like you're saying no technical standards exist - which is very, very incorrect.

Technical standards do exist. But they are not always what's wanted or needed for the job at hand. That's where CSS comes in to help chamge the standards so they are as needed.

Um, you just did that very thing.

Saying "p defaults to no margins" makes an assertion related to the technical spec, and it is incorrect. The P element defaults to "margin: 1em 0;" - that is, one blank line above and below, with no empty space on the sides. Either you're trying to redefine the spec, or you're expressing yourself rather badly in talking about what the aesthetic standard ought to be.

I know p defaults to 1em margins and I don't think that's appropriate for eBooks.

Your focus is so narrow that it does you a disservice here; you have apparently overlooked that the P element is used for things besides body text, and in those circumstances, the HTML defaults can work quite well.

Yes, I know p is used for other things. Sometimes not quite correctly. Header text should be using a h and not a p. Programs like Sigil use h to generate a ToC.

Do you notice how I take care to differentiate between semantic elements of a book ("body text" or "body paragraphs" and "chapter headers") and technical elements used to render those elements ("the P element" and "Hn elements")? It's not accidental, and it gets frustrating when you haphazardly blend them together after I've taken great care to distinguish them.

Not all text is body text. So yes, you are correct here.

Ultimately, it matters little to the reader whether an ebook achieves "no vertical margin between body paragraphs" by applying corrective CSS to P elements or by using DIV elements which default to having no vertical margins. The latter makes me cringe a bit because of the "semantic markup" aspect that's getting thrown away, but they're both valid approaches.

Personally, I find div instead of p to be poor coding even though it is correct.

[Rev. Bob]

Originally Posted by JSWolf

I know that ePub gets defaults from HTML but, I'm talking about the formatting.

You're talking nonsense. "I'm not talking about the formatting, I'm talking about the formatting!"

Originally Posted by JSWolf

eBooks should have a standard set of formatting rules such that the options can then be used so the user can set the eBook to look how he/she wants.

More nonsense. You've just tossed book-level, spec-level, reader-level, and UI implementation into a blender and hit "puree." You either don't know what you're talking about or can't express yourself; either way, you're just babbling.

Originally Posted by JSWolf

There is a difference between the defaults of HTML and the defaults of formatting. I'm talking formatting, with some HTML defaults but not all. I'd go with the default font size and the default line-height. But I would not go with the default text-indent or the default paragraph space.

At the risk of sounding even more like a broken record - more nonsensical babbling. See my first paragraph in this message. You sound like you want readers to change some of the display defaults that are defined in the HTML spec, and I told you before that that's just not going to happen.

Originally Posted by JSWolf

The problem is that most reading software cannot subtract but only add. So when you have left/right margins of 1em you can only make them larger, not smaller. So yes, we need CSS to help change some of the defaults of p.

The complete non sequitur in your third sentence transforms the entire paragraph into gobbledegook. Yet again, you're blending things that happen at different levels as if they're all one thing, not to mention stating outright falsehoods. (P's left/right margins default to zero, not 1em.)

Let me be clear. What I'd like to see is not a change in the specs, in reader software/devices, or anything like that. I'm advocating a simple, basic stylesheet that publishers and authors could use as a starting point for the ebooks they produce, and an accompanying set of principles to use in case a particular book needs rules that aren't defined there. That's all.

For instance, suppose we all agreed to define a standard body text paragraph as having zero margins all around, no changes to font size or line height, and a first-line indent of 1.5em... and then we defined that as class "std". A non-indented version would be the same, except for a zero value for first-line indent - and since that's usually used to start a section/chapter, that could be "first". These are CSS classes, and those two right there are sufficient to lay out the bulk of your average novel.

In terms of principles, those would be more like "use the body text indent value as your standard unit of indentation, applying to lists and blockquotes as needed." Likewise, "always accompany center-justification with a first-line indent value of zero" to prevent "centered" text that isn't, "define text sizes in ems or percentages, instead of pixels, cms, or inches" to make sure scaling works right, and "define your standard document properties - font, justification, et al. - in the BODY element's style rules, instead of over and over in every class" to promote compactness.

None of that talks about reader software or device GUIs, because that's not its job. The guiding principle here is to trust the platform to do its job and focus on giving publishers an easy way to deliver a robust, flexible book that any platform can render well.

Do you see the difference in how I'm talking about this versus how you are? Any publisher reading my advice above can put it to work immediately, but someone reading your prescriptions would be lost about whether these were things they should do in their books or things future platforms would handle for them.

[Akerbos]

Aura One

For everybody who has problems with the touch display: use the fleshy parts of your fingertips (where you'd take a fingerprint), not the skinny/bony parts (the actual tip, next to the nail). I get almost 100% recognition of taps and swipes with the former, but very low with the rest.

Also, changing a word selection really sucks. Not only is grabbing the handle extremely tough (see also former paragraph) but moving is lags so bad. Workaround: hold tap, but before the handles appear, move as if to select a passage. Then the Kobo will actually select that passage. Sometimes.

[Amiieey]

I turn the brightness down to 1%. It stays at 1% for like a minute, then the lights turn off. I turn it back to 1%, stays for a minute, turns off again. Annoying...

[DNSB]

Originally Posted by Amiieey

I turn the brightness down to 1%. It stays at 1% for like a minute, then the lights turn off. I turn it back to 1%, stays for a minute, turns off again. Annoying...

A known bug which Kobo is aware of. Hopefully, to be fixed RSN.

[Rev. Bob]

Originally Posted by Rev. Bob

For instance, suppose we all agreed to define a standard body text paragraph as having zero margins all around, no changes to font size or line height, and a first-line indent of 1.5em... and then we defined that as class "std". A non-indented version would be the same, except for a zero value for first-line indent - and since that's usually used to start a section/chapter, that could be "first". These are CSS classes, and those two right there are sufficient to lay out the bulk of your average novel.

As a belated postscript, I just proved that about an hour ago. I saw a series in the Smashwords sale that was eight short stories (all available free) and one omnibus (not free). As far as I'm aware, the omnibus contains zero new content, so I just snagged the infividual stories and reconstructed the collection myself.

This actually proved much easier than I'd expected it would. Saving a sample of the omnibus got me the front matter and the first two stories. Once I cleaned those up, I used the stub of the third story (title and first paragraph) to make a template for the other six stories' files. The back matter was fairly standard, so I lifted that from the last story in the set (as the most recent). So, in relatively short order, I've got a pretty solid skeleton for the omnibus.

After that, it was just a matter of opening the omnibus and each story in separate calibre instances, deleting all the text files from each component ebook to leave just the story intact (not even the title!), and cleaning out the unused CSS classes. In most of the cases, all I was left with was one class for the body text, another for the midpoint line Smashwords likes to insert, and sometimes an italics class. A quick search let me remove tbe midpoints and deal with italics, then I just renamed the body text class to match the omnibus stylesheet. Copy, paste, save, repeat until done. I don't think the omnibus style sheet topped 50 lines.

[Akerbos]

I thought I stumbled over settings in Calibre once that allowed you to replace all styles when saving an EPUB to disk.

[JSWolf]

Originally Posted by Akerbos

I thought I stumbled over settings in Calibre once that allowed you to replace all styles when saving an EPUB to disk.

Why would you want to muck up the ePub by replacing all of the styles?

[paulaf]

Hi,

I have reported my issue of not being able to open library books to Kobo using the email address provided, see my other post, not sure if I am allowed to copy the text in here.