diff options
author | Ken Sharp <ken.sharp@artifex.com> | 2020-09-08 14:24:10 +0100 |
---|---|---|
committer | Ken Sharp <ken.sharp@artifex.com> | 2020-09-08 14:24:10 +0100 |
commit | 8b805ceb6fe15bd835a48dac227b85da401d7a81 (patch) | |
tree | 0bba7206353333246690f31c8e746f643e49a48a /windows/ghostpcl.vcxproj.filters | |
parent | e8a6f1d98300fd06965dbdccd82a746adeb05b72 (diff) | |
download | ghostpdl-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