[anatolykoptev]

What does this change?

Documents with Cyrillic, Greek, or Latin letters outside Latin-1 (Polish, Czech, Turkish, Vietnamese, …) come out of DOCX / Markdown / TXT / HTML / XLSX / PPTX / HWPX → PDF with overlapping letters. The cause is in rhwp: its built-in width tables are generated only for ASCII, Latin-1, general punctuation, math, CJK symbols, Hangul and the fullwidth forms, so every other letter is placed at a fixed half em while its glyph is drawn at full width. Reported upstream as edwardkim/rhwp#8143.

Measured with rhwp 0.8.7 (Filee 2.0.0, macOS), Arial in every slot, advance per glyph:

glyph  rhwp em  Arial em
 О      0.500    0.778
 П      0.500    0.719
 Т      0.500    0.611
 т      0.500    0.458
 ż ę ź Š  0.50 each

This PR treats that like the existing complex-shaping case, but softer:

• ITextShapingCheck now answers both questions from one scan of the source text (ScanScripts → TextScripts(NeedsShaping, WithoutWidths)).
• WithoutWidths is derived from rhwp's measured ranges instead of a list of scripts: a letter or combining mark outside those ranges and outside the full-width CJK rhwp estimates at an em. Latin-1-only Western European text, Korean, Chinese and Japanese are not affected. Variation selectors (emoji ❤️, IVS) are ignored, and character references outside Unicode are skipped.
• JobQueue: such a file takes a route without the Unshaped edge when one exists (LibreOffice). Otherwise it keeps rhwp and converts. It is never refused. Shaping scripts keep precedence and their behaviour is unchanged.
• docs/ENGINES.md and the comments describe the rule.

Policy point for you to decide: one such letter anywhere in the scanned text sends the whole document to LibreOffice. That includes a stray Greek μ (U+03BC) or a French œ in an otherwise Latin-1 document. This matches how the shaping check treats one Arabic letter, and rhwp really does draw those letters at a half em. Happy to add a threshold if you prefer.

How was it tested?

• dotnet format --verify-no-changes
• dotnet test: Filee.Core.Tests 456 passed / 2 skipped (main: 454 / 2). Filee.Engines.Tests filtered to ComplexScript|Rhwp: 59 passed / 1 skipped. I did not run the full Engines suite locally, so I'm relying on CI for it.
• Tried it with the CLI on macOS (arm64), rhwp 0.8.7 and LibreOffice 26.8 installed:
  • Russian DOCX → PDF: LibreOffice. Cyrillic advances match Arial within ±0.004 em.
  • Polish / Czech / Turkish / Vietnamese Markdown: LibreOffice.
  • French / German / Spanish (é ü ß ñ only), Korean, and text with ✔️ ❤️: rhwp, as before.
• Each new test was checked against a production mutation that turns it red:
  • Disabling the new JobQueue branch → Text_the_engine_cannot_measure_takes_another_route_but_is_never_refused.
  • Letting the widths branch win over shaping → Text_with_shaping_and_unmeasured_scripts_is_refused_for_shaping.
  • Pretending rhwp measures Latin Extended-A → Scripts_without_widths_are_found_in_documents.
  • A path-keyed scan cache → A_file_is_scanned_again_once_its_text_changed.
  • Dropping the out-of-range guard → A_character_reference_outside_unicode_is_skipped.
  • Dropping the variation-selector exclusion → Variation_selectors_are_not_unmeasured_text.

Not in this PR, noticed on macOS: RhwpFonts.Plan replaces a font that is installed but unusable, but not one that is missing. On a Mac without Malgun Gothic, Filee-written HWPX text falls back to rhwp's own pick (Apple SD Gothic Neo). That's cosmetic next to the width issue.

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files (none added)
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md (none added)

🤖 Generated with Claude Code

[KnifeLemon]

Thank you @anatolykoptev, this is a great find and a careful fix. I reproduced it locally with only rhwp installed: Russian, Polish and Greek Markdown → PDF overlap exactly as you describe ("Отчёт", "ОПТ", "Αναφορά"), and with your branch they go through LibreOffice and come out right. Deriving the rule from rhwp’s measured ranges rather than a script list, keeping shaping first, never refusing for widths, and the variation-selector and out-of-range reference cases are all spot on. Format, build, Core (455) and the ComplexScript/Rhwp/HWPX engine tests (108) pass here.

On your policy question, one case matters a lot to us: Korean HWPX documents. A Korean report or paper with a single "α", "Ω" or "μ" now goes to LibreOffice + H2Orestart instead of rhwp, which is our most faithful HWP renderer. I checked it: a lone Greek letter between spaces draws fine in rhwp, while the LibreOffice page comes out with different margins. We’ll make two small changes on your branch before merging, unless you’d like to do them:

• Don’t reroute an .hwpx source for widths (shaping stays as it is).
• Count an unmeasured letter only when it touches another letter (inside a word), so Russian/Polish/Vietnamese words still reroute but single symbols and units (α, Ω, μ) stay with rhwp. That also covers the stray "μ"/”œ” case you mentioned.

Also a heads-up: #351 adds an .xls branch to ComplexScripts.FindInFile that calls Find(cell.Text). Once both are in, it has to use the classifier, otherwise .xls sheets skip the widths check. We’ll take care of that when merging.

CI for fork runs is waiting for approval; we’ll start it together with the change. Thanks again!

[KnifeLemon]

Thanks again @anatolykoptev! I pushed the two changes we talked about: an HWPX stays with rhwp for missing widths, and only letters inside words count (an extended Latin letter next to any letter, another script's letter next to one of its own), so α, Ω or μm in a Korean report keep rhwp while Russian, Greek, Polish and Vietnamese words still reroute. Tests for both are in. Merging.