縦中横についてお聞かせください

[Koji Ishii]

CSSの縦中横プロパティであるtext-combine-horizontal[1]がちょっとトラぶっていて、どこにも意見の合意の落としどころがなさそうなので、このまま妙案がないと落ちてしまう可能性があり、ご意見いただけると幸いです。

経過は以下のようになります。
1. 行幅を大きくはみ出る場合、傍線やルビ、傍点などとの関係整理をしなければならず、それには時間がかかると思われたので、「はみ出る場合には縦中横を解除し、90度回転に逃げる」という案が出た。この時点で、縦中横解除に対する疑問はあったが、対処法がはっきりしないことから、これでWD作成。
2. WebKitはこれに従って実装。
3. Adobeから強い反対が出て、削除。代わりにAdobeが主張した「傍線、ルビ、傍点、隣の行などに重なってもいい」という案でWD改定。
4. あるベンダーがこれに従って実装したところ、出版社から利用できないと却下された。

全体の希望が
●縦中横指定したら、勝手に解除しないでほしい
●行間は変えないでほしい
●傍線、ルビ、傍点、隣の行などには重ならないでほしい
というのであることはわかっていますが、すべてを満たす解は見つかりません。人によって重要度が違い、異なる意見が出て、別の人がそれを却下、というのを繰り返していて、このまま日本人の間ですら合意がないのでは、Level 3から落として、Level 4でもっと時間をかけて検討とするしかないかとも思い始めています。

T-Timeなどではフォントによっては全角を大きくはみ出しているようですが、これに傍線とかつけたらどうなるか、ご存知の方いらっしゃいますか？

またご意見ある方いらっしゃいましたら、お聞かせいただけると幸いです。

よろしくお願いいたします。

[1] http://dev.w3.org/csswg/css3-writing-modes/#text-combine-horizontal

[Toshiaki Koike]

石井様

ボイジャー小池です。
縦中横を指定しているのにそれが勝手に解除されるのは許しがたいことです。
T-Timeでは、縦中横の文字列の幅が大きくなれば、傍線とも重なるし、隣の行と重なることもあり得ます。
でも、それは作り手（データ制作者）の意図でなんとでもできることです。
仮に8桁の縦中横を実現したいと思った場合、通常の行間では絶対に重なる訳で、それを意図するなら、前後に空白行を設ける等、制作者側で工夫すべきです（意図的にやっているのですから）。
ドットブックの商品例をみると、2～3桁までは縦中横にするが、4桁以上の場合は全角幅の数字を縦にならべることが多いようにみえます（4桁の数字を縦中横にするのは主に新聞ですね）。
2～3桁、というのが微妙なところで、例えば、3桁の場合、縦中横にしても隣の行とは重ならないし、傍点もつけないから、縦中横にしよう、と思って意図的に縦中横を指定しているのに、それが勝手に解除されるのは困ります。

> 4. あるベンダーがこれに従って実装したところ、出版社から利用できないと却下された。

これは状況次第でなんともいえないですね。
わざわざ重なるようなデータを作ってテストさせたのでしょうか。

>「傍線、ルビ、傍点、隣の行などに重なってもいい」

ものは言いよう、といいますか、これだと無茶なデータが作られた際に、何とかするのがリーダーの役目で、それがうまくいかないと文句を言われるというのは違うかなと。
むしろ、
・縦中横指定をしたら、その文字列は必ず縦中横になる
・指定した文字列の長さによっては、隣の行と重なる可能性もあるので、制作には注意のこと
ということでうまく指定するのは制作の問題だと思うのです。

現状のままだと、縦中横の実現のために、

　あああああ<span style="-webkit-writing-mode:horizontal-tb;">2012</span>いいいいいい

のように、writing-modeを使おうとする例がでてきそうで、それは望ましくないのでは、と感じています。

--
-----------------------------------------------------------------
株式会社ボイジャー　Voyager Japan Inc.
小池利明　Toshiaki Koike
ko...@voyager.co.jp
http://www.voyager.co.jp/
-----------------------------------------------------------------

[koba]

>
> 全体の希望が
> ●縦中横指定したら、勝手に解除しないでほしい
> ●行間は変えないでほしい
> ●傍線、ルビ、傍点、隣の行などには重ならないでほしい
> というのであることはわかっていますが、すべてを満たす解は見つかりません。
人によって重要度が違い、異なる意見が出て、別の人がそれを却下、というのを
繰り返していて、このまま日本人の間ですら合意がないのでは、Level 3から落
として、Level 4でもっと時間をかけて検討とするしかないかとも思い始めてい
ます。

１．重要度の基準はなんでしょうか？

現実の縦組みプリント書籍での縦中横の使用頻度は極めて高くなっています。
もし、現在の紙で行なっているのに近い縦組みを行なおうということであれば、
縦中横がないと、ほとんど紙と同じ縦組みはできないので重要度は非常に高いで
す。

個人的には、本文中の縦中横の乱用は、あまり好ましくないと思いますが、
つまり、12月10日のような文字を<縦中横>12</縦中横>月<縦中横>10</縦中横>日と
いうような組版はしない、というなら重要度は低いですね。

必要か必要でないかを判断するのが先じゃないですかね。

３．日本人ですら合意がないという根拠は何なんだろう。
どういう意見が出ているかも知らないのです。
そもそもどういう意見がでているのでしょうか？

４．「すべてを満たす」とは上の3項目だけであるならば、縦中横の横幅は行ピッチ未満
にすれば良いのではないですか？（3文字以上なら文字の幅を小さくする。）

５．この問題は算術的問題なので先送りしても良い方法はなく、解決しないと思
います。

小林
--
koba <ko...@antenna.co.jp>
http://www.antenna.co.jp
http://www.cas-ub.com
http://blog.cas-ub.com
twitter @TokKoba

[Koji Ishii]

小池さん、早速のお返事、ありがとうございます。

> 縦中横を指定しているのにそれが勝手に解除されるのは許しがたいことです。

そういう意見もよく聞きます。Adobeの意見は基本それです。

> T-Timeでは、縦中横の文字列の幅が大きくなれば、傍線とも重なるし、隣の行と重なることもあ
> り得ます。
> でも、それは作り手（データ制作者）の意図でなんとでもできることです。

InDesignや他のリーダーとCSSの違いはそこで、CSSは読み手が行間やフォントサイズを自由に変えることを許しています。なので、製作者がエラーを直したら、読み手にとって重ならない、という状況を絶対的に作ることは不可能です。

なので、「重なってもいいという仕様にする」ということは、読み手の環境によっては重なることを意味していて、実際今のCSS仕様に従ったリーダーでは、設定によって重なってしまったので、出版社から却下されました。

今までのDTPや印刷、日本語専用リーダーとは少し事情が違うことをご理解いただいて上で、それでも「読み手の環境で重なってよい」とされますか？　そうなると、私がヒアリングしている出版社とは180度異なる意見ということになり、私には解決の糸口が見えません。

> 仮に8桁の縦中横を実現したいと思った場合、通常の行間では絶対に重なる訳で、それを意図する
> なら、前後に空白行を設ける等、制作者側で工夫すべきです（意図的にやっているのですから）。

