[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