Touch New Firmware and Desktop! - Page 9

JSWolf · 09-03-2011, 04:45 PM

Quote:

Originally Posted by frankieGom

OK, now that I understand the issue a little better, I need to ask: How should one go on about displaying the fonts as defined in the epub (apart fro making sure the specific font is available in the reader)?

Should there be an option in the reader to over-ride user choice and use embedded fonts if available?

rashkae is wrong, what he sees as a feature is 100% a bug. Kobo is doing it wrong. And I know it can be done correctly. the nook STR supports ePub font overriding and when the ePub has an embedded font and it's enabled using font-family in the body style, it displays unless it's overridden by the custom settings. So if B&N can do it, Kobo can too.

When a publisher embeds fonts in an ePub, 99% of the time, the main font used is enabled via an entry in body such as...

body {
display: block;
font-family: "charis";
}

What should happen is that ADE should use whatever font is defined to the definition of charis. In this case, it would be Charis SIL. Other readers would display the correct font on screen. Kobo ignores this because they have a bug in the font handling. If you look at any of the the new Star Wars eBooks, they come with Charis SIL as an embedded font. B&N, Sony, ADE for Windows or MAC, Pocketbook, and others will display Charis SIL. Kobo will not. Why not? Because it's a bug in the Kobo version of ADE.

Nina182B · 09-03-2011, 05:10 PM

Quote:

Originally Posted by PeterT

When you plugged the Kobo in, was it even detected as a disk drive by the PC?

Yes, it was detected as a disk drive in my computer.

I did the factory reset and everything works fine now. I just hope this doesn't happen to me with every Kobo release. I'm now going through the painful process of marking books in the shortlist.

taming · 09-03-2011, 05:51 PM

It has never happened to me with a Touch update. You should be good to go now!

larrymohr · 09-04-2011, 06:57 PM

Quote:

Originally Posted by JSWolf

rashkae is wrong, what he sees as a feature is 100% a bug. Kobo is doing it wrong. And I know it can be done correctly.

JSWolf,

You are missing the point here. If this is the way that the KOBO devs have intentionally programed the reader to behave it is NOT a bug. A bug is any behaviour contrary to the programmer's intention. It may be silly or stupid or just plain annoying, but it is not a bug unless it is unintentional.

If I wrote a text editor that allways changed the text entered in lowercase to uppercase and upppercase to lowercase, that would be stupid and annoying but if it was my intention, it is NOT a bug.

It is a matter of intent. If it operates as intended, it is not a bug. If it does not operate as intended, it is a bug.

Except in the case where the bug is usefull, then it is called "an undocumented feature"

JSWolf · 09-04-2011, 07:49 PM

Quote:

Originally Posted by larrymohr

JSWolf,

You are missing the point here. If this is the way that the KOBO devs have intentionally programed the reader to behave it is NOT a bug. A bug is any behaviour contrary to the programmer's intention. It may be silly or stupid or just plain annoying, but it is not a bug unless it is unintentional.

If I wrote a text editor that always changed the text entered in lowercase to uppercase and uppercase to lowercase, that would be stupid and annoying but if it was my intention, it is NOT a bug.

It is a matter of intent. If it operates as intended, it is not a bug. If it does not operate as intended, it is a bug.

Except in the case where the bug is useful, then it is called "an undocumented feature"

ADE is not meant to ignore font-family put in the body CSS code. So given that, it is a bug. Even though Kobo may have doe it on purpose, it is still a bug given your logic. The Adobe devs programed ADE to work the way it should and Kobo changing core functionality means that some ePub won't work properly. This is a bug in Kobo's ADE and if it's not a bug, then is a mistake that needs correcting. Either way, it's wrong and should be fixed.

readingglasses · 09-04-2011, 08:17 PM

Maybe if you assume that kobo doesn't really believe their method of font selection will make embedded fonts impossible, then you could say it is a bug.

No doubt it's a "way of working" that should be changed as it trades in one problem for another.

I wonder if the new sony prs t1, with user selectable fonts, will honor embedded fonts, at least optionally, AS WELL AS ANY SONY READER DOES NOW

I don't know about the nook but display of embedded fonts in the sony is pretty limited too. So, they both suck, as far as this.

geormes · 09-05-2011, 08:47 AM

Quote:

Originally Posted by readingglasses

... make embedded fonts impossible...

On my Kobo I have been using Sigil to remove references to embedded fonts, then using my favorite font flavor of the day.
Use of embedded fonts is not possible on the Kobo Touch?
My knowledge of CSS would not fill a beer bottle cap, but lack of knowledge has NEVER stopped me from commenting before so here goes!
To embed a font doesn't the font have to be on the device and the code has to reference the location?
So if you embed a font shouldn't the code have something like:
src:url(fonts/font-flavor.ttf) and font-flavor.ttf be in your fonts directory?

None of this is functional on the Touch??

Pistos · 09-05-2011, 09:34 AM

