Technically, the LRF format does support borders, but html2lrf doesn't translate this. For that kind of advanced formatting, it should be easier to switch to EPUB anyway.

I'm happy to announce html2lrf, an open source, cross-platform HTML to LRF converter that I believe is the most feature-complete converter available. It's distributed as part of libprs500 and will eventually be integrated into its GUI. I've attached an LRF file to show off some of its capabilities.

It has support for CSS, recursive links, inline images, lists, tables, dropcaps and embedded fonts.

If you have an HTML file it chokes on, I want to know about it!

For all you content creators, this presents an alternative content creation path. Just open the source file in you favorite office suite, save it as HTML and run it through html2lrf.

Get it and the rest of libprs500 from https://libprs500.kovidgoyal.net. After installation a command html2lrf will be available. It's self documenting, i.e. just run it to get a list of options. Basic usage is as simple as

html2lrf myfile.html


I should thank Falstaff for pylrs and esperanc for the initial CSS conversion code.



Hi

I just want in brief how to use the above given source code in linux.
And is there any c++ source code which can convert html files into lrf file format.

Regards
Krish

I have spent a fair bit of time playing with the TOC detect features in Calibre and the only thing that seems to work is importing from .prc file which has a TOC already. Importing .LIT does not see the TOC even if the file has one. The auto chapter detect does not work at all in LRF conversion - but I did make it work once converting to EPUB. The conversions were done using test files so I could control the tag name and attribute in the input doc. I have tried HTML, RTF and plain text - no luck with any of them.

TOC detection doesn't create a toc int the file itself. It creates an external toc. You can access the external toc from the menu on the sony reader.

I'm happy to announce html2lrf, an open source, cross-platform HTML to LRF converter that I believe is the most feature-complete converter available. It's distributed as part of libprs500 and will eventually be integrated into its GUI. I've attached an LRF file to show off some of its capabilities.

It has support for CSS, recursive links, inline images, lists, tables, dropcaps and embedded fonts.

If you have an HTML file it chokes on, I want to know about it!

For all you content creators, this presents an alternative content creation path. Just open the source file in you favorite office suite, save it as HTML and run it through html2lrf.

Get it and the rest of libprs500 from https://libprs500.kovidgoyal.net. After installation a command html2lrf will be available. It's self documenting, i.e. just run it to get a list of options. Basic usage is as simple as

html2lrf myfile.html


I should thank Falstaff for pylrs and esperanc for the initial CSS conversion code.


:chinscratch:Is there any way to create epub to pdf...:blink:

feat request concearning downloading feeds and converting them to lrf.
Everytime I download a feed and get it converted to lrf, I get in my newsfeeds the message: "Please turn on JavaScript. Media requires Javascript to play."

I wanted to know if it was possible to remove such a line before converting it to lrf.
It's only obvious lrf does not support javascript, and neither does the reader's screen.
Also since Calibre currently is made to fit the sony Reader, and no other mobile devices, I think it's a good idea to remove this 'javascript' line from the html.

So far I haven't seen any CNN newsfeeds with pictures.
If a version uses javascript to display a picture, then it'd be nice to get to convert the first picture to a jpg.
If it uses javascript to display a movie above the article, then it'd be nice to either see the first frame, or nothing at all(kind of like they use in an article with an integrated youtube video, or just remove the line, since it does not benefit the reader).

Removing the sentence should not be that hard (like when the html is retrieved, set a parameter like "javascript = 'Please turn on JavaScript. Media re...etc...' ". then insert some command like "if sentence "javascript" has been found, then delete it."

after it's deleted you can convert the remaining html to lrf.

I mean I hope you get the general idea...

which feed gives you this message?

I'm sorry, not CNN, but BBC news has the lines.

I don't know if it's happening to someone else too, but occasionally I get a reader reboot when opening one rss feed after another (eg like I did now, opening Daily Telegraph after BBC.
It reboots when formatting the book.
I don't know if it has anything to do with badly downloaded books, since I'm on a wifi connection and occasionally this connection has hiccups.

Just noticed that epub2lrf is ignoring the epub's page breaks and reprocessing the html for breaks.

I had used CSS in the original html to give 'H[1234]' tags a 'page-break-before: always' style. This made a nice epub appropriately split at each header, but when I used epub2lrf on that epub the resulting lrf only had page breaks on the headers that contained the magic word "book". I can force epub2lrf to split at all headers with the --force-page-break-before-tag="h[1234]" option, but I'm thinking epub2lrf should take it's splitting cues from the epub layout.

I have also used <br style="page-break-before: always;" /> tags in the original html to force page breaks in some unheadered spots. These work fine for producing the desired break in the epub, but the break is lost when converting that epub to lrf. Same issue really.

I can still use the original htmls to produce lrfs with the correct page-breaks, but I was hoping to ditch the original htmls and just keep the epubs around as my final source....that's the plan anyway.

Maybe epub2lrf could have a flag that ignores all chapter detection and just splits where the epub splits?

Cheers,
Lee

The problem isn't that html2lrf is ignoring the page breaks, it's that it cant parse advanced css selectors. So if you used

h1 {page-break...}
h2 {page-break...}
h3 {page-break...}
etc

it would still work

I think I worded it wrong.

My html files css had:
h1, h2, h3, h4 { page-break-before: always; }

From that html I can create an lrf and an epub with correct page-breaks.

But, if I run epub2lrf on that epub, which itself has correct page-breaks, the resulting lrf will have incorrect page-breaks (only breaks when it finds the "chapter detection words" in the headers).

I'll attach example files.
The lrf was generated from the epub. The epub breaks at each chapter, but the lrf only breaks on chapter headers that contain "book".

21290

21291

Looks like a bug, opena ticket and attach the files so I dont forget to address it

Looks like a bug, opena ticket and attach the files so I dont forget to address it

Umm.. sorry about this, not a bug, I just didn't quite get it and made a mess of things.

I didn't disable automatic chapter detection.
There were headers that had the keyword "book" in them so auto chapter detection was triggered and non-keyword headers were treated as non-chapters. Makes perfect sense.

I've got it working fine now.
Cheers.

Scratch that, doesn't work.
Filed a ticket with html, epub, and lrf files that show the problem.
Looks like the class="chapter", and style="page-break-before: always;" tag attributes are being honored when creating the epub, but are stripped from the epub's html. Thus, when I go to make the lrf from the epub I don't get the page-breaks.

is there any the best possible way to convert pdf into mobipocket files (.prc)...exact as same as the pdf...:)

is there any the best possible way to convert pdf into mobipocket files (.prc)...exact as same as the pdf...:)

