Bug 697354 - PDF Interpreter fails to push pdf14 compositor
Summary: PDF Interpreter fails to push pdf14 compositor
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-19 10:35 UTC by Michael Vrhel
Modified: 2016-11-21 04:03 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
transparency_check_fail.pdf (3.67 MB, application/pdf)
2016-11-19 10:35 UTC, Michael Vrhel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Vrhel 2016-11-19 10:35:02 UTC
Created attachment 13156 [details]
transparency_check_fail.pdf

The attached file draws an image with a transparency group.  For some reason the pdf14 compositor is not pushed though.   The blend color space is Gray based.
Comment 1 Michael Vrhel 2016-11-19 10:37:12 UTC
Ken, if you are swamped and can't look this over, I will push it off to Ray who had worked some in the interpreter on detecting the presence of transparency on a page.  I tried and could not see why this is failing.  Thanks.
Comment 2 Michael Vrhel 2016-11-19 10:46:55 UTC
I suspect the comment in pdf_main.ps describes the issue

% Determine whether a page might invoke any transparency features:
%	- Non-default BM, ca, CA, or SMask in an ExtGState
%	- Image XObject with SMask
% Note: we deliberately don't check to see whether a Group is defined,
% because Adobe Illustrator 10 (and possibly other applications) define
% a page-level group whether transparency is actually used or not.
% Ignoring the presence of Group is justified because, in the absence
% of any other transparency features, they have no effect.
%
% Transparency is a 1.4 feature however we have seen files that claimed
% to be PDF 1.1 with transparency features. Bugs 689288, 691273.

For the attached file, the blend color space is gray which is going
to have an obvious effect when going out to a RGB or CMYK output device.

The interpreter will need to look at the color space
of the group and if we encounter one that is different than the target device
color model then we will need to mark the page as having transparency.
If all the groups were the same color space as the device model and there were no other transparency features then we can safely not do the push.
Comment 3 Ken Sharp 2016-11-19 11:46:13 UTC
(In reply to Michael Vrhel from comment #2)
> I suspect the comment in pdf_main.ps describes the issue

Sounds plausible, I'll take a look on Monday, I can put aside annotations to look at a real problem.
Comment 4 Ken Sharp 2016-11-21 01:04:40 UTC
Yes the transparency detection is failing to detect the use of transparency on the page.

However its not to do with the presence or absence of a page Group, since the page doesn't have a group. The transparency group is in a Form XObject and *ought* to be detected. So we don't need to consult the colour space, we should simply see that the page uses a Form, and the Form has a Group.

I'm looking at it now to see why its not detected.
Comment 5 Ken Sharp 2016-11-21 04:03:52 UTC
Fixed in commit 737da8a64a873ea128c5830519d3327baecc6444