# Google soft-wrap duplication repair Normal and lite Google/Gemma/Gemini fonts no longer duplicate words in the tested browser reproductions. Recompile existing Google fonts to receive the fix. The [live specimen](../rendering-limits.html) ships rebuilt fonts in both modes. ## Cause and fix A ligature for a leading-space token inherited the space's cluster. Chromium could paint the word on both sides of a soft line break. The compiler now leaves that whitespace cluster as a zero-width, inkless mark and transfers the merged state to the following text. Later merges ignore only the compiler's synthetic marks, retaining the tokenizer's merge paths and token advances. Each dependency batch runs through exact pair contexts. Epoch-specific contexts guard shared single/ligature helpers so reusing an intermediate glyph slot cannot invoke another epoch's transition. Bounded Format 1 contexts and larger pair-only ligature chunks avoid compatibility padding and 16-bit offset overflows. The full font has 5,973 lookups and 7,505 subtables, below the existing engine limit; no vocabulary reduction or limit increase is involved. ## Verification - Fresh normal and lite builds: all 5,493 original Gutenberg chunks match exact reference IDs and every 3-em token advance; 341,367 tokens per mode, no errors and no differences between modes. All 415,570 reachable merge paths retained. - 19 focused Gemma tests cover ordinary compilation, Noto/Mutant emoji, whitespace cluster ink, TKSP 0/250/500, slot reuse, correlated pair contexts, ignored marks, first-match priority, class-zero coverage and packing boundaries. The separate ideographic-space regression also passes. - Independent exhaustive/directed fixture audit: 6,248 actual HarfBuzz checks against the tokenizer, normal/lite, including spaces, tabs, line feeds, transferred states and phrase merges. - In-app Chromium, 24px font: original “Oh, to be a fly…” sample at 320px, earlier “little door” sample at 180px, and ten copies of the internal-space token `>