summaryrefslogtreecommitdiff
path: root/windows/ghostpcl.vcxproj.filters
diff options
context:
space:
mode:
authorKen Sharp <ken.sharp@artifex.com>2020-09-08 14:24:10 +0100
committerKen Sharp <ken.sharp@artifex.com>2020-09-08 14:24:10 +0100
commit8b805ceb6fe15bd835a48dac227b85da401d7a81 (patch)
tree0bba7206353333246690f31c8e746f643e49a48a /windows/ghostpcl.vcxproj.filters
parente8a6f1d98300fd06965dbdccd82a746adeb05b72 (diff)
downloadghostpdl-8b805ceb6fe15bd835a48dac227b85da401d7a81.tar.gz
pdfwrite - fix error handling with broken type 3 fonts
The test file tests_private\pdf\customer394\problems\normal_537.pdf has a Type 3 font with a CharStrings entry where the value is not a dictionary, it is the null object. When trying to capture the outlines of the glyphs in order to rebuild a type 3 font in the output PDF file, pdfwrite detects the error. However due to an oversight when writing the code, the graphics state is not correctly preserved. This is because if an error occurs in gs_text_process it unwinds the graphics state stack back to the level stored in the text enumerator at the start of the text processing. But complete_charproc() then proceeds to do another gs_grestore (and the code incorrectly did yet another gs_grestore as well!). This results in the graphics save level being different on exit form text processing to the state on entry. Remarkably this doesn't seem to cause a problem, except for the new pdfi interpreter, where the gs_grestore restores back to a point before the type 3 font was present in the graphics state. This leads to the type 3 font having a reference count of 1 at the end of processing and the font and all its contents leaking. Fix it by updating the 'level' stored in the enumerator actually being used by gs_text_process (which, because this is for capturing glyphs, is not the same enumerator as used by pdf_text_process). Also remove the spurious extra gs_grestore in the error clause.
Diffstat (limited to 'windows/ghostpcl.vcxproj.filters')
0 files changed, 0 insertions, 0 deletions