Repository navigation
Conversation
Previous positions 15/38/62/85 had: - intra-cell row spacing: 23-24% per gap - inter-cell row spacing: (100-85) + 15 = 30% per gap That 6-7% disproportion produced a visible horizontal stripe between adjacent rows of Braille — the column of Braille cells read as discrete rows instead of a continuous grid. New positions 12.5/37.5/62.5/87.5 give uniform 25% spacing both within a cell and across cells, so a column of full-dot Braille cells flows as a single uniform grid with no visible row break. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous radius (0.07em) gave a 14% dot diameter relative to the 1em cell height, leaving an 11% visible gap between adjacent dots vertically (with the new 25% uniform center-to-center spacing from the prior commit). Bumped radius to 0.125em (= 25% diameter, exactly the center-to- center spacing) so adjacent dots just touch vertically. The 0.01em soft-transition zone is preserved (transparent transition at 0.135em). Visual effect: a column of full-dot Braille cells now reads as a solid vertical strip of touching dots, with no visible row-break stripe. Horizontal spacing between left and right column dots is unchanged (still 50% center-to-center), so dots in a row remain visually distinct as paired left/right columns. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Revert the radius bump from a485679 (user wants normal-sized dots, not bigger ones) and instead shift dot positions further apart vertically — pushing the top and bottom rows close to cell edges. New positions: y = 5%, 35%, 65%, 95% - intra-cell row spacing: 30% per gap - inter-cell row spacing: (100-95) + 5 = 10% per gap Intra-cell is now wider but each cell still has dots. Inter-cell is much narrower so the "empty stripe" between rows of cells visually shrinks. Spacing is no longer perfectly uniform, but the visible row- break gap is reduced from 25% → 10%, which is the actual perceived issue ("the inter-cell area looks emptier than the intra-cell area"). Dot radius stays at 0.07em (no bigger dots). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous edge-near positions (5/35/65/95) reduced the inter-cell gap to ~1.66px but still left a visible thin stripe between rows because the painted dots didn't quite reach the cell boundary. Pinning the top and bottom rows at y=0% and y=100% places the dot centres exactly on the cell edges. The radial-gradient only paints within the inline-block's bounds, so a y=0% dot shows just its bottom half, and a y=100% dot shows just its top half. When two cells stack vertically, the top-half from cell N+1's top dot and the bottom-half from cell N's bottom dot share the cell boundary line and together form one complete dot straddling the join — no visible gap between rows by construction. Intra-cell spacing grows from 30% to 33.33% per gap; visually the in-cell dot grid is now perfectly evenly spaced. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…te gap" This reverts commit 93cc8b6.
Cells previously had uniform 50% horizontal dot spacing both within and between cells, making adjacent Braille glyphs blur together horizontally. Moving the dot columns inward to x=27%/73% makes: - intra-cell horizontal spacing: 46% - inter-cell horizontal spacing: 54% The 8% asymmetry produces a faintly perceptible cell-boundary so adjacent Braille characters can be distinguished without obvious gaps that would break the contiguous-grid feel. Cell width stays at 1ch so Braille remains aligned with surrounding text. Only the dot positions within each cell change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
_parse_header_color() accepted both 3-hex and 6-hex values for #!bg=/#!fg= headers, inconsistent with the 3-hex-only inline `Fxxx`/`Bxxx` colour tokens. Also removes README and example references to the `FTxxxxxx`/`BTxxxxxx` 24-bit inline extension, which was actually dropped from the parser back in v1.0.2.
# Conflicts: # CHANGELOG.md
Dev's tip was going unverified between pushes and promotion to main since ci.yml only triggered on main push/PR. security.yml stays main+PR-only per the dev-branch workflow's guidance that heavier scans can wait for the promotion gate.
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
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.
Summary
#!bg=/#!fg=header colours to 3-hex, matching the inlineFxxx/Bxxxformat (previously accepted 6-hex too)FTxxxxxx/BTxxxxxx24-bit inline colour format, which was actually dropped from the parser in v1.0.2ci.ymlon pushes todev(previously main/PR-only, so dev's tip went unverified until promotion)Test plan
pytest— 51 passed locally and in CI on dev