Rendered output duplicates individual letters. The text itself is correct, so this is somewhere in shaping or glyph emission rather than in parsing.
What it looks like
From the generated letter sample, which is in the repo and in the hash baselines:
Suite 400 renders as SSuite 400
enthusiasm renders as eenthusiasm
financial renders as fifinancial
detection renders as ddetection
your renders as yyour
cycle renders as ccycle
allocated renders as allocatedd
I hit the same thing in an unrelated test document, where Latin stays Latin: Hello world rendered as Latin stays LLatin: Hello wworld.
Where it is not
rdocx text on the same file returns the correct string, and the source w:t is correct. So parsing, the model and text extraction are all fine. It only shows up once glyphs are positioned.
A hint worth following
financial becoming fifinancial is the interesting one. fi is a ligature in most of the fonts here, so the shaper emits one glyph for two characters. Every other example is a single letter, but if the underlying problem is a mismatch between glyph indices and character indices then a ligature is exactly where it would show up most visibly.
That points at the mapping between shaped glyphs and their source characters, or at the per-glyph advance handling that walks alongside it. I have not chased it further than that.
Why it matters more than it looks
This is in the checked-in samples, so it is currently baked into the hash baselines. Any fix will show up as an output delta on letter and probably contract, and that delta is the fix rather than a regression.
It is also the most visible remaining defect in rendered output now that the image, shape, list and CJK issues are closed.
Reproduce
cargo run --example generate_all_samples
then look at samples/letter.png.
Rendered output duplicates individual letters. The text itself is correct, so this is somewhere in shaping or glyph emission rather than in parsing.
What it looks like
From the generated
lettersample, which is in the repo and in the hash baselines:Suite 400renders asSSuite 400enthusiasmrenders aseenthusiasmfinancialrenders asfifinancialdetectionrenders asddetectionyourrenders asyyourcyclerenders asccycleallocatedrenders asallocateddI hit the same thing in an unrelated test document, where
Latin stays Latin: Hello worldrendered asLatin stays LLatin: Hello wworld.Where it is not
rdocx texton the same file returns the correct string, and the sourcew:tis correct. So parsing, the model and text extraction are all fine. It only shows up once glyphs are positioned.A hint worth following
financialbecomingfifinancialis the interesting one.fiis a ligature in most of the fonts here, so the shaper emits one glyph for two characters. Every other example is a single letter, but if the underlying problem is a mismatch between glyph indices and character indices then a ligature is exactly where it would show up most visibly.That points at the mapping between shaped glyphs and their source characters, or at the per-glyph advance handling that walks alongside it. I have not chased it further than that.
Why it matters more than it looks
This is in the checked-in samples, so it is currently baked into the hash baselines. Any fix will show up as an output delta on
letterand probablycontract, and that delta is the fix rather than a regression.It is also the most visible remaining defect in rendered output now that the image, shape, list and CJK issues are closed.
Reproduce
then look at
samples/letter.png.