From 70b5755a7c686fa1c8b293b43bd5d544a93d7646 Mon Sep 17 00:00:00 2001 From: mtlcl410 Date: Sun, 8 Nov 2026 13:38:41 +0800 Subject: [PATCH] M1: the numbered glyph name notes name the public readers only (create.text-extraction) Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01Pq7HyCHD1R3rywQBPCHXZA --- crates/render/src/text/tests.rs | 2 +- vendor/hayro-interpret/src/font/mod.rs | 4 ++-- vendor/hayro-interpret/src/font/type1.rs | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/crates/render/src/text/tests.rs b/crates/render/src/text/tests.rs index c0fef11e99..ee50e70da7 100644 --- a/crates/render/src/text/tests.rs +++ b/crates/render/src/text/tests.rs @@ -499,7 +499,7 @@ fn glyph_names_outside_the_glyph_list_still_read_as_text() { /// A glyph name that only numbers its glyph, with no `/ToUnicode` (ISO 32000-2 §9.10.2 has no /// route for it), reads as its code's Latin-1 character when the number is that very code, in /// decimal (`C70` at 70, `C0071` at 71, `MT72` at 72, `C39` at 39, `C174` at 174) or -/// hexadecimal (`G49` at 0x49, `GE9` at 0xE9), as pdftotext, PDFium, MuPDF and Acrobat read +/// hexadecimal (`G49` at 0x49, `GE9` at 0xE9), as pdftotext, PDFium and MuPDF read /// it: Windows printer drivers and typesetters name subset glyphs so. A control character /// (`C9` at 9) still reads as nothing. Only in a font where every numbered name names its own /// code: one more name numbering another code (`/C1` at 233, review on #3239) turns the whole diff --git a/vendor/hayro-interpret/src/font/mod.rs b/vendor/hayro-interpret/src/font/mod.rs index 0e5fc80715..2c2315e10a 100644 --- a/vendor/hayro-interpret/src/font/mod.rs +++ b/vendor/hayro-interpret/src/font/mod.rs @@ -771,8 +771,8 @@ pub(crate) fn numbered_names_name_their_codes<'a>( /// PdfCraft patch: the text of a glyph name outside the glyph list that only numbers its glyph /// (see `glyph_name_numbers`) when that number is the very code the glyph is shown with: the -/// code's Latin-1 character, for codes above 127 too (`C174` reads `®`), as pdftotext, PDFium, -/// MuPDF and Acrobat read it. The name and the code then agree, so nothing is guessed from an +/// code's Latin-1 character, for codes above 127 too (`C174` reads `®`), as pdftotext, PDFium +/// and MuPDF read it. The name and the code then agree, so nothing is guessed from an /// encoding table. A number naming another code (`/C1` at 233, review on #3239) and a control /// character read as nothing. Callers apply it only in a font where /// `numbered_names_name_their_codes` holds. diff --git a/vendor/hayro-interpret/src/font/type1.rs b/vendor/hayro-interpret/src/font/type1.rs index 64cb1759a7..366dd45311 100644 --- a/vendor/hayro-interpret/src/font/type1.rs +++ b/vendor/hayro-interpret/src/font/type1.rs @@ -143,7 +143,7 @@ impl Type1Font { // glyph list specification's full mapping (`f_i`, `hyphen.case`). A name that only // numbers the glyph (`C39`, `c251`) reads as the code's Latin-1 character only when its // number is that code (`C39` at 39) and every numbered name in the font names its own - // code, as pdftotext, PDFium, MuPDF and Acrobat read it. Anywhere else the number is no + // code, as pdftotext, PDFium and MuPDF read it. Anywhere else the number is no // evidence and reads as nothing: the code's StandardEncoding character would be a // guess, wrong wherever the font's /Encoding puts the glyph elsewhere (review on #3239). let name = self.code_to_ps_name(code)?;