前面描述了一個字體庫引起的坑: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等可能由於版權加入一些特殊東西