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.
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.