mirror of
https://github.com/mozilla/pdf.js.git
synced 2026-07-07 15:45:48 +02:00
2bbf32d83d
encodeString has the same surrogate-pair guard that encodeToXmlString had before #21526: `unicode > 0xd7ff && (unicode < 0xe000 || unicode > 0xfffd)`. That predicate is also true for U+FFFE and U+FFFF, which are single UTF-16 code units, not surrogate pairs. The extra `i++` then steps over the character that follows them, so it is silently dropped from the font-encoded output used when saving or printing a PDF. For example, encoding a string that is U+FFFF followed by "A", with a font that has a glyph for both, returns an encoded result ending in "A" on this branch but drops the "A" on master. Same fix as #21526: the correct test for a real surrogate pair is `unicode > 0xffff`, since codePointAt only returns a value at or above 0x10000 for an actual pair. This keeps existing behavior for real surrogate pairs (e.g. emoji) and the U+FFFD boundary, and only stops the character after U+FFFE/U+FFFF from being dropped. Added test/unit/fonts_spec.js, since Font.prototype.encodeString had no direct unit test. It calls the method on a minimal fake `this` (only toUnicode/cMap are read), since building a full Font requires a complete properties/font-file setup that this bug doesn't depend on.