[Anak]

Originally Posted by sysKin

Allow me to put it this way: every engineering effort is facing tradeoffs, and there's always a few parameters that are the "selling points", the most major limitations that were pushed to the limit. In case of mobile gadgets it's typically size/weight/battery life, in case of a car it might be engine power or fuel efficiency, in case of a TV it's the screen size, and so on.

Those are the most important limitations that, for a consumer, almost define how good the device is.

Kobo is actively advertising its Glo as having a six inch screen because screen size is important. It's one of those parameters where a 20% decrease cuts the sale price by a factor of three (Mini) and 13% increase almost doubles the price and creates a lot of buzz (Aura).

If screen size is important and scarce, it is common sense (and basic engineering practice) to do everything possible to maximise its use. If they use any pixel of it for non-primary task, they better have a VERY good reason.

They just did the opposite. How am I suppose to not be baffled?

If you excuse a straw-man argument, what they did is an equivalent of making a mobile phone, advertising it as thin and light, and then gluing a big heavy metal ornament to each device.

Comparisons to a paper book are not helpful because paper book's paper size is not the critical design constraint. I certainly wouldn't pay twice the price for a 6.8 inch paper book compared to a 6 inch paper book!

Hopefully this makes sense, and I do apologise for monopolising entire firmware thread with this single issue... I'm being passionate about it not so much because I don't like it (I haven't updated the firmware and will not) but because it's a very bad sign of some very faulty decision making process -- process that probably will affect me one day.



Actually you might not understand what I want after all.
What I want is for firmware changes to be consistent, justifiable, and at least remotely predictable.
I don't require individual changes to suit my tastes and needs, this won't happen. If Kobo provided any glimpse into their thinking process, showing that this sacrifice in reading space is justified (a loss comparable to Glo->Mini product change), at least I wouldn't question their common sense and their goals.
For example all the Facebook integration was clearly led by their need to make money by forging relationships with other companies. I'm not happy about that, but I understand it and their goals, and I've never complained about it.

So far the only justification for title bar is consistency with kepubs. It's actually not a bad justification, except that achieving the same consistency by *removing* that silly bar from kepubs is so *obvious*...

Let me say first that there is nothing wrong with Kobos hardware. The build quality is very good. But Kobos firmware? I agree with gouni when he said:

Originally Posted by gouni

…
I have never seen a development repair, break, repair, break, repair, break, repair, break each new system.
I find the kobo looks nice, in my country it is best-selling.
…

And yes, releasing a new software/firmware update comes sometimes with unwanted side effects: a standard feature seems suddenly to be broken or not function properly and should be fixed with the next firmware release or the next one after. But it is their cycle that worries me: repair, break…

And I can also not say that Kobo doesn't try to fix bugs at all. But going through the threads here on MR and on Getsatisfaction learns that there are a lot of very old bugs that are still waiting to be fixed. Some of these bugs are major, some minor (not irrelevant, trivial maybe), and some are totally unnecessary.
I'll give you one example of a minor, for some irrelevant, but a totally unnecessery bug in the metadata of regular epubs: the publisher name is not displayed (<dcublisher>Hachette</dcublisher>) and so easy to fix.

Originally Posted by taming

I don't understand why anyone expects a mass produced consumer product to be entirely in line with any one individual's preferences. I also don't understand why not getting everything perfectly aligned with one's individual preferences is evidence of stupidity or incompetence on the part of the company that designed it.

This is not about personal preferences but about logical and practial use of a device.
(Nearly) all ebooks sold by publishers have page margins predefined (a user may find these either too small, too large or just right), so it is not necessery that a user agent (the device itself) adds additional margins and therefore not utilizing (maximizing) the available screen size.
The margins of the headers and footers are really huge and can easily be reduced without compromizing readability. The option to hide them completely is highly wanted by me.

Another question we can ask is this: why is Kobo using two different epub rendering engines? These two engines do exactly the same thing, have the same functionality but may accomplish the visual output differently. From developers point of view one of the engines may be easier to work with. Both engines can open pdf files as Access licensed this from Adobe. Two different engines that do things slightly differently to accomplish the same result and in complience with the standards (epub, epub 3, txt…) and doen't seem very cost effective to me (double licensing fees), programming two different engines…

We can also debate if there are really unique features that justify the kepub format. Or is it just a matter of "unique" implementation of features that are incorporated in the underling rendering engines.
Both engines support (just to name a few):

• Dictonary
• Annotations
• Bookmarks
• Highlights
• Notes
• PDF reflow

So it is basically a matter of implementation of the available features in the rendering engine. And it is the implementation that makes or breaks a feature.
So a feature must be easy to use: feature must be logical, easy to navigate (just one or two clicks instead of navigating through several menus).
Or a choice to activate a feature at all. Kobo decided not to activate pdf reflow.

Bookeen Cybook Odyssey (HD)
Has the same features mentioned above.

• Table of content
• Go To … <page number>
• Font Size
• Font Family
• Night Mode
• Emboldened Text (like Kobos TypeGenius)

These features have the Kobo devices too as they are part of the rendering engine but may be implemented in a different way. E.g. "Go to" feature. Kobo uses a slider to navigate to a page. The Odyssey lets you enter a page number. Which solution I prefer as user? That doesn't matter: the feature is implemented.

The Odyssey can change or switch functions on or off:

• Layout…: Allow you to modify the layout of the book. It opens a second menu.

• Publisher Styles: Option to ignore publisher’s original styles (allows full customization of the publication and also faster processing of complex editions).
• Hyphenation: Select “Hyphenation” and you will hyphenate text for better typographic white space.
• Ligatures: Make ligatures between letters in order to improve the quality of the text.

• Show Header: Show or hide the title of the book in the header part of the page.
• Show Pageometer/Footer: Show or hide pageometer (current page vs total number of pages).

I'm not saying the Odyssey is a better reader, but it offers better flexibility (lets the user decide) while Kobo is forcing it (show header/footer) or settings are preactivated (hyphenation) whithout the ability to turn it off.

Sideloading
What is sideloading? Or what is the main book format epub or kepub?
Kobos own website states:
Supported File Formats: eBooks: EPUB, PDF, and MOBI, Documents: PDF, Images: JPEG, GIF, PNG, BMP, and TIFF, Text: TXT, HTML, and RTF, Comic Books: CBZ and CBR.

So clearly: epub is the main document format. Kepubs is an additional format as it is not mentioned in the specs. The kepub is the sideloaded content.
I'm sure that if Kobo offered to download purchased books only in their own proprietary kepub format and as this format can only be displayed on Kobo devices they will loose (international) market share really fast.

And every special or unique Kobo feature that is only implemented in the kepub format can also be implemented in a regular epub.
Special device specific features shouldn't be embedded (e.g. adding Kobo code, like kobo.css or kobo.js) in the epub of kepub but in the device it self.
So a user can read a regular epub with all the bells and whistles Kobo has added to their devices to enhance user experience. And potential buyers may say "Got to get me a Kobo because it has really unique special features." But… don't forget to make features optional and users are able to switch it on or off. A feature default setting can always be "on" or "auto".

Addition:
Users of a Kobo dedicated e-ink device have no choice. The can not change parts of the GUI.
Tablet users can switch from a Kobo reading app to other reading apps like Stanza, Aldiko, BlueFire. Just to name a few. And I'm aware that these apps aren't perfect either.