sure, make a picture of each page and include it in a prc file. Otherwise there is no way to make any other ebook reading format exactly like PDF. I am not sure why you would want to make a 6" display look exactly like a 14" (A4) size display, but to each his own.

Dale

Well,I don't know about Mobi,
But on the Sony reader LRF, one could copy the text,and save the pictures inside a PDF, and then in book designer re-create your version of the book.
Like mentioned above, identical copying is impossible,especially when you're dealing with a large papersize. the 6" screen of the reader is too small to comfortably read a4 or larger pages.

I don't know if there's a program to create mobi, but I do know,that one is able to create a HTML file of the book, and convert that to mobi.

Again,to have it identically looking the same I don't think will be possible (when you use text based methode). But looking like,yes...

Or like above mentioned, take a snapshot of every page, and view the book as pictures.

why do you want it to be same as pdf?

Open up Archive. Choose add book from menu and select file ns1.htm. Importer runs for a while. Run it through the converter to LRF. That runs for a while. As far as I can tell the files are encoded in 7bit ASCII which I am presuming is fairly standard for the older web page :)

Then try to display it with the built in viewer and get the following message.

UnicodeDecodeError: 'utf16' codec can't decode bytes in position 416-417: illegal UTF-16 surrogate
Failed to render document
Detailed traceback:
Traceback (most recent call last):
File "build/bdist.linux-i686/egg/calibre/gui2/lrf_renderer/main.py", line 33, in run
File "build/bdist.linux-i686/egg/calibre/ebooks/lrf/lrfparser.py", line 28, in parse
File "build/bdist.linux-i686/egg/calibre/ebooks/lrf/lrfparser.py", line 56, in _parse_objects
File "build/bdist.linux-i686/egg/calibre/ebooks/lrf/objects.py", line 840, in initialize
File "build/bdist.linux-i686/egg/calibre/ebooks/lrf/objects.py", line 701, in add_text
File "/usr/lib/python2.5/encodings/utf_16_le.py", line 16, in decode
return codecs.utf_16_le_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode bytes in position 416-417: illegal UTF-16 surrogate

Works fine with mobipocket creator but I am hoping the html2lrf will give me a better page layout. Everything seems squashed with mobipocket.

Am running Calibre on Ubuntu linux.

Thanks for any help.

Hello,

I have some issues with html converted to lrf : even if I don't check the option box, I always have blank lines between paragraph, even if they are none in the original html file (generated with MS Word).
Only when I replaced the "paragraph mark" (^p) by the "end line" (^l) mark did the blank lines disappear, but then I don't have the indent for the following paragraph.

When converting the same html file to epub, no problem... but when I'm converting the epub to lrf, the blank line between paragraph reapper.

Is it a bug, or am I missing something ?

Thanks.

Post an extract from the HTML file showing a couple of paragraphs.

Works fine from command line for some reason.

Works fine from command line for some reason.

The conversion or the viewer?

here's the extract, thanks !

The conversion or the viewer?

Um both. I convert from the command line:

html2ltf --link-levels=2 -t blah -a blahblah ns1.htm

It runs for a few seconds. Then using lrfviewer shows up fine. Not perfect but good enough for me :)

If I do not set the link level the conversion takes a long long time. It seems to endlessly loop round and round.

Not sure what the default settings are when I use the gui but plainly something is not working happily.

Thanks for the program it has inspired me to go out and actually buy a Sony Reader. Well not just now but when I have flogged a bunch of stuff on eBay :)

here's the extract, thanks !

I looked at the code and this is where I think your blank line is coming from.

<p class=MsoNormal><span lang=EN-GB style='mso-ansi-language:EN-GB'><o:p>&nbsp;</o:p></span></p> It's between each of your paragraphs. For some reason MS Word like to add code to every space. I use Word 97 to convert my stories to html because it doesn't add that piece of code between my paragraphs.

here's the extract, thanks !

Works for me, see attached file

Um both. I convert from the command line:

html2ltf --link-levels=2 -t blah -a blahblah ns1.htm

It runs for a few seconds. Then using lrfviewer shows up fine. Not perfect but good enough for me :)

If I do not set the link level the conversion takes a long long time. It seems to endlessly loop round and round.

Not sure what the default settings are when I use the gui but plainly something is not working happily.

Thanks for the program it has inspired me to go out and actually buy a Sony Reader. Well not just now but when I have flogged a bunch of stuff on eBay :)

Look at the encoding setting in the GUI for that book.

I looked at the code and this is where I think your blank line is coming from.

<p class=MsoNormal><span lang=EN-GB style='mso-ansi-language:EN-GB'><o:p>&nbsp;</o:p></span></p> It's between each of your paragraphs. For some reason MS Word like to add code to every space. I use Word 97 to convert my stories to html because it doesn't add that piece of code between my paragraphs.

Thanks, I tried to "save as filtered html" with Word (instead of save as html) :
it says that the "MS Office" tags will be removed, and now it's work. So I guess this is the way to prevent Word to add code everywhere...

I'm really glad it works this way, because if I understood correctly, generating html files with Word and then converting to lrf (or epub) is the easiest and best way for newbie to obtain a proper layout..

Don't know why Kovidgoyal didn't have any problem with my extract though.

it also shows of bad text conversion.
In word you should not let every sentence end with ^l or ^p.

In order to understand the exact structure of books you're better off learning html code.
^l = <br>, and ^p=<p>
it's not that hard.
If you want your text to look a certain way, creating it in HTML is probably the best thing you can do.

Book designer and the Sony reader, I think support html0.
That's very easy, there are only about 15 commands to learn to create a book!
The easiest thing you can do is create it in word, save it to html, and prune the text for html command strings that are not necessary.

Those are known-but-annoying issues with calibre’s ad-hoc CSS parsing and rendering. With the Reader getting EPUB support LRF formatting issues are downgraded a bit, but that one bugs me too and if you open a ticket I’ll see if I can’t at least improve the situation.
I've put in a ticket for the <blockquote> issue in LRF generation.

Ticket #1839 (new defect)

I hope this can be fixed.

I guess i've found one or two issues in Calibres LRF-Output:


Instructions for spacing between paragraphs get ignored, e.g.
p { margin-bottom:8pt; }
Calibre adds far too much space above headlines

Both issues don't occur when converting to ePub or to mobi.

I did attach an excerpt of a html-file as well as the lrf-result of the conversation which shows both issues.

Does sombody know a simple workaround for the two problems? Should i open a ticket?

The LRF Output code is pretty much in maintenance mode where I wont fox anything other than critical bugs. This is because LRF as a format is neccesary only on the PRS 500. So you can open a ticket, but it's not likely that it will be looked at anytime soon.

Any word on how the blockquote fix is coming along?

Any word on how the blockquote fix is coming along?

That's llasram's baby

The LRF Output code is pretty much in maintenance mode where I wont fox anything other than critical bugs. This is because LRF as a format is neccesary only on the PRS 500.
Ok. Seems as it's time for me to switch to ePub. First i didn't like ePub but now i can't even remember why. :headscratch:


So you can open a ticket, but it's not likely that it will be looked at anytime soon.
Tickets #1881 and #1882 opened.
(Because according to the "Which E-book device do you have?"-Poll there are still enough PRS-500 users around)

I guess i can find a workaround for the pragraph spacing issue meanwhile (like inserting a paragraph with a very small line height between the "real" paragraphs or something like that)...

Any word on how the blockquote fix is coming along?

My offer to look at that was from waaay long ago. At this point to be honest I mostly just want LRF to go away. I'll check tomorrow if there might be a quick fix, but if not then I'm afraid you're on your own.

My offer to look at that was from waaay long ago. At this point to be honest I mostly just want LRF to go away. I'll check tomorrow if there might be a quick fix, but if not then I'm afraid you're on your own.
Thing is, what about all the 500 owners who probably would like this fix? They don't have ePub. They have LRF. And the problem with ePub is the really annoying page numbers on the side that overwrite the text. And I've found that buy trying to set a good base font size using ePub's settings, the headers get to be way too huge. So overall, ePub needs work.

