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

[ssameer]

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)

[lc2beyond (2beyond)]

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.

[grissiom (chaos.proton)]

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

[ssameer (ssameer)]

Upstream bug report: https://bugs.kde.org/show_bug.cgi?id=186531

[Jordonwii (jordonwii)]

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.

[Myriam Schweingruber (myriam)]

Setting status correctly.

[grissiom (chaos.proton)]

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)]

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

[Sam Gweon (gweon)]

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)]

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)]

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)]

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

[Lauri Lyly (lauri-lyly)]

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)]

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)]

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)]

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.

[Marius B. Kotsbak (mariusko)]

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

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

[Albert Astals Cid (aacid)]

Marius: Tell him to come here.

[Albert Astals Cid (aacid)]

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

[adaptee (adaptee)]

clolse per comment #7

[Marius B. Kotsbak (mariusko)]

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."

[Albert Astals Cid (aacid)]

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?

[Christian Mertes (cmertes)]

(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.

[Albert Astals Cid (aacid)]

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 :-)

[Sahilsehgal1995-8 (sahilsehgal1995-8)]

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?

[Ssameer+bugs (ssameer+bugs)]

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.

[Daniel-lichtenberger-n (daniel-lichtenberger-n)]

(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)

[Jakelinder (jakelinder)]

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.

[Daniel-lichtenberger-n (daniel-lichtenberger-n)]

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)]

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

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

[AstroFloyd (astrofloyd)]

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.

[molecule-eye (niburu1)]

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.

[Nikolaos Kakouros (tterranigma)]

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

[molecule-eye (niburu1)]

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.

[Nikolaos Kakouros (tterranigma)]

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

[Kishore96 (kishore96)]

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.

[David-hurka (david-hurka)]

Works fine with Okular 1.7.2.

Even after both changing color mode and restarting Okular.

[Albert Astals Cid (aacid)]

ok, let's mark it as fixed then.

If someone can still reproduce it with the version David mentioned please tell David what to do and which document to use.

[Jonas (jonas743)]

(A variation of) the problem still exists for me (Kubuntu 20.04, okular 1.9.3).
More precisely, trim margins stops working if I set a background color, and then disable the background color feature again. After setting the background color, okularpartrc contains a block like this:

[Document]
ChangeColors=true
PaperColor=202,254,78
RenderMode=Paper

With background color set, trim margins is still working.
After disabling the background color again, this block changes to

[Document]
PaperColor=202,254,78
RenderMode=Paper

and trim margin stops working after restarting okular. Deleting the block (or just the PaperColor line) solves the problem.

[molecule-eye (niburu1)]

Same problem as Jonas on Manjaro with Okular 20.12.2.

[Jalsti (jalsti)]

Similar problems here with 1.3.2 (on Debian) – having had accessibility features turned on and off again, the 'trim margins' features stopped working.
Removing the out of that resulting new configuration file line `BWThreshold=75` (under `[Dlg Accessibility]`) in okularpartrc, and restarting Okular made 'trim margins' work again.

[Kaue-sena (kaue-sena)]

I can report the behaviour reported by Jonas.

[Paul-wertenbaker (paul-wertenbaker)]

I cannot reproduce this on KDE Neon with Okular 22.11.70 following the same steps. After setting the background color, my okularpartrc contains this:

[PageView]
BackgroundColor=255,85,0
UseCustomBackgroundColor=true

After disabling the background color, my okularpartrc changes to this:

[PageView]
BackgroundColor=255,85,0

And Trim Margin still works whether I then restart Okular or not.