all devices regression report - 2018-11-05-06:59:21 - 85e6fd4df9bb51d5c36e7811a2bac4c52898b08c

Differences in all devices errors using gs/examples files

Previous Revision: b4f29851a33ff04979bb2eb3a32ab62000c6f19c
 Current Revision: 85e6fd4df9bb51d5c36e7811a2bac4c52898b08c

commit 85e6fd4df9bb51d5c36e7811a2bac4c52898b08c
Author:     Ken Sharp <[email protected]>
AuthorDate: Mon Nov 5 14:02:51 2018 +0000
CommitDate: Mon Nov 5 14:02:51 2018 +0000

    pdfwrite - add a performance enhancing heuristic for text processing
    
    Bug #700124 "pdfwrite device over 800% performance loss between 9.25 and 9.23"
    
    This is a heuristic attempt to resolve the reduction in performance. The
    code originally used the FontBBox to try and determine if a glven
    glyph was completely clipped out, or was at least partially drawn.
    
    For efficiency reasons we don't include glyphs which are clipper out
    in the pdfwrite output, reducing the PDF size.
    
    However in bug #699454 and bug #699571 we saw EPS files produced from
    OneVision EPSExport which include fonts with a wildly inaccurate
    FontBBox. Two commits; 6a4202691c4317a698fa23c5309ad8974fe2b003 and
    3bf4f3ea45f0022b6cd36415f095f1bfc119fb73 resolved this.
    
    The initial fix considered the advance width in addition to the glyph
    width, but this proved to be insufficient with the second file which
    drew the same glyph multiple times, with an advance width of 0. The
    commit logs note that the only solution is to determine the glyph width
    accurately, which means processing the glyph program for each glyph,
    which has performance implications (ie its slower).
    
    In order to try and alleviate this where possible, this commit looks at
    the number of integer co-ordinates in font space by scaling the
    FontBBox by the FontMatrix. If the resulting design space is small (an
    arbitrary value of 0.1, 1e 100x100 was chosen as 'small') then we do
    not use the FontBBox, but instead use the slower accurate method.
    
    This may need some adjustment, and its entirely possible that it may,
    in the long term, prove unreliable and have to be removed.

devices/vector/gdevpdte.c

new errors:

errors that went away:

errors that are not whitelisted:
=== ghostpdl/examples/escher.ps === pngalpha ===