Version: (using KDE KDE 3.4.2) Installed from: Fedora RPMs Many PDF files have wide margins that, while suitable for printing on paper, are very wasteful of screen resources. This problem is especially grave with some academic publications that use enormous margins in their standard stylesheets. Implications include: * In Fit to Page zoom, wide vertical margins cause the real content of the page to be unnecessarily small (and at other zoom levels page flipping is messy) * In Continous mode, wide vertical margins necessitate a lot of scrolling between pages, and you can see less content simultaneously at page borders * In Two Pages mode, wide horizontal margins cause the real content to be unnecessarily small (often making this important mode useless) It would be great if KPDF had an option to automatically detect margins and to subtract them from the image, prior to calculation of zoom level and rendering. To cover the overwhelming majority of cases, it would suffice to just have a simple heuristic which identifies the maximal white strip at each of the 4 edges of the paper. Or just do whatever "gs -sDEVICE=bbox" does. This feature would make a lot of documents much easier to read on-screen, and form a significant advantage for KPDF compared to other PDF viewers.
This would definitely be useful when you read a pdf on a latop but also when you create your Tex file on a normal screen: you could split your screen in half and have your source Tex on the left while looking at the result on the right. That's what I do on my Mac at least, and I think it is very convenient :)
Should this be done specifically for PDFs, or as part of KDE's generic document viewer framework?
*** This bug has been confirmed by popular vote. ***
*** Bug 146623 has been marked as a duplicate of this bug. ***
Created attachment 21707 [details] Example of the problem To demonstrate the importance of this feature, see the attached example. The upper part is a screenshot of KPDF 0.5.7 showing a typical document I have to deal with, in double-page mode. The bottom part is a mockup of what it *could* look like. You can probably tell which is more productive.
I know this bug concerns kpdf but shouldn't we close it now that okular provides this option ? Thx a bunch for okular btw !!
Closing this wish. kpdf is no longer under development and the okular team has already implemented it. If you have a wish on top of okular implementation please open a separate bug.