GhostPDF - Sanitize Doc info strings for linearisation

Bug #706078 "PDF write and FastWebView produces broken PDFs"

The initial problem with this bug is that pdfi was just copying the
strings from the Document Info dictionary verbatim. Technically there's
nothing wrong with that, but the linearisation code in pdfwrite expects
that strings will not contain a NULL (0x00) character, and UTF-16BE
strings can do.

The old code wrote characters outside the ASCII range as octal so we
now do the same, both for preserving document info and for strings
presented via a DOCINFO pdfmark.

At the same time....

Noticed that we were incorrectly expecting a /Limits entry in the
root node of a Names tree, which is invalid. Fix that. This wasn't
causing a problem but it was throwing a spurious warning.

The function pdfi_pdfmark_modA() wasn't dealing with the case where a
named destination pointed directly at an Action array instead of a
dictionary with a /D key.

0 files changed, 0 insertions, 0 deletions