谷歌字体和开放字体库中的免费 Web 字体已经改变了游戏规则，但仅在有限的范围内。

毫无疑问，近些年来互联网的面貌已经被开源字体所改变。早在 2010 年之前，你在 Web 浏览器上几乎只能看到微软制作的通常“Web 安全”的核心字体。但这一年（2010）正好是好几轮技术革新开始的见证之年： Web 开放字体格式 Web Open Font Format （WOFF）的引入为通过 HTTP 有效地传输字体文件提供了一个开放的标准，以及像谷歌字体和 开放字体库 Open Font Library 这样的 Web 字体服务的推出，使得 Web 内容发布者可以在开源许可证之下免费使用海量的字体库。

这些事件对 Web 排版的积极影响再夸大都不过分。但是要将 Web 开放字体的成功与整个开源排版等同起来，并得到结论——挑战已经远离了我们，困难悉数被解决了——却很容易。然而事实并非如此，如果你很关注字体，那么好消息是你有好多机会参与到对这些字体的改进工作当中去。

对新手来说，至关重要的是必须要意识到谷歌字体和开放字体库提供了专用的服务（为网页提供字体），而没有为其他使用情况制定字体解决方案。这不是服务方面的缺点，这只是意味着我们必须去开发其它的解决方案。

需要解决的问题还非常多。可能最明显的例子就是给 Linux 桌面计算机的其他软件安装字体所遇到的尴尬情况。你可以通过任何一种服务下载任何一种 Web 字体，但是你得到的只是一个最普通的压缩包文件，里面有一些 TTF 或 OTF 二进制文件和一个普通文本文件的许可证。接下来会发生什么完完全全需要你去猜。

大部分用户很快学会了“正确”的步骤就是手动地复制这些字体二进制文件到他们硬盘里几个特殊文件夹里的某一个里。但是这样做只能使这个文件对操作系统可见。它并不能为用户体验带来什么提升。再强调一遍，这不是 Web 字体服务的缺陷，相反它佐证了对于关于服务到哪里停止和需要在其他方面做更多工作的观点。

在用户视角来说，一个巨大的提升可能就是在“只是下载”这个阶段，操作系统或者桌面环境变得更智能。系统或桌面环境不仅会把字体文件安装到正确的位置上，更重要的是，当用户选择要在一个项目中使用的字体时，它会自己添加用户所需要的重要的元数据。

这些附加信息包含的内容与它如何呈现给用户与另一个挑战有关：与其它操作系统相比，在 Linux 环境管理一个字体库显然不那么令人满意。字体管理器总是时不时的出现一下（例如 GTK+ 字体管理器，这是最近的一个例子），但是它们很少变得流行起来。我一直在思考一大堆这些软件让人失望的方面。一个核心的原因是它们把自己局限于只展示内嵌在二进制字体文件内的信息：基本字符集的覆盖、粗细/宽度和斜率的设定，内置的许可证和版权说明等等。

但是除了这些内嵌数据中的内容，在选择字体的过程中还涉及很多决策。严肃的字体用户，像信息设计者、杂志文章作者，或者书籍美工设计者，他们的字体选择是根据每一份文件的要求和需求做出的。这当然包含了许可证信息，但它还包含了更多，像关于设计师和厂商的信息、潮流风格的趋势，或者字体在使用中的细节。

举个例子，如果你的文档包含了英语和阿拉伯文，你多半想要拉丁文和阿拉伯文的字体由同时熟悉这两种 字母系统 script 的设计师所设计。否则，你将浪费一大堆时间来微调字体大小和行间距来使两种字母系统良好地结合在一起。你可能从经验中学到，某些设计师或字体厂商比其他人更善于多种字母系统设计。或许和你职业相关的是今天的时尚杂志几乎无一例外的采用 “Didone)”风格的字体，“Didone)”是指一种两百多年前最先被 Firmin Didot 和 Giambattista Bodoni 设计出来的超高反差的字体风格。这种字体恰好就是现在的潮流。

