柳鲲鹏

【代码】嵌入式交叉编译：fontconfig（未成功）

【代码】嵌入式交叉编译：pixman。

2024年最新版是1.18.2。

首先确认libz.so与libfreetype.so存在同一目录；然后检查了libfreetype.so的rpath，正确。神奇的事情发生了，竟然糊弄过去了！编译harfbuzz时出现的。

【代码】嵌入式交叉编译：brotli。

这个错误看着十分怪异。

为了省事，禁用了with_brotli=no、with_harfbuzz=no。

要说文字布局最关键的事情，就是基线公式。就是不同大小字体都是在同一个基线绘制。为此吾专门提出了基线公式，并堂而皇之的称之为柳鲲鹏基线公式。基线=布局高度-(字体升部+字体降部)/2+字体降部。

其实字体本身是有高度的，所以这不是问题。而WORD在布局的时候，使用的高度完全不同于字体本身的高度。是不是OpenType的问题？WORD已经这么做了，你也不得不这么做。又称原始高度、物理高度。字体度规读取字体文件时，直接计算得到的高度。字体的本征高度，粗略来说，由字头、字升、字降三部分组成。通过字体布局高度公式，计算得到的高度。为什么这样不清楚，后果就是需要不同系数。字体布局高度=(字升+字降)*1.296868。字体布局高度=(字升+字降)*1.299668。这两个高度都是真实高度。

一开始在.git中寻找，没找到。今天一看，就在源码目录下。赶紧修改，提交，重组。终于收到了pipline success的消息。硬着头皮看了一下，大意是说因为有人利用服务器挖矿，所以要进制限制，然后一通说法。第二次（还是第三次）提交了位图斜体代码，一起没有采纳。看了一下，提示失败：Pipleline failed。

就是对于参数的具体含义是什么。我开始以为是要求我提供一个更好的参数，后来才明白对方问的是参数的具体意思？我就老老实实的回答：我无法回答这个问题，我的工作是建立在粗体基础上。意思是你要不问粗体去？哈哈，粗体现在各家各有做法，没有统一标准。有人奇怪了，大锅这作者不是你啊。因为这个功能进行了反复讨论，最后负责人也是忍无可忍，又重新开了个MQ。FreeType越来越强大完善了！

这个值不是算出来的，是直接从文件中读取的。在这里直接读入一段数据，转换为结构体。

