LRF no longer "supported" by Calibre

[kjk]

Originally Posted by netseeker

I'm pretty sure that Pepak is aware of that (just search for his contributions regarding ePub in the forum), though does it really matter? Italics doesn't work on the PRS-505 out of the box, you have to embed fonts. How would an average reader do this with his DRMed eBooks?

What about the 300KB hurdle? What about full justification? What about oeb-page-head (and all other oeb-styles as well)? There are so many unimplemented details on the PRS-505...i just can't count all.

I agree. If the Sony ignores the valid ePub settings that Pepak wants and expects (given its an ePub), then he is perfectly right to say it doesn't handle ePub properly for him.

If your definition of "handles ePub properly" includes the disclaimer "except for justification and certain valid tags", well, ok. I'm guessing Pepak's criteria of what "handles ePub properly" means doesn't.

[pepak]

http://www.idpf.org/2007/ops/OPS_2.0...tml#Section3.1
"Reading Systems must support all CSS2 selectors."

It is true that the specification doesn't specify what "support" means - maybe that term really does include "crashing your device" :-)

Not that it matters. Fact is, LRF will not be supported by Kovid anymore. It doesn't matter whether there are or are not reasons for people to stick to LRF.

[theducks]

Originally Posted by kennyc

And so then you are saying the EPUB Spec requires this to be supported?

Then the spec is in error

How many fiction, dead tree books, chosen at random, do not use italics somewhere in their contents?
Normal, Bold and Italics have been the staple of word processing from the early times that computers first appeared in homes.
These strokes and weights were built into the first PCL based (Laser) printers.
My first printer (the Epson MX80) produced output that reproduced the effects (double-strike to get bold).
Logic suggest that the EPUB spec did not exclude something as basic as italic support.

[kennyc]

Originally Posted by theducks

Then the spec is in error

How many fiction, dead tree books, chosen at random, do not use italics somewhere in their contents?
Normal, Bold and Italics have been the staple of word processing from the early times that computers first appeared in homes.
These strokes and weights were built into the first PCL based (Laser) printers.
My first printer (the Epson MX80) produced output that reproduced the effects (double-strike to get bold).
Logic suggest that the EPUB spec did not exclude something as basic as italic support.

May be true, but that's not the point, The claim was made that the Sony Implementation violated the EPUB spec. I was asking for examples of that violation. Didn't get any yet that I can see.

[pepak]

Originally Posted by kennyc

May be true, but that's not the point, The claim was made that the Sony Implementation violated the EPUB spec. I was asking for examples of that violation. Didn't get any yet that I can see.

You may want to reread by last post.

[cmdahler]

Originally Posted by Valloric

In Calibre's defense, LRF output has been dropped from the Sigil roadmap, too. It's a dead format.

That's like saying Windows XP was dead when MS started selling Vista. ePub, espcially on the Sony 500-series, sucks dirt right now. Maybe in the future it won't, but for now, if you want something to look nice on the screen, LRF has ePub beat six ways from Sunday. LRF won't be "dead" no matter what Kovid and Sigil say, until all ePub catches up with it, and I don't see Sony in any hurry to update their crappy ePub renderer on the 500-series.

My thanks to Kovid for his hard work, but let's just say it's a disappointing decision to stop fixing bugs in the LRF conversion utility. I'm glad the functionality is still there - there will still be people who vastly prefer LRF over ePub for quite some time to come until Sony gets its thumb out and provides an update to make ePub look like something that wasn't typed up by a high school kid in an afternoon on Word.

[kiklop74]

Originally Posted by pepak

If you tried it before responding, you would know that this simple rule will make your Reader reboot. I am pretty certain that's not in the specifications.

I wrote around 30 recipes that use exact that rule and nothing crashes on Sony Reader (which I own). So I DID check it out before responding.

And it is in the specifications since it is an example of font-embedding. Font embedding is supported by epub standard.

[pepak]

Originally Posted by kiklop74

I wrote around 30 recipes that use exact that rule and nothing crashes on Sony Reader (which I own). So I DID check it out before responding.

And it is in the specifications since it is an example of font-embedding. Font embedding is supported by epub standard.

Where in my example do you see any font-embedding? I am not talking about font-embedding or even italics! I am talking about the fact that if you use a * selector (which MUST be supported as per the specs), the ADE will reboot your Reader.

[theducks]

Originally Posted by kiklop74

I wrote around 30 recipes that use exact that rule and nothing crashes on Sony Reader (which I own). So I DID check it out before responding.

