Custom Query (324 matches)
Results (16 - 18 of 324)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #16 | fixed | keep a history of recently opened files | ||
| Description |
It would be convenient to have a 'recently opened' files history, like Acrobat Reader has. Amazingly enough, I use that quite a lot ;) |
|||
| #17 | wontfix | slow rendering of certain pages | ||
| Description |
Please see page 3,4,6 etc. of this PDF document. They seem to render quite slow, especially when compared to Acrobat Reader 4. |
|||
| #18 | fixed | Plug-in API should support delayed loading of requested file pages only | ||
| Description |
First of all my congratulations to the very good idea of a generic document viewer. It looks really promising. For developers the plugin API needs to be documented but I guess this is planned already. I just had a quick look at the plugin sources of the PDF reader because it takes quite long to open a PDF file with many pages. The Plug-in API seems to support only loading a file as a whole with all pages. This might not be possible for large documents (e.g. big multipage images or complex PDFs) due to system memory constraints. Also it forces the user to wait unecessarily long time and finally the user might not even want to have a look at all pages of the document. As a workaround plugins could defer loading pages to view during rendering but this is obviously not intended as there is no way to report read errors. I'd suggest to either enhance the loadFile function or introduce some kind of page switching function with a return code that allows plugins to load a document page on demand. This might be also helpful for supporting document streaming from an URL if this is planned sometime. If memory gets low, the plugin could drop pages from memory if not needed to reduce memory footprint. Heiko |
|||
