直读TTF的进展（轮廓信息完成，进入2D阶段，50%）

正确含曲线（2010.5.8日凌晨三点取得此进展）不含曲线。（2010.5.5日凌晨四点取得此进展）

黑体的字体没有一个用曲线的。突然想到了微软雅黑，不含曲线生成也快些，下次用微软雅黑看看。

做了很多测试，主要是纳闷在truetype曲线格式的描述上，资料太少了，做过的那些同志都是一笔带过，没有人详细解析一下，truetype那一长串不再曲线上的点应该做何解释。我现在是对于一串的，就按照二阶贝塞尔的要求，按照 012 234 456 这样的顺序来绘制曲线。

得空还得去研读一下freetype的源代码，看是不是这么回事儿，至少现在这个视觉是对的。

使用方法如下，先是从文件中获取一个字模

Render2Path过程，从字模信息建立一个FontCurveList对象。

然后Render，最后取出pathlist，就是点列表了，直接用这些信息创建VertexBuffer就可以了。

Render参数传入的是细分贝塞尔曲线的距离，我是采用一个按照曲线长度去细分，比如传入0.2，就是在一条曲线上每0.2距离创建一个顶点。实际上传0.2分的过于细小了，会产生大量的顶点。

freetype默认的绘制空间都是相当大的。具体的尺寸可以看FontCurveList里面的FontSize成员，至于传入的那个'’干’，是个冗余参数，忘了删掉。

下一步就是再设计一个CLFont_Render2Texture.

历史 （from 2010.5.2，每天都到凌晨三四点）

错误结果  。

这个主要是曲线绘制的问题，没有把每段曲线分开绘制。而且truetype的第0个点完全就是为了标位置的，不参与绘制。就正确了。

但是我用simsunb.ttf怎么也输出不了一个正常的汉字，都是些极为生僻的。

一开始我以为我cmap表解析错了。查了一晚上，找不出毛病。还顺便查到资料，这个字库的cmap表使用了一个opentype的cmap format12扩展，用USC-4的。

辛苦了半天手写了Utf-8到USC-4的转换，WP7 SDK 的UTF32不让使用，有些奇怪。后来发现simsunb.ttf的cmap表里记录着0x20000以后的文字。

一查是中日韩的不常用字。。。。。。。。。。。。，这原来是一个CJK-B扩展字库。

人生若梦。。。。

换字库，试了几个小字库有些字会出错，cmap表里会放置一些不存在的字，不知道不存在是不是应该去找宋体。

然后找了厚道的老牌黑体、楷体，终于正常的绘制了出来。

正确结果

用的纯c#，保证可以移植windows phone 7。效率肯定是和unsafe的代码没法比。

而且发现windows phone 7 环境用的 dotnet framework 3.微软拟累不累啊。

PC让我用4，Windows phone 7 让我用三，虽然所差不多，但还是得编译一下试试，你这是为了宣传你能创建copy项目很牛嘛？

我现在就建立了copy版的windows phone 7 项目，随时需要保证代码兼容性。

字的读取完成了30%吧，如果要用作3D文字已经可以了。但到2D，还有一个过程，还要取得字符的排版信息。

不晓得微软会不会做个dotnet版本的字体封装，越来越觉得我这是在做微软应该做的事儿。