-
Notifications
You must be signed in to change notification settings - Fork 806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjusting half-blocks, quadrants,... coordinates to unify mosaics #727
Conversation
This update adjusts the points coordinates of some previously existing blocks/mosaics characters to fit them in the same grid as used by octants and eights. This is required because the new octants and eights from Symbols for Legacy Computing do not duplicate existing patterns and expect those existing one to join perfectly with them to provide the whole set of all possible pseudopixels mosaics. blocks: ------- U+00A0 : nbspace : already correct (empty) U+2588 : fullBlock & fullBlock.stypo : already correct (used as reference bounding rectangle for all pseudopixels mosaics) half-blocks: ------------ U+2580 : upperHalfBlock & upperHalfBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+2584 : lowerHalfBlock & lowerHalfBlock.stypo : already correct (confirming upperHalfBlock y=50% was wrong) U+258C : leftBlock & leftBlock.stypo : already correct U+2590 : rightBlock & rightBlock.stypo : already correct Quadrants: ---------- U+2596 : lowerLeftBlock & lowerLeftBlock.stypo : already correct (confirming all other corrections above and below) U+2597 : lowerRightBlock & lowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+2598 : upperLeftBlock & upperLeftBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+2599 : upperLeftAndLowerLeftAndLowerRightBlock & upperLeftAndLowerLeftAndLowerRightBlock.stypo : already correct U+259A : upperLeftAndLowerRightBlock & upperLeftAndLowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+259B : upperLeftAndUpperRightAndLowerLeftBlock & upperLeftAndUpperRightAndLowerLeftBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+259C : upperLeftAndUpperRightAndLowerRightBlock & upperLeftAndUpperRightAndLowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+259D : upperRightBlock & upperRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo) U+259E : upperRightAndLowerLeftBlock & upperRightAndLowerLeftBlock.stypo : Some y=50% fixed from 707 to 873 (gdi) and 710 (stypo), some were already correct U+259F : upperRightAndLowerLeftAndLowerRightBlock & upperRightAndLowerLeftAndLowerRightBlock.stypo : already correct Octants: -------- U+2582 : lowerOneQuarterBlock & lowerOneQuarterBlock.stypo : already correct U+2586 : lowerThreeQuartersBlock & lowerThreeQuartersBlock.stypo : already correct Eights: ------- U+2581 : lowerOneEighthBlock & lowerOneEighthBlock.stypo : gdi was correct, y fixed from -183 to -182 (rounding unification for all Eights) for stypo U+2583 : lowerThreeEighthsBlock & lowerThreeEighthsBlock.stypo : y fixed from 534 to 535 (rounding unification for all Eights) for GDI, stypo was correct U+2587 : lowerSevenEighthsBlock & lowerSevenEighthsBlock.stypo : y fixed from 1887 to 1888 (rounding unification for all Eights) for GDI, stypo was correct U+2594 : upperOneEighthBlock & upperOneEighthBlock.stypo : y fixed from 1887 to 1888 (rounding unification for all Eights) for GDI, stypo was correct U+1FB83 : upperThreeEighthsBlock & upperThreeEighthsBlock.stypo : already correct (part of my previous PR, so already based on correct grid) U+1FB86 : upperSevenEighthsBlock & upperSevenEighthsBlock.stypo : already correct (part of my previous PR, so already based on correct grid)
Would you be able to give this a shot in Windows GVIM? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
That looks suspiciously like the older coordinates, feels like a caching issue to me. |
Actually, switching back to the old version the block glyphs get shorter. I wonder if the rclt/stypo switch is being compiled wrong (ala #721) |
I adjusted the coordinates of both normal and stypo versions, so whichever is used, it may be taller or shorter than expected if it messes up the substitution, but it cannot have the lower and higher pseudo-pixels of The rclt substitution work for all my sextants, octants, etc..., and I checked some of the problematic characters and they were in the rclt of I'm testing now after just changing the code point for one of the problematic characters without changing its name, so hopefully I'll be able to see if they get substituted properly in Terminal when it's not part of the known classic block elements. |
To your other questions in the main thread - Terminal Preview DXEngine used to scale block elements, and Atlas used to cut them off. Now DXEngine is dead, and as of 1.21 Atlas doesn't do any clipping. If you leave |
The one thing that could think of is if there is some legacy hinting based on the previous outline that forces it to use the previous coordinates when snapping to pixels. |
@lhecker You may be the expert @PhMajerus needs here |
Yeah, I didn't dare to summon him, but I figured he'd be the one I need 😆 |
For gvim, I just installed the wrong binary out of my build output folder. GAH. |
Yeah, I didn't want to sound too confident, but that sounded like the most plausible explanation 😉 |
Oh, I have another demo file you might enjoy: |
As it turns out this API is "at fault": https://learn.microsoft.com/en-us/windows/win32/api/dwrite_1/nf-dwrite_1-idwritetextanalyzer1-gettextcomplexity |
Nah, it looks like it is in gsub. We'll figure it out! Anyway, I'm merging this since it is correct. Thanks all for playing! |
@lhecker Thanks for looking into it. FYI, more experiments explained in #644 seem to indicate that DWrite selects the non-stypo version of these glyphs which explains why they are taller than they should. This also means that if you stretch/squash them according to Anyway, that seems to confirm that the best is for the font to use the proper coordinates, and then find a way for AtlasEngine to find a way to handle them correctly. At least then the pseudo-pixels will align perfectly, while if we keep the previous coordinates for the base block element characters, they don't align perfectly today and won't either when AtlasEngine achieve the goal. |
Thanks! Glad this could then be used to help test the future improvements in AtlasEngine. |
This update adds support for: - Unicode 16 Large Type Pieces (they are really cool, you *have* to see them) - Unicode 13 Sextants (U+1FB00 - U+1FB3B) - Octants, sedecimants, eights, miscellanrous blocks, separated quadrants and sextants, and diagonals - Segmented digits (think LED numbers) - Checkerboards It also fixes the coordinate system used in all of the blocks, half-blocks, quadrants and eights for consistency. This update does **not** include the new "Nerd Fonts" variant of Cascadia Code or Cascadia Mono. With big thanks to @PhMajerus for contributing all of the new symbols for legacy computing. See microsoft/cascadia-code#723, microsoft/cascadia-code#708 and microsoft/cascadia-code#727 for more details.
This update adds support for: - Unicode 16 Large Type Pieces (they are really cool, you *have* to see them) - Unicode 13 Sextants (U+1FB00 - U+1FB3B) - Octants, sedecimants, eights, miscellanrous blocks, separated quadrants and sextants, and diagonals - Segmented digits (think LED numbers) - Checkerboards It also fixes the coordinate system used in all of the blocks, half-blocks, quadrants and eights for consistency. This update does **not** include the new "Nerd Fonts" variant of Cascadia Code or Cascadia Mono. With big thanks to @PhMajerus for contributing all of the new symbols for legacy computing. See microsoft/cascadia-code#723, microsoft/cascadia-code#708 and microsoft/cascadia-code#727 for more details. (cherry picked from commit 41bb28c) Service-Card-Id: 92434844 Service-Version: 1.19
This update adds support for: - Unicode 16 Large Type Pieces (they are really cool, you *have* to see them) - Unicode 13 Sextants (U+1FB00 - U+1FB3B) - Octants, sedecimants, eights, miscellanrous blocks, separated quadrants and sextants, and diagonals - Segmented digits (think LED numbers) - Checkerboards It also fixes the coordinate system used in all of the blocks, half-blocks, quadrants and eights for consistency. This update does **not** include the new "Nerd Fonts" variant of Cascadia Code or Cascadia Mono. With big thanks to @PhMajerus for contributing all of the new symbols for legacy computing. See microsoft/cascadia-code#723, microsoft/cascadia-code#708 and microsoft/cascadia-code#727 for more details. (cherry picked from commit 41bb28c) Service-Card-Id: 92434845 Service-Version: 1.20
This update adjusts the points coordinates of some previously existing blocks/mosaics characters to fit them in the same grid as used by octants and eights.
This is required because the new octants and eights from Symbols for Legacy Computing do not duplicate existing patterns and expect those existing one to join perfectly with them to provide the whole set of all possible pseudopixels mosaics.
Description of the Pull Request
This update verifies and adjusts the existing characters that are now required to join seamlessly with the extended pseudo-pixels mosaics introduced with the symbols for legacy computing.
Some of the existing characters were not proper mosaics, most notably
▞
, where the two black rectangles overlap because they don't use the same y coordinates.This shouldn't happen as all the mosaics are supposed to fit precisely on a unified grid.
Only a few characters required adjustments, but this PR also documents all the glyphs that have been checked to ensure alignments of all the mosaic characters.
BLOCKS:
U+00A0
nbspace : already correctU+2588
fullBlock & fullBlock.stypo : already correct (used as reference bounding rectangle for all pseudopixels mosaics)HALF-BLOCKS:
U+2580
upperHalfBlock & upperHalfBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+2584
lowerHalfBlock & lowerHalfBlock.stypo : already correct (confirming upperHalfBlock y=50% was wrong)U+258C
leftBlock & leftBlock.stypo : already correctU+2590
rightBlock & rightBlock.stypo : already correctQUADRANTS:
U+2596
lowerLeftBlock & lowerLeftBlock.stypo : already correct (confirming all other corrections above and below)U+2597
lowerRightBlock & lowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+2598
upperLeftBlock & upperLeftBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+2599
upperLeftAndLowerLeftAndLowerRightBlock & upperLeftAndLowerLeftAndLowerRightBlock.stypo : already correctU+259A
upperLeftAndLowerRightBlock & upperLeftAndLowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+259B
upperLeftAndUpperRightAndLowerLeftBlock & upperLeftAndUpperRightAndLowerLeftBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+259C
upperLeftAndUpperRightAndLowerRightBlock & upperLeftAndUpperRightAndLowerRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+259D
upperRightBlock & upperRightBlock.stypo : y=50% fixed from 707 to 873 (gdi) and 710 (stypo)U+259E
upperRightAndLowerLeftBlock & upperRightAndLowerLeftBlock.stypo : Some y=50% fixed from 707 to 873 (gdi) and 710 (stypo), some were already correctU+259F
upperRightAndLowerLeftAndLowerRightBlock & upperRightAndLowerLeftAndLowerRightBlock.stypo : already correctOCTANTS:
U+2582
lowerOneQuarterBlock & lowerOneQuarterBlock.stypo : already correctU+2586
lowerThreeQuartersBlock & lowerThreeQuartersBlock.stypo : already correctEIGHTS:
U+2581
lowerOneEighthBlock & lowerOneEighthBlock.stypo : gdi was correct, y fixed from -183 to -182 (rounding unification for all Eights) for stypoU+2583
lowerThreeEighthsBlock & lowerThreeEighthsBlock.stypo : y fixed from 534 to 535 (rounding unification for all Eights) for GDI, stypo was correctU+2585
lowerFiveEighthsBlock & lowerFiveEighthsBlock.stypo : already correctU+2587
lowerSevenEighthsBlock & lowerSevenEighthsBlock.stypo : y fixed from 1887 to 1888 (rounding unification for all Eights) for GDI, stypo was correctU+2594
upperOneEighthBlock & upperOneEighthBlock.stypo : y fixed from 1887 to 1888 (rounding unification for all Eights) for GDI, stypo was correctU+1FB83
upperThreeEighthsBlock & upperThreeEighthsBlock.stypo : from my PR #723U+1FB86
upperSevenEighthsBlock & upperSevenEighthsBlock.stypo : from my PR #723U+2589
leftSevenEighthsBlock & leftSevenEighthsBlock.stypo : already correctU+258A
leftThreeQuartersBlock & leftThreeQuartersBlock.stypo : already correctU+258B
leftFiveEighthsBlock & leftFiveEighthsBlock.stypo : already correctU+258D
leftThreeEighthsBlock & leftThreeEighthsBlock.stypo : already correctU+258E
leftOneQuarterBlock & leftOneQuarterBlock.stypo : already correctU+258F
leftOneEighthBlock & leftOneEighthBlock.stypo : already correctU+2595
rightOneEighthBlock & rightOneEighthBlock.stypo : already correctU+1FB87
rightOneQuarterBlock & rightOneQuarterBlock.stypo : from my PR #723U+1FB88
rightThreeEighthsBlock & rightThreeEighthsBlock.stypo : from my PR #723U+1FB89
rightFiveEighthsBlock & rightFiveEighthsBlock.stypo : from my PR #723U+1FB8A
rightThreeQuartersBlock & rightThreeQuartersBlock.stypo : from my PR #723U+1FB8B
rightSevenEighthsBlock & rightSevenEighthsBlock.stypo : from my PR #723References
This fixes the inconsistent alignments problem explained in issue #644, and ensures unified grid coordinates with PR #708 and #723.
PR Checklist
Validation Steps Performed
Based on purely mathematical grid coordinates already used for octants, checked visually in VTT, Terminal Preview 1.20.10822.0 and Canary 1.21.240424002-llm, and Visual Studio editor.
Note there is another related issue that impacts some of those characters, but this PR at least provides the correct glyphs and improves the situation. I believe the remaining alignment issue to be a problem in Terminal itself as it works perfectly in Visual Studio editor, and the original Cascadia Mono 2111.001 exhibits the same issue. More details about this in #644.
Having the proper coordinates at least ensures they won't induce in error someone trying to fix the Terminal rendering and expecting the alignments to work with a font using inconsistent glyphs coordinates. A believe this PR to be a step in the right direction.