上記の通り、CSSでは「制作側の工夫」で逃げることはできません。「制作中に重なってよいか」と「読み手にとって重なってよいかどうか」の違いをご理解いただいた上で、「重なってよい」とされますか？

> これは状況次第でなんともいえないですね。
> わざわざ重なるようなデータを作ってテストさせたのでしょうか。

これも上記の通りで、リーダーの設定によっては必ず重なります。

> 現状のままだと、縦中横の実現のために、
>
> 　あああああ<span style="-webkit-writing-mode:horizontal-tb;">2012</span>いいいい
> いい
>
> のように、writing-modeを使おうとする例がでてきそうで、それは望ましくないのでは、と感じ
> ています。

実際にそうなりました。私が聞いている範囲、制作側は「CSSの縦中横は使わない方針」を立てた、と聞いています。

実利用が存在しないのであれば仕様化しても意味がないので、より深く考えて後で仕様化した方がいい、と感じ始めています。

[thoton]

石井さん

縦中横で使用できる文字種と字数を制限してしまうと議論が早い気がします。例えば、半角数字カンマピリオドのみ、2〜4文字まで。ただし、これは「縦中横」というより、「組数字」と呼ぶのでしょうが。でも、実用上はこのように数字だけに限定してもそれほど問題はないです（実家が元写植屋）。

[Koji Ishii]

> > 全体の希望が
> > ●縦中横指定したら、勝手に解除しないでほしい
> > ●行間は変えないでほしい
> > ●傍線、ルビ、傍点、隣の行などには重ならないでほしい
> > というのであることはわかっていますが、すべてを満たす解は見つかりません。
> 人によって重要度が違い、異なる意見が出て、別の人がそれを却下、というのを
> 繰り返していて、このまま日本人の間ですら合意がないのでは、Level 3から落
> として、Level 4でもっと時間をかけて検討とするしかないかとも思い始めてい
> ます。
>
> １．重要度の基準はなんでしょうか？
>
> 現実の縦組みプリント書籍での縦中横の使用頻度は極めて高くなっています。

誤解された様で申し訳ありません。縦中横が重要、という点は合意されています。

でもどう実現するか、上記の問題のうち、同時に達成できない場合どれを優先するか、という点に対して合意がない、という意味で書きました。


> ３．日本人ですら合意がないという根拠は何なんだろう。
> どういう意見が出ているかも知らないのです。
> そもそもどういう意見がでているのでしょうか？

上に書いたとおりです。「ユーザーの環境で重なってよいか」に対してYES/NO。NOの人は「じゃぁ、重なってしまう場合どうするか」に対して複数意見、です。

> ４．「すべてを満たす」とは上の3項目だけであるならば、縦中横の横幅は行ピッチ未満
> にすれば良いのではないですか？（3文字以上なら文字の幅を小さくする。）

フォントのスケーリングに対しては、CSS WGから強い反対が出ています。OpenTypeの三分、四分を使う、という案もありますが、使えない環境もあるので、そこではどうするか、ということに対しては合意が出ません。ある人は「重なってよい」と言い、ある人は「重なってはいけない」と言います。


> ５．この問題は算術的問題なので先送りしても良い方法はなく、解決しないと思
> います。

永久に解決しないなら、永久に仕様に入らないだけです。

[Koji Ishii]

> 縦中横で使用できる文字種と字数を制限してしまうと議論が早い気がします。例えば、半角数字カ

> ンマピリオドのみ、2〜4文字まで。ただし、これは「縦中横」というより、「組数字」と呼ぶので
> しょうが。でも、実用上はこのように数字だけに限定してもそれほど問題はないです（実家が元写
> 植屋）。

ご意見ありがとうございます。機能を制限して仕様化を早める、という案には大賛成です。

半角数字３桁で傍線や隣の行に重なってしまう場合、どうしますか？　たとえば携帯の小さい画面では行間を狭めた方がよい見やすい、という意見もあり、CSSはそれも許していますので、半角数字の幅が広めなAdobeやモリサワのフォントではほぼ確実に重なります。

[Toshiaki Koike]

石井様

> InDesignや他のリーダーとCSSの違いはそこで、CSSは読み手が行間やフォントサイズを自由に変えることを許しています。
> なので、製作者がエラーを直したら、読み手にとって重ならない、という状況を絶対的に作ることは不可能です。

状況理解しました。
そういう状況であれば「重なってもいい」ということにはなりません。
ならば、縦中横最優先、重なりそうな場合には行間を空ける、というのが落としどころかと思います。
（インライン画像みたいなものでしょうか）

[Koji Ishii]

> > InDesignや他のリーダーとCSSの違いはそこで、CSSは読み手が行間やフォントサイズを自
> 由に変えることを許しています。
> > なので、製作者がエラーを直したら、読み手にとって重ならない、という状況を絶対的に作るこ

> とは不可能です。
>
> 状況理解しました。
> そういう状況であれば「重なってもいい」ということにはなりません。
> ならば、縦中横最優先、重なりそうな場合には行間を空ける、というのが落としどころかと思いま
> す。
> （インライン画像みたいなものでしょうか）

それも一案だと思います。ただこれだと

> >> 現状のままだと、縦中横の実現のために、

> >>
> >> 　ああ<span style="-webkit-writing-mode:horizontal-tb;">2012</span>い

これと同じ結果になりますので、CSSの新しいプロパティは要らない、と言われてしまいますし、実際これで実現できるので不要です。私がコンタクトしている出版社がこの手法に切り替えたのも、「そもそもspanでできる」という話になったからです。

なので、これで合意であれば、text-combine-horizontalはお蔵入り、ということになります。

[koba]

小池さんとのやりとりで状況は大体理解しましたが、
それぞれ価値観が根本的に違うところまで無理にCSSで標準化する必要はないん
でしょうね。

但し、

>なので、「重なってもいいという仕様にする」ということは、読み手の環境に
>よっては重なることを意味していて、実際今のCSS仕様に従ったリーダーでは、
>設定によって重なってしまったので、出版社から却下されました。
>今までのDTPや印刷、日本語専用リーダーとは少し事情が違うことをご理解いた
>だいて上で、それでも「読み手の環境で重なってよい」とされますか？　そう
>なると、私がヒアリングしている出版社とは180度異なる意見ということになり、
>私には解決の糸口が見えません。

なるほど。これは面白いですが。私なら同じような状況になったら、御社はPDF
で出版しなさい、と言いますね。

>
> > ５．この問題は算術的問題なので先送りしても良い方法はなく、解決しないと思
> > います。
>
> 永久に解決しないなら、永久に仕様に入らないだけです。

弱小ベンダーとしては、そのほうが嬉しいですね。
お金を払う価値を認める人向けに、独自拡張版を提供して、お金をもらって商売
できますからね。

CSS3からドロップしたら良いでしょう。しかし、当社は独自仕様で実装します。

[thoton]

>ご意見ありがとうございます。機能を制限して仕様化を早める、という案には大賛成です。

こちらこそありがとう。

