| Summary: | app-text/epdfview-0.1.8 switches blue and red colors | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vladimir <v_2e> |
| Component: | Current packages | Assignee: | Daniel Pielmeier <billie> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo, hppa, ppc64, ppc, printing, sparc |
| Priority: | Normal | Keywords: | PMASKED |
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
RGB PDF test file
CMYK PDF test file |
||
|
Description
Vladimir
2011-10-14 13:27:32 UTC
You must apply this patch [1] from epdfview's upstream to fix the issue. > When using Poppler 0.17.0, I needed to swap the blue and red channels, > otherwise the colors (other than black and white) looked wierd. [1] http://trac.emma-soft.com/epdfview/changeset/367 (In reply to comment #1) > You must apply this patch [1] from epdfview's upstream to fix the issue. > > > [1] http://trac.emma-soft.com/epdfview/changeset/367 epdfview upstream strikes again - I don't know if any of the supported by the ebuild arches is bigendian, but I'm almost certain, that if it is, this patch will break them instead. I confirm this bug and that the patch from comment #1 resolves the problem. (In reply to comment #3) > I confirm this bug and that the patch from comment #1 resolves the problem. I can confirm this bug too. Don't tried yet the patch. This bug is already out there for a while and the patch seems to be working. I strongly suggest to push this to the official portage tree. +*epdfview-0.1.8-r1 (28 Jan 2012) + + 28 Jan 2012; Daniel Pielmeier <billie@gentoo.org> +epdfview-0.1.8-r1.ebuild, + +files/epdfview-0.1.8-swap-blue-red-channels.patch: + Add patch from upstream to fix bug #387125. Thanks to Vladimir for the report + and Fab for the link to the upstream patch. Possible endian issues still have + to be sorted out. I have added the patch for 0.18-r1. Regarding endianness. If I am correct x86 and am64 are little endian so there should be no problem there. ppc(64) and sparc are bi-endian so there might be problems. For hppa I am not sure [1] says bi-endian and [2] says big-endian. All in all a patch working everywhere would be appreciated. CC-ing affected arch teams for advice. @ ppc, ppc64, sparc, hppa: Can you please test if the patch causes any issues on your architecture? [1] https://en.wikipedia.org/wiki/Endianness [2] https://en.wikipedia.org/wiki/PA-RISC (In reply to comment #6) > I have added the patch for 0.18-r1. Regarding endianness. If I am correct x86 > and am64 are little endian so there should be no problem there. ppc(64) and > sparc are bi-endian so there might be problems. For hppa I am not sure [1] says Linux/HPPA is big-endian. I didn't test with a coloured PDF for the -r0 stabilisation - checking again. Not that it really matters to me, but it's like this: - gdk-pixbuf is machine independent RGBA - cairo surface (24/32 bit type) is machine endian ARGB (that is it's BGRA on little endian) as such that 'swap(data[0], data[2])' fix is correct for little endian, but no real help for big endian I have tested 'epdfview-0.1.8-r1' on 'ppc', 'ppc64', 'amd64' and 'alpha'
with two PDF test files and obtain the following results:
X86 PPC AMD64 PPC64 ALPHA
sl_rgb.pdf ? PASS PASS FAIL-2 PASS
sl_cmyk.pdf ? PASS FAIL-1 FAIL-2 FAIL-1
FAIL-1 Red and Blue swapped
FAIL-2 All colors including Black get munged in non-obvious way
I do not have access to X86 but have attached the test files for reference.
The test files render correctly using 'xpdf' on all above platforms.
So the problem seems related to using CMYK colorspace in the PDF.
Stephen Lewis
Created attachment 302755 [details] RGB PDF test file see Comment 9 Created attachment 302757 [details] CMYK PDF test file see Comment 9 For me both test files are working: Linux flora 3.2.1-gentoo-r2 #1 SMP Mon Jan 30 23:12:58 CET 2012 x86_64 Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz GenuineIntel GNU/Linux amd64 environment with epdfview-0.1.8-r1 running (currently amd64 keyworded) So we really need a fix which endian independent. I already contacted upstream about this issue but got no response until now. Masked for removal. Hello! (In reply to comment #14) > Masked for removal. It's a pity epdfview is "dead" as today's emerge message says. I also says that " Unfortunately the best lightweight replacement I can # recommend is app-text/apvlv, otherwise you can go for app-text/acroread # (huge, closed source), kde-base/okular (KDE), or app-text/evince (Gnome)." But what about app-text/qpdfview? It looks stable even in its current state, but it is also being developed actively. At least, the developer responds very fast to any bugreports and feature requests. He tries to keep this application lightweight as well. To my mind, qpdfview is a nice alternative to epdfview in the nearest future. It also has a "tabbed" interface which is not widely implemented in PDF viewers. Regards, Vladimir (In reply to comment #15) You forgot zathura which has evolved to near evince completeness. Another viewer to look at is mupdf, very quick with vi-like shortcuts, has text search and goto page, pretty basic but very good performance. Not in the tree anymore. |
