rioterm: shape attached combining marks with their base glyph - #1850
Closed
raphamorim wants to merge 1 commit into
Closed
raphamorim wants to merge 1 commit into
raphamorim wants to merge 1 commit into
Conversation
The emit loop hashed a cell's zerowidth codepoints into the run-cache key but only ever pushed the base char into the shaping buffer, so a combining sequence rendered as its bare base: e + U+0301 drew as e. Marks now shape with their base on both platforms. The glyph-to-cell walk moves to explicit per-cell starts everywhere (UTF-16 units on macOS, byte offsets on swash) since the swash path's per-char cursor assumed one char per cell. VS15/VS16 stay out of the buffer, matching the hash: presentation is already resolved into font_id, and a selector fed to a text font only produces a notdef. Kitty placeholder cells are excluded; their zerowidth carries image-slice coordinates, not text.
Owner
Author
|
Folded into the consolidated unicode-foundation PR (all four workstream-0 pieces in one branch for testability, commits preserved). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Workstream 0c of the mode-2027 scoping — a standalone rendering bug fix that ships on its own.
The bug
build_row_fghashes a cell's attachedzerowidthcodepoints into the run-cache key (soe+U+0301 ande+U+0302 don't alias) but never put them in the shaping buffer — only the base char was pushed. Every combining sequence in the grid renders as its bare base character: decomposedédraws ase, Devanagari conjuncts lose their matras, etc.The fix
emit_preedit_clusterin rioterm: render the IME composition inline at the cursor #1849 already does this for IME text; this brings grid text to parity).char_indices()assuming one char per cell — with marks in the buffer that cursor would misattribute every following glyph. macOS already used a cell-starts table; the two walks now share one implementation (run_cell_starts: UTF-16 units on macOS, byte offsets on swash — swash reportscluster.source.startas byte offsets).hash_combining: presentation is already resolved intofont_id, and feeding a variation selector to a text font's shaper only yields a notdef.zerowidthencodes image-slice coordinates, not text.Verification
174 rioterm tests pass (two new: shaping-buffer layout incl. selector skipping, and the cell-starts attribution walk). Clippy/fmt clean. The swash side compiles only on non-macOS — the ubuntu CI leg is the verifier for that path (local cross-checks are blocked by native build scripts). Visual check:
echo -e 'éx'should renderéx, notex.