>半角数字３桁で傍線や隣の行に重なってしまう場合、どうしますか？　たとえば携帯の小さい画面では行間を狭めた方がよい見やすい、という意見もあり、CSSはそれも許していますので、半角数字の幅が広めなAdobeやモリサワのフォントではほぼ確実に重なります。

紙の組版なら、重ならないように、字幅の狭い三分の一の幅の組数字専用の書体を使用するか、文字に長体をかけるか、です。

傍線に重なることや、隣の行の文字に重なることは、ほぼ100%容認されないです。

[Toshiaki Koike]

ボイジャー小池です。

(A)

みたいなものも対象にしたいです。
3桁ですが、さほど幅も広がりませんし。

> 石井さん
>
> 縦中横で使用できる文字種と字数を制限してしまうと議論が早い気がします。例えば、半角数字カンマピリオドのみ、2〜4文字まで。ただし、これは「縦中横」というより、「組数字」と呼ぶのでしょうが。でも、実用上はこのように数字だけに限定してもそれほど問題はないです（実家が元写植屋）。

[Koji Ishii]

> >半角数字３桁で傍線や隣の行に重なってしまう場合、どうしますか？　たとえば携帯の小さい画
> >面では行間を狭めた方がよい見やすい、という意見もあり、CSSはそれも許していますので、半角
> >数字の幅が広めなAdobeやモリサワのフォントではほぼ確実に重なります。
>
> 紙の組版なら、重ならないように、字幅の狭い三分の一の幅の組数字専用の書体を使用するか、文
> 字に長体をかけるか、です。
>
> 傍線に重なることや、隣の行の文字に重なることは、ほぼ100%容認されないです。

おっしゃる通りだと思います。

さて、三分文字がないフォントで、長体もかけられない、という状況で、さて、どうしますか？　というのが質問になります。禅問答のようですが（笑

誰もが引かず、「これができないなら要らない」という点が論理的に矛盾するのであれば、小林さんのおっしゃるように、仕様化を断念するのが一番です。

[koba]

> > ４．「すべてを満たす」とは上の3項目だけであるならば、縦中横の横幅は行ピッチ未満
> > にすれば良いのではないですか？（3文字以上なら文字の幅を小さくする。）
>
> フォントのスケーリングに対しては、CSS WGから強い反対が出ています。
OpenTypeの三分、四分を使う、という案もありますが、使えない環境もあるので、
そこではどうするか、ということに対しては合意が出ません。ある人は「重なっ
てよい」と言い、ある人は「重なってはいけない」と言います。

「フォントはレンダラが変形してはならない」という前提条件追加ですか？

・和字のイタリック体やってるでしょ。
・ボールドフォントがないときは？ボールド作ってない？
・平体、長体は一切認めないのですか？

それから、最初は３つの条件でしたが、あとで条件がひとつ増えました。
他にも前提条件があるのですか？

[Koji Ishii]

> (A)
>
> みたいなものも対象にしたいです。
> 3桁ですが、さほど幅も広がりませんし。

ユーザーがフォントを指定できるし、ユーザーがインストールしたフォントを使うことも可能なので、「９割以上の確率で重ならない」は作れても、「これなら重ならない」という環境は作れません。

出版社としては、それでは商業物を出せない、というお話で、それは理解できます。

[thoton]

小池さん

たしかに、(A)もあったほうがいいですね。

写植の世界では、専用の文字が作られてましたが、HTML/CSS/Unicodeでは、別なアプローチで表現すべきでしょう。

[thoton]

>さて、三分文字がないフォントで、長体もかけられない、という状況で、さて、どうしますか？　というのが質問になります。禅問答のようですが（笑

その場合、左右の行間を広げて、重ならないようにしてほしいです。段落内で部分的に大きな文字を使用した場合と同様、他の文字とは重ならないことが大事です。

>誰もが引かず、「これができないなら要らない」という点が論理的に矛盾するのであれば、小林さんのおっしゃるように、仕様化を断念するのが一番です。

そんなこと言わずに、まずは文字種を数字に限定して、仕様化を実現して下さい(笑)。

その後、拡張して、一般化すればいい。

[Koji Ishii]

> >さて、三分文字がないフォントで、長体もかけられない、という状況で、さて、どうしますか？
> >というのが質問になります。禅問答のようですが（笑
>
> その場合、左右の行間を広げて、重ならないようにしてほしいです。段落内で部分的に大きな文字
> を使用した場合と同様、他の文字とは重ならないことが大事です。

小池さんへの返信にも書きましたが、それならspanでいいんですよ。だから仕様化する必要がなくなります。

「縦中横自動解除」はそれほど嫌ですか？

[thoton]

石井さん、

実質、spanでもOKだとしても、仕様化してほしいです。

縦組に縦中横は必須ですから。

＞人によって重要度が違い、異なる意見が出て、別の人がそれを却下、というのを
繰り返していて、

そんなに話がまとまらないのですか？

組版について知識があり、常識があるなら、

それほど意見が別れる問題だとも思いませんが...

話がちょっと変わりますけど、横組み中に、伝統的モンゴル語を

挿入した場合、どうなりますか？理想的には「横中縦」ですが。

[Koji Ishii]

> 実質、spanでもOKだとしても、仕様化してほしいです。
> 縦組に縦中横は必須ですから。

既存機能ですべてがカバーできるなら、仕様化は不要です。誰かがhow to本で書けば終わりであって、W3Cの仕事ではありません。

カバーできないシナリオはありますか？　それがあれば検討可能です。


> そんなに話がまとまらないのですか？

今現在まとまってないですよね（笑　「自動解除」も組版・出版に深くかかわる人たちからの意見でしたが、「私は別のオプションがほしい」ならまだ両方書けば済むんですが、「そんなものは間違いだ」と言ってしまえば、仕様がとん挫します。

「重ならない」でいいなら仕様かは不要、という点もまとまってないですよね。

まぁ、まとまらないなら自動的に落ちるので、落ちてよいなら心配はないです。

[Koji Ishii]

> 実質、spanでもOKだとしても、仕様化してほしいです。
> 縦組に縦中横は必須ですから。

ちなみに傍線やルビや傍点は、どういう挙動を期待されていますか？

1. 重なる
2. 縦中横の部分だけずれる
3. 縦中横を含む連続した傍線・ルビ・傍点だけずらす
4. 続いていなくても、その行内の傍線・ルビ・傍点をすべてずらす

…ん～、4は案としては出しましたけど、実現が難しすぎるかな…

[thoton]

石井さん、

「縦中横」というより、「組数字」の話になりますが、対象文字列のほうを無理やりにでも全角幅に収めるべきですから、傍点や隣接行の文字に重なる、というケースは想定しなくてもいいんですよ。

[thoton]

[Yasuo Kida]

賛成です。

縦中横は棚上げして、ぐっと制限して「組数字」機能にしませんか？それで現実的に多くの場合はカバーされるでしょう。残った問題が明らかになるでしょうから、それを将来のバージョンで解決する。

木田

[Koji Ishii]

> 賛成です。
>
> 縦中横は棚上げして、ぐっと制限して「組数字」機能にしませんか？それで現実的に多くの場合は
> カバーされるでしょう。残った問題が明らかになるでしょうから、それを将来のバージョンで解決
> する。

