Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

「//emlist」でキャプションがない場合のスペースを狭くする #913

Closed
wants to merge 1 commit into from

Conversation

kauplan
Copy link

@kauplan kauplan commented Jan 2, 2018

連番なしのリスト //emlist[]{ ... //} を使ったときに、キャプションがある場合は本文との間のスペースが適切だが、キャプションがないとスペースが空きすぎる。

スクリーンショット: https://imgur.com/4rttY8q

なので、キャプションがある場合とない場合とでスペースを変えるよう変更する。

修正後スクリーンショット: https://imgur.com/3osgEKf

(なお空文字列かどうかの判定には以下のサイトを参考にした。
https://tex.stackexchange.com/questions/179964/how-to-test-if-a-string-is-empty

@kmuto
Copy link
Owner

kmuto commented Jan 8, 2018

むしろリスト環境の作り方が問題 (#916) なので、それを修正したいと考えています。既存の制作物の表現互換性をいろいろ壊しそうなのが悩ましいですね…

@kauplan
Copy link
Author

kauplan commented Jan 10, 2018

リスト環境の作り方が、直近で修正されるなら、そちらを修正してからこのPRをrejectしてください。
もし直近では修正されないなら、それまでのworkaroundとしてこのpull requestを取り入れてほしいです。

@kmuto
Copy link
Owner

kmuto commented Jan 11, 2018

「たとえ当時のが間違った値だったとしても過去の版に影響を及ぼさないように注意し、及ぶなら大々的にアピール」という組版ソフト(Re:VIEWは変換器であって組版ソフトのつもりはあまりないんだけど)の原則があります。

  • システムのlayout.tex.erbでこのアキ調整を入れると、既存の標準レイアウトでやっていたコンテンツはいろいろ変わってしまう可能性。
  • 大々的にアピールするタイミングとするなら、(各種パラメータ含め)全面的に変えたい。
  • 後方互換性のフラグみたいなことはいろいろゴチャゴチャして後々禍根になるので避けたい…。

今これを入れるなら、ローカルにコピーされるreviewmacro.styにrenewcommandとしてコメントで入れておく(ユーザーの判断でコメントを外す) くらいでしょうか。

@kauplan
Copy link
Author

kauplan commented Jan 14, 2018

たとえ当時のが間違った値だったとしても過去の版に影響を及ぼさないように注意し、

これは、互換性を理由にバグを修正しないという意味でしょうか。

既存の仕様(この場合なら、キャプションがない//emlistでは空きが広くなること)をアテにしているユーザが多い場合は、たしかに互換性を維持することが大事でしょう。
しかし今回のは、それに当てはまるとは思えません。

スクリーンショット (https://imgur.com/4rttY8q) を見ればわかるように、現在の仕様ではキャプションをつけない場合は使い物になりません。現在の仕様のままでキャプションをつけずに//emlistを使っている人がいたとして、その人たちは空きが調整されると困るのでしょうか。

ちょっと考えにくいです。できれば他のユーザの意見を伺いたいです。

システムのlayout.tex.erbでこのアキ調整を入れると、既存の標準レイアウトでやっていたコンテンツはいろいろ変わってしまう可能性。

標準レイアウトで困っていた点を修正するのだから、変わってしまってもいいのではないでしょうか(修正なのだから変わってくれないと困ります)。

繰り返しますが、既存の仕様をアテにしているユーザが多いなら、互換性を維持するのもわかります。
しかし今回のケースは、それに当てはまるとは思えません。
改めて、ご一考をお願いします。

@takahashim
Copy link
Collaborator

ちゃんと出力結果を見れてないですが(すみません)、そもそも//emlistにキャプションがないときは\reviewemlistcaptionが出力されないのが正解だったような…?(なのでそこで修正かけても効果ないのが意図した挙動のはず)

@kmuto
Copy link
Owner

kmuto commented Jan 14, 2018

あぁ、//emlist[]なのがいけないですね。空文字だけどnilではないから\reviewemlistcaptionができちゃう。
ということはcaption.present? 判定にすればいいだけですね。

@kmuto
Copy link
Owner

kmuto commented Jan 14, 2018

#922 で修正予定

@kmuto kmuto closed this in 4f98eed Jan 22, 2018
@kauplan
Copy link
Author

kauplan commented Feb 12, 2018

修正ありがとうございます。
最初にバグ報告をしたときは「たとえ当時のが間違った値だったとしても過去の版に影響を及ぼさないように〜」と明確に拒絶されたのに、他の方が指摘するとすんなり修正されるんですね。
まあ修正されたからいいですけど、今後は作者の方の意に沿うような修正方法を提案できるよう勉強させていただきます。

@kmuto
Copy link
Owner

kmuto commented Feb 12, 2018

キャプションなしの記法は//emlist{を想定していて(こちらなら普通にちゃんとしたアキになる)、//emlist[]という記法は想定外だったというだけですね。

@kauplan
Copy link
Author

kauplan commented Mar 1, 2018

キャプションなしの記法は//emlist{を想定していて(こちらなら普通にちゃんとしたアキになる)、//emlist[]という記法は想定外だったというだけですね。

その書き方が想定外というなら、最初にそう書いてほしいですね。あとから「想定外」と言われても。

キャプションなしでも言語名を指定したい場合はあります。その場合、//emlist[][言語名] とするしかないと思いましたが、ほかに方法があるんでしょうか。この書き方も想定外ですか。

@kmuto
Copy link
Owner

kmuto commented Mar 2, 2018

emlistの上のアキが広いようなのはなぜ、というissueだったらすぐに気付いたのですが、ロジックで見てスペースを埋めるというPRだったので真の原因に気付くのが遅れました。すみません。

言語名のあたりは後付けですし、私自身はTeX PDF+ハイライト は使わないので、やはり想定していなかったというほかないです。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants