疑似文泉驿字体 BUG

感谢您的工作。鉴于文泉驿没有源码,而这个 BUG 影响字符数量众多,并且 0.9.46-May 到 0.9.47-snapshot 并不是一个有着重要修改的更新,退回 0.9.46 似乎是可行的一个折中方案。

我肯定是要使用 google 的 fontmake 从零编译文泉驿的,因为只有这样才能让它长存而不是死掉…我已经把 .ttc 拆分成 .ttf 转成 .ufo3 格式丢到 GitHub 上去了,仓库在:GitHub - marguerite/wenq: WenQuanYi Fonts in ufo3 format

我检查 ufo3 格式发现它其实就是 .xml。然后我就去 glyphs 文件夹下找到一个有问题的字,比如艺术的 “艺” 字是 uni827A_.glif。打开格式是这样的(不是一个完整的字,有删节):

<?xml version="1.0" encoding="UTF-8"?>
<glyph name="uni827A" format="2">
  <advance width="1024" height="1024"/>
  <unicode hex="827A"/>
  <outline>
    <contour>
      <point x="215" y="403" type="line" smooth="yes"/>
      <point x="151" y="403"/>
    </contour>
    <contour>
      <point x="135" y="719" type="line" smooth="yes"/>
      <point x="18" y="722" type="qcurve"/>
      <point x="20" y="688" type="qcurve" smooth="yes"/>
    </contour>
  </outline>
</glyph>

这里很好猜,outline 是一整个字,contour 是左右或者上下这种分开的结构。里面带 (x,y) 的 point 就是画字形的锚点。

对应打开 fontforge 的界面(看我前面的图),是有 (x, y) 坐标系的,那么解决方法就是:

找到出问题的点,删掉它。

经过排查(就是在 fontforge 图形界面看个大概,然后打开 .glif 文件去找大概点,之后删掉这个点,再图形界面打开看效果),问题在这里:

      <point x="4" y="95"/>
</contour>

出问题的艹字头字基本在第二个 contour 的最后一个 point,都是 x = 4 且 y 不等的。

那么我们可以通过 programming 来解决啦,稍等我写个程序跑一下看看。

文泉驿不是开源的么?

开源的但你能改吗?

我也不懂啊。。。你说的文泉驿源码不公开,我就有点懵了

当然不公开了…在 wenq 自己的服务器上谁也没见过

我写了个程序跑了一遍,应该是这些字显示不对:

你看看跟你的情况是不是一样 @BearChild

文本:

艺艻艼艽艾艿芀芁节芃芄芅芆芇芉芊芋芌芍芎
芏芐芑芒芓芕芖芗芘芙芚芛芜芝芞芟芠芡芢芣
芤芥芦芧芨芩芪芫芭芮芯芰芲芳芴芵芶芷芸芹
芺芼芽芾芿苀苁苂苃苄苅苆苇苈苉苊苋苌苍苎
苏苐苑苒苔苕苖苗苘苙苚苜苝苞苟苠苡苢苣苤
苦苧苨苩苪苫苬苭苮苯苰苲苳苴苵苶苷苸苹苺
苻苼苽苾苿茀茁范茄茅茇茈茉茊茋茌茍茎茏茐
茑茒茓茔茕茖茘茙茚茛茜茝茞茟茠茡茢茣茤茥
茦茧茨茩茪茫茬茭茮茯茰茱茲茳茴茵茶茷茸茹
茺茼茽茾茿荀荁荂荃荄荅荇荈荊荋荌荍荎荏荐
荑荒荓荔荕荖荗荘荙荚荛荜荝荞荟荠荡荢荣荤
荥荦荧荨荩荪荫荬荭荮药荰荱荲荳荴荵荶荷荸
荹荺荻荼荽荾荿莀莁莂莃莄莅莆莇莈莉莊莋莌
莍莎莏莐莑莒莓莔莕莖莗莘莙莚莛莜莝莞莟莠
莡莢莣莤莥莦莧莨莩莪莬莭莮莯莰莱莲莳莴莵
莶获莸莹莺莻莼莽莾莿菀菂菃菄菅菆菇菈菉菊
菋菌菍菎菏菑菒菓菔菕菖菗菘菙菚菛菝菞菟菠
菡菢菣菤菥菦菧菨菩菪菫菬菭菮菰菲菳菴菵菶
菷菸菹菺菻菼菽菾菿萀萁萂萃萅萆萇萈萉萊萋
萌萍萎萏

