jynxio / font-caster

Ultra-simple font subsetting library

"I am idle and aimless here."

font-caster's Issues

BUG: The `read` API will read the ".DS_Store" file.

Description

For MacOS, this method will misread .DS_Store when dealing with folders, you can find and filter it by the name and type attributes.
For .DS_Store file, the value of the name property is ".DS_Store" and the value of the type property is ""

platform

MacOS

BUG: Cannot handle escape characters.

Description

The library lacks the ability to handle HTML escape characters, The read, parseHtml, and subset APIs all treat HTML escape characters as normal strings.

字符的行高或尺寸发生了变化吗？

结论

没有发生变化，经该库处理后的 字体文件的字符的行高或尺寸 与 原始的字体文件的字符的行高或尺寸 是一致的。

描述

关于 FontDrop!

首先，称原始的字体文件为 font-origin，称子集化的字体文件为 font-subset。

如果你使用 FontDrop! 来分析 font-origin 和 font-subset，你会发现 font-origin 和 font-subset 的同一个字符的尺寸不一致，比如：

左图是 font-origin 的字符 X 在 FontDrop 中的样式，右图则是 font-subset 的字符 X 的，可以看出右图的字符的尺寸更大。

造成这种现象的成因来自于 FontDrop! 对字符的渲染机制，而不是这个库。详细来说，FontDrop! 会统计输入的字体文件中的所有字符的 boundingBox，然后计算出一个最大的 boundingBox，最后每个字符都会根据这个最大的 boundingBox 来渲染。如果某个字符的 boundingBox 的尺寸与这个最大的 boundingBox 的尺寸很接近，那么这个字符被 FontDrop! 渲染出来后，就会显得占满了整个区域，就像上图的右图。反之，如果某个字符的 boundingBox 的尺寸比这个最大的 boundingBox 的尺寸小的多，那么这个字符被 FontDrop! 渲染出来后，就很显得很小，就像上图的左图。

所以上图现象的真正成因是：font-origin 和 font-subset 的同一字符的 boundingBox 是一样的，但 font-origin 和 font-subset 的最大的 boundingBox 是不一样的。

因此，当你看到类似上图的现象时，你不需要怀疑该库是否破坏了原始字符的尺寸，实际上，该库没有改变字符的尺寸。

另外，下图是 font-origin 和 font-subset 两份字体文件分别在 HTML 中的渲染效果，可见 font-origin 和 font-subset 的字符的行高和间距都是完全一致的。

关于 three.js

如果你将 three.js 的 FontLoader.js 和该库结合在一起使用，你就有可能遇到该问题，否则你可以忽略这个小节。
当我使用 FontLoader.js 时，我发现，如果传入 FontLoader.js 的字体是未经该库处理后的字体，则会产生下图中左图的样式，如果传入 FontLoader.js 的字体是经过该库处理后的字体，则会产生下图中右图的样式：

造成这种现象的成因来自于 Facetype.js 对 boundingBox 的计算方式，而不是这个库。

Facetype.js 是一个将诸如 otf、ttf 等格式的字体文件转换为 json 格式的字体文件的开源库，使用它的原因是 FontLoader.js 需要使用 json 格式的字体文件。

详细来说，Facetype.js 会统计传入的字体文件的所有字符的 boundingBox，然后计算出最大的 boundingBox，这个最大的 boundingBox 的数据就存储在生成的 json 字体文件的 boundingBox 字段中，然后 FontLoader.js 会基于这个最大的 boundingBox 来绘制每个字符。

由于在这次实践中，子集化的字体文件只包含 J、Y、N、X、I、O 六个字形相近的字符，基于它们统计得到的最大的 boundingBox 与每个字符的 boundingBox 都很相近，所以字符串 JYN\nXIO 在 three.js 中的渲染效果就更紧凑（是一种行高为 1 的效果）。而原始的字体文件包含八百余个字符，其中不乏许多类似上标和下标之类的字符，由于它们的存在，导致统计得到的最大的 boundingBox 比 J、Y、N、X、I、O 六个字符的 boundingBox 要大得多，所以字符串 JYN\nXIO 在 three.js 中的渲染效果就更疏松（是一种行高为 1.5 的效果）。

这才是造成这种现象的成因。

该如何解决这个棘手的问题呢？其实，看完上文你就应该明白，对于字体族相同而字符数不相同的字体文件而言，分别使用它们来在 three.js 中创建文字，会很容易导致行高不一致的结果，对于字体族不相同的字文件而言，也可能会有类似的问题。
这是一个根植于字体文件的问题，你不应该对 three.js 或该库 debug。我的解决办法是：使用 Box3 来统计每个字符的尺寸，然后根据我期望的行高与间距，来位移每个字符。

环境

• three.js: 139.2
• chrome: 100.0.4896.88 (arm64)
• font: IBM Plex Mono Regular 400