Yet another PDF to LRF converter

[Vladekk]

Hm, currently dos verison doesn't accept --fit=page.
I believe it should?
Anyway, thanks for amazing app. I used JAP previously, but its author almost ceased development because he's not using Reader himself.

But your app is abosultely ultimate pdf/djvu/comics formatting method. I wonder why Sony can't make Reader solid product, but one programmer can do it - and even as freeware.

[hdtvman]

Originally Posted by ambertape

HDTVMAN,

which program did you use for conversion that you were successful in ?

I used pdflrfwin-0.99win.zip

I think I left the default settings as is. I only did one file but I will soon do more.

Hdtvman, Royal Oak, MI

[kimstudio]

Hi all.

How to convert eachpage of a pdf into one png file without splitting and combining the pages vertically with defined height?

In another word, I hope I can just input the width and leave height blank, then the tool will automatically calculate the height it needs to convert a page into an image.

Thanks in advance!

[Vladekk]

I made word macro for Reader+pdflrf+libprs500.

It works so:
You paste into word something (usually from web page), than press button.
Macro sets font to Calibri size 14, page size for reader, saves file to PDF using Word 2007 converter. Then calls pdflrf, converts pdf to lrf. Than calls libprs500 routines to copy file into Reader.

If someone is interested, I'll polish and finish this thing and upload it here.

[mieslep]

Hello,

How hard would it be to have the utility dynamically detect columns? I'm thinking about Scientific American and other magazines which have 3 columns, often with varying widths. Probably a rather big challenge, but surely achievable?

[viric]

Hello,

I still waiting for the postal service to bring me the Reader, but I'm sure I'll find this tool useful.

As someone already notes in this thread, the source code of the program should be available due to the GPL-2 license of Poppler. I see it as a clear violation of the license...

I'm also a Linux developer, and I've been working in document processing (mostly postscript) and bitmaps graphics, and I'm also interested in being able to apply changes to your tool.

Thank you in advance (although I have not been able to try the program yet).

[JSWolf]

Originally Posted by Vladekk

I made word macro for Reader+pdflrf+libprs500.

It works so:
You paste into word something (usually from web page), than press button.
Macro sets font to Calibri size 14, page size for reader, saves file to PDF using Word 2007 converter. Then calls pdflrf, converts pdf to lrf. Than calls libprs500 routines to copy file into Reader.

If someone is interested, I'll polish and finish this thing and upload it here.

Why not just set the page size for the reader? Then you would not need to use pdflrf at all.

[rstarid]

I'm having a problem with font sizes on some of my ebooks. When I convert the pdf with pdflrf, the font size is tiny. The pdf has images in it that I need for reference, so I cant use the built in converter with libprs500 since it strips the images. I need the font size set to 11 or 12 so I can read it easily, vs the 4 or 5 it's showing up at. Does pdflrf have options for font resizing? Does anyone know a way I can do this? I'm currently running Linux, but I can find a Windows machine to do the convert on if I need to since I only need images on a few rare pdf's.

Thanks.

[Vladekk]

Originally Posted by JSWolf

Why not just set the page size for the reader? Then you would not need to use pdflrf at all.

Because
1)Reader is very slow at the end of book when pdf have more than 200-400 pages.
2)Pdftolrf makes letters look better.

[netseeker]

Originally Posted by rstarid

Does pdflrf have options for font resizing? Does anyone know a way I can do this?

You can't specify the target font size because pdflrf just uses an image for each page within the pdf. Pdflrf has no knowledge about which parts of a page contain texts and which parts contain images or tables.
In such cases i use rotation=-90, split pages = yes, crop sides = yes, smart cut = yes, scale=fit to width.
This results in a file in landscape orientation with more pages than in the original pdf. Due to the "fit to width" and "crop sides" the font size will be increased.

[Deputy-Dawg]

Originally Posted by Vladekk

Because
1)Reader is very slow at the end of book when pdf have more than 200-400 pages.
2)Pdftolrf makes letters look better.

Neither of which statements are true.

I am working on a Bible project that will result in a file that has presently 5,353 pages and the page change at 5,000 page level is not different than that at the 30 page level, nor are either of the page changes observably different than the page changes on a test file containing only 30 pages. Nor is the jump from page 4954 to page 22 different from the jump from page 22 to page 65.

