diff options
author | Ken Sharp <ken.sharp@artifex.com> | 2022-04-04 13:49:58 +0100 |
---|---|---|
committer | Chris Liddell <chris.liddell@artifex.com> | 2022-04-04 14:46:22 +0100 |
commit | 83a272b13561436b924a30a61691f6e11928a662 (patch) | |
tree | a0c9d0f33760b7bb0b397a22bdb86a0a4fe7d0de /doc/thirdparty.htm | |
parent | 6fda03fb5d85e51a9acdb446185c2edcf6612b9c (diff) | |
download | ghostpdl-83a272b13561436b924a30a61691f6e11928a662.tar.gz |
GhostPDF - fix text rendering mode 3 and pdfwrite
Bug #705187 "Ghostscript 9.56 removes hidden (e.g. OCR) text layers when refrying with NEWPDF=true"
Due to an oversight in the code to preserve text rendering modes
pdfwrite was falling back to rendering text to bitmaps in some cases.
This was especially a problem with text in text rendering mode 3
because that doesn't make any marks on the page, snd so we ended
up discarding the text altogether.
This commit adds the TEXT_RETURN_WIDTH flag to the text operation
which means pdfwrite will properly process the text. This shows
two differences in our automated tests. Firstly a file which has
an invalid sized glyph (point size > 1,000,000) which worked
with the old code simply because we did not embed the font. The
new PDF interpreter does embed the font (which is a separate bug)
and that causes an error to be thrown.
Because our testing runs with -dPDFSTOPONERROR that means content
goes missing. If we don't set that flag then it all renders
correctly. I'm choosing to ignore the problem for those reasons
and the fact that the original PDF ifle is broken.
Secondly a file that had stopped throwing an error with the new
PDF interpreter goes back to throwing an error, now that we are
not discarding the text. Again, this is a separate bug (which I
will open a report for shortly) and is not a change in behaviour
wrt the old PDF interpreter so I'm choosing to ignore it with
this commit.
Diffstat (limited to 'doc/thirdparty.htm')
0 files changed, 0 insertions, 0 deletions