Bug 51548 - DeviceN images in level 3 PostScript
Summary: DeviceN images in level 3 PostScript
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-29 01:57 UTC by Thomas Freitag
Modified: 2012-07-05 08:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Resolves DeviceN images problem in level 3 (1.18 KB, patch)
2012-06-29 01:57 UTC, Thomas Freitag
Details | Splinter Review
PDF with DeviceN image (628.62 KB, application/pdf)
2012-06-29 02:01 UTC, Thomas Freitag
Details

Description Thomas Freitag 2012-06-29 01:57:51 UTC
Created attachment 63589 [details] [review]
Resolves DeviceN images problem in level 3

In commit 59946e0c34e762eb5f5a13b4ae8c9ec7fb21379a I introduced the implementation of the DeviceN colorspace in PostScript in case of level3. Unfortunately I missed that in case of images with DeviceN colorspace in doImageL3 the alternate colorspace is used for decode and the stream was converted to the alternate colorspace. This of course now conflicts to the setup DeviceN colorspace, so this special handling of DeviceN colorspaces in doImageL3 must be removed. The attached patch solves it.
Comment 1 Thomas Freitag 2012-06-29 02:01:43 UTC
Created attachment 63590 [details]
PDF with DeviceN image

Run pdftops with the -level3sep option on this PDF. The resulting postscript file will cause PostScript errors i.e. when ripping it with gs
Comment 2 Thomas Freitag 2012-07-01 02:17:24 UTC
I made some additional tests with my patch, i.e. with the DeviceN tests from the Ghent PDF Workgroup. The output could be rendered with gs 9.0.5, but the output looked terrible when the DeviceN images contains other colors than process colors (or is it because of the usage of None?). But when I rendered it with acrobat X, everthing looked fine.
Therefore I think it is a gs problem, and opened a bug there, too. You can follow it here: http://bugs.ghostscript.com/show_bug.cgi?id=693163
Comment 3 Albert Astals Cid 2012-07-02 01:30:51 UTC
Is that a regression or it did not work anyway without your patch?
Comment 4 Albert Astals Cid 2012-07-05 05:00:36 UTC
Thomas?
Comment 5 Thomas Freitag 2012-07-05 05:12:51 UTC
(In reply to comment #4)
> Thomas?

Sorry, still working on it, You'll get a new patch propbably this weekend. s.a. http://bugs.ghostscript.com/show_bug.cgi?id=693163. 
But it did not work anyway without this new patch: pdftops with -level3 or -level3sep produces unrippable postscript if the PDF contains an image in DeviceN since commit 59946e0c34e762eb5f5a13b4ae8c9ec7fb21379a.
Or would You say it is a regression because it works if the PDF doesn't contain a DeviceN image?
To clearify: PostScript is always produced, You'll get just a problem if You try to use the PostScript
Comment 6 Albert Astals Cid 2012-07-05 06:41:49 UTC
Ok, let me try to make my question clearer:

Do you think that this patch makes the ps output better or worse?

Will your new patch need this parch or not?
Comment 7 Thomas Freitag 2012-07-05 07:02:39 UTC
(In reply to comment #6)
> Ok, let me try to make my question clearer:
> 
> Do you think that this patch makes the ps output better or worse?

Better: DeviceN images will no more produce PostScript failures and are shown well except when the alternate colorspace is csLab.

> 
> Will your new patch need this parch or not?

It's up to You: I'll create a new diff against actual git, so if You think it is better to commit the patch from 2012-06-29 first, I'll have no problems with it. Otherwise You'll get a new patch which replaces that one and corrects also the csLab problem.
Comment 8 Albert Astals Cid 2012-07-05 08:46:39 UTC
Commited.


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.