Bug 51479 - Correction of %%DocumentCustomColors in PSOutputDev.cc
Summary: Correction of %%DocumentCustomColors in PSOutputDev.cc
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-27 07:43 UTC by Thomas Freitag
Modified: 2012-06-28 16:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Repairs %%DocumentCustomColors (917 bytes, patch)
2012-06-27 07:43 UTC, Thomas Freitag
Details | Splinter Review

Description Thomas Freitag 2012-06-27 07:43:34 UTC
Created attachment 63523 [details] [review]
Repairs %%DocumentCustomColors

According to the PDF specification, the reserved names Cyan, Magenta, Yellow, and Black shall always be considered to be process colours (and NOT custom colours), and there is a special handling for the reserved names All and None.
This is not considered by PSOutputDev.cc: it inserts them as %%DocumentCustomColors. The attached patch repairs this.
Comment 1 Albert Astals Cid 2012-06-27 15:32:26 UTC
So "All" and "None" do the same thing?
Comment 2 Thomas Freitag 2012-06-28 00:52:46 UTC
(In reply to comment #1)
> So "All" and "None" do the same thing?

Yes, indeed: in this case they do nothing. "All" and "None" are neither custom colours (or spot colours / separation plates) nor process colors, so they should neither appear in %%DocumentCustomColors nor in %%DocumentProcessColors:
"All" should be interpreted as printing it on all plates (so on all process and custom colors), "None" should be interpreted as printing it on none plates, both should be done by the postscript code.
Comment 3 Albert Astals Cid 2012-06-28 16:58:49 UTC
Pushed


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.