f1af1e2e79
Add text, headers/footers and watermarks wrote every character outside
WinAnsiEncoding as `?` and reported success. They now refuse it with a
specific error ("the standard fonts can't draw "中" (U+4E2D) ...") before
changing anything, as the maintainer asked on #327. Form fields and
text-box comments are unchanged (they keep the value).
- fonts: win_ansi_encodable / first_non_win_ansi, defined through
win_ansi itself so a fuller table widens them too; the edited-text
Type 3 decision uses the same check (same character set as before).
- edit: one drawable() check, fed the lines exactly as each tool draws
them, so a CR that would become `?` is refused and CRLF in headers is not.
- ui: the Add-text editor keeps such text open with an inline warning.
Done, a click elsewhere or a double-click on another item don't take
or replace it; it counts as unsaved work; Save stops and shows it; a
deleted page takes its draft with it.
- Arabic (#403): one public check, first_undrawable, follows the drawing:
Arabic shaped with the craft-fonts face is drawable, and only what's left
to the standard font counts. Without the face, #403 still decides for the
Arabic letters (new items refused with what's missing, existing ones stay
movable), but nothing else in the item may become `?`. The editor uses
the same check, cached per draft.
- #403's odd_arabic_text_never_panics: its U+2029/U+0085 input, which was
drawn as `?`, now expects a refusal naming the character.
- The warning is translated (fr, ru, zh-hans, zh-hant, es, ja, bg, de); the
catalogs' SHA-256 entries in ATTRIBUTION.toml are updated.
Claude-Session: https://claude.ai/code/session_01VNJqS2dEQawHJn1qTRJiKp
Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
pdfcraft-fonts
Layer L2. Font helpers for the appearance streams PdfCraft generates (comments, form fields).
Today it holds what generated appearances need without a font program:
helvetica_width: an approximation of Helvetica's proportions by character class. No metrics file or font program from any vendor is bundled; widths are PdfCraft's own estimates, good enough for line breaking and alignment, not for typesetting.wrap: greedy line breaking with that measure (paragraphs on newlines, long words split).win_ansi: Unicode → WinAnsiEncoding bytes (?for characters it can't represent), andliteralto write bytes as a PDF literal string.
It also holds the fonts of the optional craft-fonts
build input. build.rs embeds them as CRAFT_FONTS when the build sets
CRAFT_FONTS_DIR=<checkout> (and fails if it can't while CRAFT_FONTS_REQUIRED=1, as releases
set). Without that variable CRAFT_FONTS is empty and everything below copes:
ui_japanese_fonts: theJpanfaces for the interface, BIZ UDPGothic first.ui_chinese_fonts: theHansfaces for the interface, in manifest order (without one, Chinese characters the Japanese faces lack show the replacement glyph).ui_cjk_fonts(prefer_hans): both in fallback order for the UI language (Chinese group first in Chinese mode, so one line never mixes faces with different vertical metrics).ui_arabic_fonts: theArabfaces for Arabic-script interface text (file names, document titles), in manifest order.ui_telugu_fonts: theTelufaces for Telugu interface text (the Telugu catalog, file names, document titles), in manifest order.document_japanese_font/japanese_glyph: the face (Shippori Mincho, then BIZ UDMincho) whose outlines become the Type 3 fallback font for Japanese text written into PDFs. Without it,japanese_glyphreturnsGlyphError::NoFontand the editor reports a clear error.document_japanese_font_for_style/japanese_glyph_from: select and draw a real Japanese fallback face for edited text. Sans sources prefer BIZ UDPGothic Regular/Bold; serif sources keep Mincho. Type 3 paths and advances both come from that selected face. Missing weights fall back to a real Regular face, never synthetic bold; no italic face is supplied. The defaultdocument_japanese_font/japanese_glyphAPIs still use regular document Mincho.document_arabic_font/shape_arabic/arabic_glyph: the firstArabface, shaped with harfrust (joining forms, ligatures, mark positions) into clusters for Arabic text written into PDFs; the editor draws each cluster as one Type 3 glyph with a ToUnicode entry. Without the face they returnGlyphError::NoFontand the editor reports a clear error.document_japanese_fonts_for_style: everyJpanface in that order of preference, so the editor can use the first one that has all of the replacement's glyphs (the faces differ in coverage, e.g. of Cyrillic).SHIPPORI_MINCHO: Shippori Mincho's bytes, orNone.
Generated Japanese Type 3 fonts record the fallback face's family and style in an indirect
FontDescriptor. pdf::Metrics::base_font uses its FontName when the Type 3 dictionary has
no BaseFont, so text inspection and edit-tool results identify the fallback after save/reopen.
The descriptor does not change glyph programs or replace the Type 3 FontBBox metrics when
Ascent/Descent are omitted (PDF Reference 1.7, tables 5.9 and 5.19). The small web input has
only Gothic Regular, so it cannot preserve bold. No new font assets or changes to that input are
needed.
wasm32 builds embed only BIZ UDPGothic Regular and any Arab or Telu face, to keep the web build small: the web build
currently has no Chinese face, so Chinese there still shows the replacement glyph.
Font files are never
committed here (AGENTS.md §1.4; team members: craftrules standards/fonts.md, internal).
The full font subsystem (parsing, shaping, subsetting and embedding) arrives with M2.2/M7.