mirror of https://github.com/storytold/pdfcraft.git synced 2026-10-26 11:08:48 -06:00

Files

T

Sameh ElhawaryandClaude Opus 5.5 d30bb111db M14: Arabic and Hebrew file names render in the tab strip, recent files and Properties (#285 )

A tab named in Arabic showed replacement boxes: no interface font had the
glyphs, and egui joins the letters of a right-to-left word but places the
runs in logical order.

- Fonts: the interface takes `Arab` faces from the craft-fonts build input
  (also on wasm), and on desktop adds one font already installed on the
  machine as the last fallback of every family. It is read at runtime, never
  embedded; PDFCRAFT_SYSTEM_FONTS=0 turns it off and `cargo xtask screenshots`
  sets that. AGENTS.md §1.4 records the rule.
- Order: bidi::visual puts single-line text in display order with a
  left-to-right base, used for the painted tab label and hover text, the
  recent-files name and path, and the Properties File and Location rows.
  Accessibility names keep the logical text.

misc.rtl-ui stays planned: multi-line text, text input and a mirrored layout
are not done.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-08 10:46:58 -04:00

src

M14: Arabic and Hebrew file names render in the tab strip, recent files and Properties (#285 )

2026-10-08 10:46:58 -04:00

build.rs

M14: Arabic and Hebrew file names render in the tab strip, recent files and Properties (#285 )

2026-10-08 10:46:58 -04:00

Cargo.toml

Rename PrintCraft to PdfCraft (#174 )

2026-10-07 16:03:57 -04:00

README.md

M14: Arabic and Hebrew file names render in the tab strip, recent files and Properties (#285 )

2026-10-08 10:46:58 -04:00

README.md

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), and literal to 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: the Jpan faces for the interface, BIZ UDPGothic first.
ui_chinese_fonts: the Hans faces 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: the Arab faces for Arabic-script interface text (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_glyph returns GlyphError::NoFont and the editor reports a clear error.
SHIPPORI_MINCHO: Shippori Mincho's bytes, or None.

wasm32 builds embed only BIZ UDPGothic Regular and any Arab 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.