SVG就是你所需的一切

二十年前在剑桥大学植物科学系担任博士后时开展的一个项目，最近重启该工具时，惊喜地发现它在现代浏览器中仍能完美运行

 💬 146 条评论 |  svg | 

SVG 相当酷炫——以简单 XML 格式呈现的矢量图形。它们几乎支持所有设备和平台，在任何显示屏上都清晰锐利，还能嵌入脚本实现交互功能。其功能远超多数人认知的范畴，我认为我们可以挖掘其中尚未开发的潜力。

阿尼尔近期发表的《构建大规模集体知识系统的四大要素》一文引发我对科学论文背后实验永续性的思考。在我理想化的科学出版愿景中，每篇论文都应配备全交互式环境：读者可探索原始数据、复现实验过程、调整参数并观察结果变化。当然这无法普遍实现——某些实验成本过高或耗时过长，无法随时复现。但对多数论文而言，尤其在计算机科学领域，这完全可行。

元素周期表

这番思考让我想起约二十年前在剑桥大学植物科学系担任博士后时开展的一个项目。当时我正在撰写关于真菌网络协同作用的论文，并开发了一个小型SVG可视化工具，让读者能自由浏览培养皿中真实真菌网络生长的原始数据。最近重启该工具时，惊喜地发现它在现代浏览器中仍能完美运行——尽管原始“封面页”推荐使用Firefox 1.5或Adobe SVG插件(!)。快来试试吧！点击培养皿下方的“前进”、“后退”等按钮即可探索！

亲爱的读者，这正是你所需的一切。一个完全自包含的SVG文件既可从版本化仓库获取数据，也可像本例那样直接嵌入数据。它能处理数据、生成可视化效果，并呈现旋钮和滑块供交互探索。无需服务器端魔法——所有操作都在浏览器客户端运行，由普通静态网页服务器提供支持，且极易分享。

这与阿尼尔提出的四大特性如何契合？

  • 永久性：SVG可像论文、博客或数据集一样分配DOI。上述SVG历经二十年仍能正常运行，正是其格式持久性的明证。
  • 溯源性：作为纯文本格式，SVG与Git等版本控制系统完美兼容。当SVG引入外部数据时，安尼尔为数据集提出的溯源追踪策略同样适用。
  • 权限管理：由于SVG处理逻辑与数据源的分离特性，其权限模型与常规数据管理完全一致。
  • 空间呈现：SVG具有固有的空间属性，例如用SVG制作精美的世界地图非常容易。

上述SVG仅作为数据可视化工具，本身不执行处理操作，但具备处理能力。自本文撰写二十年来，最大的变化在于浏览器计算能力的飞跃式提升。如今完全可在SVG中实现该论文的完整数据分析流程，甚至无需启动笔记本电脑的风扇！

这标志着我们持续推进工作成果共享与再创作的又一里程碑——继Jupyter笔记本、Marimo botebooks、slipshow/x-ocaml 组合， Patrick对Jon Sterling的Forester工具的见解， 我自己的笔记本，以及许多其他资源——而这仅仅是我们团队内部使用的部分内容！

本文文字及图片出自 An SVG is all you need

