【发布时间】：2017-01-03 11:20:49
【问题描述】：
我正在开发一个字体检测库，它需要非常非常小，适合在网站的每个页面上包含内联。我已经把它弄得很小了（417 字节压缩）。您可以通过the Github repo查看。
经过进一步思考，如果我可以做出一些基本假设，我可以再次显着减小库的大小（大约另外 10%）：
- 如果没有space 字符/定义，就不可能定义一个工作字体文件（无论如何对于浏览器）。
- 或者，如果可以创建这样的
space-省略字体，那么当需要space字符时，所有现代浏览器和IE9+ 都会选择备用字体的space字符。也就是说，就字体回退而言，space字符并没有什么特别之处。 - 而且，切线，所有现代浏览器和 IE9+ 将在浏览器提供的
serif和monospace通用字体中具有不同的space字符宽度（可能，但我需要进一步测试）。
我只是尝试使用FontSquirrel's font generator 明确定义没有space 字符的字体。这是通过明确省略所选子集中的空格并禁用space 的“修复缺失字形”来完成的。 FontSquirrel 仍然生成了一个带有space 字符的字体，其宽度不同于serif 和monospace。
我了解某些语言没有传统意义上的space 字符，但由于字体文件格式和定义的性质，我认为为这种语言量身定制的字体不能或不会省略@ 987654338@ 字符。
如果这些假设都成立，则库可以消除支持自定义文本检查的需要，并将测试数量从 3 减少到 2，同时加快库并减少其内存使用量。 gzip 压缩后的新大小约为 380 字节或更少。
字体专家，怎么样？是否可以在没有space 字符定义的情况下定义有效字体？如果有这样的字体，可以举个例子吗？
【问题讨论】：
-
我不知道你在问什么，但我建议你问问自己：你真的在乎吗？ 40字节？这产生任何影响的可能性非常小，不值得你花时间......
-
浏览器中的第二个请求应该已经来自缓存，因此大约 40 字节的节省可能只适用于第一个请求。由于大多数网站还下载大型 JS 库，因此大约 500 字节的总字节数不太可能有多大关系，更不用说这种优化可能节省的成本了。
-
这很重要，因为我正在构建的网站被设计为完全内联。所有 HTML、CSS、JS、SVG 和一些图像都将被内联，只留下字体文件和更大的图像需要额外的 http 请求。只要所有内联的总大小小于 14 kb 左右（gzip 压缩），就可以在单个 http 请求中交付，甚至比缓存这些资源更有效。在这些条件下，40 个压缩字节已经很多了。
-
简短回答：是的。更长的答案：processingjs.nihongoresources.com/the_smallest_font（特别突出的是，如果需要加载 gzipping 以进行某种即时测试，那么 gzipping 就不是最有意义的）
-
没有想到，因为对于普通字体没有空格是没有意义的。 Unicode 的 ASCII 范围在任何真正的字体创建应用程序中都得到了微不足道的支持，因此即使是非拉丁语言也倾向于支持。
标签： javascript css browser fonts whitespace