前面描述了一个字体库引起的坑:https://blog.csdn.net/chijingjing/article/details/80549289; 通过三方字体编辑软件重新给字体库编码得到了解决,但是这不是一个很好的解决方案,经过再三研究尝试,总算是有两点眉目.
问题的根本原因: 字体库的字体都是有特定编码映射的, 我们的系统存储的unicode字符编码,所以GIS内核也使用unicode来兼容我们原有的系统文字符号,但是使用内核绘制引擎agg却不能通过unicode找到字体在字体库的位置, 给freetype调用的字体设置编码也不行.
问题的解决办法: 字体都是有版权的, 一般的字体库的映射编码规则都有unicode,但是如果不带Unicode映射那么可以使其他编码映射目前:常用的三种映射:
Mac ,Ms, Unicode的,最初认为MS和Unicode等价,因为受word,execl等插入字体符号的时候误导,如下:
但是还是太年轻,殊不知MS偷偷做了事情, 我们存这个字体原有使用com组件存储了45(十进制69) ,但是在ttf文件中其实是F045,那么这类字体将绘制的字符直接加F000 即可在freetypeAPI中找到他们了.
总结一下有两点: 1: freetype 设置正确编码映射
2: 不知名原因的某些字体竟然需要偏移F000然后才能找到字体.
尝试的解决办法如下:
1:更换freetype库的版本,(经验证此方法没用)
2:重新安装字体库,(没用)
3:小程序直接调用freetype读取字体库并设置字体编码映射再并绘制:
分两次尝试: 直接调用C:\windows\fonts下的字体库, 有些成功有些字体失败(后经过验证失败的字体是个错误的字体文件,我安装的字体文件为30K,通过everything和代码查找到的字体文件为10K,并且查找到的文件名不同,都删除掉就可以了 )
freetype:主要设置如下:
通过编码找到字体:
字体找到了后面就都是绘制的事情,不做描述.
后续还有一个探寻方向: 通过遍历所有字体找到对应的字, 但是这个方法目前还有一些问题,所以暂时不提供了,主要使用函数如下:
FT_UInt agindex[1];
agindex[0] = 0;
FT_ULong a = FT_Get_First_Char(face, agindex);
int ccc = 0;
FT_ULong charcode = a;
while (a != 0)
{
a = FT_Get_Next_Char(face, charcode, agindex);
std::wcout << a << std::endl;
if(a!= 0)
charcode = a;
ccc++;
}
此方法能找到所有charcode, 但是我的charcode是 以前com组件或者第三方字体生成,部分字体对不上这个code.
所以大家最好还是用unicode 这个编码目前看来坑最少. ms, mac等可能由于版权加入一些特殊东西