LRF output

[pepak]

Originally Posted by llasram

Is the @font-face rule with a 'res://' src insufficient for you, or would you like to see specific support for that?

The problem is that I would have to include that with every book, which means extra 200+ KB which must be included in the file AND processed by the Reader. It has some legal ramifications, too - even if I could distribute the book itself (copyright expired, the author gave his permission, or whatever), the font may be a different issue - plus I don't like forcing my fonts on other users.

I can see how this might be an issue, as Adobe doesn't seem to cache any pagination information to help it jump into a flow more easily. I admit that I'm not sure what could be done here on Calibre's part.

AFAIK, nothing. That's why I would rather like to see a fix in LRF engine, which is something Calibre CAN do.

Originally Posted by kovidgoyal

The LRF converter has a separate parser from all the other conversion engines.

I assume that's because LRF support is the oldest and doesn't share the framework of all other engines.

Still, wouldn't it make sense to update the LRF engine to the current framework? I was under the impression that the converters are written in such a way as to make it quite easy to add new formats - is there anything that prevents LRF from being considered a new format? Other than the time you are willing to spend on such efforts, obviously. (I would be happy to write the converter myself, but unfortunately Python is completely unknown to me.)

[kovidgoyal]

Originally Posted by pepak

Still, wouldn't it make sense to update the LRF engine to the current framework? I was under the impression that the converters are written in such a way as to make it quite easy to add new formats - is there anything that prevents LRF from being considered a new format? Other than the time you are willing to spend on such efforts, obviously. (I would be happy to write the converter myself, but unfortunately Python is completely unknown to me.)

There's no fundamental reason the LRF engine can't be rewritten, I just prefer to spend my time on other things.

[gwynevans]

Originally Posted by llasram

OOC, what have you been "unimpressed with" about EPUB? Ok, fine, DE on the Reader as of this moment doesn't do fully-justified text. Is there absolutely anything else which is a problem?

The two problems I have with ePub support are that I've had my 505 reboot on me while reading twice, both times while reading an ePub conversion and the other problem is the time taken to display (calculate?) the TOC links.

Re the rebooting, the same books converted to LRF were fine.

[kiklop74]

That is actually quite the oposite from experience people usualy have with LRF files.

LRF files are better for reading since the fonts are nicer and it suporrts real justified text. But due to bug in reader's firmware it crashes the OS during indexing of large and complex books if you transfer them using file manager and not sony software.

Only because I was sick of those crashes and not wanting to use crappy sony software I switched to EPUB.

And apart from being a bit slow and not having propper rendering of justified text EPUB's are fine.

[bkilian]

Originally Posted by llasram

That's not really a format issue so much as an "implementation" issue -- the font Sony bundled just has more glyphs than the one Adobe bundled. Is the @font-face rule with a 'res://' src insufficient for you, or would you like to see specific support for that? Will embedding a font in each book still be not an answer once Calibre has support for it and can just embed your default font selections automatically?



I can see how this might be an issue, as Adobe doesn't seem to cache any pagination information to help it jump into a flow more easily. I admit that I'm not sure what could be done here on Calibre's part.



Well then lets make EPUB more usable :-). I'd much much much rather put time into EPUB usability improvements than fixes to the all-but-dead LRF generator.

-Marshall

I have nothing against the *format*. The implementation on the Sony is buggy and, in my case, almost unusable. I cannot read non-fully-justified texts, because it messes with my ADD and draws my eyes to the space gaps on the right. It essentially halves my reading speed, and bothers me no end. It's slow, it crashes my sony about three times more than normal, and the books are bigger, on average, which means I can fit less on the device.

Concerning the Calibre conversion, it leaves out a number of the functions I require, as far as I can tell, like --force-page-break-before-tag (which is _not_ the same as a chapter) and setting fonts at the command line (--serif-family).

All of this essentially means that, as of now, and until Sony fixes some things, ePub cannot stand in for LRF for me, and I suspect a number of folks using Calibre, especially the thousands that don't have a 505 or up.

[pepak]

I have just noticed that html2lrf doesn't support text-transform: uppercase but it does support text-transform: small-caps. Neither is particularly important for me, but I find it interesting that the more complex transformation works while less complex one does not.

