我正在尝试在GlyphRun中使用GlyphRunDrawing实例，但文档非常糟糕，几乎可笑。例如，参数renderingEmSize的描述如下：
renderingEmSizeType: System.Double
A value of type Double.
只是......哇。
我知道字体中的“em”是什么（em破折号的宽度），但我不知道网格单元是什么。设备像素？设备无关的像素？
答案 0 :(得分：1)
原来答案在源代码中。感谢MS让这个可用，如果他们要在文档上流眼泪。
有趣的是，我们需要的所有信息都包含在GlyphRun.cs的xml doc评论中。例如renderingEmSize如下：
<param name="renderingEmSize">Font rendering size in drawing surface units (96ths of an inch).</param>
文件的其余部分也有类似的评论，包括这看似不合时宜但令人抓狂的读物：
/*
The default branch prediction rules for modern processors specify that forward branches
are not to be taken. If the branch is in fact taken, all of the speculatively executed code
must be discarded, the processor pipeline flushed, and then reloaded. This results in a
processor stall of at least 42 cycles for the P4 Northwood for each mis-predicted branch.
The deeper the processor pipeline the higher the cost, i.e. Prescott processors.
Checking for multiple incorrect parameters in a method with high call count like this one can
easily add significant overhead for no reason. Note that the C# compiler should be able to make
reasonable assumptions about branches that throw exceptions, but the current whidbey
implemenation is weak in this regard. Also the current IBC tools are unable to add branch
prediction hints to improve behavior based on run time information. Also note that adding
branch prediction hints increases code size by a byte per branch and doing this in every
method that is coded without default branch prediction behavior in mind would add an
unacceptable amount of working set.
*/
可以在此处找到整个文件：GlyphRun.cs at webtropy