前几天我收到了一封来自 Andy Fitzsimon 的邮件，内容是他正在进行的一些项目。其中一个是 logomono，我个人觉得它非常有趣，并且 几天前分享了它。我觉得，与其费尽心思自己去弄懂并重新解释，还不如直接问 Andy 一些问题，访谈的形式来进行。
我的问题用标题表示；Andy 的回复紧随其后。
你能简单地解释一下 logomono 到底是什么，以及它背后的动机是什么吗？
logomono 是一个（相当）庞大且不断增长的 GitHub 代码库，它包含了单色 SVG 的 logo。这个项目的目的是促进人们对在网络上使用和引用 logo 的关注。
该网站还涵盖了一些技巧、工具和教程，旨在让设计师和开发人员更容易使用 logo。
为了保持极简，所有 SVG 都只由几个平面的 <path> 组成，并且没有颜色。
logomono 主页上展示的第一件事是关于让 logo 在深色或浅色背景上都能正常显示的想法。这是你遇到的一个问题吗？你认为这是任何真正强大的 logo 的先决条件吗？
对于许多现有的 logo 来说，正确反转无疑是一种礼貌的行为，也是值得考虑的事情。这是 logo 的一个功能，在如今却常常被忽略。如果使用的 logo 包含阴影（或其他一些考虑因素），很可能存在另一种版本，你应该在深色背景上使用它。对于 logo 设计师来说，要为浅色和深色情况制作多个 logo 变体需要投入更多，但这确实是一种相当常见的需求。请记住，你的 logo 并不总是只由你使用。
logomono 的诞生源于我在 Red Hat 做品牌经理时遇到的种种挫败。Shadowman（Red Hat logo 中的图标）的眼睛上投下了阴影。当在深色背景上反转填充色时，它并不起作用。他更像是用白色填充了眼睛的激光眼男人。
同样的问题也出现在我最喜欢的两个开源项目 logo 上
Inkscape（以墨迹斑斑的山脉 Inkky 为特色）和 Linux（以企鹅 Tux 为特色）
我们知道企鹅的翅膀是黑色的，肚子是白色的。我们也知道山峰上的冰盖需要比山峰本身更亮。令人惊讶的是，这样的细节竟然会被忽略。
为了解决这个问题，我们可以用我们的一生来告诉一百万个设计师一百万次。或者，我们可以把它写下来，并努力使其足够有用以记住。这就是 logomono 存在的意义。
在工作中，我总是收到客户、合作伙伴或员工使用错误反转的单色 Red Hat logo 的样稿。这让我感到双倍的痛苦。第一，因为它不是正确的 logo。第二，因为某个可怜的家伙不得不从他们在维基百科上找到的全色 logo 中努力制作它。也许他们甚至搞砸了坐标。也许我们的 logo 失去了鼻子。
有些设计师会搜索“单色 [公司名称] logo”，并在正确的背景下找到合适的东西。但今天，他们得到的只是像 Brands of the World 和 Wikimedia 这样的网站。更不用说，还有很多糟糕的网站，里面有通过自动描边矢量创建的下载文件，以及非常古老的 logo 版本，它们迟迟不消失。我想主动为他们提供更好的版本。我想提高人们的意识，让大家明白，反转是 logo 背后的人希望被考虑的事情。
单色也是其中的一部分。就我而言，我希望我们的红色帽子是红色的，但是当它与其他公司的 logo 堆叠在一起时，我理解视觉和谐的必要性。
看起来，要使 logo 能够反转，需要进行一些隐藏/显示的翻转操作，有时还需要额外的元素。资源大小是否会成为问题？或者嵌入技术？
我建议为三种类型的 <path> 使用两个可选的类
- 正常路径。无需添加类。它们应该始终显示。通常是 logo 文本，以及许多品牌的整个 logo 轮廓。Nike、IBM、Intel… 你们这些幸运的品牌！
- 仅限浅色背景。对于应该在浅色背景上渲染为深色填充的形状，使用
class="only-light-background"。想想：任何带眼睛的东西。你希望绘制瞳孔的路径是深色的。看看 Hadoop、Tux 以及像福特这样的没有吉祥物的公司的品牌标识，这些公司更喜欢用浅色文本书写他们的名称，并相应地反转。
- 仅限深色背景。对于只在深色背景上作为浅色填充才有效的路径，使用
class="only-dark-background"。
默认情况下，我们假设使用的是浅色背景，因此我们以这种方式将它们存储在代码库中。这样，文件仍然可以以其原始形式使用。这意味着在仅限深色背景的路径上使用了内联 style="display: none;"。这可以在构建过程中删除。
你使用 logomono 的方式可能有所不同，这取决于你需要做什么。如果你有一些交互功能可以反转背景，那么将所有路径都放在 SVG 中并将 display、opacity 或 visibility 值在你的 CSS 中覆盖以根据需要翻转浅色和深色是有意义的。
如果你只需要一个版本（深色或浅色版本），那么你可以使用 logomono logo，但可以使用像 Gulp 或 Grunt 这样的工具运行一个任务来剥离你不需要的路径。
你建议使用 viewBox，但不使用 height 或 width 属性。这是在生产环境中推荐的吗？还是说这些属性可以稍后添加？我发现如果没有默认的宽度/大小，SVG 会尽可能地宽，直到 CSS 调整其大小，这可能会导致加载体验很不理想。
这是为了保持代码库精简高效。我们希望在用户知道他们想要什么之前不要添加宽度和高度。
如果你获取每个 logomono 文件，并向 <svg> 添加一些随机的尺寸属性，例如 width="100px" height="76px"，就不会出现问题。你将拥有你声明大小的所有 logo，并避免加载时的不流畅。但是，对于一个包含不同大小 logo 的文件夹来说，就不能这样做了。我们无法提前知道你喜欢的尺寸，因此我们不添加它们（但你可以添加）。
像 Slides.com 这样的网站就是这样做的，如果你上传一个只有 viewbox 的 SVG，导入器会使用 viewbox 尺寸添加宽度和高度属性。
你另一个建议是，由于抗锯齿，logo 周围要留 4% 的间距。你能详细解释一下吗？我担心，将 logo 准确地对齐到边缘，就需要进行可能令人沮丧的逐像素调整。
我希望能得到更多关于这方面的反馈。问题在于抗锯齿溢出。
一开始，我想的是“让我们将源代码库中的 SVG 直接贴在墙上：0 0 为其 viewBox 的最小值和最大值！”
我的想法是，我们可以始终使用后期处理来为 viewbox 添加相同的间距，以避免抗锯齿溢出。例如，假设一个 logo 的 viewBox 为“0 0 120 150”。处理后，它会变成 viewbox="-4 -4 124 154"。假设另一个 logo 的 viewBox="0 0 50 70"。它会变成 viewBox="-4 -4 54 74"。这样就能避开潜在的溢出。
但随后我开始思考，在 viewBox 中对每个轴添加和移除 4 会对“坐标系很大”的 SVG 与“坐标系很小”的 SVG 产生不同的影响。也许它必须基于 viewBox 长度总和的计算百分比。
然后我意识到，在后期处理中进行所有这些操作意味着代码库中的源 logo 本身就会出现缩放抗锯齿问题，这是不可取的，因为这些文件必须本身可用。
然后我开始思考，这个“4%”的建议为 logo 贡献者提供了极小的视觉调整自由度。
即使我们生活在一个缩放 SVG 没有硬边抗锯齿问题的魔法世界中，logo 也像印刷字体一样。圆形和角度，例如 O 和 W，需要稍微调整一下，才能让它们看起来更直。4% 看起来是最简单的折衷方案。
目前，我们把这个想法放到“太难了，放一边”的篮子里。也许我们将来会重新计算现有 logo 的坐标，但现在还不做。
作为设计师，我们在排版工作时注定要进行微调。希望将 4% 作为通用规则，可以将这种微调降至最低。我绞尽脑汁也想不出如何才能正确存储并尊重设计师们想要权衡的所有平衡因素。
- 徽标和文本沿着基线排列
- 粗细和重量平衡
- 左右视觉对齐
同时，将这些文件保持“原始”状态，使其成为网络的基本构建块：易于贡献；易于使用。至少现在它们已经足够接近，可以容忍眼睛处理了。士兵，继续微调吧！
也许在未来，当网络拥有诸如元素媒体查询之类的奇妙功能时，我们可以扩展 logomono，包含用于垂直或水平堆叠徽标或折叠为图标的徽标的经验法则。今天，让我们保持简单。
任何人都可以贡献吗？如果可以，最有用的是什么工作？
任何人都可以贡献。
- 单色徽标。到目前为止，最有用的是单色徽标。找到缺少的徽标并发送拉取请求。将那些剪切路径布尔运算，将文本轮廓化，合并那些重复的控制点。
- 工具和项目页面改进。
- 意识到一些徽标需要反转。
如果您是相关品牌的负责人，那将非常有帮助，这样就可以按您的要求优化文件。但如果您想添加另一个徽标，请不要犹豫。