RusDox preserves Unicode text, meaningful image descriptions, and document language metadata across its supported authoring paths. Those guarantees are machine-tested. They are not a claim that every script is fully laid out or that the current PDF is an accessible tagged document.
Support decision
Latin text is supported. Arabic/right-to-left, Hebrew, CJK, and emoji remain experimental in the native PDF renderer. The checked-in international fixture passes semantic DOCX reopen, PDF text projection, language metadata, and the deterministic Linux page baseline, but RusDox does not yet implement:
- the Unicode bidirectional algorithm and contextual Arabic shaping;
- CJK kinsoku line-breaking rules or a pinned representative CJK font profile;
- color or ZWJ emoji composition;
- a dated review in representative Word, LibreOffice, Preview, and Acrobat versions for these script combinations.
compatibility/international-readiness.json is the executable graduation gate. A track cannot change from experimental to supported while any required gate is false. This intentionally prevents a green semantic round-trip from being presented as typographic parity.
Font embedding and fallback contract
DOCX stores the requested family names and lets the reader choose an installed font when those families are absent. RusDox does not embed fonts in DOCX, so Word or LibreOffice substitution can change line breaks and pagination.
The native PDF path resolves the requested family, common sans/serif/mono fallbacks, and then script-specific Arabic, Hebrew, CJK, or Devanagari fallbacks. It admits only single-face outline TrueType fonts for which OpenType reports installable, preview-and-print, or editable embedding permission. Restricted fonts and fonts that forbid outline embedding are rejected. The admitted font program is embedded in full and accompanied by a Unicode map.
Parity evidence records, for every font used:
- the resolved family and PostScript name;
- the OpenType embedding permission;
- the number of mapped Unicode characters;
- every character that fell back to the font's missing-glyph box.
This is a technical permission check, not a font licence grant. Distributors must confirm that their selected font licence permits the intended embedding and redistribution. Production deployments that need reproducible pagination must pin and licence an explicit font set in the container or host image; system font discovery is intentionally outside cross-machine byte parity.
Alternative text and language
Every visual block must provide non-blank alt_text. RusDox writes the same description to both relevant DOCX drawing-property locations, reopens it, and compares it with the source and PDF semantic projection in the image_alt_text parity check. Decorative-image semantics are not yet exposed; authors should describe the visual's purpose, not its file name.
metadata.language accepts a bounded BCP 47-style language tag such as en-US, fr, or mul. It is written as dc:language in DOCX core properties and /Lang in the PDF catalog. The document_language parity check compares the source, reopened DOCX, PDF projection, and rendered PDF evidence. Documents that intentionally mix languages can use mul; future run-level language changes will require their own contract.
The current PDF records image descriptions in its semantic projection, but it does not attach them to a PDF structure tree. Assistive technology therefore cannot consume those descriptions as tagged figure alternatives. See the PDF conformance research before making any PDF accessibility or archival claim.
Accessibility parity boundary
The 21-check parity report adds two explicit accessibility-oriented assertions:
image_alt_textpasses when every visual has identical meaningful text in the source, reopened DOCX, and PDF projection; it skips when there are no visuals;document_languagepasses when all four representations agree; it skips when the author did not declare a language.
These checks prevent metadata loss. They do not replace keyboard, screen-reader, reading-order, contrast, or representative-viewer review. Tagged PDF and PDF/A remain separate, unclaimed conformance projects.
Graduation checklist
RTL or CJK can become supported only after the implementation adds the missing layout algorithm, representative licensed font profiles, deterministic parity fixtures, and dated viewer evidence, then every machine-readable graduation gate passes. Tagged PDF requires the separate structure, validation, and human assistive-technology work described in the research note.