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