[bug] 箇条書きで複数行の英単語が連結されてしまう

[kauplan]

箇条書きにおいて、複数行の英単語が連結されてしまう。

再現例：3行に分かれた箇条書き（3つの英単語）

 * foo
   bar
   baz

LaTeXへの変換結果（Re:VIEW 3.1）：

\begin{itemize}
\item foobarbaz    % ← 3つの英単語が連結されて1つになっている
\end{itemize}

期待した変換結果（英単語が連結されない）：

\begin{itemize}
\item foo
   bar
   baz
\end{itemize}

環境：Re:VIEW 3.1、Ruby 2.5、macOS Mojave (10.14.5)

[takahashim]

これは日本語の文で、改行が空白に変換されて微妙な空白が入るのを撲滅するための仕様なんですよね…。回避策としては「1行に書く」「単語の末尾に空白を開ける」といったものがあります。

ちなみに、

* foo
   bar
   baz

を、

* foo bar baz

と書きたくなかった理由は何でしょうか？

（Re:VIEW側で解決するには文字種で場合分けして空白を入れるか入れないか決めるとか？　Unicode Technical Reportとかで連結してはいけない文字・連結するべき文字とか決まっていたりしないんだろうか…）

[kmuto]

単純にLaTeXだけの処理であれば、ul_item, ol_itemを

      str = lines.join

↓

      str = lines.join("\n")

でいけそうではあります（linesはここにくる時点ですでにstripされているはず）。

LaTeXビルダは本文のほうはもともとこういう形でしたね。

ただ、ほかのビルダではそのような判断は現状できないので、すべて単純に1段落を1行に結合しています。後続行の文字を見て連結するとしても、そこにインラインタグが入っていたときの処理など、悩ましい問題です。

[kauplan]

回避策としては「1行に書く」

この回避策がありなら、日本語の場合でも「改行が空白に変換されて微妙な空白を入れたくなければ1行に書いてください」と案内すればよくて、わざわざRe:VIEWが改行文字を取り除く必要はないのでは？

と書きたくなかった理由は何でしょうか？

単に、英語の文章を書いただけですけど…。

 *  Congratulations on the beginning of the
    new era! We hope 令和 will be blessed
    with peace and prosperity for everyone
    in Japan. (Tim Cook)

表示結果：
https://imgur.com/cEruRyn

英語の文章を書くのに理由が必要でしょうか。

文字種で場合分けして空白を入れるか入れないか決めるとか？

改行文字を取り除きたいならpLaTeXと同様でいいと思いますが。少なくとも英文を書いたら単語が結合されるのは仕様としてどうかと思いました。

[kauplan]

ただ、ほかのビルダではそのような判断は現状できないので、すべて単純に1段落を1行に結合しています。

判断できないなら改行を取り除くべきではないのでは？
判断できないのになぜ改行を取り除いているのか理解しかねます。

後続行の文字を見て連結するとしても、そこにインラインタグが入っていたときの処理など、悩ましい問題です。

改行文字を取り除くなら、pLaTeXと同じでいいと思います。
美文書作成入門から引用します。
https://imgur.com/jZjKJvb
またインラインコマンドの開始部と終了部はascii文字だから、ふつうにascii文字として扱えばいいでしょう。

そんなに悩むようなことなんですか、これ。
それに改行文字のせいで微妙な空白が入るのを防ぐことは、英単語が勝手に結合されることより優先すべきことなんでしょうか。

[kauplan]

箇条書きではなく通常の本文であれば、改行文字は取り除かれないようです。

例：

= Re:VIEWサンプル

新しい御代の幕開けに心からお祝い申し上げます。
『令和』が日本の国に平和と繁栄をもたらす
祝福された時代となるよう祈念致しております。

Congratulations on the beginning of the
new era! We hope 令和 will be blessed
with peace and prosperity for everyone
in Japan. (Tim Cook)

LaTeX変換結果

\chapter{Re:VIEWサンプル}
\label{chap:mybook}

新しい御代の幕開けに心からお祝い申し上げます。
『令和』が日本の国に平和と繁栄をもたらす
祝福された時代となるよう祈念致しております。

Congratulations on the beginning of the
new era! We hope 令和 will be blessed
with peace and prosperity for everyone
in Japan. (Tim Cook)

