mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-28 03:58:45 -06:00
432d3172d4
A PDF that embeds the complete TrueType/OpenType program of a simple WinAnsi font can only encode 256 characters through that font, but the program usually has many more glyphs. Typing one the encoding lacks (ő, or Arabic in a face that has it) ignored the program: the edit went to the Type 3 fallback, so official builds drew the character with the Japanese face's Latin glyph, and builds without craft-fonts refused it with "this text needs PdfCraft's Japanese fallback font", even for a Latin letter. The row editor now looks at the paragraph font's own program after the source encoding, same-face resources and matching craft-fonts faces, and before the fallback. When it has the glyph, the program is embedded once per edit as a Unicode Type 0 font (the same embedding a loaded font gets), so the new character keeps the source face. A paragraph whose new characters only that program can draw takes the row editor's path. The program is used only when: - the font is not a subset (no `ABCDEF+` tag), since a subsetter can keep a character's mapping after dropping its outline; - `validate` accepts it, which includes the OS/2 fsType check, so a font licensed for preview & print or restricted embedding is not reused for editable text. When no face has a non-Japanese character, the error now names it and points to Load font / Installed fonts; Japanese text keeps its message. Tests: Inter embedded as a simple WinAnsi TrueType font, edited in a one-row paragraph (the single-style path) and in a row of a two-row one, draws ő from a Type 0 font whose program is Inter's bytes, with no Type 3 font and the word read back whole. The same program under a subset name is not used, and without craft-fonts the edit fails, naming "ő (U+0151)", and leaves the page unchanged. Both fail without this change. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com>