ブログトップ 記事一覧 ログイン 無料ブログ開設

ちくちく日記 このページをアンテナに追加 RSSフィード Twitter

2014-07-03

CSS3のルビ機能を考える

昨年来日し、CSS3の日本語組版について楽しいディスカッションを提供してくれたCSS3のエディターfantasaiさんが今年も来日されました。

去年、fantasaiさんを囲んでの食事会ということで居酒屋に集まって穏やかに親睦を深めるだけのつもりがfantasaiさんから「日本語縦中横の横幅はどうあるべきか」という楽しいお題がだされてしまった結果、集まった皆がfantasaiさんをほっぽらかして大激論をやる、という盛り上がりを見せてしまったため、今年は「それなら最初から議論するつもりで集まった方がいいんじゃないか」と主催の方が考えたのかどうかはわかりませんが、とにかく今年は「CSS3が開く日本語組版の未来」と銘打ち、会議室をかりての勉強会開催となりました。

告知が開催二日前という直前だったにも関わらず、なかなかに濃いメンツが顔を揃えたのはさすがというか。(参加者リスト



ここから当日話された内容についてレポートしますが、レポートは私の手書きメモをもとに書いています。録音からの書き起こしなどではないのと、fantasaiさんの話を聞いて「こういうことだろう」と推測したものも混ざっているので、細かい部分などは間違っている可能性があります。それとその場で話された話だけでなくその後の懇親会でさらに話をした内容なども含みます。


第一部 fantasaiさんからの提示

第一部はfantasaiさんから「現在CSS3で決めようとしている仕様」について。

【問題】

文章にルビをふる際に、親文字に対して長過ぎるルビ文字がきたときの組版処理はどうあるのが一番よいか


現在仕様をまとめているルビ処理についてfantasaiさんから「親文字が終わっても、ルビだけの行が次の行まで続くような処理を容認できるか?」という質問がありました。


f:id:akane_neko:20140703181225p:image

▲親文字が終わってもルビが次の行まで続く。つまりこういうことですな

CSS3で使われる場合、ページ幅というのが可変なので、たとえばスマホ画面のような狭い画面に親文字より長いルビ文字が来た場合、ルビ文字だけが改行するという処理になるかもしれないと。


f:id:akane_neko:20140703181226p:image

▲改行してルビだけの行が出来た状態。左はfantasaiさんがボードで説明した図、右は実際に組んでみたもの


しかし、この「ルビ行だけが改行する」って実際作ってみると奇妙だなぁ…。

あの場ではホワイトボードに手書きだったから「まぁそうするしかないかな」という感じだったんだけど、実際にルビ行だけが折り返す表示の奇妙さよ…!

まあ日本語組版においても、ラノベとかでやたら長いルビとかあるけど…。

CSSでの表示、この場合ルビだけの行ができてしまい、もしかしたら改ページしちゃう可能性もあるって事だよね…。

「デフォルトはルビの改行禁止にしてオプションで改行可という処理にする」という話もでてたのだけど、改行禁止の場合長過ぎるルビはどうなるのかはききそこねた。


さらにfantasaiさんは「ルビ機能は今後こういったケースにもつかうことが考えられる」として以下のような例をだしました。

f:id:akane_neko:20140703181224p:image

▲日本語の文章に対して、英語、フランス語の対訳をルビとしてふる。左はfantasaiさんがボードで説明した図、右は実際に組んでみたもの


ルビ機能は「単語に対してその読みを添える」機能というだけではなく「文章に対して追随する添え文機能」なので、こういった文章の対訳を併記するような使い方が考えられる。親文字に対して長文になることもあり得るし、ルビが1行ではなく2行、3行とつくこともあり。

この場合、通常のルビのように単語に対してその意味を対応させるというのが難しいので、どこで改行させるべきかという問題などがある。

会場からは「これはルビではなく注記といったものであると考えられるので、ルビのように単語と単語で対応させる必要はない。つまりそのまま肩付きにして流すしかない」という意見や「親文字がジャスティフィケーション指定されたとき、ルビの扱いと、ルビのつかない文字部分との扱いはどうあるべきか」といった議論がありました。

f:id:akane_neko:20140628121051j:image:w500

▲ジャスティフィケーショ処理でルビ部分と親文字部分、それ以外の部分をどうスペース処理するか


さらに「ルビが入ったときの行間のありかたはどうあるべきか」というような話題

上の行とルビの行間の間隔が均一だと、ルビが上の行についているのか下の行についてるのか判断しづらくなるので、上の行と下の行のルビ間はルビ親文字とルビ間より大きくなければならない。

f:id:akane_neko:20140628130713j:image:w500

▲親字のマージン設定を活かすべきかどうか?といった説明

マージン設定を活かすと上下左右のマージンと干渉するので、それよりもルビオフセットといったルビ下空きを指定するプロパティを作って、そこで設定するほうがよいか?という議論。

ルビオフセットというオプションを作った方が設定はすっきりするが、こんどはボーダーの指定と重なったときにどこからどこまでをルビオフセットと考えるかなど。



【感想】

CSS3の組版機能を考えるというのは「ありとあらゆる可能性に対して一番問題の出ないであろうデフォルト処理を考える」ということである。

例えば「ルビが長過ぎて行(またはページ)をまたいでしまいそう」といった場合、今までの紙の組版であれば「前後の文章(コンテンツ)を変更し調整する」といった処理でにげることができた。

しかしCSS3という「可変の文章を表示するためのルール」となると、コンテンツを変更して対応するといったことは不可能。となると、まず優先されるのは「とにかく読める事」である。まずコンテンツが欠落せずに表示できること、これが第一の優先事項。その次に読みやすさ、美しさがくる。

言い方は悪いけど「読めればいいじゃん」というのが最優先。

この中でどこまで今までの『美しい組版』が生き残っていけるか。というか必要なのか。

処理として必要とされるところまでは採用されるが、美しさのみを目的とするものは採用されないのではないか。

fantasaiさんの提案はどれも「まず読める事」を第一にしてよく考えられていたと思う。正直「ルビだけが改行する」という仕様は実際見ると変だなぁと感じるのだけど、じゃあどうすればいいかといっても対案を思いつけない。

さらに、このルールは日本語だけを対象にしたものではない。

日本語の処理をもとに搭載された機能であっても、規格となった時点ですべての言語でこれが使われると考えなければならない。「日本語ではそういう使い方はしない」というのは通用しないのである。

紙の組版に必要とされる美しさと電子の組版に必要とされる組版は違うのだから、CSSの規格としてはこれでいい、という考え方もあるけど、今後CSSを使って紙の組版を作る、という流れもある(電子書籍から印刷するとかね)と考えると、どういう規格になっていくのか興味深いところ。

残念ながらfantasaiさんはこの後予定があるということで、第一部のみの参加だったのだけど、fantasaiさんの考えるCSSの組版処理が聞けて、普段日本語組版だけを相手にしている私たちにとって大変示唆にとんだ時間となりました。



第二部 標準はどうやってつくられているか


後半はCSSのエディターである石井宏治氏や村上真雄氏)、この会の主催者である小形克宏氏による「W3Cの標準規格というのはどうやって決まるのか」といったテーマでのお話。