The LRF Output code is pretty much in maintenance mode where I wont fox anything other than critical bugs. This is because LRF as a format is neccesary only on the PRS 500. So you can open a ticket, but it's not likely that it will be looked at anytime soon.Aah, but so far I have been singularly unimpressed with the ePub format on the Sony. It was designed for LRF, and works extremely well with LRF. Why make LRF a second class citizen because of nominal support of another standard? I mean, it supports PDF and RTF too, so why not just standardize on RTF, the ebook supports it fine...

Because EPUB is a techincally superior standard that is much easier to code for and has support for advanced features that will be useful in the future.

Aah, but so far I have been singularly unimpressed with the ePub format on the Sony.

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?

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?
Several things, actually.

Aside from the stability, which seems to be a lot better with LRF (on my books, anyway), there's also international font support (embedded fonts are NOT an answer if I have to embed them into every single book separately) and the speed of intra-document links.

I do not deny that EPUB is a better format and these issues will likely be fixed in the future, but as it is now, LRF is still the more usable of the two.

Oh, and one other reason: The bugs I notice with LRF support are not really LRF-specific bugs. They are general parser bugs that will appear in every format that performs conversions, and need to be fixed for that reason alone.

Several things, actually.

Aside from the stability, which seems to be a lot better with LRF (on my books, anyway), there's also international font support (embedded fonts are NOT an answer if I have to embed them into every single book separately)

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?

and the speed of intra-document links.

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.

I do not deny that EPUB is a better format and these issues will likely be fixed in the future, but as it is now, LRF is still the more usable of the two.

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

Oh, and one other reason: The bugs I notice with LRF support are not really LRF-specific bugs. They are general parser bugs that will appear in every format that performs conversions, and need to be fixed for that reason alone.

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

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.

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.)

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.

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.

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.

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.

-MarshallI 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.

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.

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 :)

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 :)

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)

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


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

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?

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

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++

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?

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" (http://daringfireball.net/projects/markdown/basics) syntax, which Calibre will process.

I don't like Word too much, but I just have a lot of books in PDF format. Now I'm clear, that was a mistake, but I do it in the early steps in my relationship with E-books, and at that time I knew nothing about Calibre. My Reader knew nothing about Cyrillic till now, so that I can't read TXT files in any coding. Some days, a lot of megabytes internet traffic. Help me to resolve this problem, if possible. If not, I understand, of course, that PRS-505 permit the handling and reading PDF, but too slow and without important features.

Kovid! Your program, in my poor opinion, more useful, intuitive and bug free software. I have a big pleasure to work with it, when I became clear in their features due to this kind of forum. Last evening I has resolved some of my problems with PRS 505. I bring you a big pardon, but I haven't any posibilities to donate your work. Many thanks. Best regards.

Glad you like it :)

I don't like Word too much, but I just have a lot of books in PDF format.

No worries - I've not come across the DRM issue, so can't directly help, but the best way I've currently found to convert PDF to Sony is to use Mobipocket Reader to create a PRC file (which is just a drop & click operation), then drop that file into Calibre & use Calibre to convert it to LRF or EPUB, so maybe give that a go?

Thank you for your suggestion. I'll try to perform it, not now due to I'm at work today. I hope, this is usefull way. I guess too, that it possible use some converter (without DRM monitoring) between PDF and Calibre conversion. Please, understand me - I'm not a pirate, I'm only want to read on my Sony reader e-books, that have got from legal sources in cyrillic, with minimum dificultes. Cyrillic coding is not native for E-book Library from Sony and a lot of another software, including honoureable Calibre. Due to this fact *TXT files was fully unreadable, in any possible coding, in my PRS 505, no matter I convert them in Calibre or Sony software, or without coversion at all. Unfortunately, I don't knew English so well to reading art literature; technical issues only.

[QUOTE=gwynevans;418145]No worries - I've not come across the DRM issue, so can't directly help, but the best way I've currently found to convert PDF to Sony is to use Mobipocket ReaderQUOTE]

Many thanks. I have resolved this problem with DRM in PDF files, that appear from nowhere during conversion legal *TXT into LRF.
My way: open TXT from OpenOffice Writer(3.0), save TXT as PDF, and than convert and send to PRS 505 via Calibre, and whatever messages about DRM not appeared! Text on reader in LRF became more readable than in PDF format (aligned to page width, more quikly handling with reader, etc.).
It may be effective for cyrillic languages users, possible for others.
I have a some doubt, what can I doing with existing PDF in my library, may be another way I found.

I have a some doubt, what can I doing with existing PDF in my library, may be another way I found.

For existing PDF, try
PDF -> MobiPocket Creator -> PRC -> Calibre

For TXT, better than going via PDF, try
a) TXT -> TXT with Markdown syntax (http://daringfireball.net/projects/markdown/basics) -> Calibre
b) TXT -> HTML -> Calibre
c) TXT -> RTF -> Calibre

[edit]Corrected "MobiPocket Reader" to "MobiPocket Creator"

For PDF...

PDF > Recycle Bin > empty Recycle Bin

For PDF...

PDF > Recycle Bin > empty Recycle Bin

