| Summary: | pdftops -level2sep writes RGB color | ||
|---|---|---|---|
| Product: | poppler | Reporter: | William Bader <williambader> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | williambader |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Sample file to show the problem
proposed patch against 0.17.1 patch to make -level2sep and -level3sep write cmyk instead of rgb patch to make -level2sep and -level3sep write gray instead of cmyk patch to remove str1 patch to make -level1sep write gray instead of cmyk |
||
level2sep and level3sep should use CMYK as the manpage states. Can you provide a patch to fix this? Yes, I can provide a patch in a few days. I think that I have it working, but I started with a version that has some of my unaccepted patches and I need to redo the changes against an unpatched version. Is it OK if I scan the bitmap to check if C=M=Y in every pixel and then write a DeviceGray bitmap instead? ***** Is it OK if I scan the bitmap to check if C=M=Y in every pixel and then write a DeviceGray bitmap instead? ***** Personally i think this falls out of the scope of this bug. Created attachment 47292 [details] [review] proposed patch against 0.17.1 I have attached a patch for 0.17.1. -level2sep and -level3sep now generate gray or cmyk instead of rgb. They request splashModeCMYK8 from SplashOutputDev() the same as -level1sep instead of requesting splashModeRGB8 like -level2 and -level3. In addition, -level2sep and -level3sep scan the bitmap, and if the C, M and Y components match in every pixel, they write a gray image instead of a cmyk image. This should make color images separate better and fix the problem where gray images in -level2sep and -level3sep output write to the c, m and y plates instead of to the black plate. I plan on testing it in the workflow on Monday. Here are sizes from converting my test file with different options. 3305716 May 29 23:32 elp-B83378-gray-level1.ps 13201974 May 29 23:32 elp-B83378-gray-level1sep.ps 232460 May 29 23:32 elp-B83378-gray-level2.ps 188460 May 29 23:32 elp-B83378-gray-level2sep.ps 151154 May 29 23:32 elp-B83378-gray-level2sepbinary.ps Hmmm, it seems you added the gray detection thing, could you please separate it to a different patch as i asked? I don't really see what it has to do with the problem that level2sep writes RGB. Alternatively you can convince me that it is not a separate issue :-) OK, I'll make two separate patches, one for the cmyk and a second that depends on the first that adds gray detection. The gray detection is probably a separate issue because it looks like SplashOutputDev::rgbToCMYK puts 0,0,0 rgb to 0,0,0,255 cmyk. Created attachment 47320 [details] [review] patch to make -level2sep and -level3sep write cmyk instead of rgb Here is the first half to write cmyk instead of rgb. Created attachment 47322 [details] [review] patch to make -level2sep and -level3sep write gray instead of cmyk Here is the second half to scan images, and if they are gray, to write gray instead of cmyk. Can str1 = new CMKYGrayEncoder(str0); str = new RunLengthEncoder(str1); be reduced to str = new RunLengthEncoder(new CMKYGrayEncoder(str0)); ? William Comment on attachment 47292 [details] [review] proposed patch against 0.17.1 As i understand this is obsolete as it's replaced by the other two I've commited both patches, i think that yes, you could replace those two lines if you wanted and not have a str1. If you attach a patch doing that to the patch i'll commit it. Sorry for the delay. Created attachment 48796 [details] [review] patch to remove str1 This is a patch to the 6 July 2011 git source that removes str1. It's in Created attachment 48826 [details] [review] patch to make -level1sep write gray instead of cmyk This patch makes pdftops -level1sep write gray instead of cmyk for gray images, similar to the previous patches for-level2sep and -level3sep. When pdftops -level1sep needs to write a bitmap, and the image is grayscale, this patch makes the resulting ps file 1/4 of the size. Please open a different bug for this and attach the bug there, the subject for this one says level2sep ;-) >Please open a different bug for this and attach the bug there OK, I opened Bug 39012 https://bugs.freedesktop.org/show_bug.cgi?id=39012 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 47248 [details] 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