今CSSで日本語組版が取り込まれようとしている。これはインタナショナライゼーションというか国際化の流れ。

昔のCSSはラテン文字による横書きを前提としてた。だけど、Webという全地球的に使われるものの中で英語(ラテン文字)だけを前提とせず、色んな文字体系に対応していかなければならない。その流れのなかで日本語組版への対応がある。

CSSが目指しているのは「日本語組版」ではなく「多言語組版」。

今日もfantasaiさんは日本語組版の話はしていない。ルビの話でも、それが英語、フランス語でつかわれる場合の話をしている。

W3Cの規格というのはどういったものであるのか。W3Cの規格とは大きな物で言えばHTML、CSSといったあたり。

一番大事なのはW3Cは「実装」を前提とする規格だというところ。


W3Cの規格はどうやって決まるか

W3Cで規格として登録されるには、WD(草案)→LC(最終草案)→CR(勧告候補)→PR(勧告案)→REC(勧告)という手順をふむ

WD(草案)ここでどういった仕様にするかの草案をだして

LC(最終草案)CSSワーキンググループでその草案を議論して練る

CR(勧告候補)勧告候補になったら「実装の呼びかけ」が行われる

PR(勧告案)規格を実装したアプリケーションが複数あると認められれば勧告案へ

REC(勧告)規格として認定!


まず仕様はWD(草案)としてメーリングリストで議論される。ここはオープンな場なのでその気になれば誰でも参加できる。fantasaiさんは17歳でメーリングリストに参加して学生の内にエディターになった。

メーリングリストで叩かれ、練られた草案はCR(勧告候補)へ進み「実装の呼びかけ」が行われる。

CRの段階で「実装の呼びかけ」が行われるというのがW3Cの大きな特徴。実装が伴わなければ次の段階に進めない。提案された(HTMLなりCSSの)規格を実際に搭載したアプリケーションというのがなければ、実際の規格として認めるところにいかないということ。

CRの段階まで進んだ規格であっても、その後実装するアプリケーションがなければWDに差し戻されることもある。

実際、2003年MicrosoftがつくったCSSテキストの縦組標準はCRまでいきIEに実装したが、それ以外のアプリケーションで実装するものがなくWDに差し戻されている。(IEほどのブラウザが搭載したといってもそれだけでは認められない)

この「実装とともに進む」というのはものすごく時間のかかるやり方。他の標準規格でこういったやり方をやっているところはない。ここがW3Cの大きな特徴。

実装が認められる条件も厳しく「2種以上のアプリケーション」で「実装具合が問題ない(規格の条件を満たしている)」こと。

この「2種以上のアプリケーション」については、どんなマイナーなアプリケーションでも認められるわけではなく、ある程度規模が大きく、影響力(このブラウザが搭載すれば、他のブラウザも追随するといったような)が強くなければだめ。つまり、IE、Safari、Firefoxといったあたりが実装するような。

仕様と実装について、その仕様がちゃんと実装されているかどうかといったテストは誰がやるのか?というと、ボランティアでやるということになるのだけど、そういっても誰もやらないので、現実的にはブラウザベンダーが自社の開発のためにテストをかいて、それを寄付しているということになる。


W3Cの難しいところ

ISOやJISのようなデジュール標準(特定の機関で話合いの結果登録された規格)は、登録された規格に対して特許がとれる。対してW3Cはデファクト標準(多くの人が使っているという事実を基準として規格とする)なので、規格としてRECまで進むと特許の請求を破棄しなければならない。つまり企業にとっては苦労して規格を作っても直接の利益にはならない。

このため、W3Cはどうやってお金を回すかという問題が常につきまとっている。

W3Cで規格を通すには

・仕様を書く人(エディター)

・実装する人

・テストを行う人

が必要。これを全部もっているブラウザベンダーなどがやるのが一番話が早いのだけど、大手ブラウザベンダーなどは自社の利益に関係なければなかなかやってくれない。

特に問題なのは実装とテスト。ここをやるのにはお金がかかる。今やっているCSS Writing Modes、縦組などの実装も、諸々ひっくるめてやるのには3千万から5千万円ぐらいのお金が必要。


ブラウザとしてもレイアウトに関する部分というのはプライオリティが低い。レイアウトに手を入れるよりその分HTMLの読み込みが1%でも早くなった方がいいでしょという考え。

ブラウザの開発にテスターも含めて1チーム2-300人ぐらいいてもその中でレイアウトの部分をやっているのは7人ぐらい。縦書きというはブラウザの中でもかなり下の方のコードに手を入れなければならないので、大変な実装になる。実装をやってもらおうと思ったらその7人の中からこれが出来る人を押さえて確保しないといけない。


ユーザーに何ができるのか

ベンダーに機能を実装してもらおうと思ったら、ユーザーの要望が多いという事実をみせるしかない。

(影響力の大きそうな)ブラウザベンダーに「この機能いれてよ」と要望する。要望の数が多ければベンダーは実装する。



居酒屋談義(その後懇親会での雑談)

考え方として、こういったオープンな規格の策定というのに、積極的に関わって(お金をだして)規格が標準になった後で、それまで得たノウハウその他を自社の強みとして商売に活かすというのが最近の主流なんだけど、日本ではこういったことに対して積極的に投資しようという企業が少ない。

CSS Ruby Module、ルビ機能についても、ずっと支援してやってる会社があるのだけど、さすがに一社だけでやり続けるのは厳しい。

CSSの規格はEPUBなど電子書籍の表示にも使われる物なのだし、印刷会社や出版社のような組版に関連するところが出してくれるといいのだけど。



【感想】

こういった規格というのはなんとなく「どこか雲の上で決まっている」というように感じがちなのだけど、実際はかなり身近なところで決まっていて、参加しようと思えば誰でも参加できるということ、さらに「実装ありき」というかなり厳しい条件によってきまるのだという話。これはかなり面白かった。

「実装にはお金が必要」という話に生々しい具体的な金額も。うーん、なるほど雲の上とかいっても、規格を決める人だって霞を食って生きているわけではないのだ。

とりあえずWriting Modesその他の実装のために5千万円ぐらいだしてくれる企業を募集中のようです。

その後居酒屋での雑談のなかで「5千万ぐらいいるらしいです」「そのくらいの額でできるなら安いもんじゃないか」と頼もしい発言もでていたので、ぜひ期待したいところ。

実際CSSのこの辺の仕様は今後電子書籍の規格などに重要な部分なので、今のうちから資金を出して情報を蓄積しておくというのはいいのではないか。


でかい印刷事故一発だせばこのくらいの金額はいっちゃうと思えば、安いもんだよ!

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証