但是像 Didone、Didot 或 Bodoni 这些术语都不可能会出现在二进制文件的内置数据当中，你也不容易判断拉丁文和阿拉伯文是否相得益彰或其它关于字体的历史背景。这些信息有可能出现在补充的材料中，类似某种字形样本或字体文件中，如果这些东西存在的话。

字形样本 specimen 是一份设计好的文档（一般是 PDF），它展示了这种字体的使用情况，而且包括了背景信息。字形样本经常在挑选字体时充当市场营销和外观样例的双重角色。一份精心设计的样本展示了字体在实际应用中的情况和在自动生成的字符表中所不能体现的风格。字形样本文件也有可能包含了一些其他重要信息，比如怎样激活字体的 OpenType 特性、提供的数学表达式或古体字，或者它在支持的多种语言上的风格变化。在字体管理应用程序中向用户提供此类材料，对于帮助用户找到适合其项目需求的字体将大有帮助。

当然，如果我们希望一个字体管理软件能够处理文件和样本问题，我们也必须仔细观察一下各种发行版提供的字体包所随附的内容。Linux 的用户刚开始只有自动安装的那几种字体，并且发行版存储库提供的包是大部分用户除了下载通用的压缩包档案之外的唯一字体来源。这些包往往非常的“简陋”。商业字体总的来说都包含了样本、文档，还有其他的支持项目，然而开源字体往往没有这些配套文件。

也有一些优秀的开放字体提供了高质量的样本和文档（例如 SIL Gentium 和 Bungee 是两种差异明显但是都有效的方案），但是它们几乎不涉足下游的打包工作链。我们显然可以做的更好一些。

要在系统的字体交互方面提供更丰富的用户体验上面还存在一些技术问题。一方面，AppStream 的元数据标准定义了一些字体文件特有的参数，但是到现在为止，这些参数没有包含样本、设计师/厂商和其他相关细节的任何信息。另外一个例子，SPDX（ 软件包数据交换 Software Package Data Exchange ）格式也没有包含太多用于分发字体的软件许可证（及许可证变体）。

最后，就像任何一个唱片爱好者都会告诉你的，一个不允许你编辑和完善你的 MP3 曲库中的 ID3 信息的音乐播放器很快就会变得令人失望（LCTT 译注：ID3 信息是 MP3 文件头部的元信息，用于存储歌曲信息）。你想要处理标签里的错误、想要添加注释和专辑封面之类的信息，本质上，这就是完善你的音乐库。同样，你可能也想要让你的本地字体库也保持在一个方便使用的状态。

但是改动字体文件的内置数据一直有所忌讳，因为字体往往是被内置或附加到其他文件里的。如果你随意改变了字体二进制文件中的字段，然后将其与你的演示文稿一起重新分发，那么下载这些演示文稿的任何人最终都会得到错误的元数据，但这个错误不是他们自己造成的。所以任何一个要改善字体管理体验的人都要想明白如何从策略上解决对内置或外置的字体元数据的重复修改。

除了技术角度之外，丰富的字体管理经验也是一项设计挑战。就像我在前面说的一样，有几种开放字体也带了良好的样本和精心编写的文档。但是更多的字体包这两者都没有，还有大量的更老的字体包已经没有人维护了。这很可能意味着大部分开放字体包想要获得样本和证明文件的唯一办法就是让社区去创建它们。

也许这是一个很高的要求。但是开源设计社区现在比以往任何时候都要庞大，它是整个自由开源软件运动中的一个高度活跃的组成部分。所以谁知道呢，也许明年这个时候会发现，在 Linux 桌面系统查找、下载和使用字体会变成一种完全不同的体验。

在这一连串关于现代 Linux 用户的文字设计上的挑战的思考中包含了打包、文档设计，甚至有可能需要在桌面环境加入不少新的软件部分。此外还有其他一系列的东西也需要考虑。其共通性就是在 Web 字体服务不可及的地方，事情就会变得更加困难。

从我的视角来看，最好的消息是现在比起以前有更多的人对这个话题感兴趣。我认为我们要感谢像谷歌字体和开放字体库这样的 Web 字体服务巨头让开放字体得到了更高的关注。