改行によって微妙な空白が入るのを防ぐなら、本文もそうすべきですよね。
でもそうなってないので、仕様が一貫してないです。

[kmuto]

本題のほうはul/olでjoin("\n")にしても先頭スペースは削り済みになっているので副作用は少ないのではという印象です。

ワープロ的な書き方をしたとしても1行1段落というDTPソフトに適したテキストファイルにするというのが大元の趣旨なので、改行を取り除くことは必要な処理です。それは現状も変わっていないです。

ASCII範囲でよいかどうかは微妙（英字のみ? Unicode的にほかにアルファベット扱いのものがありそう?）なのと、先頭にインラインタグがあったときのその掘り下げがあるので、「そんなに悩むこと」です。調査しきれていませんが、TeXも実際には単にASCII範囲ではなく文字の分類を内部設定しているはずです。

LaTeXビルダでの「本文もそうすべき」は一貫性からは確かにそうすべきです（ほかのビルダはそうなっている）。が、それは求められていることではないでしょうし、将来的にTeX的な行結合のロジックを実装してそれでLaTeX以外のビルダの段落・箇条書きのほうの処理を担うようにする、ことを検討します。

[takahashim]

改行文字を取り除きたいならpLaTeXと同様でいいと思いますが。少なくとも英文を書いたら単語が結合されるのは仕様としてどうかと思いました。

わかる〜、という気持ちになったので、この仕様については先送りにしていたのですが、ちょっと前向きに対応してみようかと思いました。UTR読みこんでみます。

たぶん https://unicode.org/reports/tr29/#Word_Boundary_Rules の逆を考えればよいような気がする…。

仕様が一貫してないです。

確かに。じゃあ3.xでも修正してしまってよい？

[kmuto]

検討のための情報

• https://twitter.com/zr_tex8r/status/1135510295709868032 のスレッド
• https://twitter.com/golden_lucky/status/1135514994416603136

[takahashim]

ちなみに、

と書きたくなかった理由は何でしょうか？

と聞いたのは、何か特殊な事情があるならそれを回避できるようにしないと…と思っただけです。
そして結論としては、箇条書きで（そしてそれ以外のparagraph等でも）普通に長い英文が改行混じりで書けることが求められている、という理解です。

[kmuto]

わかる〜、という気持ちになったので、この仕様については先送りにしていたのですが、ちょっと前向きに対応してみようかと思いました。UTR読みこんでみます。

たぶん https://unicode.org/reports/tr29/#Word_Boundary_Rules の逆を考えればよいような気がする…。
確かに。じゃあ3.xでも修正してしまってよい？

英文が入ったときにつらいのはわかるので、実装ができるといいですね。
で、その場合、LaTeXのもそれに合わせて、今のLaTeXに任せるではなく自前結合ロジックを使う、ということになるのが一貫性の観点で筋でしょうか。ちょっと怖いので結合ロジック使用有無のスイッチフラグが必要？

[takahashim]

#1312 (comment) のtwitterのスレッドを見ましたが、どちらかというとwhite spaceの扱いよりは、line breakingとword separatorの扱いの仕様を元に考えた方がよいかも、と思いました。

• https://drafts.csswg.org/css-text-3/#line-breaking
• https://www.w3.org/TR/typography/#line_breaking
• https://www.w3.org/International/articles/typography/linebreak.en

そして、上記をなんとなく眺めた限りでは、とりあえず改行の前後がひらがな・カタカナ・漢字の場合(JapaneseとChinese)は改行を無視して、それ以外は改行を活かすかU+0020にする、くらいが妥当かなあ…という気がしています（modern Hangulにはword separatorがあるのでそこで改行しそう。あとKhmer、Lao、Thai辺りは困ったときに再考したい）。

[kmuto]

テキストやIDGXMLのほうは改行を活かされても困る（1行1段落にすべき）ので、やはりスペースを追加するにはどうするか？という話になるような。

[takahashim]

なるほど、その場合は機械的に改行をU+0020にする、とかではないでしょうか。
IDGXMLの方でZWSP(U+200B)にしたいとかはありますか？

[kmuto]

U+200Bにすることはないですね。あくまでU+0020を入れるか入れないか程度の処理に済ませたい…。

