all devices regression report - 2017-12-19-03:27:46 - 1143a7aba79e6316ccfb5fc2b0943dcd7a64a48f

[email protected] Tue, 19 Dec 2017 03:27:46 -0800 (PST)
Newsgroups gmane.comp.printing.ghostscript.regression
Message-ID <20171219112746.2F2B22040253@i7>
Differences in all devices errors using gs/examples files

Previous Revision: 6e77c8f647fecaa1a31116fbcd59ad26fb650905
 Current Revision: 1143a7aba79e6316ccfb5fc2b0943dcd7a64a48f

commit 1143a7aba79e6316ccfb5fc2b0943dcd7a64a48f
Author:     Ken Sharp <[email protected]>
AuthorDate: Tue Dec 19 10:16:16 2017 +0000
CommitDate: Tue Dec 19 10:16:16 2017 +0000

    pdfwrite - drop unusable Matte from SMask when doing colour conversion
    
    Bug #698817 "ColorConversionStrategy=Gray breaks image with smask"
    
    SMask images can have a Matte entry which is a preblended colour. It
    must have the same number of components as the parent image. If we are
    doing colour conversion then we can't unconditionally use the existing
    Matte value, as it may have the wrong number of components for the
    converted image.
    
    In fact Matte values are optional and rare. Even rarer are Matte entires
    which have any actual effect. We can't use the value (unless the parent
    image was already in the target colour space, and we can't realistically
    convert the Matte to another space.
    
    So here we test the color conversion strategy, if the image colour space
    is not the same as the target, then we simply discard the Matte entry.
    This isn't 'correct', but then nothing will be, and this stops Acrobat
    from whinging and refusing to render the image at all.

devices/vector/gdevpdfi.c

new errors:

errors that went away:

errors that are not whitelisted:
=== ghostpdl/examples/transparency_example.ps === cp50 ===
=== ghostpdl/examples/transparency_example.ps === psdrgb ===