And it is in the specifications since it is an example of font-embedding. Font embedding is supported by epub standard.

I think kennyc is nit picking here.
He is implying the nothing in the spec says that italic must be supported (rendered correctly?).

Note[11] Reading Systems need not distinguish italic and oblique from each other.

A crash from any legal css is implicitly a violation of the spec

[kennyc]

Originally Posted by theducks

I think kennyc is nit picking here.
He is implying the nothing in the spec says that italic must be supported (rendered correctly?).

Right. I have no special understanding of the epub spec, but the claim was that the Sony implementation violated it. I asked for specifics of that violation, not what someone thinks it should or shouldn't do, but whether it actually violated something in the specification.

[kiklop74]

Hm, ok than I misunderstood your complaint. My css rule uses explicit tag and that does work while you applied generic selector. OK, fine. ADE is buggy on Sony. We all know that. What I sent you was just a workaround for the italic issue.

Anyways you and me have the same device. I stopped using LRF because that format crashed my reader so many times due to a preindex bug in firmware. And I am not able to use sony sofware for preindexing as it does not work on my vista machine. So I switched to calibre&epub and learned to live with it's limitations.

It does not help at all to nitpick about epub related issues because Sony will not issue firmware update for older devices since they want all of us to buy the new ones. You have the device such as it is so you need to find a way to use in spite of all the present limitations. If you are happy with LRF, ok fine. No problem with that.

[netseeker]

Originally Posted by kennyc

Didn't get any yet that I can see.

Look at the examples in my last post. According to the specification a reading system must support the oeb-styles as well as text-align: justify. The sony does not. It's violating the specification (as well as all reading systems using Adobes Mobile Reader SDK).

A conforming Reading System must render all OPS CSS 2.0 required subset properties.

List of properties: http://www.openebook.org/2007/ops/OP...tml#Section3.3

[JSWolf]

ADE on the 505 supports italics the same way that ADE for Windows does by simulating italics.

[JSWolf]

Originally Posted by pepak

My assessment was that PRS-505 EPUB rendering is unsatisfactory for my needs. I take it you disagree, that is, PRS-505 EPUB rendering is well suited to my needs.


If you like... Add this CSS specification to your book and see what happens:

* { font-style: italic; }

I just added that to an ePub and there was no embedded fonts being used. And guess what, it worked perfectly on the 505. The italics were simulated. But no reboot. So what doesn't work that really doesn't work?

[DrMoze]

Originally Posted by cmdahler

My thanks to Kovid for his hard work, but let's just say it's a disappointing decision to stop fixing bugs in the LRF conversion utility. I'm glad the functionality is still there - there will still be people who vastly prefer LRF over ePub for quite some time to come until Sony gets its thumb out and provides an update to make ePub look like something that wasn't typed up by a high school kid in an afternoon on Word.

Amen to this. I confess I haven't read this entire thread (which seems to have taken off a bit). The quote above is what I was getting at when I started this thread. Well said, cm.

[Update: caught up on things here a bit]

And to the chastising I got for posting a 'mad' smiley in the original post: I'm sorry but I couldn't find a 'disappointed' smiley here. And I purposely directed my sarcastic 'thanks' at Calibre, and not Kovid personally. I do appreciate the huge amount of underrewarded effort he has put into this whole project. I guess that subtlety/message was lost on many.

In plain English, I am disappointed (I'm not posting in ePub, am I?) about lack of future support for lrf bugs in Calibre. (I doubt there are many left--lrf is where it started,isn't it?) I refuse to upgrade my 500, because the upgrade is reported to kill the battery life (still 2+ weeks). I still have lots of lrf files that work fine on all 3 Readers, and display nice justified text. I will continue to convert to lrf because ePub does not display justified text on the Readers (and won't work at all on the 500). Apparently there are a few more subtle text style and header problems with ePub on Readers too. And yes, I know I can convert these ebooks to another format someday, if I want to. (FYI, I'm still running XP on my home computers. I may consider Win7 someday, but XP didn't 'die' when Vista came out and I am glad I never switched to it!)

For those who suggest I fix the bugs myself--I'm not a coder. These days, converting ebook files with various utilities and figuring out end-user-level problems on my commercial business software is all I can deal with these days. (I started out programming Basic and Fortran--Watfor and Watfiv--on punchcards in the 70's, but have evolved into an end-user over the years in response to my particular needs and interests. Sorry.) The suggestion of airing some bugs and hoping that someone else may be motivated to fix them is a good one. Didn't I kinda do that with this thread?