all devices regression report - 2017-11-21-11:56:29 - ce5c3f42d8bd062da65d592abdaaeea90b901970

Differences in all devices errors using gs/examples files

Previous Revision: 19ebb5f1f497b6f2d50fe13d17d3e627dfb6c868
 Current Revision: ce5c3f42d8bd062da65d592abdaaeea90b901970

commit ce5c3f42d8bd062da65d592abdaaeea90b901970
Author:     Robin Watts <[email protected]>
AuthorDate: Tue Nov 21 17:40:53 2017 +0000
CommitDate: Tue Nov 21 18:03:21 2017 +0000

    Ensure that single component planar devices can cope with hl_color.
    
    As part of tracking down indeterminisms in the cluster, I found that:
    
     gs -sBandListStorage=file -sOutputFile=out%d.psd -dMaxBitmap=10000
     -sDEVICE=psdcmyk -r300 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE
     -dBATCH -K2000000 -dClusterJob -dJOBSERVER -ZL
     tests_private/pdf/sumatra/586_-_missing_images_gs_SMask_not_applied.pdf
    
    was hitting a case where we were writing a pattern tile into the
    clist that hadn't been initialised at all. This was because all
    the writes to the pattern accumulator went through
    pattern_accum_fill_rectangle_hl_color. This passes the hl_color
    data to the memory devices fill_rectangle_hl_color function, and
    fills the mask with 1s.
    
    The mask was being entirely filled with 1s and so was being discarded
    as unnecessary. Unfortunately the devices fill_rectangle_hl_color
    entrypoint was left as the default which does nothing by raise an
    error.
    
    The fix here is to ensure that when we open a planar device, we
    always add in a suitable fill_rectangle_hl_color function, even
    when the device is superficially the same as a chunky one.
    
    Thanks are due to Michael and Ray for their help with tracking this
    down.

base/gdevmpla.c

new errors:

errors that went away:

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