BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Web版式和@font-face简介

| 作者 Greg Veen 关注 0 他的粉丝 发布于 2011年11月17日. 估计阅读时间: 31 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

目录

随着大量支持CSS3 @font-face的浏览器诞生,Web上的版式向前发展了一大步:您最终可以在网页中使用真实的字体,而不会求助于以来图像、Adobe Flash或其他基于非文本的技术的解决办法。但这个新的Web版式时代也带来了新的法律、技术和设计挑战。本文介绍我们如何实现Web版式,如何以可客户所涉及到的新挑战的方式使用Web字体,为您提供在Web设计和开发项目中成功应用已存在1世纪的版式原则的自由。

安全使用:Web版式的开端

经过在印刷媒介中数百年的磨砺,版式的设计现包含一些节本的准则,比如使用对比、重复、对齐和近似性来明确且个性地传达含义,在品牌影响力下保持合法性。这些准则在Web上与在其他任何地方一样重要——毕竟,Web设计的95%都关乎版式。甚至可以说,版式在Web等交互式媒介中甚至更加重要,其中由于文本可能是可单击的并具有行为,所以它不仅仅是内容,它是用户界面

总之,拥有选择正确的字样的能力是关键。在如今由各种不同的搜索引擎、设备和残疾人技术访问动态、不断更新的网站的世界里,以可访问、可维护和基于标准的方式选择正确的字样是一项必不可少的能力。

在Web的大部分历史中,这个圣杯都遥不可及。

尽管版式设计的悠久历史催生了书签中字样,但当Web诞生时,在这种新媒介中工作的设计人员几乎无法选择要使用的字样。例如,1993年,第一个图形Web浏览器NCSA Mosaic仅包含单一的、默认的字体(参见图1)。

图1. NCSA Mosaic 1.0提供了极其有限的版式控制。图片来源:NCSA/University of Illinois

Web安全字体

这一情形在接下来的15年中仅有细微的改观,因为所谓的“Web安全”字体集到2008年在增长到大约18个(参见图2)。Web安全字体是预先安装在主流个人计算机操作系统中的系统字体的子集——类似于最小公分母。因为Web设计人员和开发人员知道他们网站的所有访问者都至少拥有这18种字体之一,所以它们可通过CSS中的font-family属性引用它们,从而在网页中安全地使用它们。然而,考虑印刷设计领域可用的数千种字体,能够使用18种字体仍然是很糟糕的情景。差异化地表示、品牌化、找到适合工作的正确字样的能力仍然不容乐观。

图2. 到2008年,“Web安全”字体集增长到了大约18种。(图片来源:所有Windows版本和Mac等效版本的常见字体。)

解决办法:将文本用作图像、脚本或对象

围绕这些限制,一些设计人员开始依靠各种技巧和解决办法来推进Web版式发展。或许这些方法中最常见的是使用图像来在渲染非Web安全字体中的文本。这使得可以在网页中使用任何字体,但这样做具有重大的成本:因为文本陷入在图像中,它不可选择、搜索、翻译或供使用残疾人设备的人访问,与正常的HTML文本不同。CSS图形替换等技术可解决这些问题,使用CSS将图像放在底层文本上,底层文本实际上位于页面的HTML源代码中,因此可供搜索和访问,但可选择性和可翻译性问题仍然存在。而且,对于频繁更改的文本元素,比如新闻网站的头条新闻,此技术会带来在文本更改时创建新图像所需的维护成本,除非网站的开发人员设置了一种服务器端机制来动态生成这些图像。基本原则是:使用图像渲染文本能够实现更丰富的Web版式,但它采用笨重方式的复杂性通常超过了收益。这是一次大胆的努力,但最终不是发展的最佳方式。

其他解决办法,比如基于JavaScript的Cufóntypeface.js,会自动化画布或VML元素中的文本的渲染。尽管这最大程度减少了使用图像渲染文本所带来的维护和设置成本,但它仍然导致了渲染的文本给人感觉不是Web原生的:文本不可选择或调整。另外,使用此技术来渲染大量文本(例如,包含许多段略的正文)可能对性能带来负面影响。

