宽高比高的图片不遵守帖子中手动设置的大小（编辑器预览显示正确大小，提交帖子时大小短暂正确，但随后被调整为屏幕宽度）
2 个赞
多年来，我们讨论过几个关于高宽比图像（高度远大于宽度）的话题。据我所知，您遇到的情况是标准行为。有一个站点设置可以更改此行为：
3 个赞
如果图片是未手动裁剪尺寸而插入的，情况确实会如此。
我的问题在于，不希望图片以默认尺寸（高度大于宽度）显示，而是希望其按照手动输入的参数进行缩放（请注意，两张图片的尺寸都设置为50x50，但只有一张生效）。
我仍然认为这是一个缺陷，因为图片并非由系统自动设置尺寸（随后根据站点设置调整）后插入的，系统实际上没有尊重手动有意输入的尺寸。
2 个赞
我明白你的意思了：我刚才说的是，据我理解，这是标准行为。
换句话说，你并没有手动裁剪保存帖子的尺寸。我认为你无法这样做，但团队成员可以确认这一点。
请查看以下帖子，其中解释了如何处理调整大小。你会发现，除非高度和宽度的数值是实际尺寸，否则同时设置这两个测量值将不起作用：
1 个赞
respectfully，我认为事实并非如此。也许我解释得不够清楚，让我再试一次：
- 原始图片的宽高像素比确实很低（这一点没有争议）
- 如果直接将图片插入到编辑器中，它会在 Markdown 中以自动宽高方式显示，格式类似
，此时仍会保持原有的低宽高比，因此会根据“最小裁剪比例”设置进行显示 - 但是，当图片在 Markdown 中手动调整大小为
时：新的宽高比为 1，因此不应触发“最小裁剪比例”站点设置。
原始图片不能被裁剪，因为其包含的所有信息都很重要。我们期望的结果是创建一个指向原始图片的 50x50 小缩略图。
因此，正确表述的问题应为：
“最小裁剪比例”站点设置应尊重 Markdown 中定义的宽高比，而不是物理像素的宽高比。
@dax，这个话题已从 bug 移至 #support。我是否应该在 bug 中开启新话题，还是在此话题中编辑原始帖子（OP）？
3 个赞
重述后的问题看起来是正确的。但如果你读过我链接的那些主题，你就会明白为什么它可能不会引起任何关注。
该站点设置是为了防止个人覆盖它而开发的，而你想要覆盖它。相反，必须更改站点设置，使图像宽高比适合调整大小。
换句话说，过于细长的图像默认是不可接受的，必须由站点管理员明确允许。普通用户无法覆盖此限制。
1 个赞
这个缩略图会是什么样子？以你的 50x50 示例为例，我看到有三种选项：
- 裁剪图片的顶部/底部，使缩略图成为完美的 50x50 正方形。
- 左侧/右侧填充黑色（或类似颜色），以便在 50x50 缩略图中以原始宽高比显示“完整”图片。
- 拉伸图片，使完整（但失真）的图片占据完美的 50x50 正方形。
还有其他我没看到的选项吗？
请查看原始帖子：第一张图片实际上被调整为 50x50 像素，其处理方式非常合理，适用于任何宽高比（我认为它会从顶部中心裁剪图片，保持完整宽度，高度则根据声明的尺寸比例进行调整，然后再进行缩放）。
问题在于，对于宽高像素比很低但手动设置的屏幕比例可接受的图片，全局设置不应生效。
手动设置的比例应优先，因为此设置的目的是防止图片（因其高度）在显示区域中占据过大的比例，而在 50x50 的尺寸下显然并非如此。
[quote=“md-misko, post:8, topic:138374”]
请查看原帖：第一张图片实际上已缩放到 50x50，其处理方式完全可行，应适用于任何长宽比（我认为它会从顶部中心裁剪图片，保持完整宽度，并根据声明的尺寸比例调整高度，然后再进行缩放）。[/quote]
是的，我看到了。但这似乎与你之前的另一句话相矛盾：
[quote=“md-misko, post:5, topic:138374”]
原始图片不能被裁剪，因为它包含的所有信息都很重要。期望的结果是创建一个指向原始图片的小尺寸 50x50 缩略图。[/quote]
再读一遍后，我意识到你说的是原始图片不应被裁剪。据我所知，原始图片从来不会被裁剪，所以这方面无需担心。
无论如何，我同意你的总体关切/建议。仅显示部分图片的 stated 原因是为了防止高宽比的图片占据页面主导地位。当像你的例子中将尺寸设置为 50x50 时，显然不存在这种情况。因此，没有理由忽略指定的 Markdown 尺寸。
1 个赞
我不是 Discourse 团队的一员，所以只是在复述我所看到的内容。
关于当前的默认设置，已给出不止一个理由。我记得在这里看到的理由包括：
- 让站点所有者能够控制此功能
- 防止因垂直方向占用过多空间而导致拉长的图片占据主导地位
- 防止拉长的图片变成水平细条或断裂
- 提供清晰可读的预览
- discourages 不寻常且未优化的图片（包括拉长的图片），这些有时是由于某一维度的无意拉伸造成的
此外，还有一个关于编辑器预览的问题，它让你误以为可以手动调整显示图片的大小。这个问题之前已被报告过，但显然尚未被视为需要优先修复的问题：
我认为你误解了重点。为什么一张实际尺寸为 200x1000 但在 Markdown 中指定为 200x200 的图片，应该与另一张实际尺寸为 200x300 且同样在 Markdown 中指定为 200x200 的图片区别对待？
1 个赞
我并非没有理解要点，因为我也不是在支持或反对更改默认设置。我重申，我只是在报告论坛中已经存在的情况。我不是 Discourse 团队的成员，因此在决定会发生什么方面没有任何角色。
我表达的唯一观点是，我认为当前的默认设置不太可能发生变化。在五年里阅读了该论坛中几乎每一个新主题后，我对团队如何做出决策感到更加放心。目前，Discourse 团队缺乏反馈这一事实已经说明了一切。
也许我们应该给团队一些空间来回应，因为这个话题已经从简单的错误报告偏离成了完全离题的长篇观点。
这个稻草人论点已经被驳斥得毫无意义，或许现在是时候让它安息了？
这里没有人主张需要更改这个默认设置；实际上，它目前的设置非常合理：
我主张的是，“最小裁剪比例”应仅根据帖子中定义的尺寸进行计算，而不是根据图像文件的物理尺寸。
如果宽高比极低的图像在帖子中被手动调整大小，它难道就不再主导讨论了吗？
在大家提出疑问之前，先说明这为何构成一个错误：
原因在于，我无法仅对特定子集的图像进行格式化，而这些图像若未格式化将会主导讨论，从而陷入进退两难的境地。
如果您仍不相信该设置破坏了预期功能，请尝试使用编辑器缩放工具将主题帖（OP）中的第二张图片缩小至 50%。
结果是，帖子中的所有图片都可以缩窄至一半宽度，唯独那些又高又窄的图片除外。
1 个赞
这不是一个漏洞，因为这是 Discourse 的正常且默认行为。这是设计上已知的限制。此外，有一个站点设置可以允许您想要的功能，而是否解除该限制是站点所有者的特权。
还有一些关于图片尺寸、文件扩展名等的站点设置，也常有人请求更改默认值。如果只需向站点所有者提出请求以尝试更改设置，那么这些就不是漏洞。
这并非一个漏洞。如果你将其改回“漏洞”，你将会突然发现自己不再受欢迎。
2 个赞
你好，Jeff，感谢你对此问题感兴趣。
我可以向你保证，我从未（也永远不会）重新分类此主题。该主题是由团队成员移动到另一个类别的（请注意，重新分类回“错误”类别并非由我完成）。我很乐意将此视为功能请求。
我在此发帖的目的是说明我在正常使用软件时遇到的问题，并希望能得到团队的回应。
我绝无索取任何内容之意，甚至不要求回复，但至少希望团队能听到我的声音（而不是被同一位—无疑出于好意—的论坛成员用同样的理由多次驳回，而该理由并未完全解决问题）。
希望你已经仔细阅读了整个讨论并了解了问题所在，但为了清晰起见，在此简要回顾：
- 并非所有图像都能通过 Markdown 设置为用户期望的尺寸（从用户角度看这是意外行为）
- 这由“最小裁剪比例”控制，该设置使用图像的像素宽高比，即使图像已通过 Markdown 手动调整为可接受的宽高比
- 如果投入不太大，是否可能改用 Markdown 中定义的宽高比？
这将解决此类意外的图像缩放行为（所有图像均设置为 50x50）：
感谢你的考虑，也再次感谢整个团队为这款出色的软件所付出的努力！
7 个赞
我不确定修改起来会有多复杂，但我也希望看到这个功能。
我通常在发布 UI 截图时遇到这个问题……当你起草帖子时，没有任何提示表明图片会被裁剪，所以我往往会先发布，看到裁剪后的图片，然后再编辑帖子以避免裁剪。有几次我尝试在 Markdown 中修改尺寸，但当然这不起作用……所以我最终会回去裁剪图片并重新上传。
8 个赞
@zogstrip 你对这段代码怎么看？
if crop
cropped_width, cropped_height = ImageSizer.crop(original_width, original_height)
if cropped_width < width
width = cropped_width
img["width"] = width
end
if cropped_height < height
height = cropped_height
img["height"] = height
end
end
与现有的实现对比：
这确实比当前行为更不易令人意外，也会让 @awesomerobot 感到满意。唯一明显的缺点是，这个测试显得非常非常非常依赖模拟数据。
如果你认可，欢迎直接提交。
7 个赞
建议进行一个小改动：
只更改一个维度而不更改另一个可能会导致一些……奇怪的情况
2 个赞
据我所知，它随后会进行宽高比修复，至少在开发环境中是这样。
5 个赞