MobileRead Forums - View Single Post - Official iPDF Fullscreen candidate v1.0 alpha 1 released

jharker · 10-19-2007, 10:03 AM

This post got kinda long, so broke it up into sections...

Column zooming

I believe someone has already developed a patch for ipdf that does column zooming... can't find the thread right now, though... It's actually even more flexible than your proposal: you draw a horizontal zoom line across one column, and then it uses that to infer how many columns on a page, and how wide the columns are.

Community development vs. official inclusion

Bear in mind that most modifications won't ever be included in the official version of iPDF because they are very feature-heavy, and iRex is feature-stingy (for good reason). For example, we have bookmarks, column following, search, etc... At some point, you run out of room for new buttons on the toolbar! And we can only make so many hardware button shortcuts before they're impossible to remember. In this context iRex is trying to include the most broadly useful stuff while preventing the UI from getting too complicated to use.

I've thought about compiling all the community developments into one ipdf viewer, but there are so many different community versions of ipdf at this point, it would be quite an undertaking!

This fullscreen patch was written by request of iRex for possible inclusion into the official version of ipdf. (See this thread in the community development section of the iRex forums.) I don't know when it will be officially released, but if all goes well I expect this patch (or one like it) will be in 2.12, or 2.13 at the latest.

Zoom in iPDF

Currently, ipdf zooms by sending a request to poppler for the WHOLE page to be rendered at a certain resolution. So a fit-to-page zoom in fullscreen mode would ask that the page be drawn at 768x1024 pixels, taking up 768 KB in memory (at 1 byte-per-pixel).

If you double the zoom, you would get a page that's 1536x2048 pixels, taking up about 3 MB in memory. Triple the zoom would take up about 7 MB in memory. Rendering time goes linearly with the number of pixels, so a page at 300% should take 9x longer to render than a page at 100%.

The iLiad also pre-caches pages, usually storing many pages at the same time, up to the limit of available memory.

The result is that zoom is hard-limited, because if it wasn't you could zoom to 1000% and fill all the iLiad's available memory with just one page. And it would take a REALLY long time to render that page.

Arguably this is a poor way to handle rendering. A better way would probably be only ask poppler to render the following, in this order:

Just the part of the page that's visible on the screen, then
A one screen-width border around the visble region (for panning), then
The same areas on the next page (for pre-caching).

Doing it this way would take much less memory and would probably be significantly faster, especially when jumping from place to place within a long document.

However, it would have been substantially more complicated for iRex to write a program to do this. To make the necessary modifications to ipdf would require a major rewrite, and I'm too lazy (and too busy!).

10-19-2007, 10:03 AM	#5
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	This post got kinda long, so broke it up into sections... Column zooming I believe someone has already developed a patch for ipdf that does column zooming... can't find the thread right now, though... It's actually even more flexible than your proposal: you draw a horizontal zoom line across one column, and then it uses that to infer how many columns on a page, and how wide the columns are. Community development vs. official inclusion Bear in mind that most modifications won't ever be included in the official version of iPDF because they are very feature-heavy, and iRex is feature-stingy (for good reason). For example, we have bookmarks, column following, search, etc... At some point, you run out of room for new buttons on the toolbar! And we can only make so many hardware button shortcuts before they're impossible to remember. In this context iRex is trying to include the most broadly useful stuff while preventing the UI from getting too complicated to use. I've thought about compiling all the community developments into one ipdf viewer, but there are so many different community versions of ipdf at this point, it would be quite an undertaking! This fullscreen patch was written by request of iRex for possible inclusion into the official version of ipdf. (See this thread in the community development section of the iRex forums.) I don't know when it will be officially released, but if all goes well I expect this patch (or one like it) will be in 2.12, or 2.13 at the latest. Zoom in iPDF Currently, ipdf zooms by sending a request to poppler for the WHOLE page to be rendered at a certain resolution. So a fit-to-page zoom in fullscreen mode would ask that the page be drawn at 768x1024 pixels, taking up 768 KB in memory (at 1 byte-per-pixel). If you double the zoom, you would get a page that's 1536x2048 pixels, taking up about 3 MB in memory. Triple the zoom would take up about 7 MB in memory. Rendering time goes linearly with the number of pixels, so a page at 300% should take 9x longer to render than a page at 100%. The iLiad also pre-caches pages, usually storing many pages at the same time, up to the limit of available memory. The result is that zoom is hard-limited, because if it wasn't you could zoom to 1000% and fill all the iLiad's available memory with just one page. And it would take a REALLY long time to render that page. Arguably this is a poor way to handle rendering. A better way would probably be only ask poppler to render the following, in this order: Just the part of the page that's visible on the screen, then A one screen-width border around the visble region (for panning), then The same areas on the next page (for pre-caching). Doing it this way would take much less memory and would probably be significantly faster, especially when jumping from place to place within a long document. However, it would have been substantially more complicated for iRex to write a program to do this. To make the necessary modifications to ipdf would require a major rewrite, and I'm too lazy (and too busy!).