另一种技术将字体样式的文本渲染为某种与HTML文本不同的东西,使用Flash代替画布或VML。在此方法中,设计人员将一个字体嵌入到一个Flash对象中,将它应用于该对象中的文本,然后通过Flash平台内置的文本渲染引擎渲染该对象。这无疑会带来漂亮且高效的版式,但它也可能导致使用图像或其他非文本元素渲染文本的方法固有的一些相同问题。但是,更重要的是这样一个事实,来自苹果公司越来越流行的iOS平台不支持Flash。这意味着iOS设备(比如iPad和iPhone)的用户不会从此方法所实现的漂亮版式获益——或者,更糟的是,它们完全不会看到该文本。

超越Web安全字体:@font-face

正确的发展道路非常简单,它所基于的是设计标准的、构建块式的Web技术HTML和CSS来以作者定义的样式联合呈现内容的方式。确实如此:它就是使用一种名为@font-face的CSS功能,通过链接到一个字体文件(而不是通过引用预先安装的系统字体)来定义一个字体集,然后通过CSS中的font-family属性引用该字体,从而将它应用于网页元素,这非常类似于您应用Web安全系统字体的方式。

这种基本的CSS机制的工作原理如下。首先,您使用一个@font-face声明定义一个字体集,使用font-family描述符为它提供一个名称,然后使用src描述符指向包含字体本身的文件:

@font-face { 
    font-family: 'Awesome Font'; 
    src: url('awesome-font.ttf'); 
} 

这里,通过链接到一个名为wesome-font.ttf的字体文件,定义了一个名为Awesome Font的字体集。

然后,在您的CSS中,使用font-family属性将该字体应用到一个HTML元素,非常类似于您对Web安全系统字体所做的:

h1 { 
    font-family: 'Awesome Font'; 
} 

这里,Awesome Font字体集(前面使用@font-face声明定义)应用于1级标题。

以这种方式渲染的文本具有正常的HTML文本样式,使用一种作者定义的字体集,而不是默认的系统字体集。这意味着此方法避免了基于非文本的解决办法的问题:文本是可搜索、可选择、可调整、可访问和可轻松维护的。

它的核心其实就是CSS @font-face。这种基本机制是由Web标准机构万维网联盟在二十世纪90年代晚期定义的。不幸的是,由于那个时代的浏览器战争和其他因素导致了不一致的实现,它从未被充分利用——直到最近。到2009年,所有主要Web浏览器都支持@font-face,很快iPhone和iPad上的移动Safari浏览器也提供了支持。朝Web安全字体发展的正确道路最终被采用。

但简单、开放、基于标准的@font-face质量带来了一个新问题。以销售字体为生的人担忧,一旦您可以将一个字体文件链接到网页中(因此向它公开一个链接),很难保护该文件不被盗窃。这种担忧阻止了大多数商业创建者允许将它们的字体用于Web字体。

这正是第一批托管的Web字体服务(包括Typekit,我合作创建的服务)使用解决方案介入的地方,这些解决方案允许设计人员使用字体作为Web字体,同时仍然保持这些字体远离未授权的使用。

这是Typekit中的工作原理:作为设计人员,您购买Typekit的字体库的订阅,选择您希望使用的字体,指定您希望在其上使用这些字体的网站。Typekit然后为您提供一个JavaScript代码片段以添加到您的HTML页面的标题元素中。当用户访问您的网站时,该JavaScript从Typekit的系统请求字体。如果请求来自您向Typekit注册的网站,字体将使用标准CSS @font-face动态地注入到页面中;如果不是,字体会被拒绝。您向Typekit支付字体使用费用,Typekit然后与字体所有者分享收入。

当然,许多Web开发人员知道都知道这种保护方法(称为引用方检查)可使用简单、广泛使用的命令行工具来欺骗一个引用方而轻松规避。这正是Typekit通过一种方式修改字体文件来保护字体的原因,这种方式不会更改它们渲染或执行的方式,但将使它们无法安装在操作系统中。这样,即使您绕过了引用方检查或者您从浏览器缓存中挖走了这些字体,它们仍然无法在Adobe Photoshop等应用程序中安装和使用,这是许多传统创建者在业务中提供的服务,以及因此而担忧要保护的服务。这个额外的防御层尽管仍然可被某个拥有正确的字体编辑软件和专业技能的人破坏,但已足以阻止字体的随意误用,并且它已使许多字体铸造上习惯于允许它们的字体通过Typekit用作Web字体。

当然,Typekit不是唯一一个托管的商用Web字体服务。该领域现在包含许多选项,包括KernestFontdeckFonts.com Web FontsWebINKFontsLiveWebType等。尽管在功能、选择和价格上不同,但每项服务都具有相同的基本功能:它们托管授权用于Web用途的商用字体文件,通过CSS @font-face向Web设计人员提供访问它们的权限。

