Version: 0.5.81 (using KDE 4.7.4) OS: Linux Okular's trim margins feature doesn't like multi-column layouts, especially their last page, when there isn't enough text to start the second column. The image attached best illustrates the problem. Reproducible: Always Steps to Reproduce: -Open a multi-column pdf whose last page contains only one column (but still a multi-column layout). -enable the trim margin option -go to the last page Actual Results: last page is zoomed out of proportion Expected Results: okular shouldn't zoom the text, just trim the margins. OS: Linux (x86_64) release 3.0.6-2-desktop Compiler: gcc
Created attachment 67703 [details] Okular's trim margins problem
Can you still reproduce this in a newer version? I remember we did a few improvements to trim margins support
It still happens with Okular 0.15.5 / KDE 4.9.5.
I'm not sure this is a bug: it's kind of expected behavior because you have "Fit width" zoom and the algorithm treats each page independently.
Created attachment 77850 [details] File that triggers the bug (can be freely accessed through http://ft.ornl.gov/pubs-archive/vetter-xfer/2000-sc00-umpire-vetter.pdf ) Confirmed for Poppler(git/master)/Okular(git/master) combination.
Created attachment 77851 [details] How the document show be rendered (minus the margins)
@Fabio did you see the image I attached at the beginning? That's clearly a bug. Here is another picture showing the normal document. We are not trying to "zoom" into the document, just to remove the margin as advertized.
Sure, we remove margins (blank space) -> Page width is decreased -> "Fix width" uses a higher amount of magnification
Try with a fixed zoom level (i.e. a number) instead
Created attachment 77854 [details] with a fixed zoom level
I added a new screenshot with a fixed zoom level. The empty column on the right is treated as if it were a margin and removed. Perhaps okular should scan the document to determine the smallest margin and then trim that amount on every page, or something like that. The lack of layout awareness also affects other functions, like the highlighter, etc.
(In reply to comment #11) > Perhaps okular should > scan the document to determine the smallest margin and then trim that amount > on every page, or something like that. We can't: it would take ages to render the whole document :( > The lack of layout awareness also affects other functions, like the > highlighter, etc. They are not related: Can you please open or check if some bug report exists about this issue? Thanks :)
Ok, i see what you want, that's not going to happen anytime soon for the reasons Fabio points out, but since whishing is free i'm going to move it to wish.
>We can't: it would take ages to render the whole document :( How about using the left margin size as an upper bound when cutting the right margin? Even if it only works for left-to-right languages, it would be still a step forward. >Can you please open or check if some bug report exists about this issue? I was referring to Bug 161324 and now I realize it has been fixed. Kudos!
What is the "left margin size"?
Created attachment 77859 [details] Left-margin
That would be the width of the left margin. See screenshot.
We still have to go though all the pages to calculate that.
I don't know how okular currently determines what to trim, but that is probably done on demand page by page. What I propose is, for a given page, to limit the amount trimmed on the right, so that it's never bigger than the amount trimmed on the left.
That's not trim margins, sorry. That's "trim margins but have this very specific code to make Alvaro happy". It's just not a general enough feature to make sense.
Let alone RTL languages, about which I'm no expert at all, there are also some cases where that would lead to wasted space. For example even pages in http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
If you have a document with a four-column layout and the last page has only a couple of lines of text filling only the first column, okular will chop off 75% of the page and zoom in the 25% to full screen. It's not trimming a margin but destroying the layout for this use-case. In western languages you fill the text from left to right and from top to bottom. If you have to guess the margin sizes to chop off, it is better to use the left and top blank space, because that's where the text begins. The blank spaces on the right and on the bottom might not belong to the margin but to the text-space. It has nothing to do with making me happy. I submit bugs to help you improve your apps. If you consider the current behavior a feature and not a bug, feel free to close the bug report.
The feautre is described as removing the whitespace around the page, and that's what it does. Yes, you as a human can do a better assessment of what'd you would like to get trimmed, but unles you code me a Skynet here i don't see a way for the code to be as smart as you want it to be so i'm closing the bug following your suggestion. Of course we do appreciate your suggestion and personally I'm sorry we can't provide a solution for it.