[ashkulz]

Originally Posted by alex_d

ashkulz, that page reflowing sounds pretty cool. will it only take out big spaces, or could you do something subtle like decrease line spacing? Actually, for that, you'd probably be better off trying something drastic like modifying the pdf itself. (It's nearly impossible to increase boldness that way... believe me, I've tried... but font kerning should be easier.)

alex_d, PDFRead already supports "taking out big spaces" and "decreasing line spacing" -- it's done by the cropping mechanism. If you reduce it from 2.0 to something like 1.0 or 0.5, it will decrease the inter-line spacing drastically. An example of removing big spaces is present in the demos at the start of the thread (the "romans" example).

What I want to do with reflow is to break up indiviudal lines, and move part of the words to the next line (and so on for the rest of the lines). Something like what happens when you reduce the browser window size, the text automatically reflows. I've got a very simplistic algorithm in mind, but I'll document it after I've actually tested it out

Originally Posted by alex_d

Another thing you should put in the backend is the ability to render any subsection of a page. JAP used this feature as the basis of the tool, and for a suitably powerful gui it would allow the greatest flexibility.

I can't think how to implement this properly, as specifying "which" subsection of the page is quite tricky (considering I have to support multiple devices and dilation at variable DPI). It'd be better to crop it properly in Acrobat or whatever, and then render it through PDFRead (as it respects the CropBox).

My next project I think will be to start writing a new gui for the Sony Reader. (The knowledge for doing this is a bit scattered right now, but I've talked with some people who collectively seem to have all the pieces.) At first i'll focus on the core rendering to speed up page-turns (very important for nonfiction/textbooks that I read) and improve quality. I'll do this by implementing page caching and change the the refresh policy in a way that lowers battery life (i.e. no more black-white flashing but rather multiple refreshes). Cold page turns should go from the 2s they are now (for rastered .lrf) to 0.25s or less. Also I'll implement page-number entry and folder-based navigation (and maybe panning, zooming, and even searching... although searching won't be straightforward seeing as I'll still be using an image-based book format). I know none of the above things are an issue for you, ashkulz, with your fancy 1100, but hopefully it'll be the start of a good project.

Do you mean something that will actually run on the Sony Reader itself? That'd be absolutely great, as I don't think anyone has gotten/wanted to run apps on the Sony yet (as compared to the Librie). Wish you the best of luck, and hats off to you

I've also given some thought to a better font-enhancement algorithm vs edge enhancement that would essentially do autohinting on bitmaps. I'll try experimenting a bit with that (but I have a feeling it'll be incredibly processor-intensive).

It's done by all desktop PDF Readers I've seen, and I think it would be rather processor intensive, even if you do it in C.