アスペクト比（縦横比）が高い画像は、投稿内で手動で設定されたサイズを無視します（作曲プレビューでは正しいサイズが表示されますが、投稿を送信すると一時的に正しいサイズが表示された後、画面幅に合わせてリサイズされてしまいます）
「いいね！」 2
長年にわたり、縦長の画像（高さに対する幅の比率が高いもの）に関するいくつかのトピックがありました。私の知る限り、標準的な動作はあなたが遭遇している通りです。これを変更するサイト設定があります：
「いいね！」 3
画像を手動でサイズを切り取ることなく挿入されたのであれば、確かにその通りでしょう。
私の問題点は、画像がデフォルトのサイズ（縦横比が横より高い状態）で表示されるのではなく、手動で入力したパラメータに合わせてサイズが調整されることです（両方の画像でサイズが50x50に設定されていることに注目してください。しかし、そのうちの一つだけが反映されています）。
これは依然としてバグだと考えています。なぜなら、画像はシステムによって自動サイズに設定された後、サイトの設定に応じて調整されたものとして挿入されたのではなく、手動で意図的に設定されたサイズをシステムが実際には尊重しなかったからです。
「いいね！」 2
おっしゃっていることは理解しました。私の理解では、それが標準的な動作です。
つまり、保存された投稿のサイズを手動で切り取ったわけではないということです。それが可能かどうかはわかりませんが、チームの誰かが確認してくれるでしょう。
リサイズがどのように処理されるかについて説明している以下の投稿をご覧ください。実際の寸法でない限り、高さおよび幅の両方の測定値を設定しても機能しないことがわかります：
「いいね！」 1
失礼ながら、それは違うと思います。もしかすると私の説明が不足していたのかもしれませんので、再度説明させていただきます。
- 問題となっている元画像は、縦横のピクセル比率が低いです（これは争点ではありません）。
- 画像を直接コンポーザーに挿入すると、Markdown で
のように幅と高さが自動で設定され、同じ低い縦横比が維持されるため、min ratio to crop（最小切り取り比率）の設定に従って表示されます。 - しかし、画像を Markdown で手動でリサイズして
とした場合、この新しい縦横比は 1 になります。したがって、min ratio to cropサイト設定がトリガーされるべきではありません。
元画像は切り取ることはできません。含まれているすべての情報が重要だからです。望ましい結果は、元画像を指す 50x50 の小さなサムネイルを作成することです。
したがって、適切に言い直した問題は以下の通りです。
min ratio to cropサイト設定は、物理的なピクセルの縦横比ではなく、Markdown で定義された縦横比を尊重すべきである。
@dax、これは bug から Support に移動されましたが、bug で新しいトピックを作成すべきでしょうか、それともこのトピックの OP を編集すべきでしょうか？
「いいね！」 3
再構成された問題点は正しいようです。しかし、私がリンクしたトピックをお読みいただければ、おそらく注目されない理由がご理解いただけるでしょう。
サイト設定は、個人がこれを上書きすることを防ぐために開発されたものであり、あなたが上書きしようとしているのとは対照的です。代わりに、画像のアスペクト比がリサイズに許容されるよう、サイト設定を十分に変更する必要があります。
つまり、過度に細長い画像はデフォルトでは受け入れられず、サイト管理者が明示的に許可する必要があります。個人ユーザーはこの設定を上書きすることはできません。
「いいね！」 1
このサムネイルはどのようなものになるのでしょうか？あなたの 50x50 の例を考えると、3 つの選択肢が見られます。
- 画像の上下を切り取り、サムネイルを完璧な 50x50 の正方形にする。
- 左右に黒（または同様の色）の余白を追加し、50x50 のサムネイル内で元のアスペクト比を維持した「完全な」画像を表示する。
- 画像を伸縮させて、歪んだ完全な画像を完璧な 50x50 の正方形に収める。
他に考えられる選択肢はありますか？
元投稿（OP）をご確認ください。最初の画像は実際には50x50にリサイズされていますが、その方法は問題なく、あらゆるアスペクト比で機能するはずです（画像を上中央から全幅で切り取り、宣言されたサイズ比率に合わせて高さを調整した後、リサイズしていると思われます）。
問題は、画像の幅と高さのピクセル比率が低い場合でも、手動で設定された画面比率が許容可能であれば、グローバル設定が適用されないべきだということです。
手動で設定された比率が優先されるべきです。この設定は、画像の高さによって画面の大部分を支配してしまうのを防ぐために意図されたものであり、50x50のサイズでは明らかにそのようにはなっていません。
はい、それを見ました。しかし、それがあなたの他の発言と矛盾しているように思えました：
もう一度読み直して、あなたは「元の画像」を切り取るべきではないと述べていたことに気づきました。私の知る限り、元の画像が切り取られることはありませんので、そこについては心配する必要はありません。
いずれにせよ、あなたの一般的な懸念や提案には同意します。画像の一部のみを表示する理由として、高さ対幅の比率が大きい画像がページを支配するのを防ぐことが挙げられています。あなたの例のように寸法を 50x50 のような値に設定する場合、これは明らかに当てはまりません。したがって、指定された Markdown の寸法を無視する理由はありません。
「いいね！」 1
私は Discourse チームのメンバーではないため、私が目にした内容を繰り返しているにすぎません。
現在のデフォルト設定には複数の理由が挙げられています。ここで目にした記憶のある理由は以下の通りです：
- サイト所有者がこの機能の制御を持てるようにする
- 縦に伸びた画像が縦方向にスペースを取りすぎて支配的になるのを防ぐ
- 縦に伸びた画像が横に細長いスリットや区切りになってしまうのを防ぐ
- 読みやすいプレビューを提供する
- 意図しない方向への伸縮によって生じることがある、非標準的な最適化されていない画像（縦に伸びた画像を含む）を抑制する
また、コンポーザーのプレビューでは、表示画像を手動でリサイズできると思い込ませてしまうという問題もあります。これは以前から報告されていますが、修正は優先事項として考慮されていないようです：
私は、あなたが要点を見落としていると思います。なぜ、200x1000の画像をマークダウンで200x200として指定した場合と、200x300の画像を同様にマークダウンで200x200として指定した場合とで、扱いが異なる必要があるのでしょうか？
「いいね！」 1
私はデフォルトの変更を支持も反対もしていないので、要点を見落としているわけではありません。繰り返しますが、私は単にフォーラムに既に存在する状況を報告しているだけです。私は Discourse チームのメンバーではないため、何を決めるという役割もありません。私が表明した唯一の意見は、現在のデフォルトが変更される可能性は低いと考えているということです。このフォーラムでほぼすべての新しいトピックを 5 年間読み続けてきた結果、チームの意思決定のあり方に私は非常に納得しています。現時点では、Discourse チームからの発言がないことが何よりも物語っています。
このスレッドが単純なバグ報告から完全に話題外れの意見表明にすり替わってしまっている以上、チームが回答する余地を残すべきではないでしょうか。
この藁人形論法はすでに徹底的に叩き潰されています。そろそろ葬り去る時ではないでしょうか。
ここにいる誰も、このデフォルト設定の変更を主張しているわけではありません。実際、現状のままでも非常に合理的です。
私が主張しているのは、「トリミングする最小比率」は、物理ファイルのサイズではなく、投稿内で定義された寸法に基づいて動作すべきだという点です。
低アスペクト比（縦横比）の画像が投稿内で手動でリサイズされた場合、それがもはや議論を支配することはないはずです。
また、これがなぜバグなのかという疑問が湧く前に説明します。
私の場合、そのまま放置すれば議論を支配してしまう特定の画像 Subset のみをフォーマットできないため、ジレンマに陥っているからです。
この設定が期待される機能を損なっているとまだ信じられない場合は、Composer のスケーリングツールを使って、OP（最初の投稿）にある 2 枚目の画像を 50% にリサイズしてみてください。
その結果、投稿内のすべての画像が幅の半分まで縮小できるにもかかわらず、縦長で細い画像だけが例外として縮小されないことが確認できます。
「いいね！」 1
これはバグではなく、Discourse の標準的なデフォルト動作です。設計上、既知の制限事項です。さらに、ご希望の動作を許可するサイト設定が存在し、その制限を解除するかどうかはサイト管理者の判断次第です。
画像サイズやファイル拡張子などに関するサイト設定でも、デフォルト値の変更を求める同様のリクエストが寄せられます。サイト管理者に設定変更を要請するだけで済む場合、それはバグではありません。
これはバグではありません。バグとして再設定すると、突然ここで歓迎されなくなるでしょう。
「いいね！」 2
こんにちは、Jeff さん。この件に関心を持っていただき、ありがとうございます。
私がこのトピックのカテゴリを変更したことはなく（今後もしません）、チームのメンバーが別のカテゴリへ移動させた後、再びバグカテゴリに戻したのは私ではありません。これを機能リクエストと呼ぶことに同意します。
私がここに投稿した目的は、ソフトウェアの通常の使用において直面している問題を表明し、チームからの回答を求めたかったからです。
私は何らかの要求をしているわけでも、回答を求めているわけでもありません。少なくともチームに話を聞いてほしいだけです（同じ論理で何度も繰り返し却下されたくないのです。その論理は確かに善意から来ているのでしょうが、問題を完全に解決していません）。
トピック全体を読み通していただけたか分かりませんが、念のため、問題の概要をまとめます。
- マークダウンを使用してすべての画像を希望のサイズに設定できない（ユーザーにとって予期しない動作）
- これは「切り抜き最小比率」によって制御されており、画像をマークダウンで手動で許容可能な幅/高さ比率にリサイズした場合でも、画像のピクセルの幅/高さ比率を使用します
- 可能であれば、マークダウンで定義された幅/高さ比率を使用することはできないでしょうか
これにより、以下のような予期しない画像のスケーリング動作が解決されます（すべての画像を 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