GhostPDF - spot errors in hex strings in fonts/CMaps

This was inspired by OSS-fuzz bug #55443, the PDF file has a CMap which
is corrupted, a hex string defining an entry in the CMap has some
garbage inserted into it.

This causes the CMap to have an extremely large range, which takes a
very long time to work through. Short-circuiting this by detecting the
error in the hex string makes the file complete much more quickly. Since
the CMap is corrupted the result is always going to be incorrect anyway
and at least this way we stop processing it more quickly.

Because CMaps and fonts use the same parser, this then exhibited an
error with a lot of fonts, particularly the PostScript emitted by
ps2write. It turns out that the eexec encrypted portion of the font has
rubbish following the 'currentfile closefile' and in some cases this
included an opening hex string marker '<' followed by non-hex data.

Obviously we shouldn't be processing that, I think we're lucky to have
got away with it to date. To fix the problem, create an operator for
fonts to deal with the 'closefile', and have that consume all the
remaining data in the buffer.

0 files changed, 0 insertions, 0 deletions