Very helpful Jon. :(

BOb

[QUOTE=gwynevans;419076]For existing PDF, try
PDF -> MobiPocket Creator -> PRC -> Calibre

For TXT, better than going via PDF, try
a) TXT -> TXT with Markdown syntax (http://daringfireball.net/projects/markdown/basics) -> Calibre

Many thanks for your attention and understanding for me, for old wild soldier!
I have downloaded, unzipped and read "Readme Me" file from "Markdown syntax". What I could understand, this software required for this work on my PC some additional soft. I has listen somethig about Perl, but I'm not a programmer, I'm only DSNG engineer. Due to this circumstances, it's too difficult for me, install third party, never before used me software, and integrate to this Markdown. I'm so sorry. :(

P.S. What about PDF - (PDF<Recycle bin<empty Recycle bin) - absolutely right action! Fully agree.

this software required for this work on my PC some additional soft.

No, the needed software is already part of Calibre! Try adding the TXT below to Calibre, converting then seeing the output (should be as the LRF below)

No, the needed software is already part of Calibre! Try adding the TXT below to Calibre, converting then seeing the output (should be as the LRF below)

Wondering! I have performed recommended actions - download and converting both files. But I couldn't understand (exuse me), how I can integrate downloaded "Markdown*PL" file into Calibre, or they can work separately, as standalone program, and I can process the TXT files before this conversion in Calibre?

Calibre assumes that any TXT files it is given is in Markdown syntax and knows how to process it without anything more needing to be done. With the uploads, the LRF file was created by loading the TXT file into Calibre & converting it to LRF.

The thought was that your input text files might be easy to have added the markdown syntax, using a text editor, which would then load directly into calibre & when converted, give books with chapters, etc.

The thought was that your input text files might be easy to have added the markdown syntax, using a text editor, which would then load directly into calibre & when converted, give books with chapters, etc.

Excuse me twice, no - a lot of times! Please explain to me, respected Gwynevans, how Markdown syntax worked: I have to leave them in folder in which dowloaded and unzipped, or copy them into some appointed directory in PC? What a text editor I have to use? :thanks:

Respected gwynevans! I have got TXT file from library, then load them into Calibre, convert it in LRF and upload in device. Coding of this e-book is true, text fully readable (in this fact I must bring my great respect to Kovid - Sony E-book library couldn't do it with cyrillic texts correctly), but there are no chapters, pages numbers - nothing more than text. What I doing wrong? Or in plain TXT no chapters, pages and nothing else?

Before loading into Calibre, put "///Table of Contents///" near the start of the text and "## " at the start of the line before each Chapter heading, e.g.


///Table of Contents///

## Chapter 1
text
...

## Chapter 2
text
...


then see what the book looks like on the reader after conversion

Dear gwynevans! I'm grateful for your time, that you spending for me. I have got a lot of important information not only about Sony reader, but about much more useful things. Now I can help for many other Sony reader owners, that expierenced the same difficulties with their devices, but couldn't get a help from our community due to they didn't knew English sufficiently. I admire from Kovid, who developed Calibre. Thank you very much, friends!

I used Calibre to convert a pdf book, the outcome was a pure text, although the font size was reasonable and comfort to read on my prs-505 ebook reader, the whole graphics of the book seemed to have lost completely.

I just wanted to know if this what the outcome should be? or is there a way to use Calibre and still keep some of the appearance of the book right?

I just wanted to know if this what the outcome should be? or is there a way to use Calibre and still keep some of the appearance of the book right?

Not with PDF. Try to convert it to LIT first and/or use Bookdesigner.

I've been trying to create an ebook using the demo files for creating books with html2lrf that Kovid attached to the first post of this thread.

My book consists of 11 short stories and I'd prefer if I could handle them seperately instead of having everything in one big file. As far as I understand it's possible to link to files you want included, but apparently I don't know how to do it.

I have a "master" html file with cover and table of contents etc. and then I assume I should put in the links to the short stories that are each an html file. And I assume I should put all files in a zip file before adding it to calibre for conversion.

I guess I don't know what markup to use for linking to the story files. A tried <a href=" ... and <link href="... - not sure if either of those is correct. In both cases I tried linking to three files, but the book that was created only contained the last file and no table of contents. Incidentally, the name of that file is also the last alphabetically, which leads me to suspect it's not working and calibre is simply just converting the last file in the zip archive.

Does all this make sense? I can attach sample file if needed.

Normally you would only add the master HTML file (the one containing the cover image and table of contents). Calibre will create the required ZIP file pulling in all the files referenced by links in the master one.

Okay, thanks. But it doesn't seem to make any difference. I've one some more testing, it looks like calibre is creating a book from the last file in the list of links. No table of contents or the other files (it's short stories). For example in this list, the book will be created with the last file, in this case "Stuck on you"

<a href="the_allure_of_la.html" />
<a href="the_ghosts_of_christmas_crack.html" />
<a href="stuck_on_you.html" />

That does not look like valid HTML to me!

I would expect the links to be of the form

<a href="the_allure_of_la.html">The Allure of La</a>

as the <a> tag is meant to enclose something that can be clicked on.

You should load the first page into the browser and check it behaves like you want it to.

No, you are right, it's not valid. Well, I changed it, and converted again. Now the first file in the list was converted, but still no table of contents or other files. I'm working from the demo file, so I assume it is okay for conversion, and my master file looks like this:

<html>
<head>
<style type='text/css'>
.toc { page-break-after: always; text-indent: 0em; }
.tocpn {text-align: right; }
.tocchr {text-align: right;}
.hanging_indent { padding-left:4em; text-indent:-4em }
.drop { text-indent: 0pt}
.drop:first-letter { font-size:xx-large}
.h2 { page-break-before: always; text-indent: 0em;}
</style>
</head>
<body>
<h1>Book title</h1>
<p>Blurb text</p>

<h2 id="toc">Table of Contents</h2>
<ul style='page-break-after:always'>
<li><a href="#every_year_again_its_christmas">Every Year Again it's Christmas</a><br /> &mdash;For Silverchipmunk</li>
<li><a href="#now_and_then">Now and Then</a><br /> &mdash;For Laura McEwan</li>
<li><a href="#the_other_side_of_the_window">The Other Side of the Window</a><br /> &mdash;For Ancasta</li>
</ul>


<a href="every_year_again_its_christmas.html">story one</a>
<a href="now_and_then.html">story 2</a>
<a href="the_other_side_of_the_window.html">story 3</a>

</body>
</html>

I don't know if I am adding the links to the files correctly, but I assume if I want a table of contents that link to the story headers, I would need to do it this way?

How exactly are you converting?

I'm creating the html file(s). Then importing them into calibre and converting via the GUI.

Edit: if I put everything into one big file it works as intended - which is why I'm assuming the problem lies in linking to the individual story files...

You HTML file should all be in one folder and the HTML file you import into calibre should be the one that links to all others. Also when you import it, does calibre create a ZIP file?

I keep all the files in one folder (there's more files in that folder, but I don't know if that's a problem?). Calibre creates a zip file when I import.

I've just checked: I saved the files in calibre to disk after importing the 'master' file, and got a zip archive with these files - see attached screen shot.

It's the 'master' file and the files it links to, And they look okay in a text editor. Also tried one more time to convert to lrf and send the lrf to device, just in case. Still only the first story in the list of three (
<a href="every_year_again_its_christmas.html">story one</a>) and no toc.

open a ticket and attach the zip file

The HTML is still not valid!

It should be something like:
<li><a href="#now_and_then">Now and Then</a><br /> &mdash;For Laura McEwan</li>
<li><a href="#the_other_side_of_the_window">The Other Side of the Window</a><br /> &mdash;For Ancasta</li>
</ul>

<a name="the_other_side_of_the_window />
<a href="every_year_again_its_christmas.html">story one</a>
<a name="the_other_side_of_the_window.html" />
<a href="the_other_side_of_the_window.html">story 3</a>

The point is that the href="#xxx" type syntax needs a named point in the same file to jump to - it cannot be a reference to an external link.

Whether this would fix your problem I do not know.

I'm having this very problem, only it's with the books of the Bible. I have each book in a separate HTML file, with a TOC file, and I only get Genesis. When I had each chapter of each book in a separate HTML file, I would only get Genesis chapter 1. I just opened a separate topic, and then I found this portion of the LRF output thread. oops.

Maybe this'll help. I just tried to convert the HTML Bible to ePub, and it worked. Then I converted the ePub to LRF, and that worked as well. I did it on a subset of 3 books to make it quick. Now to do it for the full Bible.

red_five--

Just wanted to let you know (in case you don't know already) that the King James version of the bible is available for download from this site in both ePub and LRF formats. Both are very nicely formatted IMO.

dordale :)

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

Actually it's more like because it's gratis Software.

There is also commercial (non gratis) OpenSource (parts of Mac OS X as a well known example) and customers who spend hard earned €$¥£ on commercial OpenSource are just ans entitled to service as those who spend there money on closed source software.

Actually I sell open source software (http://fx-602p.krischik.com/index.php) myself and my customers can expect service and bug fixes.

Martin

When converting from ePub font-variant: small-caps; is not preserved. Any other way to have small caps in LRF? I'm pretty sure it supports them, since Sony books have them.

The HTML code to do that is demonstrated in

http://calibre.kovidgoyal.net/downloads/html-demo.zip

Looked at your sample. So why doesn't font-variant: small-caps work for me with latest calibre?

My machine will not let me on your site as it says that your certificate is self-signed - any ideas how to get round this (alt sites etc)

My machine will not let me on your site as it says that your certificate is self-signed - any ideas how to get round this (alt sites etc)

Can't you ignore that warning in a browser? If for some reason you can't (like blocked by admin at work), try another computer and browser.

I have just "upgraded" Calibre to 0.6.1.6. The whole book is now in Times Roman italic except where <strong> has been used which is now Times Roman (upright) It has also ignored Trebruchet font. Version 0.5. whatever worked perfectly well. All font calls are via css file.
I upgraded because I had a number of "lost lines" at the end of para's which I hoped would be cured.

Hi.

First of all - THANKS for a great product. It's usefull once you'll reach a certain limit of books to manage them all both on your PC as well as in your reader.

:thanks:

Now to my problem I have - I've used calibre (0.6.17 but upgraded today to 06.18) to test 20 News Feeds over 3 days (in total 59 news, 1 was just for 2 days) with a bit mixed up results for me newly aquired PRS-505.

Calibre is all set to defaults with output to Sony Reader (LRF) and it's mamanging my collections just fine. However - 9 of 20 News feeds fail to open on my reader and always cause it to reboot - I've tried putting them to internal memorry as well as to both cards (MS & SD) with the same result. They'll indeed open fine within the Calibre itself. My Reader is customized with PRS Customizer 1.04 (UK Version) with custom Fonts, Icons, Languages, Logo, to display time, Personal details and to shutdown via Enter button but I don't think this is causing the problems as hundreds of other and much larger (in file size) books works just fine.

See bellow a full list of all 20 feeds together with file size and page count and indications which are failing. They're all from October 18 (automatic batch at midnight). In general - LARGER (in file size) News books tend to fail with only exception of Telegraph.co.uk (4.9 MB) wich seems to work just fine despite it's larger file size. All the Fetch News Recepies were used as supplied by default.


NAME - File size in MB - Pages - Working Yes / No
***************************************
CNN - 1.8 - 430 - NO
darknet - 0.1 - 38 - Yes
Fudzilla - 0.9 - 378 - NO
Glasgow Herald - 0.0 (it fails to actually READ the feed) - 6 - Yes (It's empty though)
London Review of Books - 0.2 - 166 - Yes
NASA - 0.3 - 272 - Yes
New Scientist - 1.3 - 701 - NO
Newsweek - 0.5 - 149 - Yes
ScienceDaily - 0.3 - 208 - Yes
securitywatch - 0.1 - 40 - Yes
Slashdot.org - 7.5 - 3,672 - NO
Telegraph.co.uk - 4.9 - 744 - Yes
The BBC - 8.9 - 2,285 - NO
The Daily Mail - 13.6 - 1,539 - NO
The Guardian - 2.9 - 494 - NO
The Scotsman - 0.5 - 379 - Yes
USA Today - 1.1 - 521 - NO
Wikinews - 0.2 - 94 -Yes
Wired.com - 5.2 - 629 - NO
zdnet - 0.2 - 50 - Yes

So - in general the large files with more pages tends to fail to load / cause the reader to Reboot (with above mentioned exception of Telegraph). Any advice? Thanks.

Try using epub output, I've had far better success with feeds that way.

Yeah - was thinking about using epub. It's just that I prefer LRF (size and paragraph jsutification) but I guess it's not that much important for News feeds anyway. Will try that now and report back.

Just to update on my previous post - epub NEws seems to work fine so far.

The developer has stated that there is a problem in the Sony firmware that prevents News feeds from displaying in LRF properly. Use ePub.

When I upgraded from version 5.x to 6.20, the GUI options for conversion increased. What also increased was the large margin in the top and bottom. When converting from RTF to LRF, I like to fill the whole reading area and put in the title&author header. But with 6.20, even with a 0.0 pt margin all around, the top and bottom have large open spaces.

The text size has also increased. With an RTF that has 10.0 size type, the LRF output looks to be about 14pt. How do I fix that?

ZenEngineer: I added the following to the Extra CSS section in Conversion/Look & Feel in Preferences. It reduced the margins to what I was used to with the earlier versions.. I also use fontsize 9.

p {margin-top: 0pt; margin-bottom: 0pt; padding: 0pt;}

Hope this helps..

ZenEngineer: I added the following to the Extra CSS section in Conversion/Look & Feel in Preferences. It reduced the margins to what I was used to with the earlier versions.. I also use fontsize 9.

p {margin-top: 0pt; margin-bottom: 0pt; padding: 0pt;}

Hope this helps..

Worked great! Thanks.

Has anyone else had trouble with extra spaces right after < /EM > tags? This is very noticeable when a comma or period follows the < / EM > tag. So far it looks like it's only affecting the LRF conversions I'm making.

Has anyone else had trouble with extra spaces right after < /EM > tags? This is very noticeable when a comma or period follows the < / EM > tag. So far it looks like it's only affecting the LRF conversions I'm making.
Yes, I noticed it. For now I solve it by including punctuation in the tags. (< em >something, < /em >)

Has anyone else had trouble with extra spaces right after < /EM > tags? This is very noticeable when a comma or period follows the < / EM > tag. So far it looks like it's only affecting the LRF conversions I'm making.

The problem is that LRF is simulating the italics. So what happens is the spacing after the simulated italics is off. After reading ePub with proper italics, I won't go back to LRF with the awful simulated italics.

The problem is that LRF is simulating the italics. So what happens is the spacing after the simulated italics is off. After reading ePub with proper italics, I won't go back to LRF with the awful simulated italics.

I'm not sure this is an option yet for me because I still can't stand the page numbers on the margin of my PRS-505. :(

I keep hoping they'd make a firmware update to fix the epub problems on the Sony and it hasn't happened.

Yes, I noticed it. For now I solve it by including punctuation in the tags. (< em >something, < /em >)

Yeah, I was trying to avoid that option. :) I have over 150 stories I'd have to edit the HTML in order to fix the spacing issue. Currently the EPUB and Mobi do not display the same problem...

"Of all Unicorns she is the only one who knows what regret is and love." -The Last Unicorn

"There are no happy endings because nothing ends." -The Last Unicorn


You seem familiar with unicorns. I've always wondered: Why aren't they called unihorns?

You seem familiar with unicorns. I've always wondered: Why aren't they called unihorns?

I think the name unicorn is based on Latin, uni=one and corn=horse???

that's my guess. :) I'm just glad you're not in charge of naming anything! :)

I'm not sure this is an option yet for me because I still can't stand the page numbers on the margin of my PRS-505. :(

I keep hoping they'd make a firmware update to fix the epub problems on the Sony and it hasn't happened.

I've just gotten used to th page number in the right side. Even have margins set for 0 on the right and I don't mind when the words and the number overlap. Given that it's not full justified, it doesn't always overlap. Plus, using the font of my choice makes things that much nicer to read.

I've just gotten used to th page number in the right side. Even have margins set for 0 on the right and I don't mind when the words and the number overlap. Given that it's not full justified, it doesn't always overlap. Plus, using the font of my choice makes things that much nicer to read.

I'm still trying to figure out how to embedd fonts, none of the directions make sense.

I kind of got that I need to download the font .tff file? and I think it goes in the epub container (but I'm not exactly sure where) and I'm not sure if I need to do anything more than that? or add the font code to the top of the HTML file....

Currently LRF looks nicer on my device however...it's not the format that's readable on all the new devices coming out so in spite of myself I've learned how to make epubs with Calibre. (I just don't know how to do the more advanced stuff)

Now, the weird thing is using the same HTML source code for LRF and Epub produces two different results and the epub just doesn't look as good in Times New Roman. I'm going to have to play around with it until I figure out what settings I'd need to get it to look like my LRF conversions.

Yeah, I was trying to avoid that option. :) I have over 150 stories I'd have to edit the HTML in order to fix the spacing issue. Currently the EPUB and Mobi do not display the same problem...
Just get a good editor and run a correct regexp (regular expression search and replace):

1) For moving the punctuation inside the emphasis:
search = (</em>)([.,!?;:]+)
replace = $2$1

2) For moving the punctuation outside the emphasis:
search = ([.,!?;:]+)(</em>)
replace = $2$1

Just get a good editor and run a correct regexp (regular expression search and replace):

1) For moving the punctuation inside the emphasis:
search = (</em>)([.,!?;:]+)
replace = $2$1

2) For moving the punctuation outside the emphasis:
search = ([.,!?;:]+)(</em>)
replace = $2$1

I'm guessing Notepad++ would do the trick? this seems far too advanced for Wordpad.

It seems that Notepad++ can't handle regular expression replace properly (as per specified syntax). But it does wortk if you use \2\1 for replacement (use backslash instead of string).

I am not sure if Notepad++ can handle multiple files, though. I use FAR Manager with RESearch plugin and that works like a charm.

It seems that Notepad++ can't handle regular expression replace properly (as per specified syntax). But it does wortk if you use \2\1 for replacement (use backslash instead of string).

I am not sure if Notepad++ can handle multiple files, though. I use FAR Manager with RESearch plugin and that works like a charm.

Is Far Manager a program to bulk edit a lot of html files? Because I was thinking if so this could save me a lot of time since I have 130-150 stories.

Is Far Manager a program to bulk edit a lot of html files? Because I was thinking if so this could save me a lot of time since I have 130-150 stories.

FAR Manager (http://www.farmanager.com) is a file manager. One of its plugins, RESearch (http://forum.farmanager.com/viewtopic.php?f=11&t=931) provides regular expression search and replace to many components of FAR; one of its features is the ability to perform regexp s&r on multiple files at once.

It seems that Notepad++ can't handle regular expression replace properly (as per specified syntax). But it does wortk if you use \2\1 for replacement (use backslash instead of string).

I am not sure if Notepad++ can handle multiple files, though. I use FAR Manager with RESearch plugin and that works like a charm.

I do use Notepad++ and it does work fine with multiple files. It has tabs for the different files and it also allows you to search/replace all the files loaded.

FAR Manager (http://www.farmanager.com) is a file manager. One of its plugins, RESearch (http://forum.farmanager.com/viewtopic.php?f=11&t=931) provides regular expression search and replace to many components of FAR; one of its features is the ability to perform regexp s&r on multiple files at once.

This looks like it has a lot of potential to save me time. I was originally looking to see if I can accomplish the same task via Word with macros (but I haven't looked into batch editing via macros?)