此处的char_height是定点数，6400=100*64(64是6bit的关系）具体函数是ftobj.c中的FT_Request_Metrics()此处有疑点：为什么认为256是定点数？

具体什么用处目前没有研究清楚，从网上搜索了一些说法：units-per-em - SVG：可缩放矢量图形 | MDNThe attribute specifies the number of coordinate units on the "em square", an abstract square whose height is the intended distance between lines of type in the same type size. This is the size of

那么，是不是说，现在粗体还没有标准？

有的字体文件自带粗体部分。那么，与FreeType对比如何呢？这里选用(Times New Roman + 60)

Order is:

Order is:

x_scale和y_scale是26.6的浮点数。

看了一下，欣喜的发现我司提交的代码已正式启用！一方面是我司技术力量强大的体现，另外也是为开源贡献自己的力量。昨天无意中看到2.13.0正式发布，今天专门下载下来准备整合。

继上文吾做了一系列粗体研究之后，负责FreeType的老外看了觉得ppem更靠谱。可是ppem离WORD效果相差较大。吾表示不知道ppem的意思，建议使用72，即point转pixel的单位。第一句话的意思，用中文说，大约是你看看你一天天的……这部分我也确实没有仔细研究就是，不丢脸，哈哈。

我是没想明白为什么。

粗体是有代码的，就是这个计算加粗幅度（比例关系），对方也表示是个经验值，希望能知道原理。所以我先以矢量字体为例，研究一下FreeType是怎么加粗的。加粗与字号有关，这一点是毫无疑问的。对方提出：24是个经验值，能不能找到原因？这说明，关键在于FT_MulDiv。从代码也能看出，差异就在于中间的参数。查了一下FT_MulDiv(a, b, c)，大意是a*b/c。提交了一个粗体代码，对方提出，粗体增加的程度是怎么算的。把x或y的if部分注释，都会导致没有画面。把else部分注释，没有影响。

96与WORD最相似，连其中的横线灰度都一样。VS2012和WORD是有差异的。VS2012和WORD是有差异的。总体来说，FreeType偏粗。

按照weight的说法，应该是支持笔画变细、正常、粗三种方式。551-1000算粗体。难道是我代码写法不对？0-550是正常区。

宽高是完全一样的（有些细节是渲染算法不同导致）。

如果x/y同时有值，就会发生旋转，如果不同可能很怪异，哈哈。单纯从斜体功能来说，显然是我提出的接口好。这次提交代码，就新增的接口，发生了争论。通过参数控制是左右倾斜还是上下倾斜。

我知道有这么个事，具体的说明，是这次向FreeType提交代码，对方提示的。

我以为250号提交被拒了。今天仔细研究了一番，发现是接受了，做了一定修改。接口跟我预计的不一样，这个对方要求，咱就接受了。

梦笔记0207_柳鲲鹏的博客-CSDN博客Add a feature, slant outline glyph with direction l2r or t2b (!250) · Merge requests · FreeType / FreeType · GitLab

上面是WORD，下面是泰山OFFICE。高度都是13个像素。总体来说，泰山OFFICE字高一些。也有例外，如黑、字两个字是WORD高。对于英文、数字，泰山OFFICE的位置偏上，视觉效果上也确实偏上。

就是动不动就要求修改，这里不对那里不对。参与FreeType，有一次自己操作失误，一下子把自己库给删除了，MQ都没有了。最近提交斜体T2B，操作来操作去，十分的麻烦。要合并自己的代码到主分支上，实际上是一种草稿到正式版本的过程。人家也担心你代码进来，万一有问题搞得嗝屁了怎么办？于是耐心的回滚了代码，清理了分支，重新提交代码。

目前得到的数据如下：WORD字号WORD大小布局字体高度布局高度高度位置从上从上从下从下从下202026.6666730.4171334.5850634210.61764720.751041313.834020.38235319.519.52629.656733.7204334200.58823520.232261413.488170.411765小二182427.3754231.1265531190.612903。

英文字体中（如Times New Roman），不同字母宽度不同，为了协调文章排版的疏密，做出适当调整。标点和字的kerning是存在的，又称标点压缩。在文字处理中，标点都是压缩一半宽度。汉字间没有kerning。拼音存在kerning。

当值小于等于字体size的时候，kerning生效。当值大于字体size的时候，kerning无效。比如六号，size=7.5PT（10PX）。变化的原因，是kerning的布尔值。

感觉有点明白，实际上一点也没头绪。

FT_Get_Kerning( FT_Face face, FT_UInt left_glyph, FT_UInt right_glyph, FT_UInt kern_mode, FT_Vector *akerning );结果保存在akerning中。有三种：FT_KERNING_DEFAULT = 0,FT_KERNING_U

ASCPBASEcmapCOLRCPALcvtDSIGEBDTEBLCFFTMfpgmgaspGDEFglyfGPOSGSUBhdmxheadhheahmtxJSTFkernlocaLTSHmaxpMERGmetamortnameOS/2PCLTpostprepSTATVDMXvheavmtxVORGavarBASEcmapcvtDSIG。

从上述表中可以看到，泰山计算的宽度，正好落在上限下限之间。

之前记得某些情况下，Font.canDisplay()有问题。今天试了一下Times New Roman字体对泰的结果，得到了false，说明正确工作了。如果index合法（落在startCount和endCount之间），就可以找到索引。missingGlyph初始化为-1，TrueTypeGlyphMapper()中初始化为0。如果返回的glyph与missingGlyph不同，就可以显示。这个函数中，charToGlyph()得到字符图像索引，如果是-1就是无法显示。