Typography in general and fonts in particular are a fairly complex topic I'm not really into. That said here's what I've figured from Typography in Windows Presentation Foundation and related MSDN documentation:
- Text is rendered by means of a text rendering pipeline (see link above for a diagram).
- WPF facilitates OpenType as an extension of the TrueType font format.
- The
Typography
object exposes many of the advanced features of OpenType fonts.
- An important low level text rendering concept is the
Glyphs
element, see MSDN introduction.
If you look at the mentioned text rendering pipeline diagram you'll notice that while glyphs are the building blocks they may be acted upon in various ways (filtered/transformed/...) before finally getting displayed on a particular medium, e.g. a screen or a printer; one example would be applying ClearType for LCD screens. However, as usually with pipelining concepts, those transformations are more ore less optional in general.
Now, depending on your application requirements, this might already yield a solution. If you don't really need a TextBox you might as well just use Glyphs in itself like so:
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
<Grid>
<TextBox Text="TextBox: 1234567890" FontFamily="Scramble" FontSize="12" />
<Glyphs UnicodeString="Glyphs: 1234567890" FontUri="C:\WINDOWS\Fonts\Scramble.TTF"
FontRenderingEmSize="12" Fill="Black" OriginX="5" OriginY="32"/>
</Grid>
</Page>
The Glyphs element is rendering empty tiles for numbers as desired while the TextBox element does not. Please note that due to Glyphs being a low level element, several restrictions apply, especially FontUri/Fill/FontRenderingEmSize are all required, i.e. there are no defaults like for the related TextBox properties.
With all this in mind back to your original question:
I wouldn't think of the problem at hand as a WPF limitation (or a bug even), rather of an effect regarding the text rendering requirements and defaults applied in the context of WPF UI layout. E.g. the composite (i.e. non low level) TextBox
control is applying text formatting and typography settings to its content (glyphs), facilitating the various character mapping tables embedded in fonts (there are potentially lots of them...); special/simplistic fonts like Scramble might just not provide enough or correct information here, consequently the WPF rendering engine might be forced to apply font fallback as outlined by GalacticCowboy already.
If that's indeed the case, it might be possible to override the WPF default rendering algorithm somehow (see class TextFormatter
, the WPF text engine), but likely one would need to dig pretty deep into the framework to figure out what's going on within a TextBox
. It's probably much easier to 'debug' the eventually missing or incorrect character mappings within the Scramble font. This would be an entirely different endeavor though...