Okular Trim margins doesn't work if paper colour is changed

Bug #635026 reported by ssameer on 2010-09-10
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KDE Graphics
Confirmed
Medium
okular (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: okular

The Okular feature "Trim margins" doesn't do anything if I set the paper colour in Accessibility to (say) gray, i.e. margins are still visible. Margins are correctly removed if I unset paper colour.

Ubuntu 10.04.1 LTS
KDE 4.5.1 (4:4.5.1-0ubuntu1~lucid1~ppa1)
Okular 0.11.1 (4:4.5.1-0ubuntu1~lucid1~ppa1)

Version: (using KDE 4.2.1)
OS: Linux
Installed from: Ubuntu Packages

I read a PDF document with okular, turning the Trim Margin feature on, and set the page backgroud color to light yellow (for eye-comfort). Then I found the margin of following pages were appear. The pages I had read were still margin trimmed (maybe buffered).

I have tried other PDF documents and other color, the result is alway the same, Trim Margin doesn't work if paper color was set.

I can confirm this bug in KDE4.2.3. My distro is Slackware.

ssameer (ssameer) wrote :
Changed in kdegraphics:
importance: Unknown → Medium
status: Unknown → New

I'm unable to reproduce on Okular 0.13.3 on KDE 4.7.3. Can you confirm this bug still happens? If so, please provide a screenshot.

Setting status correctly.

Changed in kdegraphics:
status: New → Incomplete

Created attachment 67341
The screenshot

I can reproduce this bug on KDE4.7.3. Way to reproduce:

1, open a pdf, trim margin
2, change the paper color in settings-> Accessibility
3, screw down, you would find pages that have margin

The attachment is the screenshot. The page above is trimmed and the page down is not.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in okular (Ubuntu):
status: New → Confirmed
Sam Gweon (gweon) wrote :

I discovered this bug today, too. Okular seems like a blast. This is a small but significant bug for me. Would appreciate a quick fix!

Lauri Lyly (lauri-lyly) wrote :

Also affects me. As a side-note, for me the trimming only starts working again for the same document if I restart Okular after I disable the paper colour setting.

Lauri Lyly (lauri-lyly) wrote :

Oh yeah... and if the trimming was set before I enable this setting, it stays on for a while until I switch to a new page or so.

Lauri Lyly (lauri-lyly) wrote :

And my Okular version is like 0.14.3, so it's apparently been there for a while.

Lauri Lyly (lauri-lyly) wrote :

I looked at the code and the reason for this is probably obvious (can't be totally sure since I don't know in which order things are done here).

The imageBoundingBox function is checking whether the pixels to become cropped from the margins are white. So, if you set your paper color to something else, it's simply not going to crop them.

Instead of checking for whiteness, I presume it could check whether it's the page color.

Marius B. Kotsbak (mariusko) wrote :

Please add the comments to the upstream bug report: https://bugs.kde.org/show_bug.cgi?id=186531

Great if you can provide a patch to fix it.

Lauri Lyly (lauri-lyly) wrote :

I confirmed this is the case, so ... there's this function "isWhite" in utils.cpp which isn't used anywhere else than in Utils::imageBoundingBox.

I modified it from

inline static bool isWhite( QRgb argb ) {
    return ( argb & 0xFFFFFF ) == 0xFFFFFF; // ignore alpha
}

to

inline static bool isPaperColor( QRgb argb ) {
    return (argb & 0xFFFFFF) == (Settings::paperColor().rgb() & 0xFFFFFF);
}

(obviously had to include "settings.h")

and now it works.

Lauri Lyly (lauri-lyly) wrote :

Still, if you use page up and page down aggressively, it'll randomly not trim the pages. But I suspect this has nothing to do with this specific bug, unless it's applying settings in a delayed way. You can cause trimming then by zooming in and out randomly. I don't know what triggers it, but it doesn't bother me as it trims them during autoscroll which is what I need this trimming feature for.

There is a proposed fix/patch in the downstream bug report:

https://bugs.launchpad.net/bugs/635026

Marius: Tell him to come here.

No answer from the reporter in a long time, closing down the bug. If you can
provide what we asked for please reopen it.

clolse per comment #7

What do you think about this then:

"I confirmed this is the case, so ... there's this function "isWhite" in utils.cpp which isn't used anywhere else than in Utils::imageBoundingBox.

I modified it from

inline static bool isWhite( QRgb argb ) {
    return ( argb & 0xFFFFFF ) == 0xFFFFFF; // ignore alpha
}

to

inline static bool isPaperColor( QRgb argb ) {
    return (argb & 0xFFFFFF) == (Settings::paperColor().rgb() & 0xFFFFFF);
}

(obviously had to include "settings.h")

and now it works."

You see, was it that hard posting it here instead of forcing us to go to a bugtracker that does not have anything to do with KDE?

Changed in kdegraphics:
status: Incomplete → Confirmed

(In reply to comment #9)
> inline static bool isPaperColor( QRgb argb ) {
> return (argb & 0xFFFFFF) == (Settings::paperColor().rgb() & 0xFFFFFF);
> }

Would there be a similar possibility to use the actual page color of the PDF if it isn't white? Because as it stands now, this only works for a non-white background color when set in the settings, not when the document itself features a different background color.

There's no such thing as a "actual PDF page color" as far as i remember. I can be proven wrong of course :)

Of course you can always do some guessing like looking at the 4 corners and some other random positions but it's just guessing.

Anyway it'd be better if the bugs that happen when Trim Margins is enabled get fixed first :-)

Well i am using Debian distro and everything is working fine for me except few pages where i have tried to apply background color and then ticked and unticked trim button. The output remains the same. This might mean that the page which was not trimmed might not be having margins over there.

Please report if this issue is still there or not and if yes then what distro are you using?

This bug is still there. I am using Okular 0.20.2 with KDE 4.14.2 on Kubuntu 14.10. Please try this pdf as a test:

https://www.jair.org/media/301/live-301-1562-jair.pdf

Trim margins works normally. If you change paper colour to gray (or something else) from Settings -> Configure Okular -> Accessibility -> Change colours -> change paper colour. Trim margins no longer does anything.

(In reply to ssameer+bugs from comment #14)

Trim margins works for me with the given PDF, even when a different paper colour is set (Okular 0.21.3, KDE 4.14.9 on openSUSE 13.2)

That's strange, I was able to reproduce this about a month ago with git master.
Did you test with a non-Image PDF (of white background)? Have you tried shocking purple?

Fixing it would be trivial only the trim logic is all entangled with pixmap caching
and you have to touch 4 layers of code or so to fix this, otherwise it would be
have been long ago.

I tested the PDF from comment #14. But you are right - it doesn't really work, it seems like Okular is caching the page margins. So the following works (at least for a few pages):

* open Okular (with trim margins and background color disabled)
* set page background
* enable trim margins

But it no longer works after restarting Okular (or scrolling past the first few pages).

hannes s (temporaer) wrote :

For reference, I updated, tested, and submitted the patch by lauri-lyly to the KDE reviewboard:

   https://git.reviewboard.kde.org/r/125721/

I was able to trim margins without problem, until I upgraded from KDE4 to Plasma5. It turns out I still had a lingering paper-colour setting that I was no longer aware of. Removing the line PaperColor=x,y,z from ~/.kde4/share/config/okularpartrc solved this for me. This issue manifests itself in Okular versions 0.20.3, 0.25.0 and 0.25.80. I use inverted colours a lot, which doesn't raise this problem.

I just noticed this issue using Okular 1.1.2. I've manually set dark and light colors so that the dark is light and the light is dark, so I get light text on dark background to match the breeze dark color scheme. Trim margins no longer works.

@Michael D Are you sure? I have no problem setting colors and trimming on 1.1.2.

I am absolutely sure. In fact, even after reverting to default accessibility settings settings, I lost the ability to trim margins. I had to manually delete ~/.config/okularpartrc to get it back. Apparently it stores some residual config settings about page color which messes up trim.

Yes, you are right. After changing the page color setting I had to restart to trigger the bug.

Is this bug still reproducible? As of version 1.5.0, 'trim margins' works for me with 'accessibility > change light and dark colours' enabled, and the paper colour set to dark grey.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.