It seems that text selection / highlighting improperly applies "word spacing," e.g. after a non-0x20 CID that is just mapped to U+0020 via a ToUnicode CMap. This causes a discrepancy in the actual rendered text and a glyph's highlight / selection box.

Inversely, the text selection calculation might also NOT apply word spacing where it should.

In more detail:

Section "9.3.3 Word spacing" of the PDF spec says: "Word spacing shall be applied to every occurrence of the single-byte character code 32 in a string when using a simple font (including Type 3) or a composite font that defines code 32 as a single-byte code. It shall not apply to occurrences of the byte value 32 in multiple-byte codes."

This behavior appears to be followed by PDF.js's text rendering / layout operations, but not by the text highlight / selection layer.

See attached sample file and screenshots. First, "bad word spacing - 0x0003 to U+0020.pdf" demonstrates a Type0 font and a 3-character Tj op ("A<SPACE>A"), with a set word spacing of 50 units. The word spacing is not applied in the rendering, because the <SPACE> character actually uses \x0003 and is only mapped to space via a ToUnicode CMap. However, the word spacing is applied by the text selection / highlight calculation for the highlight boxes.

The second example file "bad word spacing - single byte font with 0x20 = A.pdf" shows the opposite effect. The single byte code 0x20 is mapped to \A, but should still have the word spacing applied. The word spacing is applied to the visible glyphs but not the highlights.

Extra note: There is a bug with the uservoice editing feature - I previously submitted this issue and then tried to edit later and add an attachment, but the entire post disappeared entirely.