Add support for custom box drawing and powerline glyphs #16729

lhecker · 2024-02-17T00:05:49Z

This adds support for drawing our own box drawing, block element,
and basic Powerline (U+E0Bx) glyphs in AtlasEngine.

This PR consists of 4 parts:

AtlasEngine was refactored to simplify _drawGlyph because I've
wanted to do that for ~1 year now and never got a chance.
Well, now I'm doing it and you all will review it muahahaha.
The good news is that it removes a goto usage that even for my
standards was rather dangerous. Now it's gone and the risk with it.
AtlasEngine was further refactored to properly parse out text that
we want to handle different from regular text. Previously, we only
did that for soft fonts, but now we want to do that for a lot more,
so a refactor was in order. The new code is still extremely
disgusting, because I now stuff wchar_ts into an array that's
intended for glyph indices, but that's the best way to make it fast
and not blow up the complexity of the code even further.
Finally this adds a huge LUT for all the aforementioned glyphs.
The LUT has 4 "drawing instruction" entries per glyph which describe
the shape (rectangle, circle, lines, etc.) and the start/end coord.
With a lot of bit packing each entry is only 4 bytes large.
Finally-finally a builtinGlyphs setting was added to the font
object and it defaults to true.

Closes #5897

Validation Steps Performed

RenderingTests with soft fonts ✅
All the aforementioned glyphs ✅
...with color ✅
customGlyphs setting can be toggled on and off ✅

lhecker · 2024-02-17T00:08:01Z

(Note: The look of 3 block shading glyphs was further improved in #16760)

src/renderer/atlas/CustomGlyphs.cpp

tusharsnx · 2024-02-18T17:27:29Z

Getting Cut off at the bottom, or is it just the screenshot 🤔

lhecker · 2024-02-19T23:22:15Z

I think it gets cut off. It's probably due to rounding errors. I'm also not 100% sure that my math is completely correct.

src/renderer/atlas/CustomGlyphs.cpp

src/cascadia/TerminalSettingsEditor/Appearances.xaml

DHowett · 2024-02-20T17:04:17Z

src/cascadia/TerminalSettingsModel/MTSMSettings.h

@@ -115,6 +115,7 @@ Author(s):
    X(winrt::Windows::UI::Text::FontWeight, FontWeight, "weight", DEFAULT_FONT_WEIGHT) \
    X(IFontAxesMap, FontAxes, "axes")                                                  \
    X(IFontFeatureMap, FontFeatures, "features")                                       \
+    X(bool, CustomGlyphs, "customGlyphs", true)                                        \


We may want to call this compatibility.integratedDrawingGlyphs or something - IMO and of course open to discussion!

Alternatively we could call them "integrated pseudographics" or "builtin semigraphics". apparently those (pseudo/semigraphics) are names for these glyphs

Feature label: Built-in Glyphs
Help text: "Use built-in glyphs for BoxDrawing, BlockElement and Powerline characters"

I think this fits well with the future plan where we would draw them even when the font itself may not come with any of those glyphs (Eg. unpatched fonts)

I'm mostly worried about the JSON name - where there is no help text and "glyphs" is awfully broad (there are a looooottt of glyphs in a font!)

I'm opposed to renaming this setting for 2 reasons:

wezterm calls it custom_block_glyphs

VS Code calls it terminal.integrated.customGlyphs

So while I agree that we should call it "integrated glyphs" I think consistency with other applications is more important to make it easier for users to find related settings in related applications.

FWIW that's for "vscode's integrated terminal", not for "integrated custom glyphs"

That's fair, however.

In case you're still considering other names, I think both Alacritty and Contour use something like builtin_box_drawing for this option (as a sub setting of the font configuration).

DHowett

reviewed 27/28 (still have BackendD3D to go!)

DHowett · 2024-02-20T18:26:17Z

src/inc/til/unicode.h

+    {
+        // Ah, I love these bracketed C-style casts. I use them in C all the time. Yep.
+#pragma warning(suppress : 26493) // Don't use C-style casts (type.4).
+        return (char32_t{ lead } << 10) - 0x35FDC00 + char32_t{ trail };


but i love it as long as it works

It's not too bad actually if you search for 0x35FDC00 on the interwebz. You'll find tons of results of this exact pattern. :)

DHowett · 2024-02-20T18:30:30Z

src/renderer/atlas/AtlasEngine.cpp

+    const auto base = reinterpret_cast<const u16*>(_api.bufferLine.data());
+    const auto len = offEnd - offBeg;
+
+    row.glyphIndices.insert(row.glyphIndices.end(), base + offBeg, base + offEnd);


I don't totally understand what this means for glyph indices. What are we storing for normal characters? What are we storing for box drawing ones?

I'll add a comment. For "custom" glyphs we store the UTF16 code units in the glyph indices array. The reason I do this as opposed to using a 2nd array is so that the hashmap handling code is simpler in BackendD3D.

At some point my hope is to move the DWrite handling into the 2 backends. That way there won't be any rows and no glyphIndices anymore because we'll write the QuadInstances directly into the buffer as we're shaping the text. That way this ugliness will also be gone.

src/renderer/inc/FontInfoDesired.hpp

DHowett · 2024-02-20T23:16:07Z

src/renderer/atlas/AtlasEngine.h

+        // The proper solution is to move text shaping into the backends.
+        // Someone just needs to write a generic "TextBuffer to DWRITE_GLYPH_RUN" function.
+        bool _hackWantsCustomGlyphs = true;
+        bool _hackTriggerRedrawAll = false;


sorry for yor beautiful architecture

DHowett · 2024-02-21T21:41:31Z

nit: reword the commit title to be in imperative form (e.g. it can complete the sentence, "This commit will ...")

DHowett · 2024-02-22T17:06:43Z

Hey @PhMajerus, you might be interested in this! The screenshot of all glyphs above is a bit outdated, since we've fixed the double/single intersections, but other than that this is ready to go in.

Wondered if you had thoughts/concerns as an ANSI artist :)

