Skip to content
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

Feature Request: Large Type Pieces (Unicode 16.0) #709

Closed
PhMajerus opened this issue Jan 16, 2024 · 1 comment · Fixed by #723
Closed

Feature Request: Large Type Pieces (Unicode 16.0) #709

PhMajerus opened this issue Jan 16, 2024 · 1 comment · Fixed by #723

Comments

@PhMajerus
Copy link
Contributor

PhMajerus commented Jan 16, 2024

Description of the new feature

Back in the 1970's, terminals were expensive high-tech pieces of equipment. Several manufacturers competed to provide more features and justify paying more for a terminal than we pay for a microcomputer today.
One of the high-end terminal was the Hewlett-Packard 2640 Series. It had lot of advanced features and tricks to improve the visual quality and flexibility, including the ability to add characters ROMs to support other alphabets, mathematical symbols, and semigraphics.

Everybody knows the Box Drawings set of characters to create tables and UI elements in text terminals, but HP went further, they decided to design a 64 extended characters ROM especially to display large characters.
This isn't some width or height doubling control code like the DECDHL, but more like FIGlet, using normal-sized characters as pieces of a larger glyph. But unlike FIGlet, the idea was to design pieces of large characters that would fit together perfectly when composed in a grid instead of reusing existing characters.

image

They do not force the whole line to be double-size, instead they can just be composed in the original 80×25 grid by using 3×3 semigraphic characters for each large letter.

image

We're now 50 years later, and terminal emulators are rediscovering and catching up to the advanced features those devices had.
In January 2022, Unicode approved a new set of legacy computing characters, that includes those Large Type Pieces, to be part of Unicode 16.0.

As they are inherited from those terminal devices back when competition was pushing interesting new features, those Symbols for Legacy Computing characters are highly interesting to improve modern terminal emulators as well. The proposal was even originally named "Terminals Supplement".

Proposed technical implementation details

Adding support for the large character set does not require any new features in terminals, all it requires is to add 55 new characters to the font (U+1CE1A to U+1CE50). They work similarly to box drawings and block elements, joining seamlessly when placed next to each other.

image

Even better, those characters are not limited to the terminal, as they are purely characters-based, they make it possible to use large text in any plain-text file, including readme, source code comments, social network posts, …
The pieces are also designed as a font pieces system, so they can be combined to create other characters.

image
Note the Visual Studio editor leaves an extra gap between lines, so they don't join vertically, but that's the same as with box drawings and block elements characters. Also, this screenshot uses an older set of glyphs

Easy support to compose large characters can be provided using existing software tools such as FIGlet:

image

CUI apps can also easily take advantage of them as they are simple characters.

As you can guess from these screenshots, I'm not really asking for the Cascadia team to provide those characters, I've been working on them already and am happy to submit them. I'm mostly looking for comments and suggestions, and to document the feature to go along with a future pull request.

Finally, the large characters can be further improved using ligatures to handle common horizontal combinations. For example, the following screenshot is similar to the one above, but using ligatures to round letters:
image
(This is still a work in progress, some other improvements will still be added)