The appearance of the font is largely dependent on carefully choosing a font that displays well on the Sony reader. A suitable font would be one which has somewhat thicker than normal strokes, try using semibold fonts or bold fonts which appear to be lighter than the typical bold font. Also try to avoid fonts which have a huge disparity between the weight of the various strokes. A good place to begin experimenting is to use a semibold sans serif font, you will get a good idea of what is possible.

Finally you need to carefully select your page size - as this will be the final control on your absolute font size. And always compose your document with a view to the fact that it is going to be displayed on a device whose screen has a display ratio of 3::4 Portrait orientation.

I have included a file of 6 pages extracted from my Bible Project. The Header font (the one that appears in the Book Titles only) Copperplate Gothic BT Bold at 26.0pt. All of the remaining text is set from a subset of the Optane Compact family consisting of Optane Compact Bold and Optane Compact Bold Italic. on the first page of the sample file the Title and Chapter are set at 26.0 pt. The verse # are set at 4.0.pt and the body text is set at 7.0 pt italic. On page 2 the verse # are again 4.0pt and the body text is 7.0pt normal. On pages3 & 4 the verse # are 3.0pt and the body text is in 6.0pt. Finally on page 6 the Book name is again in 26.0pt Copperplate Gothic BT bold, the Chapter # is 26 pt Optane compact normal bold, the verse # are set in 4.0 Optane compact bold normal and the body text is set in 7.0pt Optane comact normal bold.

The pages were set on a page which is 4.05in X 6.20in with margins Top 0.1in; bottom 6.2in; left 0.1in right 0.1in. I used Adobe Acrobat Professional. And it suspect that may be a critcal choice. If you used the Microsoft PDF creator and is as slovenly in producing PDF files as the Microsoft HTML generator is in generating HTML then I can easily believe that the page swap times become and issue in large files but I never would have thought files of only 200 page would be a problem.

Again I repeat if choose your font carefully, you appropriately size your fonts and the virtual page size you use, and you generate pristine pdf files the result can be quite acceptable in every respect.

[soilwork]

Originally Posted by Deputy-Dawg

Neither of which statements are true.

I don't have any experience related to 1). However, 2) is in a way true since the background color of PDF files is bit more grey than that of LRF ones.

https://www.mobileread.com/forums/sho...0&postcount=14

[Deputy-Dawg]

Originally Posted by soilwork

I don't have any experience related to 1). However, 2) is in a way true since the background color of PDF files is bit more grey than that of LRF ones.

https://www.mobileread.com/forums/sho...0&postcount=14

Did you look at the samples I posted? Yes, I am aware of the "grey" background issue, which is why the font used is critically important. But that being said I still maintain that with careful choice of font and font weight that a PDF file can be every bit as readable as a LRF file and PDF files have a much richer TOC capabilities.

[soilwork]

I think we are interpreting 'looks as good as' in a different way.

If you are talking about overall aesthetics including fonts, PDF may be a good way to view documents. However, for someone like me, I don't care AT ALL about fonts but I found the greyish background extremely annoying. So PDF documents with 'decreased constrast' due to greyish background do not qualify as 'looking as good as' to me.

You seem to be willing to trade off fonts & navigation with decreased contrast, but I don't. I think that is why we don't agree on 'looking good'.

[Deputy-Dawg]

Originally Posted by soilwork

I think we are interpreting 'looks as good as' in a different way.

If you are talking about overall aesthetics including fonts, PDF may be a good way to view documents. However, for someone like me, I don't care AT ALL about fonts but I found the greyish background extremely annoying. So PDF documents with 'decreased constrast' due to greyish background do not qualify as 'looking as good as' to me.

You seem to be willing to trade off fonts & navigation with decreased contrast, but I don't. I think that is why we don't agree on 'looking good'.

Again, I ask, did you look at the samples?

The problem with the grey background is not so much the lowering of the contrast as it wreaks havoc on the anti-aliasing of the fonts. This is why my requirement for fonts with heavier weights, and more importantly fonts with nearly equal strokes. pdflrf is a useful program but it suffers from many problems which are inherent with the approach. The most significant of which is the increased loss of edge sharpness on the characters. Try rendering my sample pages with it and observe what happens to the verse numbers, particularly on pages 3 & 4.

BTW if you are happy, I have no problem with that.