Indeed, I think some clarification is required here regarding the difference between (a) actually including the font data (which is what I think of when I hear "embedded font"), and (b) merely referring to the font name in CSS -- and which of these two are being referred to in any given post.

fbrII · 09-05-2011, 09:38 AM

I updated yesterday and no problems. I was once more going through the memory/factory reset error and I had chosen to ignore it. Now after the update the error message is gone.

It's too bad it took as long as it did for Kobo to fix the problem because it really is a great device and I think their credibility went down a notch or two.

However, with this update it looks like it's back to being a great device.

SCION · 09-05-2011, 09:40 AM

Quote:

Originally Posted by fbrII

...

It's too bad it took as long as it did for Kobo to fix the problem because it really is a great device and I think their credibility went down a notch or two.
...

Yeah, you see this reflected in non-owner comments in other sub-forums here.

Pistos · 09-05-2011, 09:57 AM

I am really quite curious about the specifics of the issue, but I guess it's wishful thinking to suppose they would divulge any details, as it could make their technical competence seem even worse. If it were possible in some (most?) cases to simply cancel and proceed, then it sounds to me like the conditions that bring up the screen were on the aggressive side -- that is, they designed it intending to err on the side of more false positives, thinking they would have fewer customer complaints because a reset would allow the device to recover and rebuild its database, etc. into a consistent, "within the boundaries" sort of state. If this line of thinking were the case (this is all just speculation on my part), it would seem their plans backfired on them, as users were more frustrated at being bothered by the screen so often (and the long reload times, in some users' cases).

But who knows what problems merely cancelling the reset would have allowed to fester in the device's system files. Certainly, any good software should be able to gracefully handle malformed data. For all we know, though, the 1.9.10 update did nothing more than alter the reset screen's trigger conditions so that it wouldn't appear as much (or at all?), even though nothing was done to actually address any data handling problems.

Perhaps just something to stop the PR bleeding, and bide the dev team time to actually fix things.

But, again, just conjecture on my part.

geormes · 09-05-2011, 10:07 AM

Quote:

Originally Posted by JSWolf

rashkae is wrong, what he sees as a feature is 100% a bug. Kobo is doing it wrong. And I know it can be done correctly. the nook STR supports ePub font overriding and when the ePub has an embedded font and it's enabled using font-family in the body style, it displays unless it's overridden by the custom settings. So if B&N can do it, Kobo can too.

When a publisher embeds fonts in an ePub, 99% of the time, the main font used is enabled via an entry in body such as...

body {
display: block;
font-family: "charis";
}

What should happen is that ADE should use whatever font is defined to the definition of charis. In this case, it would be Charis SIL. Other readers would display the correct font on screen. Kobo ignores this because they have a bug in the font handling. If you look at any of the the new Star Wars eBooks, they come with Charis SIL as an embedded font. B&N, Sony, ADE for Windows or MAC, Pocketbook, and others will display Charis SIL. Kobo will not. Why not? Because it's a bug in the Kobo version of ADE.

Doesn't the Kobo have the following fonts:Amasis, Delima, Felbridge, Gill Sans, Rockwell, Avenir and Georgia as default??
The lack of other fonts like charis is NOT a bug!! You can add charis to Kobo if you wish.
This is a feature not a bug!!

robko · 09-05-2011, 10:37 AM

Quote:

Originally Posted by Pistos

For all we know, though, the 1.9.10 update did nothing more than alter the reset screen's trigger conditions so that it wouldn't appear as much (or at all?), even though nothing was done to actually address any data handling problems.

Perhaps just something to stop the PR bleeding, and bide the dev team time to actually fix things.

If they were going to do a cosmetic coverup I doubt they would have waited 2 months to do it. While I agree with your general point that it seems like the error checking routine was a little to aggressive, just doing a cosmetic coverup would lead to issues down the road that would kill their credibility worse than the current issue. I am curious what percentage of users were actually having issues with it. I was fortunate enough to have never had the issue, and my sympathies to those who had it repeatedly, but I really wonder if it wasn't just a tiny proportion of Kobo owners that were getting it. I can understand why those who were getting it were screaming bloody murder, but that might have made it seem more widespread than it actually was.
Fortunately it appears to be fixed now!

FJames · 09-05-2011, 11:22 AM

Quote:

Originally Posted by larrymohr

If this is the way that the KOBO devs have intentionally programed the reader to behave it is NOT a bug. A bug is any behaviour contrary to the programmer's intention. It may be silly or stupid or just plain annoying, but it is not a bug unless it is unintentional.

That's an incorrect definition a definition of a bug. I lead a software product development team, and I would re-educate any of my developers who thought that. The correct technical definition of a bug is when the program does not do what it's specified to do. Since specifications can't cover every tiny detail, that must be extended in practice to include when the program does not do what a normal user would expect it to do. Developers may have an incorrect understanding of the specifications, or limited knowledge of how a normal user will use the program, or they may simply not have tested all the possibilities. These can all result in bugs.

For example, if my ebook reader has a function to select the font for the book I'm currently reading, but changing the selected font does nothing. that's a bug.