私も「組数字限定」は大賛成です。ただ

> > 「縦中横」というより、「組数字」の話になりますが、対象文字列のほうを無理やりにでも全角
>> 幅に収めるべきですから、傍点や隣接行の文字に重なる、というケースは想定しなくてもいいんで
>> すよ。

この「無理やりにでも全角幅に収める」には異論があるので、すんなり通るとは思えません。異論は二つで

1. Mozilla/Adobeからフォントのスケーリングについては根強い反対があります。
2. 日本からも「ちょっとくらいならはみ出していいからスケールしないでほしい」という声があります
3. 以前の仕様では1.1emまで許す、としていましたが、そういう「許容幅」的な考えは標準仕様に適さない、という反対があります
4. Hiraginoは1.1emで数字二桁入りますが、小塚、リューミンは数字二桁でも1.1をわずかに上回ります。

なので、数字限定にしたとしても、あふれ時の問題を解決しないと、仕様化できません。

今までになかったものを作らざるを得ないので、論理的に説きうる解であれば私は試してみてもいいと思っていますが、日本側が譲れないところと、実装側が譲れないところがぶつかっている以上、仕様化は困難です。

[Koji Ishii]

> > 縦中横は棚上げして、ぐっと制限して「組数字」機能にしませんか？それで現実的に多くの場合は
> > カバーされるでしょう。残った問題が明らかになるでしょうから、それを将来のバージョンで解決
> > する。
>
> 私も「組数字限定」は大賛成です。

あ、そうか、組数字限定だったら、フォントによって幅広になって溢れてしまったら自動解除でも仕方がない、という意味ですか？　それなら解決が可能ですが。

[Yasuo Kida]

はい。それで。

[thoton]

木田さん、

ありがとうございます。

[Takayuki Akimoto]

石井さん、

私もその仕様でいいと思いますよ。

[Kobayashi Toshi]

石井　様

　　　小林敏です

縦中横は，主に2桁のアラビア数字に使用されています．
3桁以上は，縦で正常な向きで1字1字表示するのが一般的でしょ
う．

ところで，2桁であった場合，アラビア数字の字幅が二分であれば
問題ありません．私としては和文と混ぜ組にするアラビアは，いろ
んな理由から字幅は二分が望ましく，そのように設計すべきだろう
と思っています（活字組版では本文組用はそうでした）．しかし，
近年では，二分幅以上のものが多くなっている現状があり，いかん
ともしえないと思っています．

ですので，2桁の縦中横の横幅を全角にするには難しい現状があ
ると思います．

また，縦中横では欧字交じりの例として，ダッシュや下付き・上付
が付いた場合も縦中横したいと思う人がいるかと思います．私は，
特に下付き・上付きは横向きでよいと思っています．というのも，
下付き・上付きの字面は，字面が親文字の仮想ボディから下または
上にはみ出している場合が多いからですし，親文字の下又は上に揃
えた例もありますが，活字組版に見慣れた目で見ると，ちょっとき
れいでないなと思います（ですので，下付き・上付きが付いた文字
を縦中横にすると，前又は後ろの文字と重なり場合もあり得るのか
もしれませんが，まあ，ほとんど問題にはならないでしょう）．
また，英文字2文字を縦中横にした例もありますが，私は，これは
あまり形がよいと思っていません．

いずれにしても，組文字に限定するといっても，行間にはみ出す例
がでてきます．

次に行間にはみ出しが出た場合にどうするかがあります．行中の文
字が行間にはみ出してしまう，という問題は，単純な例でいうと行
中の文字をその段落で設定した文字サイズより大きくする場合があ
ります（これまでの本では例は少ないが，最近いくつか目にしてい
ます）．このような単純な場合でも，ルビや圏点，傍線はどうなる
かは必ず問題になります．ですので，それなりの解決が必要なこと
だと思います．

それでは，文字サイズが大きくなった場合に，ルビや圏点，傍線は
どうなるんでしょう．ルビや圏点では文字サイズも問題になります
（指定があれば，サイズは変更できるでしょう）．

すなおに考えれば，大きくなった親文字の部分だけについて，仮想
ボディに接してルビや圏点は配置され，傍線はしかるべき位置に配
置されるということでしょう．

> 1. 重なる
> 2. 縦中横の部分だけずれる
> 3. 縦中横を含む連続した傍線・ルビ・傍点だけずらす
> 4. 続いていなくても、その行内の傍線・ルビ・傍点をすべてずらす

ということでいえば，2となります．どうしても，3とか，4にした
いのであれば，指定すればいいことだと思います．（私にいわせれ
ば，そもそも，そんな問題を起こす原稿が悪い，原稿編集がなって
いない，それがしたいなら，ちゃんと指定も考えろ，といいたいの
ですが，そうもいえないのでしょう．）

次に行間だけでは足りないで前又は後ろにまでかかる場合はどう
するか，ということですが（まさに，そんな原稿を作る方が悪いと
いいたいが，ぐっとこらえて），基本的には，行間を変えてほしく
ないなと思っています．

というのは，なぜか最近読んでいた本で，行間が乱れている本が何
冊か続いていたのです．だいぶ前に刊行された本でしたが，増刷で
訂正をする際，何行かまとめて鉛版で訂正したためか，管理の悪い
木のインテル（木インテル）を使ったためかもしれません．1行ア
キなど，はっきり行間が空いているのであればよいのですが，微妙
に乱れた行間は，読んでいて，とても感じの悪いものでしたからで
す．

しかし，見た目がどうか，という問題と，読めるか読めないか，と
いう問題では，あきらかに読めないことにははじまらない，という
ことでしょう．ですから，行間は，一定にしてほしいのですが，前
後の行にかかるということの方が問題は大きく，行間を広げるとい
うのは，やむを得ない処理だと思っています．

[Koyama Tadayoshi]

インフォシティ小山です。

縦中横に限らず、制作者が幅の広い行で隣と重ならないように行間を調整しても、

リーダー側で別の CSS を適用してしまえば文字は重なってしまいます。

CSS はセマンティックなことを記述するためのものではありませんから、

縦中横に限らずこのあたりはいかんともし難いでしょう。

それはさておき、

＞1. 行幅を大きくはみ出る場合、傍線やルビ、傍点などとの関係整理をしなければならず、それには時間がかかると思われたので、「はみ出る場合には縦中横を解除し、90度回転に逃げる」という案が出た。この時点で、縦中横解除に対する疑問はあったが、対処法がはっきりしないことから、これでWD作成。 

これで問題ないのではないでしょうか。

通常の行間では重なってしまうような、明らかに長いものは writing-mode を用いるとして。

そもそも text-combine に対応していない端末や、ユーザの設定でこれを off にした端末では縦中横は表現されません。

縦中横の解除を認めない出版社の方はそのような端末向けにはデータを出さないということでしょう。

であるならば、同様に、縦中横での表示が期待される文字数であるにも関わらず縦中横が解除されるような端末

