all devices regression report - 2017-11-15-14:14:51 - a8b1611e7613781cd5c2c7defa2c5315254d9d1d
| Newsgroups | gmane.comp.printing.ghostscript.regression |
|---|---|
| Message-ID | <20171115221452.047CC20401E6@i7> |
Differences in all devices errors using gs/examples files Previous Revision: fac14b8c25422529acded1e9e920eb20190db340 Current Revision: a8b1611e7613781cd5c2c7defa2c5315254d9d1d commit a8b1611e7613781cd5c2c7defa2c5315254d9d1d Author: Robin Watts <[email protected]> AuthorDate: Wed Nov 15 19:17:05 2017 +0000 CommitDate: Wed Nov 15 19:30:24 2017 +0000 Fix operation of 1bpc, 3 component halftones. In the chunky world, it makes no sense to deal with 3 bit rgb as this doesn't pack neatly into a byte. You'd do it by handling 4 bit chunks. Accordingly, parts of Ghostscript are written to assume that you'd not do anything this crazy. Unfortunately, in the planar world, a 1 bpc, 3 component device does make (some) sense. Sadly, stuff like the halftone generation gets deeply confused by this. Here we fix 2 specific instances of this problem. In the halftone generation, we generate 3bit chunky halftones as 4 bit ones, and in the planar_copy_color routines, we assume that 3 bit data is actually 4 bit (as a) it probably comes from these routines, and b) if it doesn't it'd be packed as 4 bit in any sane world). base/gdevmpla.c base/gxcht.c new errors: errors that went away: errors that are not whitelisted: === ghostpdl/examples/transparency_example.ps === cp50 === === ghostpdl/examples/transparency_example.ps === psdrgb ===