Web浏览器如何实现字体后备？ [英] How do web browsers implement font fallback?

问题描述

我很想知道字体回退在字体整形/渲染堆栈中的位置。换句话说，在什么时候检测到缺失的字形，以及它们是如何被替换的？

我在

所以问题是：

p>

1. 这个算法到底有多精确？
   
2. 这是大多数浏览器使用的标准算法 - webkit， gecko（可能不是IE）？


3. 字体是如何基于字体中的缺失字形进行回退的，这种字体与CSS字体回退相关（指定要使用哪种字体完全失踪）？

编辑：我发现这个文档解释了什么的FontConfig，但不是如何。问题1是关于如何。总而言之，这篇文章实际上只涉及到一件事 - 当字体丢失字形时，字体回退如何工作。

在浏览器中的字体后备（而不是在一个操作系统中）是基于两件事情：

文本引擎， >

CSS规范在这方面相当简单，只需使用系统名称给出字体列表，但是有几种可能的全部捕获字体（没有理由认为 serif 映射到 Times 或 Times New Roman ，例如）。

文本引擎使用的回退算法完全取决于引擎，但通常在字形查找步骤中踢：文本引擎看到一串co de点，并尝试使用字体来形成该字符串。对于序列中的每个点，它检查字体是否具有匹配的字形（通过查阅CMAP表和子表），或者通过规则告诉引擎可能有一个字形只在更多的代码点跟随时使用GSUB机制（例如，对于单个字母 e ， t 和 c ，但带有& 的字形和一个表示序列 e 的GSUB规则> + t + c 应该被替换为单个字形& ），当它完成积累这种点数单位时，它会将文本形成文本，并将其传递给要求对文本进行形成的任何内容。

如果在字形查找过程中发现字体不包含任何让引擎形成特定代码点的东西（例如，运行CMAP数据以及GSUB规则仍显示没有字形）那么文本引擎可以做两件事：

1. 放弃。没有字形，而是使用定义为字形0的 .notdef 大纲，并且通常给你带有可爱空框的文本（被字体亲切地称为豆腐）或
   
2. 尝试字体回退，在此处尝试另一种字体以查找不支持的代码点的字形。

使用备用时，引擎可以下载一个备用字体列表，直到：（a）找到字形，或者（b）列表已用完，此时引擎 放弃，并将使用 .notdef 字形。无论引擎是从原始字体还是从列表中的最后一个字体中抓取 .notdef 字形，都完全取决于引擎（尽管通常它会随着第一个字体，易读性）

这个定义的任何地方都没有标准算法;字体回退基本上是文本引擎作者提供的便利机制，比如浏览器带有书签管理器（方便，而不是任何规范的一部分）。就OpenType而言，没有要求在没有找到字形的时候，引擎是否只需要提供 .notdef ，或者它是否应该提供可以塑造，然后在其他地方找到失踪的字形，并以这种方式呈现文字。 CSS意味着你的文本引擎应该至少有某种形式的字体后备，但是它没有指定它应该如何工作，或者它应该什么时候开始。

I'm interested in knowing where font fallback fits in the font shaping/rendering stack. In other words, at what point are missing glyphs detected and how are they substituted?

I see in this document that the FontConfig tool does font fallback "based on glyph coverage transparently."

So the questions are:

1. How exactly does this algorithm work?
2. Is this the standard algorithm used by most browsers - webkit, gecko (probably not IE)?
3. How does font fallback based on missing glyphs within a font that does exist relate to CSS font fallback (which specifies which fonts to use in turn, when a font is entirely missing)?

Edit: I found this document which explains the "what" of FontConfig, but not the "how." Question 1 is about the "how."

To summarize - this post really has to do with one thing only - how does font fallback work when glyphs are missing in a font.

解决方案

Font fallback in browsers (as opposed to, say, in an OS) is based on two things:

1. The CSS specification, which gives the fonts that are to be used for fallback, and
2. The text engine, which does text shaping.

The CSS spec is fairly trivial in this respect, simply giving the list of fonts using their system names, but several possible "catch all" fonts that are in no way guaranteed to be the same from computer to computer (there is no reason to assume that serif maps to Times or Times New Roman, for instance).

The fallback algorithm used by text engines is entirely up to the engine, but usually kicks in during the glyph lookup step: the text engine sees a string of code points, and tries to use a font to shape that string. For each point in the sequence, it checks whether the font has a matching glyph (by consulting the CMAP table and subtables), or a rule that tells the engine that there may be a glyph to use only if more code points follow, through the GSUB mechanism (For instance, a font without glyphs for the individual letters e, t and c, but with a glyph for & and a GSUB rule that says the sequence e+t+c should be in-text replaced with the single glyph &), and when it's finished accumulating this kind of "unit of points", it shapes the text and hands it back to whatever asked it to shape text.

If, during glyph lookup, it turns out the font doesn't contain anything that lets the engine shape a particular code point (i.e. running through the CMAP data as well as the GSUB rules still shows "there is no glyph") then the text engine can do two things:

1. Give up. There is no glyph, instead use the .notdef outline defined as glyph id 0, and generally give you text with lovely empty boxes (lovingly called "tofu" by font folks) or question marks.
2. Attempt font fallback, where it will try another font to find a glyph for the unsupported code point in.

When using fallback, an engine can go down a list of alternative fonts until either: (a) a glyph is found, or (b) the list is exhausted, at which point the engine has to give up, and will use the .notdef glyph. Whether the engine grabs the .notdef glyph from the original font, or from the last font in the list, is entirely up to the engine (although usually it'll go with the first font, for legibility)

There is no "standard" algorithm for this defined anywhere; font fallback is basically a convenience mechanism offered by text engine authors, like how browsers come with bookmark managers (handy, and not part of any spec). As far as OpenType is concerned, there are no requirements on whether an engine should just serve up .notdef when a glyph is not found, or whether it should serve up the part it could shape, then find the missing glyph somewhere else, and render text that way. CSS implies that your text engine should have at least some form of font fallback, but it doesn't specify how it should work, or when it should kick in.

这篇关于Web浏览器如何实现字体后备？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！