总的来说,印刷排版和字体是一个相当复杂的话题,我并不是很了解。尽管如此,根据
Windows Presentation Foundation中的印刷排版 和相关的MSDN文档,我已经得出以下结论:
- 文字是通过文本渲染流程来呈现的(请参见上面的图表)。
- WPF将OpenType作为TrueType字体格式的扩展来实现。
- 一个重要的低级别文本渲染概念是
Glyphs
元素,请参见MSDNintroduction。
如果您查看所提到的文本渲染管道图,您会注意到,虽然字形是构建块,但它们在最终显示在特定媒介(如屏幕或打印机)之前可能会以各种方式进行处理(过滤/转换/...),例如对LCD屏幕应用ClearType。然而,通常情况下,像管道概念一样,这些变换通常是可选的。
现在,根据您的应用要求,这可能已经得出了一个解决方案。如果您不真正需要TextBox,您也可以只使用Glyphs本身,如下所示:
<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>
Glyphs元素按预期渲染数字为空瓷砖,而TextBox元素则不会。请注意,由于Glyphs是低级元素,因此存在几个限制,特别是FontUri / Fill / FontRenderingEmSize都是必需的,即没有像相关的TextBox属性那样的默认值。
考虑到所有这些问题,回到您最初的问题:
我不认为这是WPF的限制(甚至不是错误),而是在WPF UI布局上下文中应用文本呈现要求和默认值的影响。例如,复合(即非低级)TextBox控件将文本格式设置和排版设置应用于其内容(字形),从而便于嵌入字体中的各种字符映射表(可能有很多...); 特殊/简单的字体(如Scramble)可能没有足够或正确的信息,在这种情况下,WPF呈现引擎可能被迫应用字体回退,就像GalacticCowboy已经概述的那样。
如果确实是这种情况,可能有办法覆盖WPF的默认呈现算法(请参见类
TextFormatter
,即WPF文本引擎),但是很可能需要深入框架来了解
TextBox
内部发生了什么。然而,在Scramble字体中找到最终缺失或不正确的字符映射可能会更容易一些。这将是完全不同的努力...