It may be standard practice to paint a bug as a feature by saying "I intended it to work that way", or to add a disclaimer that it only works correctly some of the time, but the reality is that it's still a bug.

geormes · 09-05-2011, 11:37 AM

Quote:

Originally Posted by robko

I really wonder if it wasn't just a tiny proportion of Kobo owners that were getting it.

I had this problem and it appeared in more than one manner. Once I got it by turning the Kobo on after an overnight charge. I had added some books the day before, but had started reading one and turned off and restarted several times during the day. Once it erased all books and added fonts like a reset would, but still asked for a reset.
I added an sd so I could keep the books I was reading on the device. Adding and subtracting books from the card by any method caused the reset screen.

There were too many different scenarios and ways to cause the reset screen for me to think it was just a "tiny proportion" of owners. Instead I suspect the tiny proportion were the owners that hadn't experience it YET.

So far, with the firmware upgrade, it is functioning as I had initially hoped it would.

I think this problem was just further evidence the Kobo was rushed out the door to meet a sales department deadline. Maybe to introduce around the same time as the new Nook? This is a common way of doing business. Engineering/Software put bandaides on a not ready for prime time product to meet an externally imposed deadline! Fortunately it seems to be maturing into an excellent product.(Knock on wood)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Firmware Update Instructions and the latest Firmware Versions	mitchwah	Ectaco jetBook	113	10-24-2023 09:02 PM
Desktop	Rick1971	Sony Reader	5	12-26-2010 02:59 PM
v1.0 firmware with v 1.7.5 desktop app problem	gehko	Kobo Reader	4	12-01-2010 05:07 PM
Show us your desktop	Moejoe	Lounge	153	06-13-2010 09:37 PM
GUI desktop emulates papers and books on physical desktop	Bob Russell	News	2	06-25-2006 07:42 PM

09-03-2011, 05:51 PM	#123
taming Trying for calm & polite Posts: 4,012 Karma: 9455193 Join Date: May 2010 Location: Mostly in Canada Device: kobo original, WiFI, Touch, Glo, and Aura	It has never happened to me with a Touch update. You should be good to go now!

09-04-2011, 08:17 PM	#126
readingglasses Zealot Posts: 124 Karma: 9252 Join Date: Jul 2011 Device: (prospective) kobo touch	Maybe if you assume that kobo doesn't really believe their method of font selection will make embedded fonts impossible, then you could say it is a bug. No doubt it's a "way of working" that should be changed as it trades in one problem for another. I wonder if the new sony prs t1, with user selectable fonts, will honor embedded fonts, at least optionally, AS WELL AS ANY SONY READER DOES NOW I don't know about the nook but display of embedded fonts in the sony is pretty limited too. So, they both suck, as far as this.

09-05-2011, 09:34 AM	#128
Pistos Connoisseur Posts: 95 Karma: 3198 Join Date: Jul 2011 Location: Canada Device: Kobo Touch	Indeed, I think some clarification is required here regarding the difference between (a) actually including the font data (which is what I think of when I hear "embedded font"), and (b) merely referring to the font name in CSS -- and which of these two are being referred to in any given post.

09-05-2011, 09:38 AM	#129
fbrII F. BluDevil Posts: 428 Karma: 1152548 Join Date: Dec 2008 Location: St. Louis Missouri Device: Pocketbook Inkpad3 pro, Kobo Libra, Kindle Paperwhite	I updated yesterday and no problems. I was once more going through the memory/factory reset error and I had chosen to ignore it. Now after the update the error message is gone. It's too bad it took as long as it did for Kobo to fix the problem because it really is a great device and I think their credibility went down a notch or two. However, with this update it looks like it's back to being a great device.

09-05-2011, 09:57 AM	#131
Pistos Connoisseur Posts: 95 Karma: 3198 Join Date: Jul 2011 Location: Canada Device: Kobo Touch	I am really quite curious about the specifics of the issue, but I guess it's wishful thinking to suppose they would divulge any details, as it could make their technical competence seem even worse. If it were possible in some (most?) cases to simply cancel and proceed, then it sounds to me like the conditions that bring up the screen were on the aggressive side -- that is, they designed it intending to err on the side of more false positives, thinking they would have fewer customer complaints because a reset would allow the device to recover and rebuild its database, etc. into a consistent, "within the boundaries" sort of state. If this line of thinking were the case (this is all just speculation on my part), it would seem their plans backfired on them, as users were more frustrated at being bothered by the screen so often (and the long reload times, in some users' cases). But who knows what problems merely cancelling the reset would have allowed to fester in the device's system files. Certainly, any good software should be able to gracefully handle malformed data. For all we know, though, the 1.9.10 update did nothing more than alter the reset screen's trigger conditions so that it wouldn't appear as much (or at all?), even though nothing was done to actually address any data handling problems. Perhaps just something to stop the PR bleeding, and bide the dev team time to actually fix things. But, again, just conjecture on my part.

Advert

Advert