You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: strip invalid UTF-8 characters of any length, not just sequences
The non-ocr path in drawChar() only tested sequences longer than one
character, so a single invalid character was emitted verbatim and could
make the ALTO output non-well-formed. Ported from the stale branch
bugfix/utf8-invalid-characters_placeholder; that branch's -ocr ->
-placeholder rename is obsolete here, since -ocr now means "emit an OCR
sidecar" rather than "substitute placeholders".
isUTF8() encoded the sequence through the UTF-8 UnicodeMap and then
re-parsed the resulting bytes. That round trip was redundant: mapUTF8()
encodes each codepoint independently and well-formed by construction, so
the only input it can render invalid is an unpaired surrogate, and
codepoints above U+10FFFF encode to zero bytes and so were, and still
are, reported as valid. Replaced with the equivalent integer test,
verified against the old scan over every codepoint U+0000..U+10FFFF and
over multi-character sequences. This also drops a GString that leaked on
all nine of the old function's return paths, which matters now that the
function runs once per character rather than only for uLen > 1.
Verified on a 14-PDF corpus: the isUTF8 rewrite alone is byte-identical
to the previous output, and neither strip path fires on any of those
documents, so the guard fix is latent until a document carries a lone
surrogate.
// Check the sequence is valid whatever its length: a single invalid
9721
+
// character needs a placeholder just as much as a multi-char one.
9721
9722
//&& globalParams->getApplyOCR())
9722
9723
// as a first iteration for dictionnaries, placing a placeholder, which means creating a map based on the font-code mapping to unicode from : https://unicode.org/charts/PDF/U2B00.pdf
0 commit comments