via: https://opensource.com/article/18/3/webfonts

作者：Nathan Willis 译者：Fisherman110 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

对于家用 WiFi 路由器和接入点来说，OpenWrt 项目可能是最广为人知的 Linux 发行版；在 12 年以前，它产自现在有名的 Linksys WRT54G 路由器的源代码。（2016 年）五月初，当一群 OpenWrt 核心开发者 宣布 他们将开始着手 OpenWrt 的一个副产品 （或者，可能算一个分支）叫 Linux 嵌入开发环境 （LEDE）时，OpenWrt 用户社区陷入一片巨大的混乱中。为什么产生分裂对公众来说并不明朗，而且 LEDE 宣言惊到了一些其他 OpenWrt 开发者也暗示这团队的内部矛盾。

LEDE 宣言被 Jo-Philipp Wich 于五月三日发往所有 OpenWrt 开发者列表和新 LEDE 开发者列表。它将 LEDE 描述为“OpenWrt 社区的一次重启” 和 “OpenWrt 项目的一个副产品” ，希望产生一个 “注重透明性、合作和权利分散”的 Linux 嵌入式开发社区。

给出的重启的原因是 OpenWrt 遭受着长期以来存在且不能从内部解决的问题 —— 换句话说，关于内部处理方式和政策。例如，宣言称，开发者的数目在不断减少，却没有接纳新开发者的方式（而且貌似没有授权委托访问给新开发者的方法）。宣言说到，项目的基础设施不可靠（例如，去年服务器挂掉在这个项目中也引发了相当多的矛盾），但是内部不合和单点错误阻止了修复它。内部和从这个项目到外面世界也存在着“交流、透明度和合作”的普遍缺失。最后，一些技术缺陷被引述：不充分的测试、缺乏常规维护，以及窘迫的稳固性与文档。

该宣言继续描述 LEDE 重启将怎样解决这些问题。所有交流频道都会打开供公众使用，决策将在项目范围内的投票决出，合并政策将放宽等等。更详细的说明可以在 LEDE 站点的规则页找到。其他细节中，它说贡献者将只有一个阶级（也就是，没有“核心开发者”这样拥有额外权利的群体），简单的少数服从多数投票作出决定，并且任何被这个项目管理的基础设施必须有三个以上管理员账户。在 LEDE 邮件列表， Hauke Mehrtens 补充到，该项目将会努力把补丁投递到上游项目 —— 这是过去 OpenWrt 被批判的一点，尤其是对 Linux 内核。

除了 Wich，这个宣言被 OpenWrt 贡献者 John Crispin、 Daniel Golle、 Felix Fietkau、 Mehrtens、 Matthias Schiffer 和 Steven Barth 共同签署，并以给其他有兴趣参与的人访问 LEDE 站点的邀请作为了宣言结尾。

回应和问题

有人可能会猜想 LEDE 组织者预期他们的宣言会有或积极或消极的反响。毕竟，细读宣言中批判 OpenWrt 项目暗示了 LEDE 阵营发现有一些 OpenWrt 项目成员难以共事（例如，“单点错误” 或 “内部不和”阻止了基础设施的修复）。

并且，确实，有很多消极回应。OpenWrt 创立者之一 Mike Baker 回应 了一些警告，反驳所有 LEDE 宣言中的结论并称“像‘重启’这样的词语都是含糊不清的，且具有误导性的，而且 LEDE 项目未能揭晓其真实本质。”与此同时，有人关闭了那些在 LEDE 宣言上署名的开发者的 @openwrt.org 邮件入口；当 Fietkau 提出反对， Baker 回复账户“暂时停用”是因为“还不确定 LEDE 能不能代表 OpenWrt。” 另一个 OpenWrt 核心成员 Imre Kaloz 写到，他们现在所抱怨的 OpenWrt 的“大多数[破]事就是 LEDE 团队弄出来的”。

但是大多数 OpenWrt 列表的回应对该宣言表示困惑。邮件列表成员不明确 LEDE 团队是否将对 OpenWrt 继续贡献，或导致了这次分裂的架构和内部问题的确切本质是什么。 Baker 的第一反应是对宣言中引述的那些问题缺乏公开讨论表示难过：“我们意识到当前的 OpenWrt 项目遭受着许多的问题，”但“我们希望有机会去讨论并尝试着解决”它们。 Baker 作出结论：

我们想强调，我们确实希望能够公开的讨论，并解决掉手头事情。我们的目标是与所有能够且希望对 OpenWrt 作出贡献的参与者共事，包括 LEDE 团队。

除了有关新项目的初心的问题之外，一些邮件列表订阅者提出了 LEDE 是否与 OpenWrt 有相同的使用场景定位，给新项目取一个听起来更一般的名字的疑惑。此外，许多人，像 Roman Yeryomin，对为什么这些问题需要 LEDE 团队的离开（来解决）表示了疑惑，特别是，与此同时，LEDE 团队由大部分活跃核心 OpenWrt 开发者构成。一些列表订阅者，像 Michael Richardson，甚至不清楚谁还会继续开发 OpenWrt。

澄清

LEDE 团队尝试着深入阐释他们的境况。在 Fietkau 给 Baker 的回复中，他说在 OpenWrt 内部关于有目的地改变的讨论会很快变得“有毒，”因此导致没有进展。而且：

这些讨论的要点在于那些掌握着基础设施关键部分的人精力有限却拒绝他人的加入和帮助，甚至是面对无法及时解决的重要问题时也是这样。

这种像单点错误一样的事已经持续了很多年了，没有任何有意义的进展来解决它。

Wich 和 Fietkau 都没有明显指出具体的人，虽然在列表的其他人可能会想到这个基础设施和 OpenWrt 的内部决策问题要归咎于某些人。 Daniel Dickinson 陈述到：

我的印象是 Kaloz (至少) 以基础设施为胁来保持控制，并且根本性的问题是 OpenWrt 是不民主的，而且忽视那些真正在 OpenWrt 工作的人想要的是什么，无视他们的愿望，因为他/他们把控着要害。

另一方面， Luka Perkov 指出 很多 OpemWrt 开发者想从 Subversion 转移到 Git，但 Fietkau 却阻止这种变化。

看起来是 OpenWrt 的管理结构并非如预期般发挥作用，其结果导致个人冲突爆发，而且由于没有完好定义的流程，某些人能够简单的忽视或阻止提议的变化。明显，这不是一个能长期持续的模式。

五月六日，Crispin 在一个新的帖子中写给 OpenWrt 列表，尝试着重构 LEDE 项目宣言。他说，这并不是意味着“敌对或分裂”行为，只是与结构失衡的 OpenWrt 做个清晰的划分并以新的方式开始。问题在于“不要归咎于一次单独的事件、一个人或者一次口水战”，他说，“我们想与过去自己造成的错误和多次作出的错误管理决定分开”。 Crispin 也承认宣言没有把握好，说 LEDE 团队 “弄糟了发起纲领。”

Crispin 的邮件似乎没能使 Kaloz 满意，她坚持认为 Crispin（作为发行经理）和 Fietkau（作为领头开发者）可以轻易地在 OpenWrt 内部作出想要的改变。但是讨论的下文后来变得沉寂；之后 LEDE 或者 OpenWrt 哪边会发生什么还有待观察。

目的

对于那些想要探究 LEDE 所认为有问题的事情的更多细节的 OpenWrt 成员来说，有更多的信息来源可以为这个问题提供线索。在公众宣言之前，LEDE 组织花了几周谈论他们的计划，会议的 IRC 日志现已发布。特别有趣的是，三月三十日的会议包含了这个项目目标的细节讨论。

其中包括一些针对 OpenWrt 的基础设施的抱怨，像项目的 Trac 工单追踪器的缺点。它充斥着不完整的漏洞报告和“我也是”的评论，Wich 说，结果几乎没有贡献者使用它。此外，他们也在 Github 上追踪 bug，人们对这件事感到困惑，这使得工单应该在哪里讨论不明了。

这些 IRC 讨论也定下了开发流程本身。LEDE 团队想作出些改变，以使用会合并到主干的阶段开发分支为开端，与 OpenWrt 所使用的“直接提交到主干”方式不同。该项目也将提供基于时间的发行版，并通过只发行已被成功测试的二进制模块来鼓励用户测试，由社区而不是核心开发者在实际的硬件上进行测试。

最后，这些 IRC 讨论也确定了 LEDE 团队的目的不是用它的宣言吓唬 OpenWrt。Crispin 提到 LEDE 首先是“半公开的”并渐渐做得更公开。 Wich 解释说他希望 LEDE 是“中立的、专业的，并打开大门欢迎 OpenWrt 以便将来的合并”。不幸的是，前期发起工作并不是做得很好。

在一封邮件中， Fietkau 补充到 OpenWrt 核心开发者确实在任务中遇到瓶颈，像补丁复审和基础设施维护这些事情让他们完成不了其他工作，比如配置下载镜像和改良构建系统。在 LEDE 宣言之后短短几天内，他说，团队成功解决了镜像和构建系统任务，而这些已被搁置多年。

我们在 LEDE 所做的事情很多是基于转移到 Github 的去中心化软件包开发经验，并放弃了软件包应如何被维护的许多控制。这样最终有效减少了我们的工作量，而且我们有了很多更活跃的开发者。

我们真的希望为核心开发做一些类似的事，但是基于我们想作出更大改变的经验，我们觉得在 OpenWrt 项目内做不到。

修复基础设施也将收获其他好处，他说，就比如改进了用于管理签署发布版本的密码的系统。团队正在考虑在某些情况下非上游补丁的规则，像需要补丁的描述和为什么没有发送到上游的解释。他也提到很多留下的 OpenWrt 开发者表示有兴趣加入 LEDE，相关当事人正试图弄清楚他们是否会重新合并该项目。

有人希望 LEDE 更为扁平的管理模式和更为透明的分工会在困扰 OpenWrt 的方面取得成功。解决最初的宣言中被诟病的沟通方面的问题会是最大的障碍。如果那个过程处理得好，那么，未来 LEDE 和 OpenWrt 可能能够求同存异并协作。否则，之后两个团队可能一起被迫发展到比以前拥有更少资源的方向，这也许不是开发者或用户想看到的。

via: https://lwn.net/Articles/686767/

作者：Nathan Willis 译者：XYenChi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Linux 标准规范 （ LSB，Linux Standard Base ） 是一个意图定义 Linux 发行版为第三方程序所提供的服务和应用层 程序二进制接口 （ ABI，Application Binary Interfaces ） 的规范。但 Debian 项目内的某些人正在质疑是否值得维持兼容 LSB，他们认为，该项工作的工作量巨大，但好处有限。

LSB 于2001年首次公布，其模型建立在 POSIX 和 单一 UNIX 规范 （ Single UNIX Specification ） 的基础之上。目前，LSB 由 Linux 基金会的一个工作小组维护。最新的版本是于2015年6月发布的 LSB 5.0。它定义了五个 LSB 模块（ 核芯 （ core ） 、桌面、语言、 成像 （ imaging ） 和试用）。

每个模块都包含了一系列所需的库及其强制性版本，外加对每个库的公共函数和数据定义的描述。这些模块还包括命名和组织规范，如 文件系统层次标准 （ FHS，Filesystem Hierarchy Standard ） 中的文件系统布局或象 Freedesktop 的 XDG 基础目录 （ XDG Base Directory ） 规范这样的目录规范。

似乎只是一个巧合，就在 LSB 5.0 发布的同一周，Debian 项目内部针对其是否值得保持兼容 LSB 进行了一次讨论。在另一个贴子中，在提及兼容 LSB 后，Didier Raboud 顺势提议将 Debian 的兼容工作维持在最低水平。他说，目前的情况是，Debian 的“lsb-*” 元包 （ meta-packages ） 试图规定该标准中提及的库的正确版本，但事实上却没有人去检查所有的符号和数据定义是否满足要求。

