New diagonals, octants, sedecimants & eights, separated quadrants & sextants, segmented digits, and large type pieces #723
Conversation
This file contains 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
(diagonals, octants, sedecimants & eights, separated quadrants & sextants, segmented digits, and large type pieces) - Added diagonals U+1FB3C - U+1FB67 (Symbols for Legacy Computing). - Added octants U+1CD00 - U+1CDE5 (Symbols for Legacy Computing). - Added sedecimants U+1CE90 - U+1CEAF (Symbols for Legacy Computing). - Added eights U+1FB70 - U+1FB80, U+1FB82 - U+1FB8B (Symbols for Legacy Computing). - Added misc. blocks U+1FB97, U+1FBCE, U+1FBCF (Symbols for Legacy Computing). - Added separated quadrants U+1CC21 - U+1CC2F (Symbols for Legacy Computing). - Added separated sextants U+1CE51 - U+1CE8F (Symbols for Legacy Computing). - Added segmented digits U+1CCF0 - U+1CCF9 (Symbols for Legacy Computing). - Added large type pieces U+1CE1A - U+1CE50 (Symbols for Legacy Computing). Note this update does not modify any existing character, I'm only adding new ones.
DHowett
approved these changes
Apr 10, 2024
There was a problem hiding this comment.
I can sign off on everything except the stylistic choices - I love all of it! Thanks! /cc @aaronbell for the rest
|
@PhMajerus I split your PR body into a commit message and a comment (since commit messages can't have images); comment follows Summary of the Pull Request
Here are some of the characters added by this pull request:
PR Checklist
Detailed Description of the Pull Request / Additional commentsHere is the list of the glyphs added by this PR: Many of the glyphs are pure geometric shapes with no artistic liberty at all, they simply follow the unified grid and handle both GDI and DWrite ("stypo") variants. All the glyphs have been added to the The segmented digits The Large Type Pieces are based on their original HP 2640 Series terminals design and Unicode reference design, but I took liberties to reinterpret the pieces to make them more rounded and, I believe, more in line with the Cascadia Code design. Finally, |
|
Thanks @DHowett ! Here is a file to As well as a FIGlet font that makes using the large type pieces easy:
I haven't decided how to publish those yet, but figured you may want some more test files. |
|
THIS IS SO GOOD I legitimately wonder if the HowTo file should be in this repo, as a sample or a doc. :O |
|
@DHowett I realized I posted the wrong FIGfont. Download it again to get the proper one that uses large type pieces. Sorry about that. |
|
@aaronbell poke! I didn't want to merge this without your explicit signoff on the artistic direction (e.g. using curves instead of angles for the large type pieces) and thewhether the legacy computing digits should be considered digits qua digits, or just nonspacing characters. |
(This week has been a total bust. Will take a look) |
Ugh, sorry about that! |
|
FWIW, since we are preparing a servicing update for Windows Terminal 1.19/20/21 I'm going to cut a release of it mid-week. I will merge without Aaron's approval late Tuesday under the assumption that we're A-OK to launch :) |
|
Hey, I'm sorry. It has been a rough week. So I'm generally fine with how these things are designed. Personally, I'd probably round some of the curved elements more to make the transitions render more smoothly, buuuuut when I open the UFOs locally in Glyphs, it is requesting that I update the positioning of things (because Glyphs' functionality has updated) and I don't really want to potentially mess with the font right now. Would it be alright to leave it as is for now, and I'll make some modifications with the next version? |
|
I wanted to have them even more rounded and achieve the following look: But remember these are made up of pieces, so the middle horizontal bar has to be straight because it can be used to join two sharp corners or two rounded corners (or any other combination): Take the 'B' for example: This is the most I could achieve having the rounding only in the top right corner piece, which is literally just an arc joining the two straight lines it may connect to: The only solution I could find to round it more is to use ligatures, which then replaces sequences of two or three pieces horizontally with one designed to make the arc reach the middle of the central pieces:
Notice how the arcs are not the same between the exploded view and the combined view anymore. The ligatures trick works pretty well, and I could achieve the look I aimed for without having them break other combinations (I'm testing with a FIGfont containing over 1000 characters built using large type pieces covering latin, greek, cyrillic, japanese katakana, ...). Here are the ligatures I worked on so far: I also tested some other pieces sequences, but these ended up either making it worse, or inconsistent with some other letters using the same combinations in a row: So yeah, I agree with you more rounded looks even better, and I started working on it using ligatures, but I figured we need a no-ligatures version first as a baseline for Cascadia Mono and then we need ligatures to only improve them without changing the style completely for Cascadia Code. I also didn't know if you'd want to have that many ligatures just to improve the look of the large type: And there is a problem when using these ligatures in Windows Terminal, I suspect they round up the starting x position of each character, so when my ligatures group three characters into a wider one, they don't always align correctly with other rows at certain sizes: So I didn't want to make it look worse in some scenario. If you want to try out my ligatures experiments, here is a version of Cascadia Code that includes them: |
|
Thanks for the additional information! I think let’s just keep it simple for now and we can revisit it the future. |
No need to apologize - I didn't mean to put on any undue pressure. I hope your next week is an improvement on the last one 🙂 |
|
new release coming? 👀 |
|
😉 |
5 tasks
DHowett
pushed a commit
that referenced
this pull request
Apr 26, 2024
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. 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 correct `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+2585` lowerFiveEighthsBlock & lowerFiveEighthsBlock.stypo : already 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 : from my PR #723 `U+1FB86` upperSevenEighthsBlock & upperSevenEighthsBlock.stypo : from my PR #723 `U+2589` leftSevenEighthsBlock & leftSevenEighthsBlock.stypo : already correct `U+258A` leftThreeQuartersBlock & leftThreeQuartersBlock.stypo : already correct `U+258B` leftFiveEighthsBlock & leftFiveEighthsBlock.stypo : already correct `U+258D` leftThreeEighthsBlock & leftThreeEighthsBlock.stypo : already correct `U+258E` leftOneQuarterBlock & leftOneQuarterBlock.stypo : already correct `U+258F` leftOneEighthBlock & leftOneEighthBlock.stypo : already correct `U+2595` rightOneEighthBlock & rightOneEighthBlock.stypo : already correct `U+1FB87` rightOneQuarterBlock & rightOneQuarterBlock.stypo : from my PR #723 `U+1FB88` rightThreeEighthsBlock & rightThreeEighthsBlock.stypo : from my PR #723 `U+1FB89` rightFiveEighthsBlock & rightFiveEighthsBlock.stypo : from my PR #723 `U+1FB8A` rightThreeQuartersBlock & rightThreeQuartersBlock.stypo : from my PR #723 `U+1FB8B` rightSevenEighthsBlock & rightSevenEighthsBlock.stypo : from my PR #723 This fixes the inconsistent alignments problem explained in issue #644, and ensures unified grid coordinates with PR #708 and #723. ## 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. Closes #644 Co-authored-by: Philippe Majerus <phm@live.com>
DHowett
added a commit
to microsoft/terminal
that referenced
this pull request
Apr 26, 2024
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.
DHowett
added a commit
to microsoft/terminal
that referenced
this pull request
Apr 26, 2024
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
DHowett
added a commit
to microsoft/terminal
that referenced
this pull request
Apr 26, 2024
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
2 tasks
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.
New diagonals, octants, sedecimants & eights, separated quadrants & sextants, segmented digits, and large type pieces (Symbols for Legacy Computing)
U+1FB3C-U+1FB67U+1CD00-U+1CDE5U+1CE90-U+1CEAFU+1FB70-U+1FB80,U+1FB82-U+1FB8BU+1FB97,U+1FBCE,U+1FBCFU+1CC21-U+1CC2FU+1CE51-U+1CE8FU+1FBF0-U+1FBF9U+1CE1A-U+1CE50This update does not modify any existing character, it is only adding
new characters from the Symbols for Legacy Computing blocks (original
and supplement). These characters use the same unified coordinates as
my previous #708 submission. It continues the sextants with diagonal
fills that meet the sextants corners, adds octants, most of the 8×8
pixels-based lines and fills (sedecimants & eights), as well as the
separated mosaics, segmented digits, and large type pieces. Some
existing mosaic characters are not perfectly aligned on the same grid,
and it would be best to adjust them to fit the unified grid as well, but
that is not part of this PR, and I guess we won't have the time to do
that for the next release.
Note it does not complete the original Symbols for Legacy Computing
block yet, as it does not include the extra lines/box-drawing
characters, shaded mosaics, MouseText, and some other specific symbols.
The focus has been on completing the mosaics part, including the ones
coming in Unicode 16.0, and the Large Type Pieces.
This one is quite big, containing almost all the glyphs I've been
working on at once. This is to meet the short deadline for the next
release of Cascadia Code, as discussed with @aaronbell. It contains 948
glyphs for 479 characters.
Many of the glyphs are pure geometric shapes with no artistic liberty at
all, they simply follow the unified grid and handle both GDI and DWrite
("stypo") variants.
All the glyphs have been added to the
features.fea::@NotSpacelist ofnon-italic fonts, except for the segmented digits, which have been added
to
@Digitinstead of@NotSpace.The segmented digits
U+1FBF0-U+1FBF9are based on their originalAtari ST design and Unicode reference design, with the bounding box and
segments widths adjusted to fit the
Hcharacter, and spaces betweenthe segments large enough to be visible even at 12pt on 100% DPI.
The Large Type Pieces are based on their original HP 2640 Series
terminals design and Unicode reference design, but I took liberties to
reinterpret the pieces to make them more rounded and, I believe, more in
line with the Cascadia Code design. Note the Unicode reference design
is somewhat wrong as their diagonals do not join perfectly, while my
version takes great care to support all the combinations alignments with
straight diagonal lines. The only piece where more artistic liberty is
available is the
QstemU+1CE45, where I tried to make it morereminiscent of Cascadia's
Qdesign.More details and screenshots of the large type pieces are available in
issue #709.
Finally,
U+1FB97is the same pattern asU+1CDB7, they have differentorigins, but I'm not sure why Unicode repeated it for octants instead of
reusing the existing one as they did for some other existing pattern. I
included them as separate glyphs as well.
Edit: Corrected the codepoints for segmented digits from U+1CCxx to U+1FBxx.