(当該文字の２分、３分、４分幅のグリフを持たない、使用しない端末）向けにはデータを出さなければ良いだけのことと思われます。

[Toshiyuki Kamada]

鎌田と申します。

> 縦中横の解除を認めない出版社の方はそのような端末向けにはデータを出さないということでしょう。
> であるならば、同様に、縦中横での表示が期待される文字数であるにも関わらず縦中横が解除されるような端末
> (当該文字の２分、３分、４分幅のグリフを持たない、使用しない端末）向けにはデータを出さなければ良いだけのことと思われます。

話はWebの世界のことなので、端末という概念よりは、そのような設定ができるブラウザなりWebアプリなりというほうが適切なような気がします。

そして、閲覧環境を限定するということはビジネスとしては、VoyagerさんのBinBのように独自のWebアプリ上でのみ展開するとか、そういったようなことになるのではないかと思います。

Webはユーザがコンテンツを出すという面が大きいはずなので、ユーザがマークアップしやすいかどうかという観点で議論を着地させるのがよいかと思いますし、フォントの多様性に関しても、ユーザが必要とするならばということで、縦中横が組みやすいWOFFをフォントメーカー等が出すなど別のビジネスで補完される可能性もあるように思います。ユーザに厳密な組版を要求する高度な仕様よりは、そこそこの水準で使いやすい仕様、ただししっかり組みたい人のニーズにも応える余地を残すことが仕様策定にあたってのポジションなのではないかと思います。その意味で、縦中横は組数字に限り仕様に必要性の痕跡を残す、その上で問題が生じたら次の仕様で改良するというアプローチはインターネット的であり、大いに賛成です。現状、writing-modeで見た目は逃げられるというのでしたら、なおさらです。

[Hiroshi Takase]

石井さん

イースト高瀬です。

私は現在のWebKitの実装である「はみ出る場合には縦中横を解除し、90度回転に逃げる」で十分だったと思います。

直接話を聞いたわけではないので憶測にすぎないのですが、出版社が問題としているのは、責任の所在が曖昧なことではないでしょうか。

・縦中横を指定した文字列が隣の行に重なるのは制作側の問題

という論理が成立するならば、

・縦中横を指定した文字列が解除されるのは制作側の問題

という論理も成立してもよいはずです。

しかし、そうならないのは縦中横が解除される文字数の境目が曖昧さが、表示結果に対する責任の曖昧さとして忌避されているのだと思います。

どうしても縦中横を解除したくないために、制作者が自己責任でtext-combineの代わりにwriting-modeを使うことは、止むを得ない気がします。

出版社が、「何文字までは確実に縦中横が解除されない」ことさえ把握できる仕様であればよいのですが。

高瀬　拓史

tak...@est.co.jp

[Takayuki Akimoto]

石井さん、

＞縦中横は組数字に限り仕様に必要性の痕跡を残す、その上で問題が生じたら次の仕様で改良するというアプローチはインターネット的であり、大いに賛成です。

鎌田さんも、このように申してますし。

どうですか、私が提案したように、とりあえず数字に限定して、仕様化を急ぐ、という方向は。

[Koji Ishii]

皆様のおかげで少し問題の根元が見えてきた気がします。この問題は思っていたよりも根が深かったです。

「縦中横自動解除」に懸念を持っていたのは開発者側かと思っていましたが、ここで私が認識違いをしていたようで、出版社側が自動解除に対して大きな懸念を持っていました。まだ数を集められていないのでもしかしたら小数なのかもしれずそこは要調査継続なのですが、ある出版社の方からは、縦中横を解除するとそれはエディトリアルな修正であるとみなされ、著者校、編集校了が必要になる可能性がある、というご指摘をいただきました。その方は「重なってもいいから解除しない」を理想とされています。次点が「行間が広がってもいいから解除しない」だそうです。

では重なったらどうするか、という問題に対しては、主要な環境で重ならないようにするのは制作側の責任だが、特定環境やユーザー設定の変更で重なるのはユーザーあるいはUA/RSの責任、というお話でした。

ここで二つの問題が出てきます。一つは、UA/RSの責任となるのであれば、UA/RSとしては重ならない仕様であってほしいと希望されるの可能性があること。もう一つは、interoperableなWebを視野に入れた回答ではないこと。後者は、それをご理解の上で、現時点での現実的な判断をされてのご発言と理解しています。

この話が小数でした、というならまた別ですが、そうでないとすると、制作側の賛同を得られないということになりますので、自動解除しないオプションも少し考えたいと思います。

自動解除しない、という前提で改めて考えてみると、オプションは二つです。
1. 今のAdobe案（重なってもよいから行間維持）
2. 文字幅によって行間を広げる
2.1. span+writing-modeでやる
2.2. プロパティを作る

数字２桁利用に限る、という話であれば、どの案でも可能ですが
●Adobe案で３桁以上使われてしまった場合、リスクをUA/RSが負うことになる（「CSSの仕様ですから」と言い切る、というオプションもありますが、それもリスクの一部とした上で）
●spanでやると、高さを1emに合わせたり、上下の空白の調整を製作者がしなければならないし、それをされるとinteroperabilityを失う可能性がある。
●spanでやると、傍線・傍点・ルビが正常に動作しない。
●プロパティを作ると、仕様策定・実装が遅れる

…となると、Adobe案が一番有力でしょうか？

この問題、それほど問題になるとは思わず、制作側にあまり聞いてきていなかったんです、すみません。

一旦このMLでは自動解除で落ち着きかけた上でここにきて申し訳ないですが、自動解除しない場合のご意見を改めていただけますでしょうか？

[Kobayashi Toshi]

石井　様

　　　小林敏です

自動解除したら問題が出てくるでしょう．主な理由は，縦中横がよ
く利用される2桁のアラビア数字で，全角を超える場合がかなり考
えられるということです．縦中横はできないのだ，ということにも
なりかねません．

次に，縦中横にルビは付かなくてよいかについては，一般にはない
だろうなと思うのですが，ソルジェニーツィン著“収容所群島”の第3
巻（新潮社，文庫版でなく，単行本のp.173の上段，その他にもあ
り）では，“彼女はChSの”という文字列で，Chが縦中横で2文字横
に並び，その下に“Sの”と続きます．そのうえで，“ChS”に対し“チ
エー・エス”のルビが付いています．グループルビのようで，“Ch”
の右端に接し，“Ch+S”の全体に対し，ルビは配置されています．

圏点については，翻訳もので，原文がイタリックなどで強調されて
いた場合，日本語では圏点を付けるとする方式はかなり一般的なの
で，縦組でアラビア数字使用が増えている現状から，今後は縦中横
に圏点が付く場合はそれなりに予想されます．また，傍線も，ある
範囲を付けるので，例は少ないでしょうが予想されます．

ですので，縦中横に，ルビ，圏点，傍線を付けたいという要求は否
定できません．

行間を変更してよいか，どうかは，人により判断が分かれることで
すが，そもそも縦中横は，それほど行間にはみ出しが出ない場合に
選択されるものです．ですので，行間にはみ出すような設計が悪い
のだ，と考えれば，行間は固定でしょうし，いや，そのようなケー
スは少ないので，行間が広がるような場合は，ユーザー側で極端に
行間を狭くした場合などであり，そのような場合には，重ならない
ように行間を広げた方が実害が少ないと，という考え方も成り立つ
ということだと思います．

私は，変動要因の多いWebの世界では，行間は広がっていいように
思います．

ついでにいえば，日本語組版では，行間固定という観念がとても強
いのですが，私は過去に1度だけ，書籍で行間を変えて処理した例
があります（脚注があと少しで入り，それができれば，多くの問題
が解決するといった場合でした）．行間固定という観念も絶対とい
うことではなく，程度問題でしょう．

また，英文組版では，見開きのバランスをとても気にします．そこ
で，改丁・改ページの直前箇所の見開きで，版面の上下のサイズを
そろえるために行間を変更してもよい，その方がよいのだ，という
ことをどこかで読んだことがあります．ですので，英文組版は，日
本語より行間の変動を許しているんだな，と思ったことがありま
す．

日本語で，行間固定の観念が強いのは，日本語は，英文より行間が
広いこと，また，紙の透明度の問題から，裏側の行が表にもかすか
に見えてしまい．行の位置が表裏で重なっていないと，よくない，
ということもあった，と聞いております．Webでは，この問題はな
いかと思いますので，行間固定の観念も，紙よりはやや低いように
思います．

Koji Ishii さん wrote

[koba]

On Fri, 15 Jun 2012 09:14:51 +0900 (JST)
Kobayashi Toshi <bi...@k.email.ne.jp> wrote:

> 石井　様
>
> 　　　小林敏です

先生こんにちは。ちょっと便乗させていただきます。

>
> 自動解除したら問題が出てくるでしょう．主な理由は，縦中横がよ
> く利用される2桁のアラビア数字で，全角を超える場合がかなり考
> えられるということです．縦中横はできないのだ，ということにも
> なりかねません．

自動解除はほかにも懸念事項があります。

縦中横では、アラビア数字をASCIIコードで使うと思いますが、自動解除だけす
ると、いまのデフォルトの向きはASCIIコードは横倒しなので、正立したい文字
が横倒しになってしまうでしょう。

アラビア数字に縦中横をつかうケースでは、おそらく1文字のアラビア数字は正
立させていると思います。従ってアラビア数字の表示において正立と横倒しが混
在してしまいます。

そうすると自動解除したときは、text-orientationを有効にするとかしないとい
けないでしょう。あまり気持ちが良くない仕様になります。

アンテナハウス株式会社
小林　徳滋
東京都中央区東日本橋2丁目1番9号
電話03-5829-9021

[Yasuo Kida]

私自身は強い意見を持っておらず、どの方法でも良いから早く決まって、と思っているくちなんですが、ふと気がついたことを一点。

今までの議論、縦中横の理想的な姿ではなくて、失敗したときのフォールバック方法の問題が主な対象になっていますよね。より良いフォールバックももちろん大切ですが、所詮レイアウトの意図は既に失敗している訳です。負けたらどうするかではなくて、どうやったら勝つか。意図通りのレイアウトを達成するにはどうしたら良いか、そういう方向の議論をしてみるのは有益でしょうか？

木田

[Koji Ishii]

> 私自身は強い意見を持っておらず、どの方法でも良いから早く決まって、と思っているくちなんで
> すが、ふと気がついたことを一点。

早さで言えば、このまま放置がいいんでしょうね。ただ、たぶんプロのEPUB書籍ではほとんど使ってもらえない。私がヒアリングしている限りでは、出版社は一つのファイルで全デバイス対応したくて、テストしないとかぶるかも、というのは怖い。縦中横に圏点打ちたい場合にはほかに方法がないんですが、それも二分グリフのない環境では圏点がかぶるから、使ってもらえるかどうか危うい。

圏点とルビが付くケース以外は、span+writing-modesでいいみたいです。傍線はそもそも縦書きで使い物にならないのでborderで行く、と決めていらっしゃる方がいらして、これだとそこだけはみ出てくれる。理想じゃないけど重ならないならOKレベルみたいです。


> 今までの議論、縦中横の理想的な姿ではなくて、失敗したときのフォールバック方法の問題が主な
> 対象になっていますよね。より良いフォールバックももちろん大切ですが、所詮レイアウトの意図
> は既に失敗している訳です。負けたらどうするかではなくて、どうやったら勝つか。意図通りのレ
> イアウトを達成するにはどうしたら良いか、そういう方向の議論をしてみるのは有益でしょうか？

そうですね、L3でどうするか、というのは話がややこしくなるので一旦棚上げして、そもそもどうしたいんだっけ、というのは有益だと思います。

どういうオプションがありうるんでしょう？
●スケール
●行間を広げる
●他にありましたっけ？

私の記憶が正しければ、以前の議論ではスケールは論外に近かったような。ただ今回、スケール、という話が出ましたね。確か以前の話では
●今の技術ではフォントが汚くなる
●数字二桁で1.1em以下とかだったらスケールしない方が美しい
などだった気がしますが、字形維持の観点は別にすれば、スケールの汚さはRetinaでいいやん、という話も（笑

そうそう、一部の出版社から、三桁の縦中横は画像、という案も出ているようです。これはスケールを裏付けますよね。

[Yasuo Kida]

>> 今までの議論、縦中横の理想的な姿ではなくて、失敗したときのフォールバック方法の問題が主な
>> 対象になっていますよね。より良いフォールバックももちろん大切ですが、所詮レイアウトの意図
>> は既に失敗している訳です。負けたらどうするかではなくて、どうやったら勝つか。意図通りのレ
>> イアウトを達成するにはどうしたら良いか、そういう方向の議論をしてみるのは有益でしょうか？
>
> そうですね、L3でどうするか、というのは話がややこしくなるので一旦棚上げして、そもそもどうしたいんだっけ、というのは有益だと思います。
>
> どういうオプションがありうるんでしょう？
> ●スケール
> ●行間を広げる
> ●他にありましたっけ？

行間を広げるというのは既に敗戦処理ですよね。縦中横をある程度望ましい形で実現する技術的手段をリストしてみると：

a) 縦中横用のグリフがある
or
b) スケールする