另外，LSB 还不断在膨胀；他说， LSB 4.1 版（接近 Debian “jessie” 发布时的最新版本）包含“1493个组件、1672个库、38491条命令、30176个类和716202个接口”。似乎没有人有兴趣检查 Debian 包中的这些细节，他解释道，又补充说，“去年在 DebConf 上我举行过一次 LSB BoF，后来又与很多人讨论过 src:lsb，我收回自己的‘几乎没有人在意’的说法”。但，重要的是，Debian 似乎并不仅局限于兴趣的缺乏：

我认为，这个问题的关键在于是否值得去玩这整个游戏：我还没听说有哪个软件通过 LSB 包来发行。LSB 认证的应用清单上只有 6个公司的_8_个应用，其中仅有一个是针对不低于 LSB 4 的。

Raboud 提议 Debian 摈弃除了 lsb-base 包（目前包括一个用于启动系统所需的小的 shell 函数集合）和 lsb-release 包（提供一个简单工具，用户可用它查询发行版的身份以及该发行版宣称的与哪个 LSB 级别兼容）之外的所有内容。

后来，他又称，将 LSB 基本上改变为“Debian 和 FLOSS 世界中的所有的其它人所实际做的任何事”可能会使得该标准（以及在 Debian 为支持它所做的工作）更有价值。但此时他再次质疑是否有人会对推动这个目标有兴趣。

如果说他最初称 LSB 中缺乏兴趣没有足够的证据，随后整整三个月之内没有任何人对维持 LSB 兼容的包提供支持，并进行了两次拋弃它们的投票。最后，9月17日，Raboud 宣布他已经抽掉 src:lsb 包（如前所述，保留了lsb-base 和 lsb-release），将将其上载到 “unstable” 归档中。这个最小的工具集可以让感兴趣的用户在启动了下一个 Debian 版本后查询它是否兼容 LSB：结果将为“否”。

Raboud 补充说，即便摈弃了兼容 LSB，Debian 仍计划继续兼容 FHS：

但 Debian 并没有放弃所有的 LSB：我们仍将严格遵守 FHS（直到 Debian Policy 版本 2.3；虽然今年8月已经发布了3.0），而且我们的 SysV 启动脚本几乎全部遵循 VIII.22.{2-8}。但请不要误解，此次 src:lsb 上载明确说明我们将离开 LSB。

在该宣告之后，Nikolaus Rath 回应称某些私有应用依赖/lib和/lib64中的符号链接ld-lsb.so*，而这些符号链接由lsb-*包提供。Raboud 则建议应改由libc6包提供；该包维护人员Aurelien Jarno 称，如果提供这样一个补丁，他将会接受它。

似乎唯一的遗留问题只是某些打印机驱动包会依赖 LSB 兼容。Raboud 称，在其首个贴子中已经说明，据他所知，实际发布的唯一一个依赖 LSB 兼容的包为 OpenPrinting 驱动程序。Michael Biebl 称，主归档中有这样一个驱动包；Raboud 则回应说，他认为这个有问题的包应该被移到非自由仓库，因其包括了一个二进制驱动。

于是，这个问题看上去已经尘埃落定，至少对于目前的 Debian 开发周期来说是如此的状况。很自然的是，未来让人更感兴趣的是，如果该决定存在一些影响的话，那么人们将会看到它对更广泛的 LSB 接受度有何影响。正如 Raboud 所说的那样，被认证为 LSB 兼容的发行版数量很少。人们很难不会注意到这些发行版很大程度上是“企业”的变种。

也许，对某些商业领域来说，LSB 仍很重要，但很难知道有多少那些企业发行版的客户真正关心 LSB 认证标签。然而，如果 Debian 的经验靠得住的话，对这种认证的一般兴趣可能会急剧下降。

via：https://lwn.net/Articles/658809/

作者：Nathan Willis 译者：Yuking 校对：wxy

本文由 LCTT 原创编译， Linux中国 荣誉推出