UNICODE编码所有的汉字都是以笔画进行排序, 从4E00到9FA5,(4E00 是"一", 4E01大概是"丁")
BIG码我就不清楚了, 按照展迅的老代码, 感觉是GBK的编码排序的, 所以代码中检索字库中的字符索引用的是(高字节位-A1)极人臣* 5E + 低字节位 - A1, GBK好像是从A1A1(本地码)开始的.
以前我给展迅做字符显示可支持繁体时, 都是用的UNICODE字库,所以不管是简体还是繁体都不需要更改代码. 不过UNICODE码中汉字和标点符号的编码不是连续的, 所以必须修改guifont.c中的关于得到当前字符索引的函数代码.
不过我不敢恭维展迅负责编写应用模块的工程师, 取个最简单的例子, guifont.c文件中计算当前字符的宽度时, 使用的时gui_GetFontWidth(is_ucs2), 感觉这里的is_ucs2表示的是半角字符(ASCII)与全角字符的区别. 可有很多地方比如编辑框时, is_ucs2是表示当前字符的编码是GB码或UNICODE码之间的区别. 在本平台下的确是只要有汉字就使用UNICODE编码, 所以就不会出现通过UNICODE编码来判断是不是全角字符宽度的错误. 如果全角字符等于半角字符的2倍宽度时,也不会出现错误. 那如果全角字符不等于半角字符的2倍受欢迎宽度时, 通过is_chinese判断是不是中文再调用getFontWidth函数也会出现错误的.
支持繁体字库的改动不是很大的, 要是支持如越南语或俄语的话就把我的命给改掉了. 因为俄语的本地码>0x80所以展迅平台中就认为它是中文字符, 处理时, UNICODE编码转换, 宽度计算都得修改!
希望展大哥也该改进APP中的源代码了, 从D平台到M平台中的代码明显错误都是一样的, 2003年的代码几乎都没改动过. 代码优化也应该做做了.
不过RESOURCEEDIT的功能改动还是很大的,M平台的资源管理器的确好用, 这可不是吹! D平台提供就不好用,特别是多个项目共用时. |
楼主
标题置顶
标题高亮