DHowett · 2024-02-22T18:07:57Z

PhMajerus · 2024-02-22T18:57:21Z

Hey @DHowett, thanks for including me in the discussion. I'm not really an ANSI artist, more of an 8-bit nostalgic, but I do have some comments about your approach.

While I understand the reason to try to get away from font glyphs, I'm concerned about all the other block-sized characters that should be supported in the future.
The box drawing and block elements you decided to render are only a tiny fraction of all the characters that need to fill their cell and join seamlessly.
We have sextants, octants, triangles, and semicircles, lot of patterns inherited from legacy 8×8 pixels character sets, and they all need to join precisely with each other.
That means you have over 400 other pseudopixels glyphs, and I didn't even count all the mosaic patterns from legacy computers yet.

Here are just a few:

For the box drawing, there are at least 69 more connecting lines, angles, and diagonals.

And even if you decided to custom-draw all those, if you ever plan to support really all legacy scenarios, such as less common characters ROM found in some terminals and 8-bit computers, you'll have even more characters that need to join with those and each other, think about MouseText elements from the Apple II for example.
All of these will be standardized in Unicode 16.0, and more may be coming later.

Now imagine you did the work to custom-draw all of those, then you'll still leave some more block-sized characters behind. Take the large type pieces, they don't need to join with pseudopixels and box drawing, but they do need to join seamlessly with each other, and while there are standard shapes for those provided by Unicode, they are ugly and actually don't join properly with each other, so they really are just enough to recognize them, but you need to improve them for large text to work.
So several fonts will provide variations of those, some even reinterpreting their original design to give them more identity, with design hints reminiscent of the standard-sized characters.

For example, here is my current work on large type pieces for Cascadia, with rounded corners:

While the original design uses beveled corners, because it was modern in the 70s when HP originally designed them for its terminals:

(This is using https://github.com/be5invis/Iosevka font)

These cannot be custom-drawn without losing on consistency and font design.

To me it seems there are way too many glyphs to handle them all, and picking a custom-drawn solution might mean you spend less effort on trying to reduce the artifacts of the renderer when joining full-block characters.

I have even more concerns coming in an upcoming post, because Unicode only standardize glyphs intents, not their actual design, and they use the same codepoint for characters that have the same intent on several legacy systems, but which actually have incompatible designs if you want the terminal to be able to render their original semigraphics contents properly. In short, the same code point will have different pseudopixels patterns depending on the original system, and users may switch between a few fonts depending on what they are doing or which app they launch in different terminal profiles.
Imagine I build a version of the Commodore Basic interpreter as a Win32 exe and use it from the terminal, I want a font that is compatible with PETSCII, but if I have another profile for an Apple II Basic interpreter, I need another font, because some of the same characters have to look different.

And all of this is a real possibility, and one of the goals of the hundreds of semigraphics characters coming in Unicode 16.
I literally spent the last few weeks preparing 563 new semigraphics characters for Cascadia, the first batch being pending right now (microsoft/cascadia-code#708), all of which are block-sized and need to seamlessly join.

lhecker · 2024-02-22T19:36:42Z

[...] might mean you spend less effort on trying to reduce the artifacts of the renderer when joining full-block characters.

Are you aware of an approach that does this properly? I'd be happy to implement it!

(BTW I'm not sure if it's relevant to your argument, but the PR makes this a setting. It'll be next to the font size setting.)

PhMajerus · 2024-02-22T20:25:51Z

@lhecker I don't have a perfect solution and I do appreciate the thought and work you've put into trying to improve the situation.

One of the problem I'm concerned with is consistency, especially with pseudo-pixels mosaics, quadrants reuse existing half-block patterns, sextants reuse half-blocks as well, octants reuse half-blocks, quadrants, and eights fills, a new set of eights are providing horizontal and vertical lines, as well as horizontal and vertical fills from the top and right to complement existing ones from the bottom and left,...
All those need to share their coordinates system with glyphs that are part of the older box drawing and block elements, so if you custom-draw the oldest ones and not the new ones, they won't align properly, we already see such problem today because the coordinates are not unified:

I'm not against an option to make the base box drawing and block elements look nicer, but I don't think it is the ultimate solution.

Is there any way with the DirectWrite renderer to adjust the glyph size for rendering? If designed properly, all the hundreds of semigraphics of a font should be based on the Full Block U+2588 bounding box. The only solution I can think of that would make it perfect is to retrieve the bounding box of the Full Block, round it to its nearest pixels boundary, so it snaps into the grid, and feed that scaling back into the font renderer to adjust all glyphs accordingly.

Then you don't need to handle some characters in a special way, which is impossible since a font may include PUA characters that are also block-sized.
It would also be the only solution I can think of that would make it possible to have block-sized ligatures.

For example, here is a version of my large type pieces with ligatures to further round the corners:

It looks nice when the full block size is pretty much a round number of pixels, but at some sizes, it gets misaligned.
I believe this is because sequences of 2 or 3 blocks are replaced by double or triple width blocks using ligatures, and if the full block width wasn't a round number of pixels, the individual characters get snapped to the nearest pixel while the ligature group doesn't, ending up in off by 1 or 2 pixels alignment issues on the right.

If the renderer could find out the separate width and height scaling adjustments needed to snap the full block to its cell, and feed these adjustments back into the font renderer, I believe you could achieve perfect seamlessly connection of all the box drawing, pseudo-pixels, large font, and all semigraphics. No more seams or overlaps, no special table of which characters are block-sized, no special handling of "the most important" box drawing and block element characters at the expense of all the others,...

Do you think something like that is possible? It is a very special case so maybe DirectWrite doesn't support that, but since you're lucky enough to be the same company, could it be possible if it isn't supported to get a customized version of DirectWrite that supports those adjustments scaling to render the terminal characters grid perfectly?

PhMajerus · 2024-02-22T20:39:17Z

If you want to test your rendering changes with those new glyphs, here are some more resources.

This is a custom version of Cascadia with the characters I'm adding:
Cascadia-PHM 2024-02-22.zip
It contains sextants, octants, diagonals, large type pieces, and several other legacy computing characters.

Here are the charts, note I didn't do everything yet:

Here is an explanation and test document for large type pieces:
HowTo Large Type Pieces.txt

The Cascadia Code version includes ligatures for several of the corners combinations of large type pieces.

The large type pieces are probably the trickiest semigraphics I'm encountered, if you can render those you can probably render everything.

As usual, you can find more pseudo-pixels test files at https://github.com/PhMajerus/ANSI-art/tree/main/Unicode

If you try it out, run the following: echo G1swOzM4OzU7MTZtICAg4paC4paC4paC8Jy6o/CctZEKIOKWlxtbNDg7NTsyMDht4pabG1s0ODs1OzIxNG3wn66CICDwn66C8Jy0phtbNDlt8Jy0tgog8Jy3lRtbMzg7NTsyMDg7NDg7NTsyMTRt4paMICAbWzM4OzU7MTZt4paMIOKWjBtbNDlt4paMG1swOzNtIFRoYW5rChtbMDszODs1OzE2bfCctpYbWzQ4OzU7MjA4beKWmCAbWzM4OzU7MjA4OzQ4OzU7MjE0bfCcuqMgIBtbMzg7NTsxOTdt8Jy0s/CctKsbWzQ5OzM4OzU7MTZt4paMG1swOzNtICB5b3UhChtbMDszODs1OzE2bfCctKEbWzQ4OzU7MjA4bfCctL7wnLSn8Jy0kBtbMzg7NTsyMDg7NDg7NTsyMTRt8Jy2u/CcuqMgG1szODs1OzE2bfCct5MbWzQ5beKWmArilpcbWzQ4OzU7MTIzbfCctIIbWzQ4OzU7Mjdt8Jy6qBtbNDg7NTsxMjM7Mzg7NTsyMG3wnLSCG1s0ODs1OzIzMTszODs1OzE2bfCctIUbWzQ4OzU7Mjdt8Jy1hRtbNDg7NTsxMjM7Mzg7NTsyMG3wnLSCG1s0ODs1OzIzMTszODs1OzE2bfCctIUbWzQ5beKWlgrwnLqr8J+ugvCfroLwn66C8J+ugvCfroLwn66C8J+ugvCcuqgbW20K | base64 -d

lhecker · 2024-02-22T21:03:28Z

The only solution I can think of that would make it perfect is to retrieve the bounding box of the Full Block, round it to its nearest pixels boundary, so it snaps into the grid, and feed that scaling back into the font renderer to adjust all glyphs accordingly.

The old "DxRenderer" did this for the basic box drawing glyphs. If you currently have "AtlasEngine" enabled in the Rendering settings, you could try disabling it and seeing how it looks then. I think the old DxRenderer could still be fine tuned a bit, but it's probably about as good as it gets.
But first this...

Then you don't need to handle some characters in a special way, which is impossible since a font may include PUA characters that are also block-sized.

From my past experience triaging user feedback for Windows Terminal, I believe I need to disagree, even if I agree that you're fundamentally correct. There are two problems I need to prevent if I were to do what you suggest:

A large number of fonts I've been seeing on here have a limited coverage of the box drawing blocks. Most notably, since it's the most widely used monospace font on Windows, Consolas has no coverage for most glyphs in the block elements block. Even with DxRenderer's glyph scaling, this still looks somewhat inconsistent (primarily due to the blur on contemporary <150 DPI displays).
A large number of people are quite vocal about perfect old-school-style bitmap fonts. These fonts only render correctly if we don't distort them in any way, but since they're still fonts, their size is not necessarily exactly perfect. This means that we must avoid scaling them by accident even if their U+2588 is larger than the cell size.

This PR solves both problems. Not in a way that I'd like since I fundamentally agree with you, but rather in a way that I think is proven to work, given that other popular terminals do the same thing.

I'm open to brainstorm alternative approaches we can add to our text renderer, but I believe this PR is the most solid approach we can have and the one we should have if not at least as a fallback.

For instance, given what you recommended, I think we should add another toggle that allows users to scale box drawing glyphs according to the size of the U+2588 glyph. This would make Cascadia work perfectly, while not breaking fonts such as TerminusTTF again.

PhMajerus · 2024-02-22T21:33:25Z

@lhecker I think many fonts have been designed by looking at their results in whichever terminal the font designer used daily.
It's not your job to accommodate those, and I do agree your solution as a fallback is a good fix.
It was never my intention to come and try to say this commit was a bad idea, but just to provide a point of view that it won't solve everything either.

Now about the possibility to scale and snap-to-grid every glyph according to U+2588.
This to me sounds like a perfect solution, because a font that is geometrically correct in its design will always have all the semigraphics using a unified coordinates grid, and therefore all their glyphs will be sized perfectly to fit together. It would also help me a lot as right now I have two sets of coordinates to work with in Cascadia, so each of those glyphs I added are actually two, some with trigonometric functions to get the proper equivalent coordinates on the two grids (GDI and DWrite). So it would half the work required to add semigraphics to Cascadia.

It seems like it would also please the users who want pixel-perfect old-school bitmap fonts. If you can scale width and height to snap glyphs to the grid, can you provide an alternative font size configuration in the settings to let users set the font size in pixels width and height instead of points?
If you can calculate the width and height scaling for the renderer accordingly, and as long as the user choose a pixels-width-and-height size that is a multiple of their font design grid, all the pseudo-pixels would be perfectly aligned with no distortion or blurry edges.
So again, if their font is geometrically correct, they'll get pixel-perfect rendering.

Finally, just to further make the point that U+2588 should be the reference to scale all glyphs, diagonal box-drawing such as ╱:U+2571, ╲:U+2572, ╳:U+2573, and the plenty of new diagonals snapping to the middle of each borders seen in the new legacy computing charts in my post above, all need to extend slightly outside their bounding box to join perfectly with each other. So the only way to find out how to snap them properly to the terminal grid is to infer their intended cell from U+2588, because their own bounding box will extend outside that cell.

zadjii-msft

yep this is dx code alright

zadjii-msft · 2024-02-21T12:49:33Z

src/propslib/RegistrySerialization.cpp

-    { _RegPropertyType::Boolean,        CONSOLE_REGISTRY_COPYCOLOR,                     SET_FIELD_AND_SIZE(_fCopyColor)                  }
+    { _RegPropertyType::Boolean,        CONSOLE_REGISTRY_COPYCOLOR,                     SET_FIELD_AND_SIZE(_fCopyColor)                  },
+#if TIL_FEATURE_CONHOSTATLASENGINE_ENABLED
+    { _RegPropertyType::Boolean,        L"EnableBuiltinGlyphs",                         SET_FIELD_AND_SIZE(_fEnableBuiltinGlyphs)        },


SHJordan · 2024-03-06T16:48:25Z

If you want to test your rendering changes with those new glyphs, here are some more resources.

This is a custom version of Cascadia with the characters I'm adding: Cascadia-PHM 2024-02-22.zip It contains sextants, octants, diagonals, large type pieces, and several other legacy computing characters.

Here are the charts, note I didn't do everything yet:

Here is an explanation and test document for large type pieces: HowTo Large Type Pieces.txt

The Cascadia Code version includes ligatures for several of the corners combinations of large type pieces.

The large type pieces are probably the trickiest semigraphics I'm encountered, if you can render those you can probably render everything.

As usual, you can find more pseudo-pixels test files at https://github.com/PhMajerus/ANSI-art/tree/main/Unicode

If you try it out, run the following: echo G1swOzM4OzU7MTZtICAg4paC4paC4paC8Jy6o/CctZEKIOKWlxtbNDg7NTsyMDht4pabG1s0ODs1OzIxNG3wn66CICDwn66C8Jy0phtbNDlt8Jy0tgog8Jy3lRtbMzg7NTsyMDg7NDg7NTsyMTRt4paMICAbWzM4OzU7MTZt4paMIOKWjBtbNDlt4paMG1swOzNtIFRoYW5rChtbMDszODs1OzE2bfCctpYbWzQ4OzU7MjA4beKWmCAbWzM4OzU7MjA4OzQ4OzU7MjE0bfCcuqMgIBtbMzg7NTsxOTdt8Jy0s/CctKsbWzQ5OzM4OzU7MTZt4paMG1swOzNtICB5b3UhChtbMDszODs1OzE2bfCctKEbWzQ4OzU7MjA4bfCctL7wnLSn8Jy0kBtbMzg7NTsyMDg7NDg7NTsyMTRt8Jy2u/CcuqMgG1szODs1OzE2bfCct5MbWzQ5beKWmArilpcbWzQ4OzU7MTIzbfCctIIbWzQ4OzU7Mjdt8Jy6qBtbNDg7NTsxMjM7Mzg7NTsyMG3wnLSCG1s0ODs1OzIzMTszODs1OzE2bfCctIUbWzQ4OzU7Mjdt8Jy1hRtbNDg7NTsxMjM7Mzg7NTsyMG3wnLSCG1s0ODs1OzIzMTszODs1OzE2bfCctIUbWzQ5beKWlgrwnLqr8J+ugvCfroLwn66C8J+ugvCfroLwn66C8J+ugvCcuqgbW20K | base64 -d

it works:

But I miss the NERD glyphs, could you provide one version of CaskaydiaCove instead?

lhecker · 2024-03-06T17:25:53Z

This PR works with any font and you can just use CaskaydiaCove. :)

SHJordan · 2024-03-07T16:11:12Z

This PR works with any font and you can just use CaskaydiaCove. :)

Idk then, maybe the font is missing some glyphs to make the image complete:

DHowett · 2024-03-07T16:25:26Z

Just so we're on the same page...

You are testing a font which is under development by PhMajerus, which you found on a pull request about changing how box/line/shade characters are rendered for the purposes of testing, and asking for PhMajerus to provide you a version of the under-development font that has also been patched to contain "Nerd Font" characters.

Lhecker is telling you that the changes in this PR apply to any font; to be clear though: this PR will not make glyphs that exist only in PhMajerus' under-development font show up in all fonts.

If you're looking for a font that contains sextants, octants, diagonals and large type pieces as well as Nerd Font glyphs, you will need to wait for Cascadia to officially release an update for those legacy computing symbols.

SHJordan · 2024-03-07T16:44:42Z

Just so we're on the same page...

You are testing a font which is under development by PhMajerus, which you found on a pull request about changing how box/line/shade characters are rendered for the purposes of testing, and asking for PhMajerus to provide you a version of the under-development font that has also been patched to contain "Nerd Font" characters.

Lhecker is telling you that the changes in this PR apply to any font; to be clear though: this PR will not make glyphs that exist only in PhMajerus' under-development font show up in all fonts.

If you're looking for a font that contains sextants, octants, diagonals and large type pieces as well as Nerd Font glyphs, you will need to wait for Cascadia to officially release an update for those legacy computing symbols.

Yep, that's what i meant with i wish there was a merge(remix?) between Cascadia Mono by PhMajerus and CaskaydiaCove Mono by NerdFonts.

DHowett · 2024-03-07T16:49:14Z

Yep, that's what i meant with i wish there was a merge(remix?) between Cascadia Mono by PhMajerus and CaskaydiaCove Mono by NerdFonts.

Not quite yet, but maybe soon 👀

PhMajerus · 2024-03-08T14:42:38Z

@SHJordan
The modified font and examples were only intended to give more full-block glyphs to illustrate the concerns I have with a special handling of some of the block and line drawing characters, and have more mosaic characters in case people working on the DWrite renderer wanted some more test cases. It is a test build, isn't hinted, and really is limited to testing those characters.

As DHowett said, I'm just adding legacy computing characters, hoping for Cascadia to officially release an update with those included. But to clarify, I don't even intend to release a separate font unless DHowett or Aaron tell me to, I'm only submitting pull requests gradually for sets of legacy computing characters to be included in the Microsoft version: microsoft/cascadia-code#708. This is the reason the font attached in this thread contains much more characters than my public https://github.com/PhMajerus/cascadia-code/ fork currently does.

It is my understanding that other fonts based off Cascadia can then later integrate those changes as well, so what you're hoping for would probably happen the other way around, with CaskaydiaCove including those through Cascadia, instead of me integrating CaskaydiaCove changes.

I hope DHowett's "maybe soon 👀" mean they're considering accepting my pull requests, so we won't need different fonts to get those characters anymore.

I feel like we're hijacking a thread with another topic here, sorry about that. So DHowett and lhecker, feel free to mark it all as off-topic.
SHJordan, thanks for your interest though, I'm happy to see some people are as eager as I am to get those legacy computing characters more widely available. If you want to discuss this any further, I recommend we move this over to https://github.com/microsoft/cascadia-code/issues, where I have a few open issues about specific sets of characters.

SHJordan · 2024-03-08T16:33:35Z

@PhMajerus understandable, and sorry for being a bit offtopic guys.

This comment was marked as outdated.

Sign in to view

This comment was marked as resolved.

Sign in to view

This comment was marked as outdated.

Sign in to view

This comment was marked as resolved.

Sign in to view

tusharsnx reviewed Feb 18, 2024

View reviewed changes

src/renderer/atlas/CustomGlyphs.cpp Outdated Show resolved Hide resolved

lhecker marked this pull request as ready for review February 19, 2024 23:27

Support for custom box drawing and powerline glyphs

ad2391c

lhecker force-pushed the dev/lhecker/5897-custom-glyphs branch from 081901c to ad2391c Compare February 20, 2024 00:25

tusharsnx reviewed Feb 20, 2024

View reviewed changes

src/renderer/atlas/CustomGlyphs.cpp Outdated Show resolved Hide resolved

DHowett reviewed Feb 20, 2024

View reviewed changes

src/renderer/inc/FontInfoDesired.hpp Outdated Show resolved Hide resolved

Fixed round glyphs, Added conhost setting, Fixed D2D mode

3be7d11

DHowett reviewed Feb 20, 2024

View reviewed changes

lhecker added 2 commits February 21, 2024 03:01

custom glyphs -> builtin glyphs

710eb1b

Fix builtinGlyphs setting hot-reload

ac1c8b6

lhecker changed the title ~~Support for custom box drawing and powerline glyphs~~ Add support for custom box drawing and powerline glyphs Feb 21, 2024

Merge branch 'main' into dev/lhecker/5897-custom-glyphs

5606691

DHowett approved these changes Feb 22, 2024

View reviewed changes

zadjii-msft approved these changes Feb 23, 2024

View reviewed changes

DHowett merged commit a6a0e44 into main Feb 23, 2024
20 checks passed

DHowett deleted the dev/lhecker/5897-custom-glyphs branch February 23, 2024 21:40

This was referenced Feb 24, 2024

Broken display of some characters. #16757

Closed

Make shaded block glyphs look even betterer #16760

Merged

zadjii-msft mentioned this pull request Feb 27, 2024

Allow for the configuration of font fallback #2664

Closed

lhecker mentioned this pull request Mar 3, 2024

1px line between powerline glyphs #8993

Closed

lhecker mentioned this pull request Mar 28, 2024

Our box drawing character range is too broad (was: \u25ef rendered too big) #16451

Closed

PhMajerus mentioned this pull request Apr 26, 2024

Adjusting half-blocks, quadrants,... coordinates to unify mosaics microsoft/cascadia-code#727

Merged

5 tasks

PhMajerus mentioned this pull request May 18, 2024

Cascadia Code arrow segments not displaying correctly microsoft/cascadia-code#740

Open

Add support for custom box drawing and powerline glyphs #16729

Add support for custom box drawing and powerline glyphs #16729

Conversation

lhecker commented Feb 17, 2024 • edited Loading

Validation Steps Performed

lhecker commented Feb 17, 2024 • edited Loading

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as outdated.

This comment was marked as resolved.

This comment was marked as resolved.

tusharsnx commented Feb 18, 2024

lhecker commented Feb 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DHowett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DHowett commented Feb 21, 2024

DHowett commented Feb 22, 2024

DHowett commented Feb 22, 2024

PhMajerus commented Feb 22, 2024 • edited Loading

lhecker commented Feb 22, 2024 • edited Loading

PhMajerus commented Feb 22, 2024

PhMajerus commented Feb 22, 2024 • edited Loading

lhecker commented Feb 22, 2024 • edited Loading

PhMajerus commented Feb 22, 2024 • edited Loading

zadjii-msft left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SHJordan commented Mar 6, 2024

lhecker commented Mar 6, 2024

SHJordan commented Mar 7, 2024

DHowett commented Mar 7, 2024

SHJordan commented Mar 7, 2024

DHowett commented Mar 7, 2024

PhMajerus commented Mar 8, 2024 • edited Loading

SHJordan commented Mar 8, 2024

lhecker commented Feb 17, 2024 •

edited

Loading

lhecker commented Feb 17, 2024 •

edited

Loading

PhMajerus commented Feb 22, 2024 •

edited

Loading

lhecker commented Feb 22, 2024 •

edited

Loading

PhMajerus commented Feb 22, 2024 •

edited

Loading

lhecker commented Feb 22, 2024 •

edited

Loading

PhMajerus commented Feb 22, 2024 •

edited

Loading

PhMajerus commented Mar 8, 2024 •

edited

Loading