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），而你们也强调 Discourse 是为现代网络而设计的（例如无限滚动），所以我之前完全没想到，在电子邮件中完整呈现网页上所有可呈现的内容会是主要的考量因素。这对我来说是个新的认知。（我可以想象，如果有无限资源的话，或许可以将 SVG 转换为 PNG 以嵌入邮件，这样比通常用于 HTML 邮件的那些繁琐手段具有更高的保真度，但由于 SVG 默认未启用，这感觉优先级非常低……）
@Neotinker 曾考虑过有朝一日利用 threejs 实现 onebox，从而在 Discourse 中嵌入关于这些模型的交互式 3D 模型；如果未来 Maker Forums 成为一项功能，我们将希望启用它。如果 Neotinker 或其他人实现了这一功能，“无法在邮件中渲染” 这一顾虑会成为接受此类工作的障碍吗？（我注意到 threejs 团队也使用 Discourse 作为他们自己的论坛……）
或者，如果这更多是关于 CDCK 愿意投入多少时间来解决这个问题的优先级判断，我也很乐意得到代码指引；我并非意在暗示这里有负担。从我之前的贡献中你们可以看到，我不是 Ruby 或 RoR 专家，但我愿意将其列入我要查看的事项队列中。（我最初发布这个话题时，我们还没意识到它正在丢弃单位并假设为像素，因此我以为这是一个设计决策，这就是为什么我将其发布在 Contribute > UX 而不是 Contribute > 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 个赞