くらいでしょうか。

例えばですが、a) で、縦中横用のグリフがある事を何らかの手段で確保する（例えば画像やエンベッド）、とか、b) でスケールすると決める、とか、そういう方向で考えられたら、負けたらどうしよう、を議論するよりも建設的ではないか、というわけです。

> 私の記憶が正しければ、以前の議論ではスケールは論外に近かったような。ただ今回、スケール、という話が出ましたね。確か以前の話では
> ●今の技術ではフォントが汚くなる
> ●数字二桁で1.1em以下とかだったらスケールしない方が美しい

まったくその通りですが、現在オプションとしてある、縦中横が失敗して解除されたり、行間が広がったり、文字が重なったり、と比べると百倍「まし」ですよね。そもそも、和文にイタリックは合成、ボールドも書体にボールドがなければ合成。それは OK でこれは論外という議論は一貫していないように思えます。

> などだった気がしますが、字形維持の観点は別にすれば、スケールの汚さはRetinaでいいやん、という話も（笑

まあデバイスも変わって行きますが、それよりも、単に縦中横用のグリフを積むのが良いかも。

> そうそう、一部の出版社から、三桁の縦中横は画像、という案も出ているようです。これはスケールを裏付けますよね。

そうですね。また、埋め込みフォントを書籍にバンドルするという方法もありますね。出版者さんはちゃんと「どう勝つか」を考えてるんですね。