Large Type Pieces can also complement DECDHL and DECDWL to provide a 3rd heading size:
image
(This can be tested with the following command line: echo 8Jy4nMKg8Jy4nMKgwqDCoMKgwqDwnLic8Jy4o8KgwqDCoMKgwqDCoPCcuKzwnLimwqDCoPCcuJrwnLil8Jy4nMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoPCcuJ7wnLig8Jy4pcKgwqDCoMKgwqDCoMKgwqDwnLib8Jy4n/CcuKTwnLijwqDCoMKgwqDCoMKgwqDCoPCcuJ7wnLikCvCcuKjwnLif8Jy4tvCcuJrwnLik8Jy4nvCcuKTwnLia8Jy4tvCcuJzwnLib8Jy4pPCcuJrwnLinwqDCoMKg8Jy4qcKgwqDwnLipwqDwnLipwqDCoPCcuJ7wnLik8Jy4mvCcuKXwnLia8Jy4p/CcuJrwnLikwqDCoMKg8Jy4qcKg8Jy4nPCcuJzwnLib8Jy4pPCcuJrwnLikwqDCoPCcuKjwnLif8Jy5g/CcuJzwnLia8Jy4pPCcuJrwnLil8Jy4mvCcuKTwnLia8Jy4pcKg8Jy4qQrwnLi8wqDwnLi88Jy4vvCcuKXwnLi+8Jy5hPCcuL7wnLmE8Jy4vPCcuLzwnLi88Jy4vvCcuLbCoMKg8Jy4nvCcuYDwnLilwqDwnLi+8Jy4pfCcuL3wnLif8Jy4pfCcuL7wnLmE8Jy4vMKg8Jy4vvCcuLbwnLi+8Jy4pcKgwqDCoPCcuLzCoPCcuL7wnLi28Jy4qPCcuYPwnLi+8Jy4pcKgwqDwnLi8wqDCoPCcuLzwnLi+8Jy4pfCcuL7wnLil8Jy4vvCcuKXwnLie8Jy5g/CcuJ7wnLmDCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoPCcuJ7wnLmDwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg8Jy4nvCcuYPCoMKgwqDCoMKgwqDCoPCcuJ7wnLmD8Jy5kMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgChsjM0hlYWRpbmcgMiAoREVDREhMKQobIzRIZWFkaW5nIDIgKERFQ0RITCkKChsjNkhlYWRpbmcgMyAoREVDRFdMKQoKTm9ybWFsCgo= | base64 -d)

Let me know what you think!

@PhMajerus
Copy link
Contributor Author

PhMajerus commented Apr 10, 2024

Here's a comparison between Iosevka Term, which uses the Unicode reference design, and my Cascadia design.

Iosevka:

image

Cascadia:

image

Iosevka follows the Unicode reference design, while my design for Cascadia uses rounded instead of bevelled/chamfered corners, the center piece of 7, and K have also been slightly rounded. The horizontal crossbar of the diagonal piece used as the center of Z was also removed, because it can never connect to anything, and Cascadia's 'Z' doesn't have a crossbar either.
Note also the Q stem that diverge from its reference design to make it more reminiscent of Cascadia's Q.
Finally, the connection of diagonals have been adjusted to create perfectly straight diagonal lines, which wasn't the case with the reference design:

Iosevka:

image

Cascadia:

image

DHowett pushed a commit that referenced this issue Apr 23, 2024
…extants, segmented digits, and large type pieces (#723)

## New diagonals, octants, sedecimants & eights, separated quadrants &
sextants, segmented digits, and large type pieces (Symbols for Legacy
Computing)

- Added diagonals `U+1FB3C` - `U+1FB67`
- Added octants (2×4 mosaics) `U+1CD00` - `U+1CDE5`
- Added sedecimants (4×4 mosaics) `U+1CE90` - `U+1CEAF`
- Added eights (8×8 patterns) `U+1FB70` - `U+1FB80`, `U+1FB82` -
`U+1FB8B`
- Added misc. blocks `U+1FB97`, `U+1FBCE`, `U+1FBCF`
- Added separated quadrants (2×2) `U+1CC21` - `U+1CC2F`
- Added separated sextants (2×3) `U+1CE51` - `U+1CE8F`
- Added segmented digits (LED/LCD display style) `U+1CCF0` - `U+1CCF9`
- Added large type pieces (see #709) `U+1CE1A` - `U+1CE50`

This 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::@NotSpace` list of
non-italic fonts, except for the segmented digits, which have been added
to `@Digit` instead of `@NotSpace`.

The segmented digits `U+1CCF0` - `U+1CCF9` are based on their original
Atari ST design and Unicode reference design, with the bounding box and
segments widths adjusted to fit the `H` character, and spaces between
the 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 `Q` stem `U+1CE45`, where I tried to make it more
reminiscent of Cascadia's `Q` design.

More details and screenshots of the large type pieces are available in
issue #709.

Finally, `U+1FB97` is the same pattern as `U+1CDB7`, they have different
origins, 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.

* Continues #708 
* Improves #715 (does not close it, but greatly improves coverage)
* Improves #597 (does not close it, but greatly improves coverage)
* Closes #711
* Closes #709

Co-authored-by: Philippe Majerus <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant