terminal
terminal copied to clipboard
microsoft
Text appears with shadow (antialiasing) when using the Spleen font
Windows Terminal version
1.20.10293.0
Windows build number
10.0.22631.3007
Other Software
No response
Steps to reproduce
get spleen 12x24, .otf
install it
set WT to use it
there is a right drop shadow.
in the screenshot you see how notepad, visual studio, notepad++, gitk and paint.net render the text using the same font.
I tried changing atlas on/off, sw render on/off, system-wide font smoothing on/off (but never cleartype)
By the way, using vector fonts on raster devices was and always be a mistake. At least until we reach... I dunno... 600dpi? Maybe 300? Right now for desktop monitors we are looking at ~180 for a 24" 4k monitor. But I digress.
Expected Behavior
Text to be rendered without shadow.
Actual Behavior
Text is rendered with shadow. For what it's worth, the little preview window does show this shadow. Yes, I know this sounds minor, but... I consider text rendering to be quite important.
Assign me, i'll look into this
That's fine. You do not need to be assigned to investigate an issue!
I consider text rendering to be quite important.
As do we.
Thanks for reporting this!
For now, you can circumvent the issue by setting the "Text antialiasing" setting to "Aliased". You can find the setting when opening a profile's "Advanced" settings.
Supposedly spleen is a bitmap font, but if I open it in FontForge I can see that it also contains a vector font that follows a theoretical pixel path. The only application I can rely on to tell me how a font is supposed to look like in either GDI or DirectWrite is Visual TrueType (sort of Microsoft's reference text renderer) and that one fails to open the font (my first time seeing this - spleen should fix this if they can):
This makes it very difficult for me to fix the issue in our own text renderer. Only Visual TrueType allows me to see a reliable reference rendering with GDI and DirectWrite.
BTW it's natural that we look slightly different from the other applications you've shown above, because all the other ones use GDI and we use DirectWrite. Given that GDI uses a different rasterization approach (stronger hinting among others), it wouldn't be surprising that it also fails to use any embedded bitmap but happens to succeed to draw the vector font without a shadow out of coincidence.
Excellent point! @fcambus - would you have any ideas as to what might be going on here? Any hints that might point us in the right direction? Or does this just come down to a GDI vs DirectWrite fundamental difference?
