关于这些矢量图标（2011）

为什么我们不能只在应用程序中使用基于矢量的图标？通过各种重新解释，这个问题在各种论坛，博客和文章中不断出现。在桌面应用程序的上下文中，要求以不同的方式使用相同的图标，从文件列表中的很小的16 * 16图标开始，到扩展坞上使用的128 * 128图标，一直到512 * 512的图标。至少在1200dpi桌面显示器取代计算世界之前，它主要是用来突出图标设计师的艺术能力。在Android平台的本机移动应用程序的上下文中，也有人提出要提出一个矢量图标（SVG格式）来代替同一图标的多个版本的建议，每个版本都针对特定密度桶（通常是中等和高）。

乍一看，设计人员和开发人员都只能从切换到创建矢量格式的图标中受益。设计师将在他选择的工具中创建图标的单个版本，将其交给开发人员以添加到项目结构中，并使运行时将图标的组合形状缩放到所使用的任何上下文–是操作栏上的小图标，还是“关于”页面上的超大图标。实际上，在本条目后面引用的文章和博客文章中，有很多评论表明该方法效果很好。至少在技术上。因此，总结一下不满的感觉，是吗？

几天前，我邀请我们的一名视觉设计师吃午餐，并问他关于为多种屏幕分辨率创建图标的一般过程（针对Android的核心体验）。答案至少对我来说是令人惊讶的。第一阶段发生在素描簿或白板上，在其中探索不同的想法，形状和组合，以找到在平台的整体方向上均能正常工作的图像，同时仍为特定动作或对象提供独特的形状和形式由图标表示。然后，流程转移到计算机，其中Adobe Illustrator和Fireworks是最受欢迎的选择。设计师在那里以矢量格式创建图标的``主版''版本。此版本按比例缩小到所有目标分辨率（中，高，有时低，最近是超高），这就是乐趣的开始。在这里，设计师可以针对每个分辨率查看按比例缩小的图标版本，并开始有时艰苦的像素完美视觉效果处理。

在特定应用程序内以及整个平台上，创建和维护一致的视觉图标语言涉及很多艺术和工艺。线条应清晰，圆角应具有一致的曲率，照明和渐变应具有一致的方向和幅度。此外，分辨率较低的图标不应具有过多的视觉细节，而分辨率较高的图标不应感到过于稀疏。 Firewheel设计在“图标设计：位图与矢量”一文中对此进行了说明：

第一行显示了四种不同分辨率下的同一应用程序图标的手动优化版本。底行显示了从单一来源数学上缩放的图标。如果您比较顶部各行图标各部分的相对大小和细节复杂程度，则会发现它们的缩放比例不同。有些部分随着图标大小线性增长，而另一些部分则以慢得多的速度增长。 Neven Mrgan在“ iOS应用程序图标的所有大小”中作了进一步说明：

根本不可能创建出色，详细的图标，而这些图标可以在保持清晰度的情况下任意缩放到很小的尺寸。小图标是讽刺漫画：它们夸大了某些功能，放下了其他功能，并将形状与清晰的网格对齐。即使所有图标都可以作为矢量执行，最大尺寸也永远不会缩小。

请注意，缩小比例约为64像素;之后，必须重新绘制形状，使其更简单，更清晰，以便阅读。实际上，图标的侧边栏版本完全不同。由于我们知道它会显示在侧边栏中，因此看起来像一个文件夹并不重要，可以强调其他功能。将大图标创建为矢量形状-显然，您应该这样做！ –在真正需要清晰度的地方无济于事：小尺寸。高分辨率显示器实际上将使这个问题更加紧急，因为今天的64像素是明天的128像素。我们必须优化更大的图标。

Dave Shea在“图标设计：大小调整”中仔细研究了优化原始形状和线条以减小尺寸的机制：

解决方案是从缩小版本开始，然后在单个像素级别进行调整。使细节适合像素网格，删除会导致模糊的多余细节，或者如果可以帮助您达到最终目标，甚至添加额外细节。无论采取什么措施，解决方案都是认真研究问题并进行调整，直到获得满意的结果为止，这就是尺寸变化如此之多的原因。

在上面的日历中，您会注意到我对两种不同尺寸进行了调整，因此内部框最终在两侧均具有整个像素值。为此，我不得不将框的尺寸缩小为24×24，实际上创建了16×16的框。我无法提出4列具有1像素宽边框的组合，该边框将适合以较小尺寸分配的空间，我发现唯一可行的组合涉及添加额外的列并删除一行。该图标与32×32等效图标略有不同，但显然是从较大的图标衍生而来的，可以作为可接受的尺寸变化。

在各种现代应用程序和UI工具箱中，可以看到小图标移动形状甚至“丢失”其中一些图标的其他示例。这是广受好评的Mac版iA Writer应用程序的示例：

尽管中心元素（倾斜的天蓝色插入符号）保留了整体形状，角度和渐变，但靠近32 * 32尺寸，其旁边的文本开始“丢失”字符。 16 * 16图标只是插入符号，旁边没有字符。

在GNOME 3.0中引入的系统图标中可以看到用于简化形状，纹理，透视图和密度的相同方法：

如果您在这三个图标（以及原始条目上的其他图标）上跟踪过渡到较小图标大小的进度，则会看到一致的方法，该方法开始去除尺寸，复杂性，纹理，渐变和密度，不仅保留了图标的整体形状和感觉，以及在相同大小的所有图标上图标语言的一致性。

如果您不希望花费更多的时间来以较小的尺寸完成图标的像素完美处理，则可以使用单一源矢量格式作为“主版”并缩小到任意大小，这非常适合SVG。在这种情况下，以下自引自名的“图形忍者” Zack Rusin引述了KDE中的SVG：

小尺寸矢量图形的质量损失是一个严重的问题。以低分辨率渲染矢量图形基元会在输出中引入一定量的模糊。这主要是由水平和垂直图元恰好落在像素边界之间引起的，这反过来又使反走样算法尝试通过光栅化两个而不是一个行/列，但以较低的颜色强度对其进行光栅化处理。对于以小尺寸渲染的图元，“分辨率独立性”和“在各种分辨率下保持其良好外观”的目标大相径庭。我们有前者，我们需要后者。

提示此问题的方法之一。提示矢量图形基元的问题已通过字体技术进行了广泛研究。网格拟合（又称“字体提示”）是为许多字体以小尺寸生成清晰的输出的关键步骤。提示可以是手动的（例如，TrueType具有基于堆栈的语言，字体中的每个字形都包含其自己的小提示程序，由于运行该结果，轮廓的程序控制点可以通过任何方式来调整。提示）或自动（由FreeType使用）。在“基于示例的TrueType字体提示中”中描述了一种有趣的媒介，其中描述了一种将一种字体的提示重用于另一种字体的方法。总而言之，这是字体非常普遍的问题。

来自FreeType项目的工程师在自动提示方面的研究非常出色。目前，KDE艺术家解决此问题的方法是通过生成具有不同视口大小的某些SVG图标。这使他们可以为某些原始分辨率手动调整渲染。

这种情况的现实情况是，没有很高的DPI显示器，小型SVG渲染的质量将受到影响。一种解决方案将涉及引入自动提示算法或添加声明性方法来指定艺术家可以轻松利用的提示。这个问题会影响所有SVG用户，应在标准本身中解决。

像素完美的矢量图形和字体字形的自动提示之间有很多相似之处。两者都旨在解决一个非常相似的问题。两者的工作流程都是以极高的分辨率创建主版本，以便在小册子，公文包和促销材料中看起来都很好，但是按比例缩小到“真实世界”使用的版本会遇到网格拟合差，细节混乱，细节丢失和模糊的问题。 。实际上，一些设计师甚至建议完全放弃独立的图标，而改用类型引擎的高级功能。去年，由Wayne Helman提出，P.J。Onori在他的“字体嵌入图标：这是一件大事”中进一步加以扩展，并说：

这篇文章广受好评，但老实说，我希望这个想法会更加令人兴奋。在我看来，这现在似乎是在网站上设置图标的方式。我对这种方法的潜力深有感触，因此我想花点时间为Iconic生成字体集并讨论为什么我们都应该使用此方法来显示图标。

将“一个无限大小的图标”列为优势之一，这似乎是一个很好的解决方案，但仅适用于双色调或更确切地说是纯黑白图标。此外，它完全无法解决房间中的巨型大象-对于无法很好地缩放到小尺寸的复杂图标该怎么办？类型引擎有两种解决此问题的主要方法-嵌入位图和字体提示。

嵌入位图是一种非常简单的方法。您从字形的高分辨率主定义开始，然后识别那些未在特定点之前缩小的字形（小写的“ m”，“ s”，“ a”和“ g”通常是主要可疑字符） ）。对于这些字形，您可以手动调整所有目标点大小的视觉效果，将它们导出为位图，然后将位图作为二进制斑点嵌入到字体文件中。实际上，它可以以其他方式工作，正如Microsoft的排版员Simon Earshow所详述的那样：

过去，我从大纲开始就精疲力尽，并在提示方面变得更加聪明。所以我最终决定，‘我最好先抓荨麻。最重要的是使位图正确地适应人们最常用的尺寸。’因此，我从简单地制作位图字体开始，而不是从轮廓开始，然后在屏幕上提示它们。没有轮廓，只有位图。

位图相对容易制作，并且可以精确显示字体在屏幕上的外观。这使我们能够根据上下文来决定大小，权重以及衬线，无衬线，罗马字，斜体字之间的区别。通过这种方式，我们提出了一些关键尺寸和重量的定义。

关键位图完成后，我非常仔细地在它们周围包裹了轮廓。我始终牢记，然后将轮廓线交给负责提示的人-他们将需要能够提示轮廓线以逐像素地返回到我们开始的位图面。

嵌入位图在CRT显示器上效果很好，但无法扩展到LCD显示器和亚像素渲染的领域。正如彼得·比拉克（Peter Bil’ak）在Typotheque上的精彩概述所总结的，这就是提示的作用：

这正是暗示的意义：对字体的光栅化进行微调的编程指令，将数学上理想的轮廓映射到显示器像素的过程。提示可以控制字体的大小写字母的高度和宽度，其各行的宽度，字母周围的空白量，大写字母开始使用与小写字母不同的词干宽度的大小，角度斜体字符的更改最适合像素网格，以及许多其他非常技术性的细节，所有这些都是逐像素进行的。如果这听起来像是一个相当繁琐且耗时的活动，那就是（即使对于习惯于乏味且耗时的活动的字体设计人员而言）。

Beat Stamm在“低分辨率栅格悲剧”一文中说明了类型提示的复杂性，该文章对暗示单个字形的含义仅作了一点介绍，更不用说类型引擎本身的实现复杂性了。

Beat Stamm甚至还通过RasterTragedy.com跟进，深入研究了各种现代引擎的抗锯齿，提示，布局和渲染。

为了进一步了解为特定字形创建类型提示程序的复杂性，您可以从本《 Hello world》教程开始，该教程提示大写的``L''，接着是带有曲线，衬线和倾斜茎的字形的更复杂示例，最后展示了完整的TrueType指令集，该指令集的复杂度甚至可以超过SVG本身。

在整篇文章中，我都避免了SVG格式本身及其完整实现的复杂性。原因很简单–如果格式足够强大，可以满足特别关注像素级细节的设计人员的需求，那么自然就会推动将这种格式的完整实现包含在UI工具包中和平台。但是，在目前状态下，SVG尚不存在。此外，以类似于TrueType提示指令的功能扩展SVG不仅会使完整实现更加复杂。一个更重要的问题是，这是否会使图标设计人员更轻松地创建基于矢量的单个图标版本？

如果您一直遵循我的推理，那么简单的答案是“否”，不是。当需要学习每个图标行，每个图标笔划，每个图标形状时，需要在小尺寸下进行精确渲染，而当您需要远远超出每个单独的图层以确保将它们提示为一个整体时，毫无疑问，还有额外的工具集将超出类型引擎的当前指令集，因为它需要支持照明，渐变，折叠和隐藏细节–这不是一个可行的解决方案。

至于像素完美的图标的过程？将主版本缩小到所有目标大小后，您可以执行其他操作。您可以直接开始移动像素，但要以回去更换母板时重做相同的事情为代价。或者，您可以返回到母版并创建“辅助”母版，每个目标尺寸一个。每个次要母版并非旨在以最高分辨率使用，而是经过优化以缩小到目标尺寸时创建最佳像素级版本。不利的一面是，一旦更改了原始母版，您将需要进行更多调整。

关于高分辨率显示器和Neven Mrgan的上述报价的最终思考。相信我们的飞跃，假设50年后我们将拥有分辨率为1200dpi的屏幕（“仅”是iPhone 4和Galaxy Nexus的分辨率的四倍，但像素的平方英寸却是它的十六倍）。在这样的世界中，单个沙粒将覆盖四个16 * 16像素的图标。实际上，本文中所有提到的小尺寸图标都是指小尺寸的物理比例，而不是像素比例。为了维护可用的触摸界面（可以用人眼轻松扫描的界面），您将需要保持图标的当前物理比例-使它们在像素比例上更大。在具有当前用户界面构建块的此类设备上，最小的图标约为128 * 128像素。但是，这并不意味着您可以突然将所有精细细节从（甚至更高分辨率的）主图标填充到可用的像素空间中。随着每个像素变小，这并不意味着您要逐渐增加细节的复杂性和密度。

正如Neven指出的那样，清晰度是至上的，在这样的未来中，图标设计人员将不得不手动调整更多的图标尺寸。 而且，除非未来是一个概念视频，每个人都在使用似乎具有无限电池寿命和连接性的高端设备来回走动，否则高端和低端设备之间的功能差距将更大。 在这样的未来，图标设计人员将不得不维护相同像素大小的图标的多个版本，每个版本都可以完美像素化，以用于具有特定密度的设备。 但是话又说回来，在50年中，可能还存在一种完全不同的方式来呈现信息以及一种完全不同的技术来进行交互。