[tlmcguire]

For a code inside a bfrange with a string destination, Decode added the offset to the last byte of the destination only. Any range that crosses a byte boundary decodes wrongly. The common case is the identity map <0000> <FFFF> <0000>, which go-pdf/fpdf writes for UTF-8 fonts: U+2022 • decodes as " and U+0141 Ł as A.

The fix adds the full offset to the destination, carrying across bytes.

Test plan:

• Added TestCmapDecodeBFRangeCarry, which fails on master and passes with this change.
• go test ./... passes.
• Checked against a PDF generated by fpdf with an embedded UTF-8 font.

[neupenguin]

This fixes text extraction for PDFs written by go-pdf/fpdf with AddUTF8Font (Identity-H, single-range bfrange ToUnicode maps). We tested a report with Thai, Chinese and Japanese text, read with Page.GetPlainText:

	ทดสอบ / ภาษาไทย	检查 / 数据库连接池耗尽	確認 / データベース	Latin
5959a4027728 (2025-05-11)	not found	not found	not found	found
6c8c28e0e8a0 (current master)	not found	not found	not found	found
this PR (4e1f3a8729)	found	found	found	found

On master, every rune above U+00FF comes back as its low byte. pdf.js and MuPDF read the same files correctly, and with this PR the output matches theirs. We also checked two files master already reads correctly, a Chromium-printed Thai PDF and a Latin-only fpdf report, and both still read the same with this PR.

We'd move to this as soon as it's merged. Thanks!

[tlmcguire]

Thank you for the additional testing @neupenguin ! I'm glad to see confirmation of my fix.

[ledongthuc]

looks good