all devices regression report - 2017-11-23-08:03:46 - f32c03a2daad2d2e0e859bd6fc7547b68bd8bed9

Differences in all devices errors using gs/examples files

Previous Revision: 1cfc56251773304fb102237ff8a63c5576f08fe7
 Current Revision: f32c03a2daad2d2e0e859bd6fc7547b68bd8bed9

commit f32c03a2daad2d2e0e859bd6fc7547b68bd8bed9
Author:     Ken Sharp <[email protected]>
AuthorDate: Thu Nov 23 13:32:26 2017 +0000
CommitDate: Thu Nov 23 14:12:30 2017 +0000

    Do not ignore errors from the device's fill_rectangle_hl_color method
    
    Spotted by Robin while fixing indeterminisms, we currently ignore any
    error return from this method in pattern_accum_fill_rectangle_hl_color()
    when it calls its target device. Adding a check and error propagation is
    simple enough, but that then reveals problems with the high level
    devices.
    
    There are, in fact, several problems here. Firstly, the mem* devices
    which are used to render pattern tiles (amongst other things) are
    based on forwarding devices. When we send a spec_op we forward this to
    the 'underlying' device. This is a problem if the spec_op is querying
    whether the device can handle hl_color, because if it can then the
    caller may proceed to use hl_color methods. But the mem* devices cannot
    handle these methods and obviously can't forward them to the underlying
    device, resulting in an error. Fixed this one by using the default
    spec_op method instead of the forwarding one. In future this may require
    further attention.
    
    The NULL device doesn't implement fill_rectangle_hl_color. In fact, with
    the changes elsewhere it doesn't need to, but really we should simply
    handle this in the same way as fill_rectangle and return, all the null
    device does is bit bucket all operations. For completeness, implement
    such a method.
    
    gx_erase_colored_pattern() didn't do a restore (to match its save) if
    an error occurred. Again, with the other changes this is no longer
    triggered, but it does seem wrong so lets fix it.
    
    In gx_pattern_load() and pattern_paint_prepare(), avoid erasing the
    background of the tile if the pattern instance is for a device which
    handles patterns itself (eg pdfwrite). Once again, not really required
    now that the mem* devices don't pass on the spec_op to the underlying
    device, but it saves us bothering with erasing a rectangle which we are
    going to throw away anyway.
    
    Finally, the point of the whole exercise, in
    pattern_accum_fill_rectangle_hl_color(), check the return code from the
    target device's fill_rectangle_hl_color and if its an error, return it.

base/gdevmem.c
base/gdevnfwd.c
base/gxpcmap.c
psi/zpcolor.c

new errors:

errors that went away:

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