conhost.exe Cannot Display U+2717: Deep Dive into Windows Console Font Fallback
Introduction: The Missing Checkmark Problem
I wanted to display U+2717 (✗, BALLOT X) in Windows' traditional console (conhost). After selecting the system's default monospace font Consolas, what appeared was a question mark inside a box. I encountered this symbol while using NeoVim, which also requires Nerd Fonts—but even many fonts supporting Nerd Fonts don't support this character.
The cause of the problem is obvious: Consolas doesn't contain this glyph. Simply switch to a font that includes it. After checking fileformat.info's glyph support list, I found that open-source monospace fonts like DejaVu Sans Mono and Inconsolata do indeed include U+2717.
This indicates that conhost doesn't render using only a single font—there exists some kind of fallback mechanism. Following this logic, since Chinese characters can fallback to Microsoft YaHei for display, U+2717 should similarly be able to fallback to system fonts containing it (such as Segoe UI).
Understanding conhost's Font Fallback Mechanism
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.
Registry Structure Analysis
The SystemLink registry key contains multiple values, each defining fallback chains for different primary fonts. Let's examine the structure:
Key Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
Each value entry follows this pattern:
- Value Name: Primary font name (e.g., "Consolas", "Segoe UI", "Microsoft YaHei")
- Value Type: REG_MULTI_SZ
- Data: Comma-separated list of fallback fonts with optional size adjustments
Example Entry Structure
Value: Segoe UI
Type: REG_MULTI_SZ
Data:
TAHOMA.TTF,Tahoma
MSYH.TTC,Microsoft YaHei UI,128,96
MSYH.TTC,Microsoft YaHei UI
MSJH.TTC,Microsoft Jhenghei UI,128,96
MSJH.TTC,Microsoft Jhenghei UI
MEIRYO.TTC,Meiryo UI,128,96
MEIRYO.TTC,Meiryo UI
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 SymbolThe numbers after font names (e.g., 128,96) represent scaling factors for size adjustment between fonts.
Key Observations from SystemLink Entries
Analyzing the complete SystemLink registry reveals several important patterns:
- CJK Character Support: All major fonts include fallbacks to Chinese, Japanese, and Korean fonts (SimSun, MS Mincho, Malgun Gothic, etc.)
- Symbol Font Inclusion: Many entries include
SEGUISYM.TTF,Segoe UI Symbolas a final fallback—this font contains many special symbols - Asian Font Priority: For Western fonts like Segoe UI and Tahoma, Asian fonts appear early in the fallback chain
- Consolas Gap: Notably, Consolas entries don't include comprehensive symbol font fallbacks
Why Chinese Characters Display But U+2717 Doesn't
Microsoft explains the difference between Font Linking and Font Fallback in their official documentation "Customize font selection with font fallback and font linking":
Two-Tier Fallback System
Tier 1: Font Linking (SystemLink Registry)
- GDI first checks the SystemLink registry for corresponding entries
- If found, uses the specified fallback chain
- This is explicit, configurable fallback
Tier 2: Uniscribe Built-in Fallback Table
- When GDI doesn't find corresponding entries in SystemLink, it queries Uniscribe's built-in fallback table
- Chinese characters display correctly because CJK has corresponding entries in Uniscribe's built-in fallback table
The Critical Difference
Uniscribe's Built-in Fallback Table Characteristics:
- Granularity: Coarse-grained mapping by Unicode script blocks
- Coverage: Primarily covers writing systems for various languages (CJK, Arabic, Thai, etc.)
- Mechanism: Script-based fallback rather than character-by-character
U+2717's Classification:
- Unicode Block: Dingbats (U+2700–U+27BF)
- Unicode Script Property: Common (Zyyy)
- General Category: So (Other Symbol)
The Core Problem: Characters like U+2717 that "don't belong to any specific writing system" fall completely outside Uniscribe's fallback table coverage.
The GitHub Issue and Microsoft's Response
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 2021 Architecture Fix
In 2021, through PR #10478, Microsoft made an architecture-level fix: switching conhost's GDI rendering from PolyTextOutW to ExtTextOutW.
miniksa's Explanation in the PR:
"PolyTextOutW's code doesn't call Uniscribe, so glyph substitution simply doesn't occur; whereas ExtTextOutW first sends text to Uniscribe for language processing, and after Uniscribe completes, splits the call into ExtTextOutW with ETO_IGNORELANGUAGE flag for rendering."
What This Fix Achieved
This fix opened the channel for Uniscribe glyph substitution, but it solved 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 doesn't help.
The Limitation:
- ✅ Fixed: Rendering pipeline now supports Uniscribe fallback
- ❌ Not Fixed: Uniscribe fallback table doesn't include Dingbats/symbol characters
Practical Solutions
Given the technical constraints, here are practical approaches to solve this problem:
Solution 1: Use Fonts with Comprehensive Symbol Support
Recommended Fonts:
DejaVu Sans Mono
- Extensive Unicode coverage
- Includes U+2717 and related symbols
- Free and open-source
Inconsolata
- Modern monospace design
- Good symbol coverage
- Popular among developers
Nerd Fonts (Patched Versions)
- Specifically designed for terminal use
- Includes icons and symbols
- Multiple base font options
Cascadia Code
- Microsoft's modern terminal font
- Better symbol support than Consolas
- Actively maintained
Solution 2: Modify SystemLink Registry
Advanced users can add custom fallback entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
"Consolas"=hex(7):53,00,45,00,47,00,55,00,49,00,53,00,59,00,4d,00,2e,00,54,\
00,54,00,46,00,00,00,53,00,45,00,47,00,4f,00,45,00,20,00,55,00,49,00,20,\
00,53,00,79,00,6d,00,62,00,6f,00,6c,00,00,00,00,00Warning: Registry modifications can affect system stability. Backup before making changes.
Solution 3: Use Windows Terminal
Windows Terminal Advantages:
- Modern rendering engine (DirectWrite instead of GDI)
- Better Unicode support
- Active development and updates
- Supports ligatures and advanced typography
- Configurable font fallback
Migration Path:
# Install from Microsoft Store or GitHub
wingt install Microsoft.WindowsTerminal
# Configure default font in settings.json
{
"profiles": {
"defaults": {
"font": {
"face": "Cascadia Code",
"size": 11
}
}
}
}Solution 4: Application-Level Workarounds
For applications like NeoVim:
" In init.vim or .vimrc
set guifont=DejaVu\ Sans\ Mono\ for\ Powerline:h11
" Or use terminal-specific configuration
if has('nvim')
set termguicolors
let $NVIM_TUI_ENABLE_TRUE_COLOR=1
endifTechnical Deep Dive: Why This Matters
The Broader Context
This isn't just about one missing character—it represents a fundamental limitation in how Windows handles symbol characters in console applications.
Affected Character Ranges:
- Dingbats (U+2700–U+27BF): ✗, ✔, ★, ▶, etc.
- Miscellaneous Symbols (U+2600–U+26FF): ☀, ☁, ☂, etc.
- Emoticons (U+1F600–U+1F64F): 😀, 😂, etc.
- Symbols and Pictographs (U+1F300–U+1F5FF): 🌍, 📱, etc.
Impact on Modern Development
Developer Experience:
- Status indicators (✓/✗ for pass/fail)
- Progress indicators (▶, ●, ○)
- Warning symbols (⚠, ⚡)
- Navigation arrows (←, →, ↑, ↓)
Documentation and Communication:
- Bullet points and lists
- Emphasis markers
- Status badges
Tool Compatibility:
- Modern CLI tools increasingly use Unicode symbols
- Cross-platform tools expect consistent rendering
- Documentation often includes symbols
Comparison with Other Platforms
Linux Terminal
Advantages:
- Fontconfig provides sophisticated fallback
- Community-maintained font coverage
- Easy font installation and configuration
Typical Configuration:
# /etc/fonts/local.conf
<fontconfig>
<match target="font">
<test name="family">
<string>Consolas</string>
</test>
<edit name="family" mode="append">
<string>DejaVu Sans Mono</string>
<string>Noto Sans Symbols</string>
</edit>
</match>
</fontconfig>macOS Terminal
Advantages:
- Core Text provides excellent fallback
- System fonts include comprehensive symbol coverage
- SF Mono and Menlo have good Unicode support
Native Behavior:
- Automatic fallback to Symbol fonts
- Better emoji support
- Consistent rendering across applications
Future Outlook
Windows Terminal Evolution
Windows Terminal represents Microsoft's modern approach to console applications:
Current Status:
- Default terminal for Windows 11
- Regular updates with improved Unicode support
- Active GitHub repository with community feedback
Ongoing Improvements:
- Better emoji rendering
- Ligature support
- Custom font fallback configuration
- Improved CJK handling
Potential Microsoft Actions
Short-term (Likely):
- Continue improving Windows Terminal
- Add more symbols to Cascadia Code
- Update documentation on font configuration
Medium-term (Possible):
- Update Uniscribe fallback tables
- Improve conhost compatibility
- Better integration between old and new terminals
Long-term (Uncertain):
- Deprecate conhost in favor of Windows Terminal
- Comprehensive Unicode coverage in system fonts
- Unified text rendering across all applications
Recommendations for Different User Groups
For Regular Users
- Switch to Windows Terminal: Best overall experience
- Install Cascadia Code: Modern, well-maintained font
- Keep System Updated: Microsoft continuously improves support
For Developers
- Use Nerd Fonts: Comprehensive symbol coverage
- Configure Editor Fonts: Ensure IDE/terminal consistency
- Test Cross-Platform: Verify symbol rendering on all target platforms
- Provide Fallbacks: In applications, offer ASCII alternatives
For System Administrators
- Deploy Modern Fonts: Include comprehensive Unicode fonts in standard images
- Configure Font Fallback: Set up appropriate SystemLink entries
- Educate Users: Document terminal font configuration
- Monitor Updates: Track Windows Terminal and font updates
Conclusion
The inability of conhost.exe to display U+2717 exemplifies a broader challenge in Windows console text rendering: the gap between modern Unicode expectations and legacy system limitations.
Key Takeaways:
- Root Cause: U+2717 falls outside Uniscribe's script-based fallback table, not a technical limitation in the rendering pipeline
- Microsoft's Progress: The 2021 PR #10478 fixed the rendering channel but not the fallback table coverage
- Practical Solutions: Use Windows Terminal with modern fonts like Cascadia Code or Nerd Fonts
- Broader Impact: This affects many symbol characters increasingly common in modern development tools
- Future Direction: Windows Terminal represents the path forward, with conhost gradually becoming legacy
For developers encountering this issue today, the most practical solution is adopting Windows Terminal with a comprehensive Unicode font. While the underlying conhost limitations may persist for backward compatibility reasons, the ecosystem is moving toward better Unicode support.
The missing checkmark isn't just a cosmetic issue—it's a symbol of the ongoing transition from legacy text rendering to modern Unicode-aware systems. As the industry continues pushing toward richer text representation, these gaps will hopefully continue narrowing.
References:
- Microsoft Learn: "Customize font selection with font fallback and font linking"
- GitHub PR #10478: conhost rendering fix
- fileformat.info: Unicode character database
- Nerd Fonts: Patched fonts for developers