Some of the extended Unicode characters are rendered with incorrect size and placement

[vblazhkun]

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 1.1.1671.0

Any other software?

- WSL Ubuntu 20.04 LTS

- The font is PragmataPro Mono Liga v.0.828.

Steps to reproduce

Some of the extended Unicode characters are rendered with incorrect size and placement (i.e. the lower-left corner of the cell). As an example the char ✽ (0xE29CBD).

Expected behavior

Actual behavior

[DHowett]

According to Unicode 13.0, U+273D HEAVY TEARDROP-SPOKED ASTERISK is ambiguous width, non-emoji, non-emoji-presentation -- that means that it is narrow, and will always be narrow, in compliant terminals. If your font specifies that it is larger than one monospaced cell in width, it is time to fix your font. 😄

[DHowett]

(as an example, this behaviour is not recapitulated in the font I have set right now:

)

[vblazhkun]

According to Unicode 13.0, U+273D HEAVY TEARDROP-SPOKED ASTERISK is ambiguous width, non-emoji, non-emoji-presentation -- that means that it is narrow, and will always be narrow, in compliant terminals. If your font specifies that it is larger than one monospaced cell in width, it is time to fix your font. 😄

It occupies exactly one cell (i.e. it is narrow). But, the Notepad and other terminals render it correctly (within a single cell as demonstrated on the initial picture) opposing to the WT.

[vblazhkun]

@DHowett Actually, even the earlier releases of the WT demonstrated the correct rendering behavior. I believe it is a bug.

[vblazhkun]

A quick snip from ConEmu:

[DHowett]

fair enough

[lhecker]

This appears to be fixed with AtlasEngine:

Please let me know if this issue still appears for you in Windows Terminal Preview 1.16.

[vblazhkun]

This appears to be fixed with AtlasEngine:

Please let me know if this issue still appears for you in Windows Terminal Preview 1.16.

The original issue is fixed however there is a new one. The given character U+273D HEAVY TEARDROP-SPOKED ASTERISK is always rendered with white foreground color despite the WT color scheme or surrounding ANSI escape sequences (such is actually visible on your screenshot as well). I will open a new issue describing that.

[lhecker]

Thanks! Coincidentally I was just talking about this exact issue elsewhere like 5 minutes ago. 😅
It is caused by this code:

terminal/src/renderer/atlas/AtlasEngine.cpp

Lines 1506 to 1530 in 71fc4b1

	// Do fonts exist *in practice* which contain both colored and uncolored glyphs? I'm pretty sure...
	// However doing it properly means using either of:
	// * IDWriteFactory2::TranslateColorGlyphRun
	// * IDWriteFactory4::TranslateColorGlyphRun
	// * IDWriteFontFace4::GetGlyphImageData
	//
	// For the first two I wonder how one is supposed to restitch the 27 required parameters from a
	// partial (!) text range returned by GetGlyphs(). Our caller breaks the GetGlyphs() result up
	// into runs of characters up until the first canBreakShapingAfter == true after all.
	// There's no documentation for it and I'm sure I'd mess it up.
	// For very obvious reasons I didn't want to write this code.
	//
	// IDWriteFontFace4::GetGlyphImageData seems like the best approach and DirectWrite uses the
	// same code that GetGlyphImageData uses to implement TranslateColorGlyphRun (well partially).
	// However, it's a heavy operation and parses the font file on disk on every call (TranslateColorGlyphRun doesn't).
	// For less obvious reasons I didn't want to write this code either.
	//
	// So this is a job for future me/someone.
	// Bonus points for doing it without impacting performance.
	auto flags = CellFlags::None;
	if (fontFace)
	{
	const auto fontFace2 = wil::try_com_query<IDWriteFontFace2>(fontFace);
	WI_SetFlagIf(flags, CellFlags::ColoredGlyph, fontFace2 && fontFace2->IsColorFont());
	}

Thank you for opening another issue! I'll try to fix it... somehow. 🥲

[carpet92]

In the previous version of terminal the icons definitely were larger (more proportional) than now:

amro.omp.json theme for oh-my-posh

WT 1.16.2523.0

[lhecker]

@Zx-EvM That problem is specific to Nerd Fonts. Other kinds of Emojis didn't work in the previous version either. I'm working on a fix over here: #6864 (comment)