I wanted to display U+2717 (✗, BALLOT X) in the Windows traditional console (conhost). With the system's default monospace font Consolas selected, what appeared was a boxed question mark. I encountered this symbol while using NeoVim, which also requires Nerd Fonts, but even many fonts that support Nerd Fonts don't support this character.

The cause of the problem is obvious: Consolas doesn't contain this glyph—just switch to a font that includes it. After consulting fileformat.info's glyph support list, I discovered that open-source monospace fonts like DejaVu Sans Mono and Inconsolata do indeed include U+2717.

This indicates that conhost doesn't render using a single font; there must be some fallback mechanism. Following this logic, since Chinese characters can fall back to Microsoft YaHei for display, U+2717 should similarly be able to fall back to a system font that contains it (such as Segoe UI).

conhost's Fallback Mechanism: GDI Font Linking

conhost's fallback mechanism is based on GDI's Font Linking, with specific configuration located in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink.

The registry contains numerous font link entries, each specifying which fonts to fall back to for different base fonts. For example, the Segoe UI entry includes fallbacks to Tahoma, Microsoft YaHei UI, Microsoft JhengHei UI, Meiryo UI, Malgun Gothic, Yu Gothic UI, and Segoe UI Symbol.

Microsoft explains the distinction between these mechanisms in their official Microsoft Learn documentation "Customize font selection with font fallback and font linking":

When GDI doesn't find a corresponding entry in SystemLink, it also uses Uniscribe to query its built-in fallback table. Chinese characters display normally because CJK has corresponding entries in Uniscribe's built-in fallback table.

Why U+2717 Doesn't Fall Back Properly

Uniscribe's built-in fallback table performs coarse-grained mapping based on Unicode script blocks, primarily covering writing systems for various languages (CJK, Arabic, Thai, etc.). However, U+2717 (✗) belongs to the Dingbats block (U+2700–U+27BF), and its Unicode script property is Common (Zyyy), with a general category of So (Other Symbol).

These "symbol characters that don't belong to any specific writing system" are simply not covered by Uniscribe's fallback table.

Someone submitted an almost identical request to Microsoft—adding Unicode symbols commonly used in CLI (including ✔, ✖, ★, ▶, ⚠, etc.) to Consolas. These characters belong to the same region as U+2717 and face exactly the same problem.

Microsoft's Architecture-Level Fix

However, Microsoft made an architecture-level fix in 2021 through PR #10478: switching conhost's GDI rendering from PolyTextOutW to ExtTextOutW.

In the PR, miniksa explained: PolyTextOutW's code doesn't call Uniscribe, so glyph substitution never happens; whereas ExtTextOutW first sends text to Uniscribe for language processing, and after Uniscribe completes, splits the call into ExtTextOutW with the ETO_IGNORELANGUAGE flag for rendering.

This fix opened the channel for Uniscribe glyph substitution, but it solves whether the channel is clear—not whether the fallback table is complete. U+2717 isn't in Uniscribe's fallback table, so no matter how clear the channel is, it won't help.

Understanding the Root Cause

The fundamental issue is that Windows console font fallback operates at two levels:

  1. Font Linking (SystemLink registry): Provides explicit fallback chains for specific fonts
  2. Uniscribe Script Fallback: Provides script-based fallback for writing systems

U+2717 falls through both cracks:

  • It's not explicitly listed in the SystemLink fallback chains for Consolas
  • It's not part of any recognized writing system script that Uniscribe handles

Potential Solutions

For users facing this issue, there are several workarounds:

  1. Use a different console font that includes the desired glyphs (like DejaVu Sans Mono or a Nerd Font variant that includes Dingbats)
  2. Modify the FontLink registry to add explicit fallback for Consolas to include fonts containing U+2717
  3. Use Windows Terminal instead of conhost, which has more modern font handling capabilities
  4. Wait for Microsoft to expand the Uniscribe fallback table to include common symbol blocks

This issue exemplifies the complexity of Unicode rendering in legacy systems and the challenges of maintaining backward compatibility while supporting the ever-expanding Unicode standard.