某些创作者和Web服务,包括FontFontProcess Type FoundryFontspring和Monotype的Fonts.com Web Fonts,现在也在某些情况下提供了可供您下载并自行托管的Web字体,而无需依赖于托管的第三方服务。这常常可以结合一种名为WOFF的新兴标准Web服务格式来使用,后者在本质上是一个围绕字体文件的包装器,使该字体无法安装在操作系统中,但仍然可在支持该格式的浏览器中用作Web字体。但是,不是所有广泛使用的主流Web浏览器版本都支持WOFF,所以,取决于字体和创建者/服务,使用托管的Web字体服务可能仍然是向您网站的访问者所使用的大部分浏览器提供字体的唯一方式。

使用Web字体的挑战

使用托管、商用的Web字体服务以及WOFF——更别提免费的Web字体来源,比如FontSquirrel和Google Web Fonts——Web字体授权的问题已经解决。超Web上的富版式发展的最佳道路已清除了障碍。

但是,不幸的是,这仍然不是故事的结尾。

Web字体格式和浏览器支持

事实证明,Web字体具有许多不同的格式,并且毋庸置疑,各种Web浏览器支持这些格式的不同子集(参见图3)。

图3. 主流Web浏览器每个都支持不同的Web字体格式。

这带来了一项技术挑战。为了支持所有主流Web浏览器,一个@font-face CSS 声明实际上无法像前面提到的那么简单:

@font-face { 
    font-family: 'Awesome Font'; 
    src: url('awesome-font.ttf'); 
} 

相反,它必须看起来更像这样:

