Kobo Firmware 2.6.1

[jackie_w]

Originally Posted by treadlightly

I agree, I want ebooks to look the way I want too. In my mind there is no reason why the device couldn't modify the stylesheet settings. If you want to modify yours on your computer, then great, you would select "Use ebook style" on your device. But for those who don't want to do any pre-processing, the settings should be able to be configured by the device. Some of them can be modified presently, why not more of them? One of the biggest reasons that I use an ereader is because I want to modify the display to my liking. So why should the ereader restrict this in any way? One of the reasons I chose Kobo was because it gives the greatest flexibility in this, and the more flexibility that is added will make it even better.

I fear you have an over-simplistic view of how epub css styling works. Overriding styles selectively with 100% success for every epub is just not possible (at least in 2013). There are too many idiotic ways in which epub creators create the css styling and markup the html text content. There are currently only 2 ways to guarantee the precise styling you want.

The first is to manually tweak the internal css for every epub. It works perfectly but is a total PITA because it's time-consuming and you have to learn stuff.

The other way is for the reading app to completely ignore internal css and let the user set everything from the device. This may sound terrific -- and it is for some people. FBReader and CoolReader can do this, both apps work on the PocketBook range of e-ink readers and all Android devices. What frequently happens with this approach (unless things have improved in the last couple of years) is that, depending on the epub, some display features get lost, and no amount of customisation on the reader can reproduce them e.g scenebreaks, centre- and right-alignment, text indented on both sides, inline font-size changes (small-caps & dropcaps). This can be very irritating to those who like their epubs 'just-so'.

Everything else is a compromise somewhere between the two extremes -- and compromises never suit all of the people all of the time.

[DNSB]

Originally Posted by treadlightly

I agree, I want ebooks to look the way I want too. In my mind there is no reason why the device couldn't modify the stylesheet settings. If you want to modify yours on your computer, then great, you would select "Use ebook style" on your device. But for those who don't want to do any pre-processing, the settings should be able to be configured by the device. Some of them can be modified presently, why not more of them? One of the biggest reasons that I use an ereader is because I want to modify the display to my liking. So why should the ereader restrict this in any way? One of the reasons I chose Kobo was because it gives the greatest flexibility in this, and the more flexibility that is added will make it even better.

There is a whole can of worms in modifying styles as they can and are applied at multiple levels. One ebook I recently purchased and as usual, looked at with Sigil, had separate stylesheets for the title page, copyright page, dedication page, body of the book and the publishers blurb pages at the end plus a couple that were just imported into the others. Then there were multiple styles applied at the chapter level and a couple that appeared to be manually added to various special pieces of text (a quote from a poem, for example) that were added to the <div>s around the poem's text.

This ebook also looked very nice on my Aura. The only change I made was removing the first 4 entries from table of contents file so the book opened on the first chapter.

Trying to program two renderers used by Kobo to change that formatting on the fly would take a lot of developer resources and, in my opinion, not work all that well. That poem would just look so good stretched right across the page with the lines joined up - not.

Regards,
David

[TechniSol]

I agree with how annoying the split paragraph issue is. I get it a lot! I can think of no reading related reason for the renderer to default to not splitting paragraphs. There should be a "Fill Page" or "Do Not Split Paragraphs" override option, or this behavior should be eliminated from the code period. It serves no purpose but to annoy the reader.

The only reason I can think of for it's existence is that they reference location by counting paragraphs and splitting one might confuse some other location based functions by the split second part adversely affecting a location or count...

[DNSB]

Originally Posted by JD Gumby

Most paper prose books (barring poetry/lyric sections and suchline) go edge-to-edge, indent paragraphs with no space between paragraphs, have line spacing that is half (or less) of the character height (and which can vary slightly from page to page to keep widows & orphans to a minimum), and know how to split paragraphs when there is a page transition.

Is it really so much to ask that machines that can change formatting and font size on the fly get these sorts of thing right? I think not.

I can't think of any physical books that go edge to edge. A quick measurement on 5 books I have handy show the margins varying from 1.5cm to 2cm on right and left, 2cm to 3cm on the top and 1.8cm to 3cm on the bottom. The first paragraph in each chapter is not indented in 3 of them while the 4th indents all the paragraphs and the 5th doesn't believe in indenting paragraphs. The interline spacing seems to be close to a line-height of 1.2 for four, the 5th uses about 1.4 with 3 of the 5 using about double the interline spacing for paragraph spacing. The other two don't add any extra space between paragraphs.

Looking for pages where a blank line has been left (wider bottom margin) and the first line of the paragraph was moved to the next page, in the glossary in one (Next Generation Firewalls for Dummies), there are as many as two blank lines at the bottom of a page to keep entries on the same page. One example, the single line entry for Limewire is at the bottom of the page with two extra lines worth of blank space and then the entry for Mariposa is at the top of the next page.

Next Generation Firewalls for Dummies by Lawrence C. Miller, CISSP
ISBN: 978-0-470-93955-0

Regards,
David

[TechniSol]

That's great, it still does not explain why the renderer often gives me 7-10 blank lines to move a long paragraph to the next page. It's annoying as one tends to assume that is the chapter or article ending. I've had pages with only a line or two of text. There is a bug in the paragraph splitting algorithm, or at least the one deciding if a split should be made, possibly related to the widow/orphan settings.

[DNSB]

Originally Posted by TechniSol

That's great, it still does not explain why the renderer often gives me 7-10 blank lines to move a long paragraph to the next page. It's annoying as one tends to assume that is the chapter or article ending. I've had pages with only a line or two of text. There is a bug in the paragraph splitting algorithm, or at least the one deciding if a split should be made, possibly related to the widow/orphan settings.

As far as I can tell, it has no relationship to the widow/orphan settings. What it does relate to are long paragraphs which exceed a mysterious number of characters between the start and end tags. Oddly on the couple of occasions when I have renamed an ebook to use the ACCESS renderer, the issue does not seem to occur.

Regards,
David

[treadlightly]

Originally Posted by jackie_w

I fear you have an over-simplistic view of how epub css styling works. Overriding styles selectively with 100% success for every epub is just not possible (at least in 2013). There are too many idiotic ways in which epub creators create the css styling and markup the html text content. There are currently only 2 ways to guarantee the precise styling you want.

The first is to manually tweak the internal css for every epub. It works perfectly but is a total PITA because it's time-consuming and you have to learn stuff.

The other way is for the reading app to completely ignore internal css and let the user set everything from the device. This may sound terrific -- and it is for some people. FBReader and CoolReader can do this, both apps work on the PocketBook range of e-ink readers and all Android devices. What frequently happens with this approach (unless things have improved in the last couple of years) is that, depending on the epub, some display features get lost, and no amount of customisation on the reader can reproduce them e.g scenebreaks, centre- and right-alignment, text indented on both sides, inline font-size changes (small-caps & dropcaps). This can be very irritating to those who like their epubs 'just-so'.

Everything else is a compromise somewhere between the two extremes -- and compromises never suit all of the people all of the time.

Which is why I think the ereader should give the reader two options - (1) leave the stylesheet as per the ebook, for those types of books that have the centre alignment, drop caps, etc, as you describe and (2) complete customization as per FBReader, for example, for those of us that mainly read novels and don't care about having things "just so". Wouldn't that be the closest to the best of both worlds? As you say, this is 2013, where computer animation is detailed down to individual strands of hair, and we are simply talking about text displayed on a page.

[taming]

Originally Posted by treadlightly

Which is why I think the ereader should give the reader two options - (1) leave the stylesheet as per the ebook, for those types of books that have the centre alignment, drop caps, etc, as you describe and (2) complete customization as per FBReader, for example, for those of us that mainly read novels and don't care about having things "just so". Wouldn't that be the closest to the best of both worlds? As you say, this is 2013, where computer animation is detailed down to individual strands of hair, and we are simply talking about text displayed on a page.

There are so many things that would be used by a large percentage of users that could become new features. Making this particular thing happen (which I read as letting people create their own custom stylesheet on device, using some sort of checklist or drop down) seems to be important to a very small percentage of users.

I can't see Kobo investing developer time in this (though I have been wrong before ). For that kind of user, the best choice might be to develop a custom style sheet and then to substitute the book's style sheet with the custom one (which then Kobo would use automatically) or to not use a Kobo eink device and use devices that are built to do that sort of thing.

[AlPe]

Originally Posted by DNSB

As far as I can tell, it has no relationship to the widow/orphan settings.

I agree.

Originally Posted by DNSB

What it does relate to are long paragraphs which exceed a mysterious number of characters between the start and end tags.

I think that, more than the number of characters, the problem is caused by a buggy computation of the logical height required by the next element. Indeed, the defect depends on the font size.

Originally Posted by DNSB

Oddly on the couple of occasions when I have renamed an ebook to use the ACCESS renderer, the issue does not seem to occur.

That is easy to explain: different renderers, different results.

[jackie_w]

Originally Posted by treadlightly

Which is why I think the ereader should give the reader two options - (1) leave the stylesheet as per the ebook, for those types of books that have the centre alignment, drop caps, etc, as you describe and (2) complete customization as per FBReader, for example, for those of us that mainly read novels and don't care about having things "just so". Wouldn't that be the closest to the best of both worlds?

Yes, it would be nice and if you want that you can pay the premium price for one of the Pocketbook range. But you can't currently have all that in a reader which costs less than 100GBP. As I said before, it's all about compromise.

[guma]

Originally Posted by taming

There are so many things that would be used by a large percentage of users that could become new features. Making this particular thing happen (which I read as letting people create their own custom stylesheet on device, using some sort of checklist or drop down) seems to be important to a very small percentage of users.

I can't see Kobo investing developer time in this (though I have been wrong before ). For that kind of user, the best choice might be to develop a custom style sheet and then to substitute the book's style sheet with the custom one (which then Kobo would use automatically) or to not use a Kobo eink device and use devices that are built to do that sort of thing.

I don't think it is that complicated. all that is required is that the device uses the user definable settings already offered in the menus to override book- embedded styles. something that many ereader softwares are able to do just fine.

[treadlightly]

Originally Posted by taming

There are so many things that would be used by a large percentage of users that could become new features. Making this particular thing happen (which I read as letting people create their own custom stylesheet on device, using some sort of checklist or drop down) seems to be important to a very small percentage of users.

I only see it as expanding the selections that are currently there - already there is left/right margins, why not top/bottom margins? And perhaps a setting for widows/orphan, as it is causing confusion. And line-height. And then these settings would override the book css if one so chooses. I really don't believe it would be a complex feature to add.

[taming]

Top Bottom margins may not be just a style sheet choice as things happen in that space that are part of the device's functions. More than that, perhaps the one or two things you want would not be a big deal, but what about the one or two things I want, and the one or two (or dozens of things) someone else wants, ad infinitum?

Nothing will get around the fact that this is a relatively low priced commercial product that is designed to meet the needs of most people, not all people.

[theonna]

Originally Posted by jackie_w

Yes, it would be nice and if you want that you can pay the premium price for one of the Pocketbook range. But you can't currently have all that in a reader which costs less than 100GBP. As I said before, it's all about compromise.

Pocketbook just now released it's reader with light. It is about (today's conversion rate) 210 US dollars in Ukraine. It is called Pocketbook Touch Lux 623. Not that huge of a difference, it costs more to buy Aura from there. But I think it is a mistake to underestimate value of good software, we talking possibility to sell millions more... for the price of salary of a few good programmers? It is not that expensive to develop, compared with profits that can be made with better software.

[treadlightly]

Originally Posted by taming

Top Bottom margins may not be just a style sheet choice as things happen in that space that are part of the device's functions. More than that, perhaps the one or two things you want would not be a big deal, but what about the one or two things I want, and the one or two (or dozens of things) someone else wants, ad infinitum?

Nothing will get around the fact that this is a relatively low priced commercial product that is designed to meet the needs of most people, not all people.

If you read the "If you could design the user interface" thread, I think you will find that most of the suggestions relate to exactly this. I don't buy the "this is a cheap ereader" argument when someone had time to put chess or sudoku or whatever on it.