木田

[Koji Ishii]

>> どういうオプションがありうるんでしょう？
>> ●スケール
>> ●行間を広げる
>> ●他にありましたっけ？
>
> 行間を広げるというのは既に敗戦処理ですよね。

意外に敗戦じゃないのかも、とも思います。過去の話と矛盾するようですが、行ピッチ維持は通常の書籍では常識ですが、漫画では崩して当たり前だし、3inchの画面で大事か、というと実は個人的には少し疑問です。だからrubyもautoにしたいよね、という話になったわけだし、万能ではないけど、敗戦でもないのかな、と。すみません、木田さんの本筋とは離れちゃいましたね、閑話休題。

> 縦中横をある程度望ましい形で実現する技術的手段をリストしてみると：
> a) 縦中横用のグリフがある
> or
> b) スケールする
>くらいでしょうか。
> 例えばですが、a) で、縦中横用のグリフがある事を何らかの手段で確保する
>（例えば画像やエンベッド）、とか
> b) でスケールすると決める、とか、そういう方向で考えられたら、
> 負けたらどうしよう、を議論するよりも建設的ではないか、というわけです。

賛成です。特に私としては、スケールはもともと支持派なので。

>> 私の記憶が正しければ、以前の議論ではスケールは論外に近かったような。
>>ただ今回、スケール、という話が出ましたね。確か以前の話では
>> ●今の技術ではフォントが汚くなる
>> ●数字二桁で1.1em以下とかだったらスケールしない方が美しい
>まったくその通りですが、現在オプションとしてある、縦中横が失敗して解除されたり、
>行間が広がったり、文字が重なったり、と比べると百倍「まし」ですよね。そもそも、
>和文にイタリックは合成、ボールドも書体にボールドがなければ合成。それは OK で
>これは論外という議論は一貫していないように思えます。

仕様が行ったり来たりしてたんで記憶と現仕様がずれてましたが、現仕様で
http://dev.w3.org/csswg/css3-writing-modes/#text-combine-mode0
「手法は問わないけど1emに入れる」が既定ですね。じゃ、これでいいのか。私がどっかで勘違いしてました。あとは実装の問題。

>> などだった気がしますが、字形維持の観点は別にすれば、スケールの汚さはRetinaでいいやん、という話も（笑
> まあデバイスも変わって行きますが、それよりも、単に縦中横用のグリフを積むのが良いかも。

二分・三分・四分グリフへの対応は実はplatformコードなので、今はMacしか動かない、という、ちょっとお恥ずかしい事情がありまして、大多数のRSではグリフがあっても溢れちゃうそうです。制作側の論理としては、デバイスごとにファイル作りたくないので、下の方に合わせざるを得ない、ということなので、せめてWinとQt Linux/Androidをやってくれる人を探さないといけないですね。

あと「#02」とか「'12」とかだと三分グリフがなかったりして、これはそもそもないので、グリフから作らないと埋め込みもできないけど、それは厳しい。ヒラギノとかそもそも三分はなかったような。バージョンによって違うのかな。フォント買えばあるなら埋め込めますけどね。

スケールの方が守備範囲が広いんで、まずスケールやっといて、品質が気になる部分だけ二分・三分のグリフを入れれば、という気がします。

>> そうそう、一部の出版社から、三桁の縦中横は画像、という案も出ているようです。これはスケールを裏付けますよね。
> そうですね。また、埋め込みフォントを書籍にバンドルするという方法もありますね。
> 出版者さんはちゃんと「どう勝つか」を考えてるんですね。

はい、そうですね。画像ってのは悲しいけれど、上記のように実装まで含めると少し道のり長そうなんで、出版社が画像でアリと言ってくれるなら、まずは進めそうです。

その次、というと、やっぱりスケールなのかな、と思います。

[Takayuki Akimoto]

まず、あらためまして、超簡単に自己紹介させて下さい。
秋元貴之と申します。

1984年頃～94年頃まで、写研電算写植システム向けの、
組版ソフトの開発をしていました（C言語/MS-DOS）。
実家は印刷会社（写植業）で、現在は電子辞書が専門です。
Adobe InDesign関係の経験も少しあります。

＞行間を広げるというのは既に敗戦処理ですよね。

木田さんの仰る、この「行間」とは、写研の用語で言い換えれば、
「行送り」のことですね。
※添付資料参照（今、倉庫から引っ張り出してきました）。

写研の場合、行送り量の指定方法は、「行間」と「行送り」の２つから、
選択できます。

「行間」の場合は、行と行の間のスペース量が常に一定に維持される
ので、部分的に大きなサイズのフォントを使用しても、文字が他の文字と
重なることはありません。
要するに、その部分だけ、行送り量が変わるのです。

いっぽう、「行送り」の場合は、行の中心から、次の行の中心までの
距離が常に一定となります。
この場合、大きな文字が使用されれば、この文字は前後の文字と重なる
可能性があります。要するに、行間量ではなく、行送り量が一定の量に
維持されるからです。

参照: http://tosiji-dreamafi.seesaa.net/article/118113959.html

「縦中横」も全く、同様です。

「行間」の場合は、縦中横対象の文字列がどれほど長くても、
前後の行（縦書きなら左右の行）と重なることはありません。
一方、「行送り」の場合は、重なってしまうケースもあります。

＞縦中横をある程度望ましい形で実現する技術的手段をリストしてみると：

＞a) 縦中横用のグリフがある
＞or
＞b) スケールする　くらいでしょうか。

私の経験上言えることは、組版の世界では、ある文字が他の文字に
意図していないのに重なってしまうという事態は、
なんとしても避けるべきことです。

私がこのような事態に直面した場合は、まず、第一に、
縦中横対象文字列の文字サイズを小さくして、
重ならないようにします（長体を掛けます）。

それでも、解決できない場合、部分的に行間を広げます。

行間を広げる、という選択も取れない場合は、
縦中横を別の表現に置き換えることになります。

文字と文字が重なる、ということは、非常事態であり、
組版の世界で通常、容認されることはないです。

部分的に、行送り量が変わってしまっても、行間が一定
に保たれていれば、美的にも、あまり問題にならないと思います。

秋元貴之

追伸：

＊写研の組版機の資料は、倉庫から何点か見つかりました。
縦中横についても、多少、書かれています。
２０年以上前のものですが、保存状態はかなり良かったので、
今、読みながら、思い出しているところです。

肝心の日本語組版のアルゴリズムに関係したソースコードは、
残念ながら、見つからなかったですが。

[Kobayashi Toshi]

　　　小林敏です

Yasuo Kida さん wrote

>
> >> 今までの議論、縦中横の理想的な姿ではなくて、失敗したときのフォールバック方法の問題が主な
> >> 対象になっていますよね。より良いフォールバックももちろん大切ですが、所詮レイアウトの意図
> >> は既に失敗している訳です。負けたらどうするかではなくて、どうやったら勝つか。意図通りのレ
> >> イアウトを達成するにはどうしたら良いか、そういう方向の議論をしてみるのは有益でしょうか？

編集側の立場の人間として，3つの段階に分けて考えることができ
ます．以下のことをまずは実現できればと考えています．

第1段階
アラビア数字の2桁のものを縦向きにして横に並べて表示してほし
い．

これにはルビが付くことは一般にない．というのは，数詞にはル
ビは付けない，とう考え方もあるからです．が，そうも言えないか
もしれない．圏点は，前のメールに書いたように翻訳で原文がイタ
リックの箇所を圏点で表示するので，要望があるかもしれない．
横幅は，全角になることが望ましが，使用するフォントによりわず
かにはみ出してもかまわない．無理して全角にする必要はない．た
だし，第2段階に書いたような例では，横幅を揃えたいケースがあ
る．

第2段階

アラビア数字の3桁を縦向きにして横に並べて表示してほしい．こ
の場合，できれば三分数字などで，幅を狭めることが望ましいケー
スがある．
この代表的な使用例は，注記の番号です．3桁以上の番号が付くよ
うな注記は，別途考えた方がよいだろうと，私は思います（そんな
に注記を付けるのはどうかと思うので，何か工夫した方がよい）．
しかし，3桁の注記の番号の本は，それなりに，というか，結構あ
ります．
合印として注記番号は，本文の行中に，文字サイズを小さくして掲
げる場合と，行間に配置する場合があります．後者の方が，より文
字サイズを小さくしています．
注記の行頭に付く3桁の数字は，合印の場合も含め，番号は，一般
に前後をパーレンでくくるので，横に並べた場合，その横幅は，パ
ーレンの横幅と揃え，全角が望ましい．このような使用例では，2
桁の場合でも，横幅は全角が望ましい．

第3段階

次は，欧字で，欧字1字にダッシュ，下付き，上付きなどが付く，
あるいは欧字2字といったケースで，縦向きにして横に並べたとき
に，横幅が全角以内か，全角よりやや大きい場合に，縦向きにして
横に並べて表示してほしい（欧字は，縦向きにして横に並べる必要
はない，という考え方もありますが，横に並べたいという要求は，
それなりにあるでしょう）．このケースでは，無理して横幅を全角
にすると，欧字の品質が損なわれるので，やらないでほしい．
このケースでは，ルビや圏点が付く例はほとんどないと思われる
が，皆無とはいえない．

[Koji Ishii]

ちょっと面白いサンプルを見つけたので共有。
https://dl.dropbox.com/u/8812114/tcy-scale-mf201111-79.png

同じ縦中横がルビとぶつかってスケールされてますが、ぶつかっていないところではされていません。

きっとほんとに欲しいのはこういうのなんでしょうけど、これはやり過ぎ、とは思います。

[Koyama Tadayoshi]

インフォシティの小山です。

ちょっとフォーカスが定まらない駄文になりそうですが、程常々考えていることを書きます。

（１）文字を画像として入れてしまう件について。

リーディングシステムが搭載するフォント等の問題を考えると、

出版社としては組み合わせ済みの文字を画像としてインラインで配置するというのは現実的な解法と思えます。

画像文字は縦中横に限らず、通常用意されていない文字を表示するために .book や青空文庫文書でも使われています。

で、ここからが本論なのですが、

そうして画像として配された文字がリンクになっていたり、傍点、ルビが必要なケースは容易に想像できるわけです。

小説で「ゴルゴ・13」で13が縦中横でかつ「サーテイーン」あるいは「じゆうそう」とルビが付くケース、

推理小説で「〜が起きたのは12月4日のことだった」で、「12月4日」に傍点が付くケース、など。

そういったことを考えると、縦中横に限らず、inlineのイメージだけれども文字装飾に関してはあたかも文字、

キャラクターであるように扱う、という指定ができれば便利だろうな、と感じています。

<img src="10.png" style="display: character;" alt="10" /> などとして。

（２） text-combine と span + writing-mode の使い分け

縦中横と呼ばれている文字の配置の仕方は、

(a) 合字、日本語縦組み用のリガチャとでも云うべきもの (text-combine 的なもの)と、

(b) キャプションの様に本当に横組になっているもの (span で writing-mode: horizontal-lr; 的なもの) 

の２種があると思います。

で、このどちらもが span+writing-mode で製作されてしまうと、将来 CSS で、どういった仕様になるかはわかりませんが、

きちんと前者の縦中横が使えるようになった場合にも、きちんとした表示にならなくなってしまう。

そういったことを考えると、span でいいから span を使いましょうという流れよりは、

行間は変わってしまうかもしれないなど制限がありかつ -epub-text-combine というような形であっても、

早い段階から(a), (b) の違いを何らかの方法で記述しておける方が望ましいと思います。

そうは言っても text-combine で行間が変わるのでは writing-mode と変わらないではないか、というご意見もあるようですが、

出版社の方が「行間が変わるのは受け入れられない」と仰るケースは、本来1/2幅や1/3幅のグリフで１行に収まるはずの

縦中横が、フォントの問題で行を広げてしまうケースに限られているはずです。

（長々と縦中横を指定してかつ１行に納めるというのはそもそも不可能とわかるはずですから）

そうであれば、幅的に収まらない場合は行間が広がります、嫌ならコンテンツにちゃんとしたフォントを埋め込んでください、

ということで良いのではないでしょうか？その程度のフォントであれば容易に用意できるでしょう。

ただし、傍点傍線リンク等が無いケースなら　text-combine など使わず幅の狭いフォントを指定して span で組めば良いのでは？

という反論にはうまい返しが見つかりません。これはセマンティックな話でしかない訳で、見た目は同じになるでしょうから。

（３）文字の重なりについて

縦中横に限らず line-height 0.5em などすれば文字は重なります（よね）。

CSS では行間ではなく line-height を指定するという基本路線をとっている以上、

ユーザスタイルシート等で重なるような指定をされたら重なってしまう、というのは、

避けられないので、議論しても仕方ない、無視しておくべきであろう、と。

（４）コンテンツを製作する側の視点ではどうなっているのか

text-combine が縦中横を勝手に解除してしまうという現状では、縦中横を使う場合に可能な事は、

① 埋め込みフォントで合字として埋め込む（コードポイントがデタラメで本来よくない）

② 幅の狭い字のフォントを埋め込み、span + writing-mode で記述する

③ 画像で埋め込む

④ 単に span + writing-mode で記述する

の４つでしょうか。

見栄えとしてはヒンティングも行われる ① が一番良く、②は同格、④ が最悪ということになるでしょう。

可用性と見栄えの両立を考えると②になるわけでしょうか。

個人的には、text-combine は勝手に解除される問題がある以上今の仕様では使われないだろうと思います。

上記の ②に期待される動作に、「１文字として扱うこと」「可能なら文字数に応じて hwid, twid や長体など使うこと」を

加えたものをtext-combine の仕様として出直した方がいいような気がします。