とりあえず改行の前後がひらがな・カタカナ・漢字の場合(JapaneseとChinese)は改行を無視して、それ以外は改行を活かすかU+0020にする

あとはSegment Break Transformation Rulesで定義されている「punctuation or a symbol (Unicode general category P* or S*)」もかな。
極端な例だと

abc (
def
)
. 
ghi
`
j
'
k

とか？
Segment Break Transformation Rulesをちょっと実装試してみていたんですが、East Asian Width propertyが標準ライブラリの範疇に収まらなさそうでした。

[kauplan]

ワープロ的な書き方をしたとしても1行1段落というDTPソフトに適したテキストファイルにするというのが大元の趣旨なので、改行を取り除くことは必要な処理です。

だから、改行を取り除くことは英単語が勝手に結合されることより優先すべきことですかと聞いているんですけど？Yes/Noで答えられる質問ですよ。
開発陣の考え方を理解するための質問なのでお願いします。それを理解しないと話が平行線のままになるんですよ。

＃InDesignで処理するには英単語の結合が必要だなんて、初耳です。いやー知らなかった。

ASCII範囲でよいかどうかは微妙（英字のみ? Unicode的にほかにアルファベット扱いのものがありそう?）なのと、先頭にインラインタグがあったときのその掘り下げがあるので、「そんなに悩むこと」です。

先に引用した美文書作成入門では、「行の最後が日本語文字なら改行を無視する」とあります。ASCII範囲も先頭のインラインタグも関係しません。関係しないことを持ち出して、なんでそんなに悩むのか分かりません。
（「実はASCII範囲も先頭のインラインタグも関係するのです」という説明があるならまだしも。）

せっかく参考となる文章を探して引用したのに、見てもらえてないようで残念です。

調査しきれていませんが、TeXも実際には単にASCII範囲ではなく文字の分類を内部設定しているはずです。

そんな調査いります？
今わかっているのは、「日本語の場合は改行文字を取り除く」ことだけでしょう。他の言語にも詳しいならともかく、そうでないのだから、とりあえずはよく知っている日本語の場合だけ対処すればよくないですか。
たとえば中国語やハングルも日本語と同様ということがわかれば、その時点で対処すればよくて、今完璧な仕様が必要なわけではないです。

話をおおげさにしすぎ。

[kmuto]

「バグか否か」「どのように実装するか」の判断は開発陣がつけるものであり、”あなた”が判断するものではありません。今後もあなたの考える「解決方法」がそのように実装されることもなんら保証されません。
それが嫌だということであれば、フォークなり新規の開発なりに進むことをお勧めします。

改行を取り除くことは英単語が勝手に結合されることより優先すべきことですかと聞いているんですけど？Yes/Noで答えられる質問ですよ。

Yes。
LaTeXの今の段落の作り方のほうが仕様からすると不正です。

ただそれを正したところで英単語で困るだけというのは理解しているので、全ビルダ共通の妥当な行結合の実装を考える、というだけです。
issueの議論を目に入れたくないということであれば、いったんcloseしますか？

[takahashim]

それが嫌だということであれば、フォークなり新規の開発なりに進むことをお勧めします。

いやまあ、そこまで言いきらなくてもよいかと。
改行まわりはMarkdownでもline breakをhardにするかしないかが混在して不幸なことになっているくらい、文脈によって望まれる対応が異なるので、まあ対立しがちなところかと思います。

「英単語」というのは混乱しがちなので（英文にも絵文字が入ったりする時代なので）、ASCIIのprintableの範囲内については改行を落としても連結されないよう、全ビルダで対応する、という感じにしたいです。

[takahashim]

https://github.com/takahashim/unicode-eaw
nodeのeastaを移植した、East Asian Widthを取得する軽量ライブラリです。

[kmuto]

https://github.com/takahashim/unicode-eaw
nodeのeastaを移植した、East Asian Widthを取得する軽量ライブラリです。

ありがとうございます、拝見してました。コア機能になると思うのでgem経由取り込みにしたくないところですが、内包しちゃってもよさそうです？（ライセンス的に困る？）

[takahashim]

はい、内包するのは問題ないです。
って、ライセンスがついてなかったか。こっちはMITのままにしておきたいですが、まあ同梱するには大丈夫かと。