Bug 702131 - Overprint/FillStroke/Transparency non-clist problem
Summary: Overprint/FillStroke/Transparency non-clist problem
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: PC Windows 10
: P4 normal
Assignee: Default assignee
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-17 16:18 UTC by Robin Watts
Modified: 2020-02-27 13:10 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Watts 2020-02-17 16:18:09 UTC
The review of release candidate bitmaps has thrown up a problem with the pdfwrite output of a test file.

gs -o out.pdf -sDEVICE=pdfwrite tests_private/comparefiles/Bug693220.pdf 

gs -o out.ppm -dMaxBitmap=400000000 -sDEVICE=ppmraw -r300 out.pdf

The problem is in the second phase (the rendering, not the pdfwrite generation).

A fill/stroke is happening (see the top logo) and the orange stroke is going missing.

Experiments show that this is somehow related to overprint; the first thing in my reduced file is an image (the blue background behind the logo). Remove the image, and the stroke appears normally. Leave the image in, and the stroke is not drawn.

I've reduced the file as much as I can (to two rectangles), and I find that if I leave any transparency in the file (just an unused gstate with a non-solid alpha is enough), then it renders wrongly. Remove that and it renders correctly.
Comment 3 Robin Watts 2020-02-27 13:10:21 UTC
Fixed with:

commit 76fb18bc255a88cab5fbb2410b411e580f53486d
Author: Robin Watts <Robin.Watts@artifex.com>
Date:   Tue Feb 18 19:25:24 2020 +0000

    Bug 702131: Fix overprint in additive spaces.

    We should only enter CompatibleOverprint blend mode if we
    are in an subtractive space. This stops pdf14 trying to honour
    drawn_comps even in additive spaces.