The Problem: Missing Characters in Windows Console

When attempting to display U+2717 (✗, BALLOT X) in the traditional Windows console (conhost), users encounter a frustrating issue: even with the system's default monospace font Consolas selected, the output shows a boxed question mark instead of the intended symbol.

This problem frequently surfaces when using NeoVim and similar terminal applications that require Nerd Fonts. Ironically, many fonts that claim Nerd Fonts support still fail to render this particular character correctly.

The root cause is straightforward: Consolas simply doesn't contain this glyph. The logical solution would be to switch to a font that includes U+2717. Research on fileformat.info's glyph support listings reveals that open-source monospace fonts like DejaVu Sans Mono and Inconsolata do indeed contain U+2717.

Understanding conhost's Font Fallback Mechanism

This discovery indicates that conhost doesn't rely on a single font for rendering — it employs some form of fallback mechanism. Following this logic, since Chinese characters successfully fall back to Microsoft YaHei for display, U+2717 should similarly fall back to a system font containing it (such as Segoe UI).

The conhost fallback mechanism operates based on GDI's Font Linking technology, with specific configurations located in the Windows Registry at:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink

Examining this registry key reveals extensive font linking configurations. For instance, the Consolas entry (if present) would specify which fallback fonts to consult when a glyph isn't available in the primary font.

The Registry Configuration: FontLink SystemLink

The SystemLink registry key contains numerous entries, each defining fallback chains for different primary fonts. Here are some representative examples:

Segoe UI Entry:

Name: Segoe UI
Data: 
  TAHOMA.TTF,Tahoma
  MSYH.TTC,Microsoft YaHei UI,128,96
  MSYH.TTC,Microsoft YaHei
  MSJH.TTC,Microsoft Jhenghei UI,128,96
  MSJH.TTC,Microsoft Jhenghei
  MEIRYO.TTC,Meiryo UI,128,96
  MEIRYO.TTC,Meiryo
  SIMSUN.TTC,SimSun
  MINGLIU.TTC,PMingLiU
  MSGOTHIC.TTC,MS UI Gothic
  MALGUN.TTF,Malgun Gothic,128,96
  MALGUN.TTF,Malgun Gothic
  GULIM.TTC,Gulim
  YUGOTHM.TTC,Yu Gothic UI,128,96
  YUGOTHM.TTC,Yu Gothic UI
  SEGUISYM.TTF,Segoe UI Symbol

Microsoft YaHei Entry:

Name: Microsoft YaHei
Data:
  SEGOEUI.TTF,Segoe UI,120,80
  SEGOEUI.TTF,Segoe UI
  SIMSUN.TTC,SimSun
  MSJH.TTC,Microsoft JhengHei,128,96
  MSJH.TTC,Microsoft JhengHei
  MEIRYO.TTC,Meiryo,128,85
  MEIRYO.TTC,Meiryo
  MALGUN.TTF,Malgun Gothic,128,96
  MALGUN.TTF,Malgun Gothic
  YUGOTHM.TTC,Yu Gothic UI,128,96
  YUGOTHM.TTC,Yu Gothic UI

These configurations specify the fallback chain: when a character isn't found in the primary font, Windows consults each fallback font in sequence until locating the required glyph.

Why Chinese Characters Work But U+2717 Doesn't

Microsoft's official documentation on "Customize font selection with font fallback and font linking" explains the distinction between two mechanisms:

Font Linking (GDI SystemLink): The registry-based configuration described above.

Uniscribe Built-in Fallback: When GDI找不到 corresponding entries in SystemLink, it queries Uniscribe's built-in fallback table.

Chinese characters display correctly because CJK (Chinese, Japanese, Korean) scripts have corresponding entries in Uniscribe's built-in fallback table. However, 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.).

U+2717 (✗) belongs to the Dingbats block (U+2700–U+27BF). Its Unicode script property is Common (Zyyy), and its general category is So (Other Symbol). Characters in this category — symbols that don't belong to any specific writing system — fall completely outside Uniscribe's fallback table coverage.

Community Efforts and Microsoft's Response

Users have submitted nearly identical requests to Microsoft — asking for commonly used Unicode symbols in CLI environments (including ✔, ✖, ★, ▶, ⚠, and others) to be added to Consolas. These characters occupy the same Unicode region as U+2717 and face identical rendering problems.

In 2021, Microsoft addressed part of this issue through PR #10478, implementing an architectural fix: switching conhost's GDI rendering from PolyTextOutW to ExtTextOutW.

As miniksa explained in the PR:

"PolyTextOutW's code path doesn't invoke Uniscribe, so glyph substitution never occurs. ExtTextOutW first sends text to Uniscribe for script shaping, and after Uniscribe completes, it breaks the call into ExtTextOutW calls with the ETO_IGNORELANGUAGE flag for rendering."

This fix opened the channel for Uniscribe glyph substitution — but it only addresses whether the channel functions properly, not whether the fallback table is complete. Since U+2717 doesn't exist in Uniscribe's fallback table, even a perfectly functioning channel cannot render it.

The Fundamental Limitation

The core issue becomes clear:

  1. Channel Problem (Solved): PR #10478 fixed the rendering pipeline to properly invoke Uniscribe
  2. Table Problem (Unsolved): U+2717 simply isn't in Uniscribe's fallback table

The Dingbats block and similar symbol ranges fall into a gap: they're not part of any specific script system, so they don't qualify for Uniscribe's script-based fallback. Yet they're also not comprehensively covered by individual font entries in the SystemLink registry.

Potential Solutions

For users encountering this issue, several workarounds exist:

Option 1: Use Alternative Terminal Emulators

Modern terminal emulators like Windows Terminal, Ghostty, or cmux employ more sophisticated font fallback mechanisms that may successfully render U+2717.

Option 2: Install Nerd Fonts

Fonts specifically designed for developer environments (Nerd Fonts) include extensive symbol coverage, though users must verify specific character support.

Option 3: Modify SystemLink Registry

Advanced users can manually add fallback entries to the SystemLink registry, though this requires careful testing and backup procedures.

Option 4: Use Alternative Characters

When possible, substitute U+2717 with similar characters that have better font support, such as:

  • U+00D7 (×, MULTIPLICATION SIGN)
  • U+2715 (✕, MULTIPLICATION X)
  • U+2716 (✖, HEAVY MULTIPLICATION X)

Conclusion

The inability of conhost.exe to display U+2717 represents a specific instance of a broader challenge: Windows console font fallback mechanisms weren't designed with comprehensive Unicode symbol coverage in mind.

While Microsoft has made progress in improving the rendering pipeline, complete symbol support requires either:

  • Expanding Uniscribe's fallback table to include Dingbats and similar blocks
  • Individual font entries explicitly covering these symbols
  • Users adopting alternative terminal solutions with better Unicode support

Until such changes occur, developers working with Unicode symbols in Windows console environments must either work around these limitations or transition to more modern terminal emulators that handle Unicode more comprehensively.

The gap between Unicode's expansive character set and operating system font fallback capabilities remains an ongoing challenge for cross-platform terminal applications.