我試圖製作一個GlyphRun實例以用於GlyphRunDrawing，但文檔太糟糕了，幾乎是滑稽的。例如，參數renderingEmSize描述如下：GlyphRun中的renderingEmSize參數指定了什麼？
renderingEmSizeType: System.Double
A value of type Double.
只是...哇。
我知道一個字體（em破折號的寬度）是什麼，但我不知道網格單元是什麼。設備像素？設備獨立像素？
原來的答案是在源代碼中。感謝MS讓這些可用，如果他們要讓眼睛流血的文檔。
有趣的是，我們需要的所有信息都包含在GlyphRun.cs的xml文檔註釋中。該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