[Poppler-bugs] [Bug 37688] New: pdftops -level2sep writes RGB color
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sat May 28 02:55:35 PDT 2011
https://bugs.freedesktop.org/show_bug.cgi?id=37688
Summary: pdftops -level2sep writes RGB color
Product: poppler
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: general
AssignedTo: poppler-bugs at lists.freedesktop.org
ReportedBy: williambader at hotmail.com
Created an attachment (id=47248)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47248)
Sample file to show the problem
I have PDF files that are black and white.
When I run then through pdftops-0.17.0 with anything but -level1 or -level1sep,
they end up with RGB color.
They view OK on the screen and they print OK on a laserjet, but when I send
them to be typeset, anything that was black in the original becomes 100% C,
100% M, 100% Y, 0% K, which is bad. Black in the PDF should go to 0% CMY 100
%K.
I suspect that the problem is that PSOutputDev::checkPageSlice() uses
DeviceRGB.
I think that for psLevel2Sep and psLevel3Sep, it would be better to use CMYK
color space.
I have a test version that does that.
Is it OK or would you rather have a flag to force CMYK to avoid changing the
meanings of -level2sep and -level3sep?
I have attached an example PDF.
Also, to save space, if globalParams->getPSBinary() is set, is it OK to write
the results of RunLengthEncoder(str0) directly without running it through an
ASCII Encoder?
It seems to work, but it doesn't save that much space, and it messes up gv.
William
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Poppler-bugs
mailing list