Bug 186531 - [JJ] Trim Margin doesn't work if paper color was set
Summary: [JJ] Trim Margin doesn't work if paper color was set
Status: REOPENED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords: junior-jobs
Depends on:
Blocks:
 
Reported: 2009-03-08 11:57 UTC by Li Chao
Modified: 2022-08-08 00:31 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The screenshot (158.24 KB, image/png)
2012-01-02 15:05 UTC, Grissiom
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Li Chao 2009-03-08 11:57:03 UTC
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.
Comment 1 Grissiom 2009-05-16 05:38:00 UTC
I can confirm this bug in KDE4.2.3. My distro is Slackware.
Comment 2 jordonwii 2011-12-22 22:42:25 UTC
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.
Comment 3 Myriam Schweingruber 2011-12-27 17:09:37 UTC
Setting status correctly.
Comment 4 Grissiom 2012-01-02 15:05:24 UTC
Created attachment 67341 [details]
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.
Comment 5 Marius Kotsbak 2012-09-09 17:22:45 UTC
There is a proposed fix/patch in the downstream bug report:

https://bugs.launchpad.net/bugs/635026
Comment 6 Albert Astals Cid 2012-09-09 22:17:01 UTC
Marius: Tell him to come here.
Comment 7 Albert Astals Cid 2013-03-10 21:50:50 UTC
No answer from the reporter in a long time, closing down the bug. If you can
provide what we asked for please reopen it.
Comment 8 Jekyll Wu 2013-03-10 22:57:06 UTC
clolse per comment #7
Comment 9 Marius Kotsbak 2013-03-11 09:30:05 UTC
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."
Comment 10 Albert Astals Cid 2013-03-11 18:43:26 UTC
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?
Comment 11 cmertes 2014-03-22 02:30:37 UTC
(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.
Comment 12 Albert Astals Cid 2014-03-22 16:40:06 UTC
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 :-)
Comment 13 sahil 2015-03-16 19:13:46 UTC
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?
Comment 14 ssameer+bugs 2015-03-22 20:16:33 UTC
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.
Comment 15 Daniel Lichtenberger 2015-10-03 16:59:12 UTC
(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)
Comment 16 Jake Linder 2015-10-04 04:32:29 UTC
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.
Comment 17 Daniel Lichtenberger 2015-10-04 08:23:36 UTC
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).
Comment 18 AstroFloyd 2016-08-24 06:46:47 UTC
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.
Comment 19 Michael D 2017-06-09 08:35:17 UTC
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.
Comment 20 Nikolaos Kakouros 2017-06-09 22:40:28 UTC
@Michael D Are you sure? I have no problem setting colors and trimming on 1.1.2.
Comment 21 Michael D 2017-06-12 07:36:40 UTC
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.
Comment 22 Nikolaos Kakouros 2017-06-14 11:58:54 UTC
Yes, you are right. After changing the page color setting I had to restart to trigger the bug.
Comment 23 Kishore Gopalakrishnan 2018-08-24 16:40:40 UTC
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.
Comment 24 David Hurka 2019-06-09 16:50:50 UTC
Works fine with Okular 1.7.2.

Even after both changing color mode and restarting Okular.
Comment 25 Albert Astals Cid 2019-06-09 18:53:45 UTC
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.
Comment 26 Jonas 2020-10-13 03:42:00 UTC
(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.
Comment 27 Michael D 2021-03-05 16:00:33 UTC
Same problem as Jonas on Manjaro with Okular 20.12.2.
Comment 28 Kauê Sena 2022-07-08 16:04:39 UTC
I can report the behaviour reported by Jonas.
Comment 29 Paul Wertenbaker 2022-08-08 00:31:08 UTC
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.