[kovidgoyal]

Originally Posted by pepak

I have just noticed that html2lrf doesn't support text-transform: uppercase but it does support text-transform: small-caps. Neither is particularly important for me, but I find it interesting that the more complex transformation works while less complex one does not.

Somebody asked for small-caps back when I was actively developing html2lrf, no one asked for Uppercase

[bkilian]

Originally Posted by bkilian

I have nothing against the *format*. The implementation on the Sony is buggy and, in my case, almost unusable. I cannot read non-fully-justified texts, because it messes with my ADD and draws my eyes to the space gaps on the right. It essentially halves my reading speed, and bothers me no end. It's slow, it crashes my sony about three times more than normal, and the books are bigger, on average, which means I can fit less on the device.

Concerning the Calibre conversion, it leaves out a number of the functions I require, as far as I can tell, like --force-page-break-before-tag (which is _not_ the same as a chapter) and setting fonts at the command line (--serif-family).

All of this essentially means that, as of now, and until Sony fixes some things, ePub cannot stand in for LRF for me, and I suspect a number of folks using Calibre, especially the thousands that don't have a 505 or up.

Doh, I take it back, the ePubs are generally smaller. My other objections still stand though

[mmaimon]

can anyone help me with this error log file from Calibre"

Job: **Convert book: The Black Swan: The Impact of the Highly Improbable (Random House, 2007)**
**tuple**: ('ConversionError', u'Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)\r\n')
**Traceback**:
Traceback (most recent call last):
File "parallel.py", line 957, in worker
File "parallel.py", line 915, in work
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\any\c onvert_from.py", line 196, in main
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\any\c onvert_from.py", line 165, in process_file
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\pdf\c onvert_from.py", line 106, in process_file
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\pdf\c onvert_from.py", line 67, in generate_html
ConversionError: Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)


**Log**:
('ConversionError', u'Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)\r\n')
Traceback (most recent call last):
File "parallel.py", line 957, in worker
File "parallel.py", line 915, in work
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\any\c onvert_from.py", line 196, in main
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\any\c onvert_from.py", line 165, in process_file
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\pdf\c onvert_from.py", line 106, in process_file
File "C:\Program Files\calibre\library.zip\calibre\ebooks\lrf\pdf\c onvert_from.py", line 67, in generate_html
ConversionError: Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)

[kiklop74]

The error message is clear - pdf you want to convert is in version xpdf does not support.

Originally Posted by mmaimon

**tuple**: ('ConversionError', u'Error: PDF version 1.6 -- xpdf supports version 1.5 (continuing anyway)\r\n')

[JSWolf]

The thing is, by treating LRF as a second class format, a huge disservice is being done to all those people who have a 500 and not a 505 or 700. Do they not count? By not fixing the reported bugs in the LRF processing, they get screwed. My mother-in-law has a 500 and while I can generate ePub for my 505, I cannot do that for her 500. So is she not entitled to a working LRF parser? Is she not entitled to have the bugs fixed?

[pilotbob]

Originally Posted by JSWolf

So is she not entitled to a working LRF parser? Is she not entitled to have the bugs fixed?

Considering that this is an Open Source application NO ONE is "entitled" to anything.

Then again, since this is an Open Source application ANYONE is "enabled" to fix/add what they want and submit a patch to give back.

BOb

[Valloric]

Originally Posted by pilotbob

Considering that this is an Open Source application NO ONE is "entitled" to anything.

Then again, since this is an Open Source application ANYONE is "enabled" to fix/add what they want and submit a patch to give back.

Bob++

[old soldier]

I have a question about DRM. When I try to convert a PDF to LRF via Calibre, they tell me: this file is DRMed and cannot convert them! I get a primary TXT file from legal free library, convert them via Word and free doPDF program into PDF. In what stage of this conversion appeared this DRM? How I can remove or ignore them? May be exist another way to perform this conversion?

[gwynevans]

Originally Posted by old soldier

May be exist another way to perform this conversion?

A better way would be to not use PDF at all. If you want to use Word, then try saving as RTF (if you don't use images) or maybe HTML, and import them into Calibre. You could even just use the text file and markup the text via "Markdown" syntax, which Calibre will process.