@font-face { 
    font-family: 'Awesome Font'; 
    src: url('awesome-font.eot'); /* IE9 Compat Modes */ 
    src: url('awesome-font.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ 
    url('awesome-font.woff') format('woff'), /* Modern Browsers */ 
    url('awesome-font.ttf') format('truetype'), /* Safari, Android, iOS */ 
    url('awesome-font.svg#svgFontName') format('svg'); /* Legacy iOS */ 
} 

这就是所谓的Fontspring @font-face语法,它是最初的Bulletproof @font-face语法的最新版本。结合使用@font-face格式描述符和各种附加编码,这种语法开发用于诱导浏览器使用它们支持的最佳的(或者在某些情况下是唯一的)Web字体格式。不幸的是,事实证明最初的语法无法防弹(Bulletproof)。经过各种迭代,它必须不断更新来克服各种问题,比如对移动支持和最新浏览器版本(比如IE9)支持的限制。

但是,这里重要的不一定是了解此语法的每次迭代的细节,而是认识到CSS语法需要使用Web字体的变化,因为浏览器领域在不断演化,也因为Web字体社区在掌握越来越多的浏览器支持和字体技术信息。这意味着您一定要在实现启用了Web字体的网站之后继续定期测试它们,尤其是当浏览器供应商发布新浏览器版本时。这也是考虑使用托管Web字体服务的一个不错理由,其中,选择向哪些浏览器提供哪种Web字体格式的逻辑可以不用您操心了,而且理想情况下,可由Web字体服务继续更新。无需亲自维护一种复杂并可能不友好的@font-face语法,您可以将这种复杂性抽象到某些东西背后,就像这么简单:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 

这是一个用于在网站上启用Typekit的示例JavaScript代码。其他托管的Web字体服务提供了类似的简单机制,有些服务使用JavaScript提供@font-face字体,以控制加载行为(下面将介绍更多收益信息),其他服务仅依赖于CSS。

无论您选择哪条路径——托管您自己的Web字体文件并维护使用它们所需的@font-face语法,或者将该工作外包给一个托管的Web字体服务——好消息是可以导航Web字体格式和浏览器支持的复杂性,因此最终打开通往丰富且不断增多的字样选择的大门。

闪烁的无样式文本

使用Web字体的另一项挑战是处理一种称为“闪烁的无样式文本”或FOUT的现象。

一个Web字体是一项远程资源,就像图像或视频一样,并且这意味着它必须下载。那么,在下载Web字体时Web字体样式文本应该发生什么?各种浏览器会采取不同的方法。

IE9和Firefox等基于Mozilla的浏览器的一些版本在等待Web字体下载过程中,将使用一种备用字体显示文本,如图4所示。在此示例中,第一行文本在其font-family堆栈中有一个Web字体,后面是一个Web安全的备用字体。第二行文本仅包含Web安全的备用字体。在等待Web字体下载的过程中,Firefox会使用备用字体公式渲染这两行。

图4. 这里,Firefox在Web字体加载期间使用一种备用字体显示Web字体样式的文本。

下载Web字体之后,Firefox将第一行切换为使用Web字体渲染(参见图5)。

图5. 这里,Web字体完成加载后,Firefox将Web字体样式文本从一种备用字体切换为Web字体(Rosewood Std from Adobe)。

这可能是一种不和谐的体验,导致颤动和布局移动,尤其是在Web字体的指标(比如光学垂直/水平大小、默认行高等)与备用字体的指标不同时。这就是“闪烁的无样式文本。”

相反,Chrome或Safari等基于WebKit的浏览器在等待Web字体下载期间会隐藏Web字体样式文本,在布局中为它留出空间,如图6所示。这是与前面相同的两行示例,但可以看到,第一行不可见。

图6. 这里,在加载Web字体期间,Safari隐藏了Web字体样式文本,在页面的布局流中为文本留出了空间。

当Web字体下载后,Safari使该文本可见,并且它已使用Web字体渲染(参见图7)。

图7. 这里,在Web字体完成加载后,Safari使Web字体样式文本可见。

这种体验更加流畅,可能是许多用户和设计人员首选的。

幸运的是,您无需等待并接受不同浏览器之间的这种不一致性。您可以使用WebFont Loader(Typekit与Google合作开发的一个JavaScript库)控制这些浏览器之间的区别。作为开源项目发布,它兼容各种托管的Web字体服务,以及甚至您自己的自托管Web字体。

注意:如果您使用Typekit,您可以利用WebFont Loader,而无需加载额外的JavaScript文件,因为它已经构建到您放入页面中来启用Typekit字体的Typekit JavaScript代码中。

WebFont Loader通过JavaScript加载字体,以便能够确定字体何时开始加载,何时完成加载,以及它是否将完全加载(比如由于它是使用一个不支持Web字体的旧游览器请求的)。

对于这些事件中的每一个(每个状态),WebFont Loader动态地将一个类名添加到包含页面的HTML元素中。这些类用于下载字体时的wf-loading,用于字体完成加载时的wf-active,以及用于字体不会加载时的wf-inactive。您可以在您的CSS中使用这些类在每个状态期间更改页面元素样式,如此模式中所示:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 
<style type="text/css"> 
    .wf-loading { 
        /* styles to use when web fonts are loading */ 
    } 
    .wf-active { 
    /* styles to use when web fonts are active */ 
    } 
    .wf-inactive { 
    /* styles to use when web fonts are inactive */ 
    } 
</style> 

这对FOUT现象有何帮助?您可以使用类在字体加载期间隐藏文本,但仍然在布局中为该文本留出空间。这将在所有Web浏览器上模仿Safari的行为。以下是需要的代码:

<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script> 
<script type="text/javascript">try{Typekit.load();}catch(e){}</script> 
<style type="text/css"> 
    .wf-loading h1 { 
        visibility: hidden; 
    } 
</style> 

翻译为人类语言,此示例表明“当一个h1包含在wf-loading的范围内时,隐藏它的“可见性”。”这样会在加载字体时隐藏文本,在页面的布局流中为它留出空间。然后,当字体加载后,这个CSS就不再适用(因为WebFont Loader在那时删除了wf-loading类),所以该文本然后就变得可见了。

这会将WebKit更流畅的字体加载体验带给所有浏览器,使FOUT成为过去。

Web字体渲染

使用Web字体的另一个挑战是渲染的问题。如果您以前使用过Web字体,您可能已渲染过,为什么相同的字体可以在不同浏览器中渲染出如此不同的效果?或者为什么两种不同的字体,以相同的字号渲染,可能得到如此不同的可读性水平?

一种字样是一种想法——它是一种可缩放大小的形状——并且作为一种想法,它具有无限的分辨率。在计算机屏幕上渲染该想法,意味着在一个相对低分辨率的像素网格上这么做。这可能导致一些字样出现问题,尤其是这些最初为打印而设计的字体,其中分辨率并不像在屏幕上一样是一个受限的因素。关于事情如何出错的信息,请参阅图8左侧的“O”,这是字样设计人员Tim Ahrens编写的关于此主题的优秀博文中的一个示例。这里,“O”字符的右边恰好落在单列像素上,这是由字符的总体形状和它在网格上的位置导致的。但是,“O”的左边落在两列像素上。这使渲染的字符看起来不对称,当与该字体的许多其他字符的类似方面相结合呈现时,这可能影响具有此字体样式的文本的可读性。

图8. 左侧的“O”看起来不对称,因为它的右边仅落在一列像素上,而它的左边落在两列上。从右侧的“O”上显示的微调(hinting)可以看出,可通过指定一个字形的相应部分应该始终在宽度上始终具有相同数量的像素,从而改善此情形。(图片来源:Tim Ahrens。)

幸运的是,一些在首次用于Web文本而不是印刷文本时显示出类似问题的字体已通过一项称为微调的技术进行了改进,针对在像素网格上更好地渲染而优化。通过字样设计人员使用字体编辑软件对字体进行加强,微调是一组提供给文本渲染引擎的关于在出现这类问题时因如何做的说明。在图8右侧的“O”中,您可以看到微调表示为字形每一边上的链接。这些微调指定,字形的某些对应部分始终应该在宽度上具有相同像素数量,无论字形在落入像素网格时如何自然地形成。这可以显著改善此字体中的文本集的可读性,尤其是在更小字号上和在老版Windows上运行的浏览器中。(如果您对更多相关机制感兴趣,Tim Ahrens的 A closer look at TrueType hinting提供了一些有趣的细节。)

最后一个事实(一些浏览器和操作系统需要更多地借助微调的帮助)与Web字体渲染的另一个现状相关:各种浏览器和操作系统组合所使用的不同文本渲染引擎会不同地渲染文本,有时这种区别很细微,有时却很明显。这使得了解您使用的一种字体如何在您关注的浏览器中实际渲染至关重要:字体会从在任何这些浏览器中从微调获益吗,如果会,它是否经过了微调?字体是否能够在这些浏览器的每一个中以您将使用字号良好地渲染?在获得这样的问题的答案时,会在Web设计和开发中添加一个新的跨浏览器测试层——以及在设计项目的开头——它可以避免在项目晚期出现意外的渲染效果,如果您必须回溯到字样选择阶段,这可能浪费大量的工作。

如果使用Typekit字体,您可以使用Typekit的Browser Samples功能查看您考虑的字体如何在Typekit支持的每个浏览器和操作系统组合中渲染,从而节省时间和资源(参见图9)。

图9. Typekit的Browser Samples工具显示字体如何在Typekit支持的每个浏览器和操作系统组合中渲染。

简单来讲,在您的设计流程中尽早留意Web字体渲染,将有助于您从可用的Web字体选择正确的字体。但是如果您必须使用无法在您关注的所有环境中良好渲染的Web字体,您仍然有选择。您可以考虑使用基于CSS或JavaScript的浏览器,向无法良好地渲染您喜欢的字体的浏览器和操作系统组合中显示一种Web安全备用字体。如果您能够访问各种在线格式的字体,您也能够将最佳的分级显示格式分类发送到某些浏览器和操作系统组合(因为Typekit和其他创建者已在它们的托管服务中这么做)。您甚至可以与字体的设计人员合作,或者与其他精通微调的设计人员合作,针对您希望在Web上使用字体的每种方式对它进行优化。像这样的高级方法演示了实现高品质Web字体渲染时的可能性——但是,在许多情况下,当您可尽早自由选择一种渲染良好的字体时,您将能够避免这种类型的技术工作,专注于使用字样设计,而不是设计字样。

延伸阅读

由于上面讨论的复杂性,使用Web字体看起来很艰难,但它们可能很简单。现在您已知道如何合法地获得Web字体,如何以一种可维护的方式将它们包含在您的网页中,如何控制不同浏览器之间的字体加载区别,以及如何理解Web字体渲染,以便为您的设计选择正确的字体,您拥有了参与Web版式中的持续复兴所需的知识,而没有头痛。所以请全情投入,出色发挥!以下是一些有用的资源,可在您学习的过程中添加到您的工具箱中。

可从以下链接获得Web字体:

使用Web字体:

文章、教程和讨论:

clip_image013+clip_image014

本作品依据Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License授权。与本作品中包含的代码示例相关,超出本许可范围的权限可在Adobe上找到。

查看原文:Introduction to web typography and @font-face

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT