New Ghostscript/GhostPDL compiler warnings - 2018-01-15-13:15:02 - b199f558834d0fbd365cccc426eed0fdc3e035c7

[email protected] Mon, 15 Jan 2018 14:42:55 -0800 (PST)
Newsgroups gmane.comp.printing.ghostscript.regression
Message-ID <20180115224255.89DCB204025E@i7>
Previous Revision: 99a839311c7d7e1dab919bd88f7632c5e230708f
 Current Revision: b199f558834d0fbd365cccc426eed0fdc3e035c7

commit b199f558834d0fbd365cccc426eed0fdc3e035c7
Author:     Ken Sharp <[email protected]>
AuthorDate: Mon Jan 15 17:22:38 2018 +0000
CommitDate: Mon Jan 15 17:22:38 2018 +0000

    pdfwrite - Fix the detection of type 3 descendants in composite fonts
    
    Bug #698844 "ps2pdf creates unusually large PDF files starting with version 9.21"
    Bug #698647 "PCL5 - Downloadfont not as T3 Font interpreted"
    Bug #607462 "Ghostscript falls into infinite loop with pdfwrite"
    
    The actual problem was that a Type 0 composite font with a single
    descendant was used with stringwidth and the space glyph. This was not
    detected by pdf_text_begin() and so the glyph was cached, but it was not
    added to any type 3 font, it was simply processed as a stringwidth.
    
    Later the same glyph from the same font was used in earnest, pdfwrite
    noticed it didn't have a copy of the glyph and set up to capture the
    CharProc. But the glyph was present in the glyph cache which meant the
    CharProc wasn't executed, leading to an infinite loop.
    
    The fix applied prevented caching type 3 fonts, but that caused problems
    with cases where we wanted to convert a font to type 3, so the fix
    was extended to only prevent caching of input type 3 fonts, not
    synthesised ones.
    
    However, this still caused problems with programs which used type 3 fonts
    with glyphshow. Because we did not cache the glyphs we would detect each
    glyph use through glyphshow as a new glyph, and so there would be no
    glyph reuse, leading to large slow PDF files.
    
    Here we extend the check on descendants of type 3 fonts so that if no
    font change takes place, we still check the 'current' descendant to
    see if its type 3. If a type 3 descendant is detected then we skip
    caching the glyph which prevents the whole problem.
    
    No differences expected.

devices/vector/gdevpdtt.c



Ghostscript:

new scan-build warnings:

./devices/vector/gdevpdtt.c:3422:21: warning: Dereference of null pointer
                    pdfont->u.simple.s.type3.cached[cdata[pte->index] >> 3] |= 0x80 >> (cdata[pte->index] & 7);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


http://miles.ghostscript.com:8080/artifex/b199f558834d0fbd365cccc426eed0fdc3e035c7/gs/index.html

http://miles.ghostscript.com:8080/artifex/b199f558834d0fbd365cccc426eed0fdc3e035c7/gs-scan-build.txt




GhostPCL:

new scan-build warnings:

./devices/vector/gdevpdtt.c:3422:21: warning: Dereference of null pointer
                    pdfont->u.simple.s.type3.cached[cdata[pte->index] >> 3] |= 0x80 >> (cdata[pte->index] & 7);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


http://miles.ghostscript.com:8080/artifex/b199f558834d0fbd365cccc426eed0fdc3e035c7/pcl/index.html

http://miles.ghostscript.com:8080/artifex/b199f558834d0fbd365cccc426eed0fdc3e035c7/pcl-scan-build.txt