用as函数绘制EMF文件

--------感谢老大和涛涛(这称呼只有老大的老大才叫的，这里放肆一下,嘿嘿)，还有良胜。都是牛人的说.

 

刚要做这个的时候,摸不清下手的点在哪里,连EMF文件,矢量绘图,都不清楚是啥, as的绘图函数压根就没用过,B/S模式读取文件更是啥都不懂。当时想了两条方向，要么在浏览器这边转格式，要么在服务端那边转完再发过来。根据flex的特色，只能读取JPG,PNG,GIF格式的图片，

在浏览器这边转是必定难度大与服务器端转换。而且都是最后转成JPG，所以肯定是在服务端转完再传回来更方便。但是当时脑袋瓜子就是灌水了，naive地觉得在客户端读取图片数据，然后调用个库swc进行转换。更naive地觉得可以用交叉编译补充as绘图函数的不足.最后才发现一切都是naive以及不想去正视这个问题(也就是想走捷径).老一辈说得对，想走捷径的人往往走得最长.

但是还是总结一下交叉编译这块。虽然有弯路走，但是收获不少。

======================================================================================

在这个崎岖的过程，要感谢两位一直都帮我的哥们。(jumping,czcomt)都是牛人的说。。。

 

先是jumping 跟我说了试试开源库，于是乎我找到了cximage;

后来czcomt跟我说了flash有物理引擎库，于是乎我找到了交叉编译，swc,和一系列的flash函数库.

 

当时我设想是cximage的解码库没有用到windows api(确实,BMP那块是没用到API，但是EMF那块却用:()，那么就可以用cygwin+alchemy把那个库编译成swc然后套进SWF来转换格式。(感谢jiji哥多次过来指导使用cygwin)。

 

嗯，当时确实没去了解cximage解码库是否真的没用到api,直接干交叉编译那块，其实我很好奇adobe那个把 snake游戏编成SWC，原来是用C怎么做的。确实交叉编译这块功能很强大，但是只能用来弄纯逻辑的，既然是纯逻辑的就没有必要用交叉了吧，AS做纯逻辑也是很不错的。不过当时就是傻，不知道对于这些显示图片的东西是非常依赖平台的，既然要跨平台了，就不能用API，也就是要显示图片，绘制图片这些动作都无法靠SWC来实现的。

 

提供一下在这过程找的资料。

cygwin使用：

http://bbs.actionscript3.cn/viewthread.php?tid=20233&page=1#pid176466

 

alchemy 配置:

http://bbs.actionscript3.cn/viewthread.php?tid=20233&page=1#pid176466

 

alchemy调用API

http://203.208.37.132/translate_c?hl=zh-CN&sl=zh-TW&u=http://labs.adobe.com/wiki/index.php/Alchemy:Documentation:Developing_with_Alchemy:C_API&prev=/search%3Fq%3DAlchemy%2Bgcc%2Bubuntu%26hl%3Dzh-CN%26sa%3DG%26newwindow%3D1&rurl=translate.google.cn&usg=ALkJrhgGRp8ick3-rkVnL49WU9RIzNbW7g

cximage官方资料

http://www.codeproject.com/KB/graphics/cximage.aspx

 

也就在这个时候，我看了cximage 的解码库内的WMF这块的代码后，彻底绝望了，用了几个win api。也就说前面的努力都是白费了。第三方库不是一个走得通的方案，或者应该说第三方非浏览器语言是走不通的。平台依赖的问题.不过当时还没有放弃，就是看了ooo能在linux 上显示emf图片，这点倒是让我喜出望外.看了ooo里面是用了libemf库，里面的函数仿真windows 的，可以运行在linux,freebsd,unix上，但是不能排除它是用了其他平台的API，要知道涉及到平台的问题，大多数都无法跨的。这样，非flex的第三库都是走不通，而flex的第三方库是还没有读取emf的。所以走捷径是不通，要去一点点地分析图片信息，读取里面的数据再用as绘图函数绘制出来。

 

现在已经初步把一个emf图片画出来，剩下的功夫放在对每个GDI函数的解读数据，以及函数仿真上。这部分的总结就等下次把emf,swf,wmf，RGB颜色表，矢量绘图，调色板之类弄懂后再做。