web字体设置成平方字体
When using web fonts we must carefully avoid its hidden pitfalls. To do this designers, frontend developers, DevOps, and authors each have a role to play in creating a great end-user experience.
使用网络字体时,必须小心避免其隐藏的陷阱。 为此,设计师,前端开发人员,DevOps和作者在创造出色的最终用户体验中均应发挥作用。
- Designers need to establish font stacks that can realistically be delivered to users over restricted bandwidths. 设计人员需要建立字体栈,以便可以在有限的带宽上实际交付给用户。
- Frontend developers need to pay attention to CSS rules that can speed things up. 前端开发人员需要注意加快速度CSS规则。
- DevOps needs to make sure font files are fetched at the right time, and cached aggressively once downloaded. DevOps需要确保在正确的时间获取字体文件,并在下载后积极缓存。
- Content authors need to let everyone else on the team know about special glyphs and foreign language character sets that they use. 内容作者需要让团队中的其他所有人知道他们使用的特殊字形和外语字符集。
Here are some practical tips and strategies for getting fast accurate typography using real-world network bandwidths.
这里有一些实用的技巧和策略,可以使用实际的网络带宽来获得快速准确的排版。
@ font-face规则 (The @font-face rule)
Let’s begin with a typical example. The designer chooses a typeface for their website articles with a careful eye for readability. The designer then declares the typeface, size, leading, white space, and color using CSS like this:
让我们从一个典型的例子开始。 设计师为网站文章选择字体时要特别注意可读性。 然后,设计人员使用CSS声明字体,大小,前导,空格和颜色,如下所示:
article {
font-family: 'Source Serif Pro', serif;
font-size: 12pt;
line-height: 1.4;
margin: 1rem;
color: hsl(0,0%,15%);
background-color: hsl(0,0%,85%);
}
In order to implement this, the frontend developer specifies @font-face rules like this:
为了实现这一点,前端开发人员指定了@ font-face规则,如下所示:
@font-face {
font-family: 'Source Serif Pro';
font-weight: 400;
font-style: normal;
font-display: block;
src: local('SourceSerifPro-Regular'),
url('/fonts/source-serif-pro-400-latin.woff2')
format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Source Serif Pro';
font-weight: 400;
font-style: italic;
font-display: swap;
src: local('SourceSerifPro-It'),
url('/fonts/source-serif-pro-400-italic-latin.woff2')
format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
U+FEFF, U+FFFD;
}
@font-face {
font-family: 'Source Serif Pro';
font-weight: 600;
font-style: normal;
font-display: swap;
src: local('SourceSerifPro-Semibold'),
url('/fonts/source-serif-pro-600-latin.woff2')
format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
U+FEFF, U+FFFD;
}
At first glance, this looks like an excessive ruleset just for a simple CSS declaration. So let’s examine each property to understand what’s possible.
乍一看,这看起来像一个过多的规则集,仅用于简单CSS声明。 因此,让我们检查每个属性以了解可能的情况。
For all three rules, the font-family
is the same. It matches the name specified in the CSS declaration.
对于所有三个规则, font-family
是相同的。 它与CSS声明中指定的名称匹配。
It’s the font-weight
and font-style
properties that are the telling difference.
区别在于font-weight
和font-style
属性。
- The first rule is used for plain text, it specifies a regular font weight (400) and a normal font style. 第一条规则用于纯文本,它指定常规字体粗细(400)和常规字体样式。
The second rule specifies an italic font style. It will be used by the browser for HTML text marked with the
<i>
or<em>
tags, or with thefont-style: italic
CSS property.第二条规则指定斜体字体样式。 浏览器将使用它来标记带有
<i>
或<em>
标记或带有font-style: italic
CSS属性HTML文本。The third rule specifies a heavier font weight (600). It will be used by the browser for HTML text marked with the
<b>
or<strong>
tags, or with thefont-weight: bold
CSS property.第三条规则指定较重的字体粗细(600)。 浏览器将使用它来标记带有
<b>
或<strong>
标签或带有font-weight: bold
CSS属性HTML文本。
When the italic and bold typefaces don’t need to be precise, and download times need to be optimized, the second and third rules can be dropped. In that case, the browser will attempt to render its own approximation of italic and bold by simply distorting the outline of the true font. In some cases this may be good enough.
当斜体和粗体字不需要精确且下载时间需要优化时,可以删除第二和第三条规则。 在这种情况下,浏览器将通过简单地扭曲真实字体的轮廓来尝试呈现其自己的斜体和粗体近似值。 在某些情况下,这可能已经足够了。
But when the typeface can’t be suitably rendered that way, the frontend developer can still optimize the website for fast downloads by using the font-display
property. A value of swap
instructs the browser to prerender the text the best it can, then rerender it correctly when the font file becomes available. This makes the text visible to the user sooner, but may cause a small "flash of unstyled text" (FOUT). In the example, the italic and bold rules use this approach.
但是,当无法以这种方式正确显示字体时,前端开发人员仍然可以使用font-display
属性来优化网站以进行快速下载。 swap
的值指示浏览器以最佳的方式呈现文本,然后在字体文件可用时正确地呈现文本。 这样可以使用户更早地看到文本,但是可能会引起小的“未样式化文本闪烁”(FOUT)。 在示例中,斜体和粗体规则使用此方法。
By way of contrast, a value of block
instructs the browser to temporarily hold off rendering the text until the font file becomes available. When this happens within a reasonable amount of time it's rendered in its precise form without any FOUT. But if the font file download is delayed too long the browser is supposed to temporarily do the best it can, rerendering if and when the actual font becomes available. In the example, the first rule, for regular plain text, uses this approach.
相比之下, block
值指示浏览器暂时推迟渲染文本,直到字体文件可用为止。 当这种情况在合理的时间内发生时,将以其精确的形式呈现而没有任何FOUT。 但是,如果字体文件下载延迟太长时间,则浏览器应该暂时尽其所能,并在实际字体可用以及何时可用时重新呈现。 在示例中,对于常规纯文本,第一个规则使用此方法。
Two other font-display
values are possible (but not shown in the example). First, a value of fallback
instructs the browser to briefly render the text with a fallback font, waiting just a short time to obtain the actual font. If it can be obtained quickly enough (within 3 seconds), the text is rerendered with the actual font. But if it can not be obtained within that time-frame, it must simply give up trying and stick with the fallback.
其他两个font-display
值也是可能的(但示例中未显示)。 首先, fallback
值指示浏览器使用后备字体简短地呈现文本,仅等待一小段时间即可获取实际字体。 如果可以足够快地(在3秒钟之内)获得它,则将使用实际字体重新渲染文本。 但是,如果无法在该时间范围内获得,则必须放弃尝试并坚持使用后备。
Finally, a value of optional
instructs the browser to give up immediately if the font isn't available when first needed, and permanently render the text with a fallback of its choice.
最后, optional
的值指示浏览器在首次需要该字体时如果不可用,则立即放弃,并使用其后备选项永久呈现该文本。
The next part of each @font-face rule — the src
property — specifies where to look for the font file. One or more locations may be provided. If there is any chance that it might be preinstalled on the user's device, use the local()
keyword to tell the browser to look for it by name.
每个@ font-face规则的下一部分src
属性-指定在哪里寻找字体文件。 可以提供一个或多个位置。 如果有可能将其预安装在用户的设备上,请使用local()
关键字告诉浏览器按名称查找。
The more typical scenario though, is to use the url()
keyword. This syntax will trigger a network request to fetch the specified file (but only if and when it's needed).
但是,更典型的情况是使用url()
关键字。 该语法将触发网络请求以获取指定的文件(但仅在需要和何时需要时)。
It is perfectly acceptable to specify a URL that points to a third party provider like https://fonts.gstatic.com
(Google Fonts). But this approach can sometimes lead to unexpected delays, causing your website to compete with every other website using that service. For more predictable behavior, that is under your control, consider hosting these files on your own servers.
完全可以指定一个指向第三方提供程序的URL,例如https://fonts.gstatic.com
(Google字体)。 但是这种方法有时会导致意外的延迟,从而导致您的网站与使用该服务的所有其他网站竞争。 对于更可预测的行为,这在您的控制之下,请考虑将这些文件托管在您自己的服务器上。
The format()
keyword specifies the encoding and compression of the font file. All modern browsers support the new Web Open Font Format, so there's very little reason to use older TTF or EOT formats anymore. And be sure to specify WOFF2 which optimizes glyph compression using the new brotli
compression scheme.
format()
关键字指定字体文件的编码和压缩。 所有现代浏览器都支持新的Web开放字体格式,因此,几乎没有理由再使用旧的TTF或EOT格式。 并确保指定WOFF2,它可以使用新的brotli
压缩方案优化字形压缩。
The last part of each @font-face rule — the unicode-range
property — specifies which Unicode code points have actual glyph definitions within the font file. This is a natural language optimization that some font foundries provide for typefaces that cover more than just the ASCII character set.
每个@ font-face规则的最后一部分( unicode-range
属性)指定字体文件中哪些Unicode代码点具有实际的字形定义。 这是一种自然语言优化,某些字体代工厂提供的字体不仅仅包含ASCII字符集。
For example, if your font file has Greek characters it might only have glyphs defined for code points U+0370-03FF
. Or for example, Cyrillic might only have glyphs defined for code points U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116
.
例如,如果您的字体文件包含希腊字符,则它可能仅具有为代码点U+0370-03FF
定义的字形。 例如,西里尔字母可能只为代码点U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116
定义了字形。
By providing separate font-face rules with unicode-range
this way, you can leave it up to the browser to decide which font files to fetch based on the actual text on each web page.
通过以这种方式为unicode-range
提供单独的字体规则,您可以将其留给浏览器,以根据每个网页上的实际文本来决定要提取的字体文件。
One final note about @font-face rules. Because font files are only fetched by the browser when needed, it is quite common to have one set of @font-face rules that cover every possible need for an entire website. There is no need to hand-craft different rules for each page.
关于@ font-face规则的最后一点说明。 因为仅在需要时才由浏览器获取字体文件,所以使用一组@ font-face规则来覆盖整个网站的所有可能需求是很常见的。 无需为每个页面手工制定不同的规则。
预加载字体 (Preloading fonts)
Web font files need to be fetched before being used. The browser does this automatically, as needed, using its internal algorithm for matching the glyphs on a page and the CSS rules for those glyphs. This algorithm is not exposed to the developer, so there is no direct way of tweaking it.
使用Web字体文件之前,需要先将其提取。 浏览器会根据需要使用其内部算法来自动执行此操作,以将页面上的字形与这些字形CSS规则进行匹配。 该算法未向开发人员公开,因此没有直接的方法来进行调整。
But oftentimes this on-demand fetching mechanism isn’t quick enough to prevent the annoying flash of unstyled text. One strategy to deal with this is HTML’s preload
protocol. Here's how the frontend developer can instruct the browser to preload the three fonts of the previous example:
但是通常,这种按需获取机制不够快,无法阻止烦人的未样式化文本闪烁。 解决此问题的一种策略是HTML的preload
协议。 这是前端开发人员如何指示浏览器预加载上一个示例的三种字体的方法:
<head>
<link href='/fonts/source-serif-pro-400-latin.woff2'
rel=preload as=font type=font/woff2 crossorigin />
<link href='/fonts/source-serif-pro-400-italic-latin.woff2'
rel=preload as=font type=font/woff2 crossorigin />
<link href='/fonts/source-serif-pro-600-latin.woff2'
rel=preload as=font type=font/woff2 crossorigin />
</head>
In this code snippet, the rel=preload
attribute instructs the browser to prioritize the download of these files over all others. So these three will be requested before any scripts, stylesheets or images. This is the most important secret for preventing the flash of unstyled text.
在此代码段中, rel=preload
属性指示浏览器优先于所有其他文件下载这些文件。 因此,将在任何脚本,样式表或图像之前请求这三个文件。 这是防止闪烁未样式的文本的最重要的秘密。
HTML’s link
tag can be used for many other things, but the as=font
attribute is to be used only for @font-face rules. It instructs the browser to follow the content security policy for fonts and to send an accept
request header that servers will correctly interpret.
HTML的link
标记可以用于许多其他用途,但是as=font
属性仅用于@ font-face规则。 它指示浏览器遵循字体的内容安全策略,并发送服务器将正确解释的accept
请求标头。
The type=font/woff2
attribute is the corresponding content-type
response header that the browser expects to see on the file it obtains. Together with as=font
these two prevent accidental and malicious misuse of the preload instruction.
type=font/woff2
属性是浏览器希望在获取的文件上看到的相应的content-type
响应标头。 这两个与as=font
一起可以防止意外和恶意滥用预加载指令。
Finally, the crossorigin
attribute is required when preloading fonts, regardless of whether it comes from the website's host itself or a third-party host.
最后,在预加载字体时,必须使用crossorigin
属性,而不管它是来自网站的宿主本身还是第三方宿主。
Two important points about this strategy. First, don’t overdo it — not every @font-face rule needs this priority treatment. Consider using it only for titling and places where large blocks of text are a significant part of the web page experience. And remember that the browser will still load all others in due course. When italicized and heavyweight font variants only serve to emphasize words and short phrases, a short delay in their final rendering will often be unnoticeable.
关于此策略的两个要点。 首先,不要过度使用它-不是每个@ font-face规则都需要这种优先处理。 考虑仅将其用于标题和大块文本是网页体验重要组成部分的地方。 请记住,浏览器仍会在适当时候加载所有其他浏览器。 当斜体和重量级字体变体仅用于强调单词和短短语时,其最终渲染中的短暂延迟通常不会引起注意。
Second, double-check to make sure that any preloaded font files are actually used. It’s counterproductive to have users wait for a font file that is not going to be used. When putting this strategy in place be sure to examine the Chrome DevTools Console for warnings similar to this:
其次,仔细检查以确保实际使用了任何预加载的字体文件。 让用户等待将不使用的字体文件会适得其反。 采取这种策略时,请务必检查Chrome DevTools控制台是否存在类似以下的警告:
The resource /fonts/source-serif-pro-400-latin.woff2 was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.
字形子集 (Glyph subsets)
Web fonts can be used for special purposes other than general text content and titling. For example, the well-known Font Awesome project contains a collection of popular icons that are packaged as a font file. Typically, most web pages that use Font Awesome only need a small subset of the approximately 1600 icons that each font file contains, so downloading a large file just to get a couple of icons is inefficient.
Web字体可用于特殊目的,而不是常规文本内容和标题。 例如,著名的Font Awesome项目包含打包为字体文件的流行图标的集合。 通常,大多数使用Font Awesome的网页只需要每个字体文件包含的大约1600个图标中的一小部分,因此仅下载大文件以获取几个图标效率低下。
This is where font subsetting is useful. The idea is to create a font file that only contains the glyphs that are needed. To accomplish this, a tool like pyftsubset is used. It opens an existing font file, copies the SVG outlines of the chosen glyphs, and repackages the result in a brand new font file.
这是字体子设置有用的地方。 这个想法是创建一个仅包含所需字形的字体文件。 为此,使用了pyftsubset之类的工具。 它会打开一个现有的字体文件,复制所选字形的SVG轮廓,然后将结果重新打包为一个全新的字体文件。
This same technique can be used with any appropriately licensed font file. For example, the splash page for ЯΈAĐ WЯΊTΈ TΘΘLŠ chose to render its title font in graffiti-style lettering to match its crazy/cool skateboarder theme. But instead of using an alternate typographic face, the website stuck with the designer’s choice (Source Sans Pro) and simply swapped in non-latin glyphs for R, E, D, I, O and S. The final font subset contains just 20 glyphs packed into a 5Kb file.
相同的技术可以与任何适当许可的字体文件一起使用。 例如, ЯΈAĐWЯΊTΈTΘΘLŠ的初始页面选择以涂鸦样式的字体呈现其标题字体,以使其疯狂/酷酷的滑板手主题与其匹配。 但是,该网站没有使用替代的印刷字体,而是停留在设计师的选择之下(Source Sans Pro),只是将非拉丁字形替换为R,E,D,I,O和S。最终的字体子集仅包含20个字形。打包成5Kb文件。
Yes, this type of optimization is a lot of extra work. Still, it can be worth it when trying to deliver a resource-heavy website over constrained networks such as mobile cell-towers.
是的,这种优化是很多额外的工作。 尽管如此,试图过约束网络,如移动蜂窝塔提供一个资源型重网站时,它可以是值得的。
快取 (Caching)
Once a font file has been obtained, it should be cached on the client’s device. Since font files change rarely, if ever, they should be treated as a static resource. DevOps should configure the server to cache these files for a maximum amount of time. One year is a good rule to follow. Configure the server to set the response header like this:
获取字体文件后,应将其缓存在客户端设备上。 由于字体文件很少更改(如果有的话),因此应将它们视为静态资源。 DevOps应将服务器配置为在最大时间内缓存这些文件。 遵循一年是一个好规则。 配置服务器以设置响应标头,如下所示:
cache-control: max-age=31536000
If the font foundry issues an updated version within that period, use any of the traditional cache-busting techniques that are available. But of course, only if the new file contains new glyphs that your content authors need.
如果字体代工厂在此期间发布更新版本,请使用任何可用的传统缓存清除技术。 但是,当然,只有当新文件包含内容作者需要的新字形时,才可以。
服务器推送 (Server push)
DevOps may be tempted to help things along by using speculative push. This new protocol is available with HTTP/2. It works by sending targeted resources to the browser before the browser requests them.
DevOps可能会尝试使用推测性推送来帮助解决问题。 此新协议可用于HTTP / 2。 它通过在浏览器请求目标资源之前向其发送目标资源来工作 。
Speculative push was a much hyped solution to the problem of resource optimization. The reality is that it fares no better than the link rel=preload
solution outlined above. Benchmark tests prove the point. Read all about it here.
投机推送是对资源优化问题的大肆宣传解决方案。 现实情况是,它的性能并不比上面概述的link rel=preload
解决方案好。 基准测试证明了这一点。 在这里阅读所有内容。
替换字形 (Replacement glyphs)
Content authors may be blissfully unaware of all the details just covered, and may inadvertently run into trouble. Remember, every font file contains a limited set of glyphs. So when the author uses a glyph that is not in the chosen font family the browser tries its best to find an alternative. This often leads to unsightly replacements.
内容作者可能非常高兴地没有意识到刚刚涵盖的所有细节,并且可能会无意中遇到麻烦。 请记住,每个字体文件都包含一组有限的字形。 因此,当作者使用不在所选字体系列中的字形时,浏览器将尽最大努力寻找替代字形。 这通常导致难看的替换。
For example, if the author is writing about Bosnian politician Šefik Džaferović, then the rules we’ve defined above won’t work. Instead, the browser will obligingly use Š, ž, and ć from some other serif font that it has access to. That replacement might be good enough on the author’s computer, but may be completely different on a random reader’s computer.
例如,如果作者正在撰写有关波斯尼亚政治人物ŠefikDžaferović的文章,那么我们上面定义的规则将行不通。 取而代之的是,浏览器将强制使用它可以访问的其他衬线字体中的Š,ž和ć。 这种替换在作者的计算机上可能足够好,但在随机读者的计算机上可能完全不同。
If the designer has chosen a “pro” font family that has an extended set of glyphs, the solution is simple: specify an additional @font-face rule with a unicode-range
that covers U+0160, U+017E and U+0107. Thus, extending the original example we might add the "latin-ext" font file to our ruleset like this:
如果设计人员选择了具有扩展字形集的“ pro”字体家族,则解决方案很简单:指定一个附加的@ font-face规则,其unicode-range
覆盖U + 0160,U + 017E和U + 0107 。 因此,扩展原始示例,我们可以将“ latin-ext”字体文件添加到规则集中,如下所示:
@font-face {
font-family: 'Source Serif Pro';
font-weight: 400;
font-style: normal;
font-display: block;
src: local('SourceSerifPro-Regular'),
url('/fonts/source-serif-pro-400-latin-ext.woff2')
format('woff2');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020,
U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F,
U+A720-A7FF;
}
豆腐和后备字体 (Tofu and fallback fonts)
Sometimes an author may use esoteric glyphs that render reasonably well on their own computer, but that completely fail on the reader’s computer. This may happen for example when the author is writing on a computer with the newest hardware and operating system, but the reader is on a different hardware or older software that knows nothing about those glyphs.
有时,作者可能会使用深奥的字形,这些字形在他们自己的计算机上可以很好地呈现,但是在读者的计算机上完全无法使用。 例如,当作者在具有最新硬件和操作系统的计算机上进行书写,而阅读器在对这些字形一无所知的其他硬件或较旧的软件上书写时,可能会发生这种情况。
We sometimes mistakenly think of Unicode as being the miraculous solution to these types of problems, but remember that Unicode is a living standard. New versions with additional code points are added on a regular basis.
有时我们会错误地认为Unicode是解决这些类型问题的奇迹,但请记住Unicode是生活标准。 带有附加代码点的新版本会定期添加。
When this unfortunate circumstance occurs, the reader may discover “tofu” characters sprinkled into the text. The solution to this is to refine the CSS font stack, adding a fallback font that is guaranteed to have the widest possible set of glyphs.
当发生这种不幸的情况时,读者可能会发现“豆腐”字符散落在文本中。 解决方案是优化CSS字体堆栈,添加一个后备字体,以确保它具有尽可能广泛的字形集。
Google developed the Noto font just for this purpose. As of this writing, it spans 30 distinct writing scripts. It has glyphs in serif, sans-serif and monospaced styles.
Google为此开发了Noto字体。 在撰写本文时,它涵盖了30种不同的编写脚本。 它具有衬线,无衬线和等距样式的字形。
Because it is so comprehensive, it’s too big to use as a web font without splitting it up. Use of the unicode-range
rule should be considered mandatory when using Google Noto as a web font.
由于它非常全面,因此太大了,无法拆分成网络字体。 将Google Noto用作网络字体时,应认为必须使用unicode-range
规则。
特定语言的字体 (Language-specific fonts)
Unicode has steadily increased support for more of the world’s ancient and modern languages. Each year new code points are added to the spec. But because of the time and expense involved, only a few font foundries have created glyph sets for these new code points.
Unicode稳定地增加了对世界上更多的古代和现代语言的支持。 每年,新的代码点都会添加到规范中。 但是由于所涉及的时间和费用,只有很少的字体铸造厂为这些新代码点创建了字形集。
When attempting to use any of these newer code points for authoring web pages, it is imperative that the author and frontend developer work closely to make sure that the reader can see what the author has written.
尝试使用这些更新的代码点中的任何一个来创作Web页面时,必须与作者和前端开发人员密切合作以确保读者可以看到作者所写的内容。
For example, if the author is writing about Egyptian archeology and wants to use hieroglyphs within the body of the text, the CSS from our original working example might be adjusted to look like this:
例如,如果作者正在撰写有关埃及考古学的文章,并希望在文本正文中使用象形文字,则可以将原始工作示例中CSS调整为如下所示:
article {
font-family: 'Source Sans Pro',
'Noto Sans Egyptian Hieroglyphs',
sans-serif;
font-size: 12pt;
line-height: 1.4;
margin: 1rem;
}
And an extra @font-face rule would be added like this:
并且将添加一个额外的@ font-face规则,如下所示:
@font-face {
font-family: 'Noto Sans Egyptian Hieroglyphs';
font-style: normal;
font-weight: 400;
src: url(https://fonts.gstatic.com/ea/notosansegyptianhieroglyphs
/v1/NotoSansEgyptianHieroglyphs-Regular.woff2)
format('woff2');
unicode-range: U+13000-1342E;
}
With this in place, the article’s principal text will be rendered in Source Sans Pro, and the hieroglyphs will appear correctly, without tofu, using Noto Sans.
完成此操作后,文章的主要文本将在Source Sans Pro中呈现,并且使用Noto Sans将在没有豆腐的情况下正确显示象形文字。
表情符号 (Emojis)
There is no font file, with cross platform support, that contains all of the Unicode-defined emojis. This limitation is largely because fonts have been a black-and-white affair up until now. Four different competing schemes have been developed to make use of color in fonts (SBIX, COLR, SVG-in-OpenType, and CBDT/CBLC). None of these enjoys universal support across all operating systems.
没有带有跨平台支持的字体文件,该文件包含所有Unicode定义的表情符号。 该限制主要是因为到目前为止,字体一直是黑白事务。 已经开发出四种不同的竞争方案来利用字体中的颜色(SBIX,COLR,SVG-in-OpenType和CBDT / CBLC)。 这些都无法在所有操作系统上获得通用支持。
In the mean time, we are left with:
同时,我们还有:
Google Noto Color Emoji for Android and Linux
适用于Android和Linux的Google Noto Color Emoji
Apple Color Emoji for iOS, macOS, watchOS and tvOs
适用于iOS,macOS,watchOS和tvO的Apple Color Emoji
Microsoft Segoe Color Emoji for Windows 10
适用于Windows 10的Microsoft Segoe Color Emoji
Twitter Emoji for Everyone for SVGinOT
适用于SVGinOT的所有人的 Twitter 表情符号
Unfortunately the rendering of each emoji is open to artistic interpretation. As a result, the author and reader will often see something slightly different. Sometimes the difference is so great that it is open to misinterpretation. For example ‘FACE WITH ROLLING EYES’ (U+1F644) looks exasperated with Google, confused with Apple, and amused with Samsung.
不幸的是,每个表情符号的渲染都可以进行艺术性的解释。 结果,作者和读者经常会看到稍微不同的东西。 有时差异如此之大,以至于容易引起误解。 例如,“脸蛋滚动的脸”(U + 1F644)看起来对Google感到愤怒,对Apple感到困惑,而对Samsung感到很有趣。
As of this writing, a cross-platform web font solution to this problem remains elusive. Of course this doesn’t mean we can’t use emojis. But it does mean that designers can’t expect to have their designs faithfully rendered on every platform readers use. Because of this, a web font solution to the problem is simply not worth pursuing at this time.
在撰写本文时,针对此问题的跨平台Web字体解决方案仍然难以捉摸。 当然,这并不意味着我们不能使用表情符号。 但这确实意味着设计师不能期望将设计真实地呈现在读者使用的每个平台上。 因此,目前根本不值得解决该问题的Web字体解决方案 。
Follow these six golden rules to ensure a great end-user experience with web fonts:
请遵循以下六个黄金法则,以确保最终的用户体验Web字体:
- Define @font-face rules for normal, italic and bold variants for each font family used. 为使用的每个字体系列的正常,斜体和粗体定义@ font-face规则。
Use the
font-display
property to specify an appropriate FOUT strategy.使用
font-display
属性可以指定适当的FOUT策略。Add HTML
<link rel=preload>
statements to prioritize the delivery of critical fonts.添加HTML
<link rel=preload>
语句以优先分配关键字体。- Create font subsets for company-specific lettering needs. 创建字体子集以满足公司特定的刻字需求。
- Cache aggressively. 主动缓存。
- Watch for tofu and respond by specifying fallback fonts when necessary. 注意豆腐,并在必要时通过指定后备字体进行响应。
Web fonts can be a part of every website’s design. Avoiding the hidden gotchas requires diligence, but getting it right is worth the trouble.
Web字体可以成为每个网站设计的一部分。 避免隐藏的陷阱需要勤奋工作,但正确解决问题却值得。
翻译自: https://uxdesign.cc/2020-019-web-fonts-done-right-e21df103205
web字体设置成平方字体