mcdanlj
(Michael K Johnson)
1
我们在 Maker Forums 允许上传 SVG 文件，部分原因是我们的用户群体中包含激光雕刻机和切割机用户，而 SVG 格式在这些设备中非常常用。我们希望用户能够上传 SVG 文件，既方便他人下载，也便于在讨论中查看。这通常出现在用户寻求帮助的场景中。
遗憾的是，这些 SVG 文件往往被渲染得极小，有时甚至小到几乎看不见。今晚，有人上传了一个 SVG 文件，系统自动将其设置为 12x8 像素，小到彩色线条完全消失，渲染效果就像暴风雪中的一只北极熊。（令我惊讶的是，分类版主竟然注意到那里有一个 SVG 文件。）这一直是我们面临的一个常见问题。
经验丰富的用户或许可以学会将 12x8 改为 480x320 来正常查看图像，但这些用户通常并不需要这样做；大多数上传 SVG 文件的是寻求帮助的新手，他们并不了解 Discourse 的这个特性。
那么，Discourse 为什么会选择将 SVG 限制为仅几像素大小呢？
以下是分类版主提供的查询链接，供参考：
编辑：根据该讨论帖，一个可能的原因是，这个问题在本论坛比其他论坛更为突出：
常见的“K40”激光切割机的工作台尺寸为 12 英寸 x 8 英寸，并且以千分之一英寸为步进单位运行，而非采用公制单位。因此，对于这些 SVG 文件来说，使用英寸单位实际上是合理的，并非“用户应改用公制”的问题。
2 个赞
我认为您的设置非标准。当您在这里上传 SVG 时会发生什么？
由于 SVG 可能存在安全风险，因此通常不允许它们在帖子中自由渲染。
mcdanlj
(Michael K Johnson)
3
谢谢！
这就是该特定示例图形在此处的显示效果（这不是你屏幕上的灰尘，而是渲染后的图形）：
我在这里也看到了完全相同的 12x8 像素推断尺寸；以下是上传该文件后显示的原始 Markdown，未做任何修改：
将推断尺寸从 12x8 更改为 480x320，使得图像不再只是一个微小的尘埃点：
你指的是什么“设置”？
显然，这需要允许上传 SVG；我记得大约两年前，我不得不将 svg 添加到 authorized_extensions 配置中。
我确实在 Discourse 中看到了 SVG 清理代码。我看到它们在这里确实被渲染了。由于 SVG 对于 Maker Forums 的一项核心使命具有重要价值，加上我们管理用户群体的方式，我们选择故意显示它们。当人们在激光切割/雕刻 SVG 时遇到问题，能够在对话上下文中查看 SVG，对于理解和诊断问题是非常有价值的帮助。
既然我能够在这里的 meta 版块也显示 SVG，想必你也做出了同样的决定，尽管原因显然不同。
2 个赞
太好了，感谢提供更多细节。或许 @jamie.wilson 可以在接下来的一周查看一下该问题。
5 个赞
mcdanlj
(Michael K Johnson)
5
谢谢！
只是想确认一下，在调查中，Scorch 上面提到的 12x8 像素很可能不是随机的，而是由于没有正确处理 svg 元素中 width 和 height 属性的单位：<svg ... width="12in" height="8in" ...> —— 我最初提问时并未意识到这一点。
4 个赞
你说得完全正确。我们用来获取图像尺寸的库只是提取 SVG 文件中 width 和 height 属性的整数值，而不会尝试解析任何单位类型。我会进一步排查，并尝试找出解决此问题的最简洁方案。
我一直在使用 ImageMagick 和 librsvg 对几个有问题的文件进行实验。看来 ImageMagick 默认使用 96 DPI，而 librsvg 默认使用 90 DPI。我想只要选定一个合理的默认值并保持一致，两者都可以接受。
5 个赞
mcdanlj
(Michael K Johnson)
9
无论是 90 还是 96，都能让以英寸和毫米为单位的 SVG 宽度和高度呈现出更合理的尺寸。目前，以毫米为单位的 SVG 基本上是按 1 毫米对应浏览器像素来显示的，因此显示大小约为实际尺寸的 1/3 到 1/4。之前我只是一笑置之，心想“好吧，至少是可缩放的……”，但如果您能同时支持英寸和毫米，并采用合理的默认分辨率，两者的渲染效果都会好得多。
谢谢！
我们担心的是，SVG 在电子邮件中完全无法渲染，因此其实用性相当有限。
mcdanlj
(Michael K Johnson)
13
电子邮件 HTML 是一个极其受限（更不用说实现不一致；参见 Litmus）的 HTML 子集。而你们强调 Discourse 是为现代网络设计的（例如无限滚动），这让我此前完全没意识到，让电子邮件完整呈现网页上所有可呈现的内容竟是一个核心考量。这对我来说是一个全新的认知点。（我想象在资源无限的情况下，或许可以将 SVG 渲染为 PNG 再嵌入邮件，其保真度会远高于一般 HTML 邮件所需的种种权宜之计；但在 SVG 默认未启用的情况下，将其优先级定得如此低似乎有些……）
@Neotinker 曾有过这样的想法：未来利用 three.js 实现 onebox，以便在 Discourse 关于特定模型的讨论中嵌入交互式 3D 模型；如果 Maker Forums 存在，我们肯定会希望启用该功能。如果 Neotinker 或其他人实现了这一功能，那么“无法在邮件中渲染”这一顾虑是否会成为阻碍我们接纳此类工作的因素？（我注意到 three.js 团队自己也使用 Discourse 搭建论坛……）
或者，如果这更多是关于 CDCK 愿意投入多少时间来解决这个问题的优先级判断，我很希望能得到代码指引；我并非想在此增加负担。你们从我之前的贡献中可以看出，我并非 Ruby 或 RoR 专家，但我愿意将其列入我的待办事项清单。（我最初发布此话题时，尚未意识到系统会丢弃单位并默认使用像素，因此当时认为这是一个设计决策，这也是为什么我将它发在 ux 而非 bug 分区 ）
1 个赞
我在周五下午提交了一个拉取请求，旨在解决当 SVG 文件的尺寸以英寸、厘米、毫米等单位表示时显示得过于微小的问题。
该拉取请求目前正等待代码审查，因此暂时不可用，但预计很快就能投入使用。
5 个赞
mcdanlj
(Michael K Johnson)
18
感谢分享提交记录，让我能看清具体是在哪里以及如何完成的！
抱歉我误解了 @codinghorror 的意思——我原以为他是说事情变得像“潘多拉魔盒”一样棘手，我本意并非要在这里制造大量额外的工作。
2 个赞
没问题！我们是 SVG 的粉丝，但也是现实主义者；)
无论如何，我们非常欢迎任何小的改进建议！
4 个赞
这是一张铅笔的 SVG 图像，尺寸为 8 英寸 x 12 英寸。
相关更改已合并，更新后即可供您使用。
8 个赞
mcdanlj
(Michael K Johnson)
21
非常感谢！我已经在 Maker Forums 上部署了它
5 个赞