共有 146 条讨论

  1. 虽然这篇文章主要讨论可视化技术，但我想分享自己曾开发过一款舞蹈编排软件，其界面完全采用SVG渲染。其运行效果之出色令我颇感意外。

    若感兴趣，该软件名为StageKeep，可在此处查看：https://stagekeep.com/

    原始项目采用React Three Fiber框架，后因某些已记不清的原因重构为SVG。我受到有符号距离函数的启发——单个函数竟能产生如此惊人的视觉效果。虽然软件本身并未采用SDF技术，但我钟爱这种原子函数的设计理念——接受输入参数，输出SVG代码。

    回复

    1. SVG曾被誉为“Flash杀手”。凭借SVG+CSS+JavaScript的组合，它本可实现Flash的所有功能，包括炫酷的Flash网站和复杂应用程序。但问题在于缺乏优秀的创作工具，而Flash拥有卓越的创作平台。

      后来Flash悄然消亡，却未被任何技术取代

      回复

      2. 谢天谢地。Flash——愿上帝保佑它——堪称互联网历史的低谷。人们根本无法抗拒滥用它的诱惑。我并非谴责工具本身，但Flash的成瘾性让理智之人做出糟糕透顶的UI和UX决策。击溃Flash或许是乔布斯最被低估的成就。

        回复

        1. 说实话，我认为Flash的消亡主要该归咎于Adobe。

          若他们愿意投入必要资源提升性能，更重要的是确保安全性，Flash生存的几率本会大得多——甚至可能让乔布斯愿意在iPhone上支持它。(也许吧。)

          太多人哀叹Flash消亡摧毁了蓬勃发展的游戏生态与艺术形式，却忘了它同时是巨大的资源消耗者，众多系统崩溃的首要元凶，更是恶意软件传播的超级载体。真想看看统计数据：究竟有多少感染源于Flash？当浏览网络不再依赖它时，感染率又以何等速度骤降。

          更别忘了，Flash最初并非Adobe产品：他们通过收购Macromedia将其纳入麾下，既消灭了最大竞争对手，又确保了垄断地位。虽然我当时并未密切关注该领域，但若在Macromedia时期Flash能获得更频繁的优化更新，我丝毫不感意外。

          回复

        2. 不过它确实终结了网页游戏轻松制作的时代。

          回复

        3. 但Flash直接催生了《南方公园》——史上最搞笑的动画系列之一。值得！

          回复

          1. 这种Flash技术依然活跃。许多新动画都用Flash制作(小马宝莉：友谊就是魔法、蓝精灵、魔法奇缘最后一季等)。真正消亡的不是Flash本身，而是Shockwave Flash(浏览器版Flash)。

            回复

      3. 问题部分在于浏览器从未真正优化SVG渲染，尤其在CSS配合方面。若我记忆无误，动画笔触效果尤其粗糙。

        回复

        1. 浏览器对SVG的渲染至今仍未达最佳状态，这令人遗憾——若能将其视为网页的一流元素，SVG本应拥有巨大潜力。近期推动(2D)Canvas API画布元素的代码改进表明，这项工作本可在跨浏览器环境实现。阻碍发展的关键因素或许是持续未能最终确定SVG2标准？

          回复

          1. 能否具体说明你认为哪些方面不够理想？是性能问题还是其他因素？

            我多年来在各种场景中使用SVG(虽然主要用于静态图形)，个人体验尚可。

            回复

            1. 问题在于浏览器开发商出于诸多合理考量，选择不投入资源构建高效、稳健且快速的SVG引擎。我认为这更像是善意的忽视而非主动阻碍。相较于过去十年间大幅进化的JavaScript和CSS引擎，SVG至今仍仅能满足基础需求(简单场景——静态图形、图标等)，难以胜任更高要求。这样解释清楚了吗？

              回复

              1. 我对浏览器的内部机制或开发流程/计划一无所知，但曾用requestAnimationFrame通过JavaScript实现SVG图形动画，即使没有现代显卡(仅靠集成显卡)也能流畅运行。唯一出现性能下降的情况是使用包含模糊和镜面反射的复杂滤镜时。

                回复

        2. 早在2008年我就用HTML4实现了相当不错的渲染效果，支持多种浏览器(当时甚至兼容IE6、7甚至8)。

          2010年前后我尝试过Silverlight和SVG技术。SVG效果尚可，但性能表现欠佳。如今或许已大有改善。

          回复

      4. 某些企业曾多年付费维护专属版本的Flash，只为支撑其内部Flash业务应用。

        回复

    2. 这是款绝妙的软件，学习过程让我乐在其中。

      我非常期待这个功能：输入视频素材，输出基于该视频的编排方案。例如：导入Project21或Avantgardey的舞蹈视频，通过AI/ML技术解析其编舞结构。

      您认为可行吗？

      回复

      1. 若能实现，我渴望看到它应用于鲍勃·福西的《富人的弗鲁格舞》。那种编舞艺术总让我懊悔没选择截然不同的职业道路。

        回复

    3. 哇，这太酷了。作为舞台导演我偶尔会接触编舞。用这种技术预先规划舞台调度简直绝了。

      回复

      1. 这确实适合调度规划。但动作设计呢？拉班动作符号系统恐怕行不通。

        回复

    4. 小问题：底部文字写着“Start free tiral”。是舞蹈梗我没懂？但应该想写成“trial”吧 :^)

      回复

      1. 嘿嘿，谢谢。

        真希望我是舞者。

        不过说来，雇我参与这个项目的创始人确实是舞者。

        他之所以录用我，是因为面试时问到“你对舞蹈了解多少”，我回答“高中时跳过跛行舞”，就凭这句就成了首选人选，哈哈。

        编辑：这位创始人叫阿克塞尔·维拉米尔，魅力十足。你们一定会喜欢他。这是他尝试融资的视频https://www.instagram.com/reel/CyhL5kitUbD/

        回复

        1. 这是我听过最棒的开发者面试成功理由。

          回复

  2. 我赞同作者的观点：

    “”" 在我理想化的科学出版愿景中，每篇论文都应附带全交互式环境，让读者能探索数据、重现实验、调整参数并观察结果变化。“”"

    我确实欣赏大型实验室/企业发布充斥SVG元素的研究成果。近期NVIDIA的这篇就令我印象深刻：

    https://research.nvidia.com/labs/dbr/blog/illustrated-evo2/

    回复

    2. 重新运行实验的想法似乎仅在整个实验基于建模时才可行——这种建模理论上能在浏览器环境中轻松快速地重现。

      不过，能够以不同方式查看和解析数据集的构想颇具吸引力，这实质上允许读者从作者发表角度之外的不同维度解读实验结果数据集。

      回复

    3. 若不采用原帖提议的SVG格式，该选用何种格式？PDF难以胜任——除非其交互能力远超我的认知。我们从未开发过客户端多媒体文件格式，现有格式仅限Word和PDF等文本格式：它们能妥善嵌入图像，却只能以笨拙且受限的方式嵌入多媒体与交互功能(超出表单填写范围)。

      回复

      1. SVG有什么问题？笔记本电脑虽有缺陷但概念上接近。Flash和FLAs大概也行。但你说我们从未开发过“客户端多媒体文件格式”——这不正是html+js的用途吗？

        回复

        1. 我的意思是类似Word文档的等效格式：能合理编辑的文件，包括修改多媒体和交互/动态内容，支持保存、邮件发送、存入U盘或Dropbox等操作。

          回复

          1. 我认为GP提出的HTML+JS方案依然成立，但需注意几点限制。经过多年发展，HTML已具备所有必要特性，包括通过数据URI方案[1]嵌入图像的能力。

            例如我曾将Object Pascal交互程序(目标平台：Windows/Win32)移植到浏览器环境(FreePascal编译器支持JS目标)。中间阶段生成的文件能在桌面端本地运行，但在移动设备上表现欠佳。借助SingleFile扩展[2]的辅助，最终我将所有功能和内容整合到单个HTML文件中。该方案在MiXplorer内置HTML查看器中运行良好。具体细节已记不清，但file:///协议在Chrome、Firefox或两者中仍存在兼容问题。总之，用键盘正确输入本地地址颇具挑战，因此我们不妨假设：只要具备运行本地HTML文件能力的文件管理器就足够了。

            当然，要实现可控性，需要能处理任务全流程的优质工具。但至少理论上，该格式完全具备可行性。我唯一全局性的问题在于：本地运行的HTML文件状态属于某种短暂实体，不过对于交互式多媒体文件而言，这个障碍或许微不足道。

            [1] https://en.wikipedia.org/wiki/Data_URI_scheme

            [2] https://github.com/gildas-lormeau/SingleFile

            回复

            1. 本质上你描述的是epub格式——它就是HTML。我认同这种观点。虽然它潜力巨大，但似乎无人视其为超越廉价电子书格式的存在，甚至在功能层面也发展不足：例如呈现质量和注释功能远不及PDF。

              最关键的是它需要实用的编辑器，且必须能整合多媒体与动态内容编辑功能。终端用户无法像网页开发者那样为每种媒体使用不同编辑器，再将输出内容整合到epub文档中(例如：用Photoshop处理图片→保存jpg文件→复制到指定目录→在html中正确引用)。

              回复

          2. 我认为HTML正是你想要的“客户端多媒体文件格式”。问题在于我们缺乏成熟的编辑器界面，必须自行开发。

            这就像拥有.docx格式却只能使用只读的MS Word——你必须手动创建XML文件并压缩打包，再由Word进行渲染。这正是我对浏览器中HTML+JS组合的实际认知。

            回复

            1. 没错，这就是epub。请参阅我在本讨论串的另一条评论。

              回复

    4. 即便仅允许嵌入GIF或视频，也已具备显著价值。

      回复

    5. 交互功能与SVG其实难以兼容，尽管直觉上看似可行。渲染复杂SVG需耗费数秒，而任何交互都要求每秒30帧以上的刷新率。

      若去除交互性，PostScript同样属于矢量图形。

      回复

      1. 你指的复杂程度有多高？我做过包含数百元素的动画，运行毫无问题。

        回复

        1. 一款视觉效果出色的2D游戏，其典型场景图包含超过5000个元素，在15年前的老电脑上运行也毫无压力。

          回复

      2. 我很想知道你认为什么才算复杂，毕竟我用SVG做过些相当疯狂的实现，性能远超任何光栅方案。说到底，性能问题往往出在我自己身上——尤其初期阶段，那时我还用光栅图形思维来处理SVG。

        回复

  3. 使用SVG的缺点：

    – 无法实现文本环绕

    • 无法嵌入字体字形 – 若用户未安装对应字体，您的SVG可能无法显示。虽可将文字转换为曲线，但此后将无法选取编辑文本。如此显而易见的问题竟无人想到，为何？Photoshop早已解决此问题——它同时保存文本及其渲染效果，确保文本始终可显示。

    – 浏览器不会公布其支持的版本及功能特性

    – 可能包含JavaScript及外部资源引用，导致在安全隔离环境中难以查看

    解决方案之一是采用双版本SVG：作者版(在Inkscape编辑，使用Inkscape专属扩展)与发布版(基于作者版生成，仅使用基础功能且文字转曲线)。

    回复

    1. 其他诸多问题

      – 不同浏览器及渲染器呈现效果常不一致。要获得稳定结果(如PDF)极其困难，复杂图表中几乎不可能实现

      – 高效渲染器通常功能受限

      – 除浏览器外似乎没有其他渲染器能完整支持所有功能？

      – 虽可在SVG内嵌SVG(生成轻量级复合图像)，但若存在两层间接引用，所有测试过的渲染器都会拒绝渲染该SVG

      – Linux平台上基本只有Inkscape算得上优质编辑器，但处理复杂图像时极易内存耗尽崩溃

      – 复杂SVG在Chromium中会吞噬全部内存(Firefox表现仅略好)

      – Inkscape制作的箭头等基础元素在其他平台无法渲染

      我仍频繁使用SVG，因缺乏优质替代方案，但这是个糟糕的标准，我始终坚持将所有图像/图表设计得极其简洁

      回复

    2. > 且文字会被转换为曲线。

      但这会丧失文本可选取性——至少在Safari中，SVG的<text>元素能保留此特性。

      因此无论哪种方式都无法获得完整功能。

      回复

    3. Safari支持在<style>的@font-face{}中嵌入base64编码的字体文件(据我记忆类似@font-face { src: url(‘data:application/x-font-woff;charset=utf-8;base64,...’); })，此后可在整个SVG中正常引用。不过我不推荐这种做法，没人愿意处理500KB的SVG文件。

      回复

      1. 核心思路是仅嵌入文本实际使用的字形。例如，只需嵌入20个常用汉字而非全部数千个汉字。嵌入本身是必要的，否则无法保证图像在其他设备上正确显示。

        此外，允许在SVG中使用CSS并非明智之举，因为SVG渲染器需要集成完整的CSS解析器。试想当嵌入CSS包含base64编码字体时，Inkscape能否正常工作？这点尚不确定。

        回复

          1. OpenCL就是这样消亡的。他们把难以实现的功能设为强制要求。

            回复

      2. 你也可以用@font-face指向字体文件。我用的是个仅16KB的小型定制字体。不过本地打开文件时，必须先在Safari设置里禁用本地文件限制才能生效…

          <defs>
  <style type="text/css">
  @font-face {
  font-family: ‘A-font’;
  src: url(‘A-font.woff’) format(‘woff’);
  font-weight: normal;
  font-style: normal; }
  </style>
  </defs>
        回复

        1. 因此若保存SVG图像，断网时将无法显示。不太理想。

          回复

        2. 我觉得这无法解决字体嵌入问题。

          回复

    4. > – 无法换行

      这确实可行，但只能通过愚蠢的方式实现——使用<foreignObject>在SVG中嵌入HTML(显然仅当SVG渲染器至少支持HTML子集时才有效)。SVG 2通过新增inline-size[0]属性解决了此问题，现在用户代理只需…支持该特性即可。

      > – 无法嵌入字体字形 – 若用户未安装对应字体，SVG可能无法显示文本。虽可将字母转换为曲线，但此后将无法选取编辑文本。如此显而易见的问题竟无人想到，这究竟是为什么？

      确实有人考虑过这个问题。SVG 1.1 引入了 <font> 元素[1]；而 SVG 2.0 则用强制支持 WOFF 格式取代了它[2] WOFF字体既可进行子集化处理，又能通过数据URI嵌入，且已被所有浏览器UA支持，因此变更原因显而易见。但可嵌入的SVG字体早已存在(不知为何/如何被遗忘)。

      > – 浏览器未公布其支持的版本及特性

      理论上可通过CSS @supports 规则实现大部分检测，并据此隐藏/显示SVG的相应部分[3]。SVG规范本身包含特性检测机制[4]，但由于其定位是“检测用户代理中超出本规范定义的功能”，实际价值微乎其微。

      SVG文本确实存在明显未解决的问题，但这些问题更为微妙。例如，许多需要用SVG渲染的内容(如图表)更适合以左下角为原点。这通过全局变换scaleY(-100%)即可轻松实现，唯独文本例外。目前既无“基线”变换原点，也无用于控制行框上升/下降的CSS单位，更缺乏能确保变换仅作用于位置而非渲染效果的vector-effect关键词。因此除非所有文本尺寸统一，且/或预先掌握字体度量值并硬编码转换参数，否则连这种基础操作都无法实现。

      类似地，其他缩放控制问题同样荒谬地不足。你是否希望某个图案填充的形状能动态调整大小以填满 SVG 区域，同时保持图案不变形——就像 HTML 元素和 CSS background 的工作方式？祝你好运！(虽然可行，但如同文本换行问题，需要极其复杂的 hack 方案。)

      SVG 2中新增的vector-effect关键词似乎能解决部分问题，但这些属于“风险特性”，未获用户代理支持，且可能从最终规范中删除。

      [0] https://www.w3.org/TR/SVG2/text.html#InlineSizeProperty

      [1] https://www.w3.org/TR/SVG11/fonts.html

      [2] https://www.w3.org/TR/SVG2/changes.html#fonts

      [3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A…

      [4] https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessing…

      回复

      1. 有趣的是，我最初接触SVG字体时，只将其视为CSS中的网页字体格式。

        回复

  4. 两年前我重构了个人项目“虚假相关性”，该项目主要展示各类图表。然而始终找不到满意的制图软件——既要符合我设定的简洁美学要求，又需满足特定功能限制。(此前用过pCharts和HighCharts，但不喜欢基于JavaScript或PHP的图表生成方式。)

    我决定“自己动手”，编写输出SVG标记的Python脚本。本以为这会像其他“自建项目”一样进展艰难，结果却意外顺利。用Python生成可靠美观的SVG图形竟如此简单——制作图表本质上就是数学运算。

    无限可缩放性几乎成了可视化创建简易性的额外福利——这在光栅格式中简直令人抓狂。这让我对SVG的喜爱更胜一筹。

    回复

    1. 若有人寻求简洁的JS图表框架，我强烈推荐Observable Plot。

      它出自D3创建者之手，比直接使用D3简单得多。我在Observable平台之外也用它来调试图表和笔记本，发现其输出清晰锐利，API非常实用。

      它没有追求花哨功能，甚至不确定是否支持动画。但对于论文和笔记本中常见的图表类型，我认为它已覆盖绝大多数需求。

      回复

    2. Postscript未能达到应有的普及程度令人惋惜。在另一条时间线中，它本可能成为我们这个时代所拥有的HTML(及SVG)。

      回复

      1. Postscript依然无处不在，只是隐身于编译目标之中。

        PDF或许“名义上”取代了它，但实际嵌入应用仍无处不在。

        回复

        1. PDF作为PS的替代品令人遗憾。据我观察，这更像是刻意掩盖PS的举措——因为当时第三方厂商的Postscript技术已超越原始开发者。

          (当时的辩解是“PDF这类二进制格式更节省空间”，但PDF从未真正比压缩后的PS更高效。)

          Postscript并未消失，只是远未达到HTML如今的普及程度。

          回复

          1. 从一位自1980年代起就从事印刷出版业者的角度来看，事情远不止于此。PostScript作为页面描述语言和打印机控制语言，过去和现在都堪称卓越。它彻底革新了印刷行业——人们首次能够从高端照排机输出完整的页面(而非未分页的校样稿)。

            但作为向外部打印机构传输文档的媒介，它的表现并不尽如人意。PostScript文件在某些方面过于依赖目标打印机，因此创作者必须精通目标设备的各项参数：分辨率、最佳网点频率、介质尺寸等。当时在照相胶片上进行高分辨率输出每英尺成本约10美元，任何失误不仅耗时更可能造成高昂损失。

            字体问题同样棘手。理想情况下，PS文件应包含所有所需字体，但这与多数字体许可条款存在冲突。某些应用程序会将每页使用的字体重复嵌入文件中。这种做法符合Adobe推荐的文档结构规范，能使文件内各页面相互独立，但对于数百页文档而言，这种做法会导致文件体积膨胀——相比仅嵌入一次所有字体的方案，PS文件可能膨胀数百倍。在存储介质容量有限、网络传输缓慢的时代，这确实是个大问题。

            PDF中的“P”代表可移植性，正是为解决这些问题而生。与PS文件不同，PDF文件不针对特定打印机型号，且多数字体许可允许被许可方在PDF文件中包含子集字体。我曾亲自为数千本在美国各地印刷的书籍准备PS文件，后来又为数千本书籍制作PDF文件。两者根本无法相提并论：PDF在所有方面都更胜一筹。

            回复

            1. 我同意PostScript远非完美。

              但我们可以设想，若当时对PS进行些微改进，它本可走上正确的轨道。

              (感谢所有历史细节！)

              回复

          2. PDF的强大程度也刻意被削弱了许多。例如双击PS文件就能触发无限循环。

            但将完整编程语言作为文件格式确实极具实用价值。

            怀念macOS预览程序双击PS文件自动转PDF的功能。这曾是便捷分发文档的方案——每次打开都能随机排序问题，单文件打印多张宾果卡等。

            基于栈的逆波兰表示法也颇具趣味。

            回复

    3. 感谢创建这个网站。我在统计学课程首日就引用了其中的示例(“本课程结束后，你们就不会再犯这类错误了”)。

      回复

      1. 很高兴听到这个！统计课程的使用正是我持续维护网站的主要动力。

        回复

    4. > 我原本担心这个项目会像其他所有“自己动手”项目那样进展不顺

      我们整个行业都需要摆脱这种对创造事物的恐惧。

      回复

  6. 大约15年前，我制作了一个烧烤控制器。该控制器配备四个温度探头，可监测烤箱内部温度及不同部位肉类的温度。它通过伺服电机控制通风口开合，并采用自研PID算法，能推断氧气对木炭的延迟影响。

    与本帖相关的是：该控制器连接本地无线网络，内置HTTP服务器搭载基于SVG的网页界面，可绘制温度曲线并提供实体旋钮和拨盘实现实时调节。浏览器中的SVG与JavaScript配合运行效果极佳。

    回复

    1. 听起来太棒了！你拍过运行视频吗？

      回复

      1. 遗憾的是，我没有。源代码散落在某台旧笔记本电脑里。当初考虑将其产品化时，发现自己陷入了多么深的专利泥潭，实在令人沮丧。

        这项目已被列入我的未来计划清单。如今多数专利即将到期，这将是个绝佳的开源项目。这些年硬件技术进步显著，现已出现集成蓝牙低功耗及其他低功耗无线技术的更优解决方案。

        回复

      2. 完全赞同！视频放哪儿了？:D 真想看看效果。:)

        回复

  7. 作者在此：我刚悄悄修改了原文，因为它没说明一个关键点——这个SVG文件竟有20年历史，至今仍能正常运行，实在令人惊叹。当年我写的其他东西恐怕都得修改才能用了吧！

    回复

    1. 反过来说也成立：早期SVG并非理想选择，因为主流浏览器普遍不支持，或者更准确地说，各浏览器的集成效果参差不齐。

      所以二十年前为特定浏览器设计的SVG，如今很可能在所有平台都能正常显示。

      回复

      1. 邮件除外。因为邮件就是噩梦。

        回复

  8. 我真心喜欢SVG，用它做过许多有趣的项目。唯一不足是偶尔会卡顿。

    比如生成二维码、精细地图或宽度超100像素的方块时，超过100个DOM元素就会延迟数秒加载。

    动画效果也比Canvas、纯CSS或Lottie慢，但问题不大，基本还能接受。

    回复

    1. 我将国际象棋引擎嵌入棋盘的SVG图像中(https://github.com/jnykopp/svg-embedded-chess)，只需查看SVG文件，引擎就能自动移动棋子进行自对弈。

      这是为一位朋友创作的艺术装置——他在墙面投射约50×20(具体尺寸记不清了)的网格化棋盘图像，营造永不停歇的棋局狂潮。

      笔记本浏览器同时运行的棋盘SVG数量出乎意料地少，所幸仍足以支撑这个艺术作品。

      回复

      1. 有趣——是否有该艺术装置的视频记录？

        回复

        1. 遗憾的是似乎没有。但艺术家仍保留着装置使用的网页：https://heikkihumberg.com/chess/

          据说当时用iPad作为渲染设备。而且当年单个棋盘的显示效果可能与现在网页不同，因为字体可能有差异。SVG仅使用系统字体，棋子图案只是Unicode字符。

          回复

          1. 酷，谢谢。

            能否控制播放速度？我在浏览器加载单个SVG时，整个棋局瞬间就走完了。(Edge浏览器显示动画；Chrome和Firefox对我显示静态图像)

            回复

            1. SVG/嵌入式JavaScript代码第66-68行定义了三个超时设置(https://github.com/jnykopp/svg-embedded-chess/blob/a24249729…)

              您可以将 COMP_MOVE_TIMEOUT(当前值为1毫秒)增加至100毫秒。

              RESET TIMEOUT 用于定义对局结束后暂停时间(以便观众查看结果)，而 NEW_GAME_START_TIMEOUT 则规定新对局开始后等待首次移动的时长。

              静态图像可能是浏览器安全机制导致的；从GitHub直接调用的SVG在Firefox中同样无法动画，但下载后本地查看则正常。(不过历史版本从GitHub调用时确实能运行。)

              回复

              1. 感谢详细说明！

                在SVG中嵌入智能动画逻辑是否常见？对我而言这非常新颖。创意与实现都值得称赞！

                我想知道能否进一步拓展创意逻辑——比如生成每次渲染效果各异的独特图案/设计。例如持续变化的漩涡涟漪动画，却永远不显“预先录制”的痕迹。

                另外，动态SVG能否嵌入PowerPoint等软件？这样就能在紧凑便携的格式中获得清晰的矢量动画设计元素了。

                不过我担心这可能引发安全隐患——比如动态生成的二维码中植入恶意链接。

                回复

    2. 确实；我曾为小型浏览器游戏用SVG+JS构建地图浏览器，该方案运行良好。但当我尝试将底层代码复用到另一款对象密度更高的游戏时，性能变得极其迟缓。(最终我改用Canvas重构了该游戏的地图，但确实损失了部分功能。)

      回复

  9. 早在多年前，为开源数控机床Shapeoko v2编写操作指南时，由于该项目在《大众机械》杂志获得整版专题报道，有必要为那些无法像早期使用者那样清晰想象操作流程的用户提供支持。因此，我们制作了交互式示意图：

    https://github.com/shapeoko/Docs/blob/gh-pages/content/tPict…

    过去在网页浏览器中打开时，点击零件清单即可在图示中显示/隐藏或高亮/取消高亮对应部件。

    记忆所及，当时是用Inkscape完成的。

    回复

  10. 我的日常工作涉及仪表盘开发，SVG在生成清晰图标和图表方面不可或缺…跨尺寸的兼容性堪称福音，但某些特殊滤镜效果在特定浏览器仍会失效。

    另外在安全审查中，内嵌SVG常因可能携带脚本而被标记…期待更多工具能在部署前进行代码检查和安全净化。

    但看到二十年前的矢量图至今仍能正确渲染，让我确信核心规范非常可靠。

    回复

    1. > 希望看到更多工具能在部署前进行代码检查和清理

      清理是两种防御手段之一，另一种是脚本执行控制或沙箱机制。例如：若在Web服务器上提供矢量图像，可为所有图像设置Content Security Policy头部¹，直接禁止所有脚本执行。也可通过无价值内容的虚拟域名(“源域”)托管(类似googleusercontent.com和githubusercontent.com的用途)。

      就净化而言，据我所知DOMPurify²是唯一广泛使用且经过充分测试的库。虽然它需要更多语言绑定支持，但只要能调用该库，即可纳入部署管道。(声明：我曾与Cure53部分成员共事，但未参与此项目)

      您也可结合多种方法实现深度防御

      ¹ https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

      ² https://github.com/cure53/DOMPurify

      回复

  11. 这真是令人愉悦。我非常期待看到更多应用场景，以及新的编辑器和新的SVG协作方式，同时保持其功能和容量。

    偶然发现carto.net的这个案例：https://old.carto.net/papers/svg/samples/index.shtml#iact

    我彻底被SVG征服了。

    如今又发现这个：https://cartosvg.com/ 其功能与容量令人震撼，仅链接中的首个示例https://cartosvg.com/italia就让我欣喜若狂，更别说第二个了！实在令人折服。我曾梦想用OSC(开放声音控制)实现构想中的创作，但最终Hexler的TouchOSC实现了我的目标。只可惜当年无人能将VST整合为统一平台，使其支持随机控制器映射——那确实是天方夜谭。如今却大不相同。

    回复

  12. >它们几乎支持所有设备和平台

    事实并非如此。我最近在背景中使用简单SVG时，Safari无法正确渲染，尝试多种方法后放弃，改用不同尺寸的位图图像替代。

    回复

    1. SVG在og:image标签中也普遍不被支持(取决于应用/浏览器)。我知道这非常具体，甚至不确定开放图谱是否属于标准化协议，但它确实被广泛应用。

      回复

    2. 那个无法正常显示的SVG是什么？Jon在原帖示例中嵌入的SVG是他2005年左右创作的。能持续渲染20年实在令人惊叹…

      回复

    3. iOS原生应用同样不支持SVG。我们改用PDF存储矢量图。

      回复

  13. 我曾用SVG配合少量JavaScript和Python解决了某个机械加工难题。

    我正在制作一个太阳系模型原型。这需要用数控机床从黄铜板上切割出大量临时设计的齿轮和框架部件。虽然用Fusion360生成单个零件的G代码相对容易，但要让机器精确定位到黄铜板的全新区域进行切割，同时避免零件间产生过多金属浪费，这个过程却相当麻烦。整个过程充满猜测和目测操作。即便如此，零件间仍产生大量黄铜“浪费”——尤其当零件只能在X-Y平面移动而无法轻松旋转时。

    为解决此问题，我编写了Python脚本将G代码转换为SVG格式，并搭建了一个简易网页：通过拖拽旋转SVG图形，即可在黄铜板的可视化模型上调整切割位置。当找到安全的切割位置后，页面会输出对应的x,y,θ坐标。接着通过另一个Python脚本，我就能根据坐标和旋转角度转换G代码。这样SVG渲染器承担了切割路径可视化的重任，我只需专注于相对简单的变换操作。

    回复

    1. 我猜最终目标是彻底淘汰所有foreignObject用法？(否则直接渲染一个巨型foreignObject再转HTML会更简单)

      总之很厉害，但我更期待看到SVG的弹性盒模型实现 😉

      回复

  15. 这感觉有点像重新发现前端软件开发？看来我们终于摆脱了对打包功能的恐惧，开始用JavaScript在用户端浏览器中运行这些功能了。

    回复

  16. 我曾开发过一款完全基于SVG运行的音乐游戏。我们通过修改Musescore，让SVG中的音符头与MusicXML对象在两种输出模式下共享相同UUID，从而实现乐谱滚动与MIDI流的同步。若感兴趣，可观看我们八年前失败的Kickstarter宣传视频：https://www.youtube.com/watch?v=vgbB5Q4-dgY

    回复

  17. 我用ChatGPT压缩SVG文件，特别是二维码。许多二维码SVG生成器产出的文件效率低下，而传统SVG压缩工具常缺乏特定压缩技术的理解能力。ChatGPT能用<use>元素替代对齐指示符。

    是否存在将二维码编码数据直接嵌入图像的方法？这将使浏览器能直接解析数据，无需计算机视觉再次解码。进一步而言，网页图像中的二维码可由浏览器高效编码并渲染。

    回复

    1. 我不确定您的具体应用场景。现有多种JS库可生成客户端QR码。您优化过多少种文件大小？还是仅出于学术兴趣？

      SVG本质是XML，因此技术上可通过命名空间属性与元素嵌入可视化编码的数据负载。若不使用命名空间，可采用画布外文本、隐藏文本/opacity=0文本甚至XML注释。你甚至能利用SVG常规的元数据区域，将整个QR码设为可点击链接。

      回复

    2. > 我用ChatGPT压缩SVG，特别是QR码

      何必？svgomg.net资源消耗更少，效果也远胜于此。

      回复

  18. 我注意到浏览器对SVG支持存在一个致命缺陷：当多个多边形通过边连接时，渲染器会将边界按普通位置进行透明混合，导致明显“接缝”。这是2D图形领域的经典问题，通常通过显式选择混合函数解决，但我在SVG中找不到任何修复方案。

    回复

  19. 我热爱使用SVG进行创作。

    我们在https://typequicker.com/press博客的封面图片中应用了SVG技术。

    这样即使用户更换主题，图片色彩也能与当前主题保持一致。此外由于无需加载图片文件，仅需渲染SVG，加载时间几乎瞬间完成。

    回复

  20. 我记得我手下有个员工，可能是我见过最出色的工程师，他用Postscript语言为自己开发的晕影算法编写了规格说明书。

    这个算法相较于东京团队编写的经典蒙特卡洛算法，性能提升了100倍。

    文档中的图表是可执行的Postscript代码，直接运行着他的算法。

    这引起了东京博士们的关注。而他只是个高中毕业的神经多样性人士。

    回复

  21. 最近我发现，将由一系列线段组成的SVG文件转换为Python中的线段列表竟出奇地困难。

    我尝试过ChatGPT和Claude，但两者都未能找到完全符合规范的解决方案，尤其在变换处理方面。

    最初我以为肯定有现成的库能解决这类问题，可惜并非如此。

    回复

    2. 我记得DOM节点本身暴露了一些相当实用的函数。虽然是在图路由器检测边界交叉的场景下，但当时确实能通过这些函数操作计算/渲染后的坐标。

      抱歉没能提供更明确的帮助，这事已过去很久且最终没推进。

      回复

    3. 我发现 svg.path 用于解析路径数据很合适

        https://pypi.org/project/svg.path/

      至于实际解析文件，有多种方案可选(本质上是 XML 文件，我倾向于按此方式处理)

      回复

    4. 手动处理不就行了？这不过是空格分隔的坐标列表。例如：“100,100 100,200 200,200 200,100”

      回复

      1. 不行，规范更复杂——例如元素(及递归子元素)可应用变换操作。

        回复

        1. 说得对。Inkscape曾有项功能可简化SVG文件，将变换推送到树形结构末端。我从未在自动化流程中用过，只是偶尔处理文件时用过。

          回复

  22. 看到古老格式能如此经久不衰令人欣慰。SVG历经二十年浏览器迭代仍屹立不倒，正是“平淡技术”做对的有力证明。这让我不禁思考：为何当今学术论文中鲜少出现完全自包含的交互式SVG？毕竟工具链和浏览器性能已达巅峰。

    回复

  23. 是否存在SVG的3D对应技术(技术层面或理念层面)？我正在开发CAD可视化工具，需要轻量级方案来实现模型局部修改的可视化，避免每次都要调用CAD软件导出完整STEP文件再进行渲染。

    SVG能完美呈现2D草图，但希望找到类似方案处理实体模型，避免依赖底层CAD软件导致的渲染延迟。

    回复

  24. 只需键盘输入和音频输出，就能复刻(大部分)Flash体验。闲暇时或许该研究下这个方案

    回复

    1. 关键在于<script>标签的魔力——它让你像操作<canvas>而非<svg>那样调用浏览器API。例如我分叉的这个示例，通过<svg>内部的<script>实现鼠标追踪功能https://codepen.io/zamadatix/pen/emZXZKx?css-preprocessor=sc…

      诸如three.js之类的库曾提供SVG渲染选项，但随着支持更直接GPU API的<canvas>效率更高且更灵活，该功能已被弃用。

      回复

    2. 或许可用JavaScript捕获按键事件并就地编辑SVG？

      回复

  25. SVG真是妙不可言！考虑到SVG的常规用途，其中能嵌入的逻辑量简直令人惊叹。我的桌面壁纸通过内置JS在系统启动时生成随机的巴恩斯利蕨类分形图案，每次启动效果都不同。唯一的问题是只有浏览器能完整支持我需要的SVG规范，但这完全可以通过systemd和puppeteer解决。

    回复

  26. 据我所知，SVG对视障人士并不友好。不过当前状况我不太清楚。

    但即便如此，用单个SVG包揽网页所有功能可能还是过度设计了。无论是语义还是语法层面…

    回复

  27. 我始终不解PDF为何如此普及，为何不能直接用单个SVG文件替代PDF的每页内容。

    回复

    1. SVG存在诸多缺失功能。例如：单文件整合所有页面、加密支持、表单功能等。

      另请注意，不同浏览器可能以不同方式呈现和打印相同的SVG文件，这对以打印为导向的格式而言并不理想。

      回复

  28. 几年前我刚好掌握了足够的d3知识来展示交互式二维棒棒糖图。后来又刚好掌握了足够的SVG知识，为大学课程制作了一个小图表。若要重做那个最初的交互式图表，我想现在大概会直接用纯SVG实现。

    回复

  29. 我十年间一直大力推广SVG，但坦白说AVIF才是魔法。它甚至能碾压SVG的文件体积。

    回复

  31. > 基于简单XML格式的矢量图形。

    简单？不。SVG并不简单。若它简单，便不会如此强大。

    回复

  32. 记得12年前做过一个.svg灵感温度计，实时调用本地气象站数据动态调整红色温度条。虽是个有趣的小玩意，但没发现实际用途。我们还开玩笑说要制作单图SCADA监控界面。

    回复

  33. 这将彻底改变我构思中的数据可视化方案。自当年使用Illustrator和Inkscape起我就钟爱SVG，但从未意识到它能如此深度融合现代网页与交互技术。感谢分享！

    回复

    1. 首先，Cloudflare究竟认为哪种SVG阅读器会随意打开SVG文件并执行其中嵌入的JavaScript？这是Windows系统的特性吗？其次，他们难道不知道内容安全策略吗？

      顺带一提：Cloudflare本身才堪称有害

      回复

    2. “既然SVG本质上是代码，自然能嵌入JavaScript”

      这话挺奇怪。计算机里的所有东西本质上都是代码，无论能否执行。

      回复

  35. 我认为这会导致内容不可访问，屏幕阅读器无法为残障用户正确呈现SVG内容。

    因此对于面向大众的文档，这种做法并不妥当。

    回复

    1. 复杂交互式图表是否有合适的解决方案？

      回复

      1. 好问题。通常图表无法无障碍访问，因为视障用户无法使用鼠标。

        你需要一个支持键盘操作且可被屏幕阅读器识别的交互式图表库。

        回复

  37. 是SVG和JS吧？它本身并不具备交互性。

    回复

    1. JS被嵌入在SVG文件内部，并未暴露在外部

      回复

      1. 该JS在完整页面上下文中暴露，效果等同于在<div>而非<svg>标签下嵌入<script>。同样地，<script>位于<svg>标签之前或之后并不影响——无论哪种方式，它都只是作用于单一DOM(特定元素具有不同命名空间)的脚本。

        回复

        1. 关键在于你可以提供包含内部脚本的单个.svg文件。但同样也可以提供包含svg和内部脚本的单个.html文件。

          回复

  38. 太棒了！让SVG重新火起来吧。它能实现的功能总是让我惊叹不已——光是SVG滤镜、交互效果和无障碍支持就够令人赞叹了…

    回复

  39. 最讨厌Slack不支持SVG。讨论时只能截SVG火焰图的图。

    回复

    1. 你提交过问题报告/功能建议吗？

      Slack是基于Electron的应用，实现起来应该不难。

      回复

  40. 我也刚钻进同一个兔子洞，简直太有趣了！https://turbek.com/Designing-Interactive-SVGs-with-AI/

    简而言之：

    – SVG图像文件：像HTML一样强大

    – 广泛支持于浏览器
    – 设计工具可生成SVG
    – SVG采用语言编写
    – 大型语言模型擅长语言处理
    – 设计师可协作实现交互效果

    回复

    1. 我认为大型语言模型在处理SVG方面并不出色，除非指的是旋转、字号等微调操作。不过文章很棒，得琢磨如何加以利用。

      回复

      1. 当然，但相较于midjourney这类位图工具，通过指定SVG元素进行操作能更清晰地与AI沟通。“将ID为’logo’的元素旋转30度”这类指令对AI而言非常明确。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：