是的,这些字符都有问题。然后 @benren 提到的 “韭菜还会显示成非菜” 的问题也是存在的,我这里成功复现这个 BUG,能不能请您也一并看一下?

好的,我先写程序把上一个修复了。然后做一个测试版本给你用看解决没有。然后再看别的。真正推送修复需要我把 google 的 fontmake 编译链在 openSUSE 上建立起来。

另外说一句,文泉驿没有粗体版本,只有 Regular Sharp 和 Monospace。至少从代码看是这样。我怀疑粗体是 fontconfig/freetype fake 出来的版本

私以为,这种问题在于上游没有维护好这个字体的持续发布工作。下游去构建字体的难度巨大,去修字体就更费力了。所以我觉得,这种上游没搞明白的项目,要么去给上游开发者提意见,要么就任它自然消亡了……

1赞

@guoyunhe

理论上确实是这样,不过这个 snapshot 确实是我引入 openSUSE 的,版本号比正常的大,即使回退了也没法走更新通道,别的发行版没有这个问题,于是谁污染谁治理,难也得上… :joy:

1赞

竹字头相关的字也有这个问题:

至于韭菜的韭则是另一个问题了:

这是设计问题,它出 grid 了所以显示不出来 :rofl:

1赞

@BearChild

你下载 GitHub 源里的 WenQuanYiZenHei-Regular.ttf 测试看看,需要把原来的 wqy-zenhei.ttc 删掉装上我的重新运行 sudo fc-cache。修复了草字头的问题

竹字头也已经筛选出来了:

文本:

箚箛箜箝箞箟箠管箢箣箤箥箦箧箨箩箪箫箬箭
箮箯箰箱箲箳箵箶箷箸箹箺箻箼箽箾箿節篁篂
篃範篅篆篇篈築篊篋篌篍篎篏篐篑篒篓篔篕篖
篗篘篙篚篛篜篝篞篟篠篡篢篣篤篥篦篧篨篩篪
篫篬篭篮篯篰篱篲篳篴篵篶篷篸篹篺篻篼篽篾
篿簀簁簂簃簄簅簆簇簈簉簊簋簌簍簎簏簐簑簒
簓簔簕簖簗簘簙簚簛簜簝簞簟簠簡簢簣簤簥簦
簧簨簩簪簫簬簭簮簯簰簱簲簳簴簵簶簷簸簹簺
簻簼簽簾簿籀籁籂籃籄籅籆籇籈籉籊籋籌籍籎
籏籐籑籒籓籔籕籖籗籘籙籚籛籜籝籞籟籠籡籢
籣籤籥籦籧籨籩籫籬籭籮籯籰籱籲

BUG 确实修复了,但字体与 NotoSans 一样有点莫名粗大,会把 UI 莫名其妙的撑大。比如下两幅图的菜单,第一张是修复后的字体,第二张是文泉驿米黑,可以明显看到,在字号没有改变的情况下,修复后字体改变了 UI 大小。原本文泉驿正黑与米黑应该表现一致,这也是我不用 Noto 的原因。看来是 Google 的工具把字体搞大的。


@BearChild 能圈一下哪里不一样吗?我看不出来啊

请将左边的应用程序启动器的高度对比一下,截图时我采用的相同分辨率与 DPI,有背后全屏的 Firefox 作参照物应该不难看出。

这个 100% 不应该是字体背锅 :joy:

我怀疑是行高的处理代码有 bug。这个 diagnostic 方法 patch 一下让它在 text 周围描红边。先别关注这个了。

如果这是个 QT 的 Bug,那他存在的时间绝对在一年以上,QT 毕竟是商业软件,这种明显影响布局的 bug 长时间存在,我感觉可能性不大。 :sweat_smile: