JAGATセミナー「電子書籍と日本語組版」
JAGAT テキスト&グラフィック研究会の「電子書籍と日本語組版『W3C技術ノート 日本語組版処理の要件』出版記念」セミナーにいってきました。
このセミナーは「W3C 技術ノート 日本語組版処理の要件（JLReq）」が書籍として出版されたことの記念セミナー。
まず前提として「W3C 日本語組版処理の要件（JLReq）」について。
これは「日本語組版の仕様」について解説し、WWWで利用される標準技術としてW3Cに登録されたものの事。W3Cに登録されているので、この全文はWebで読む事ができる。（http://www.w3.org/TR/jlreq/ja/）
全部（無料で）読む事ができるんだけど、今回改めて紙の書籍として出版された。「Webで読めばタダですが、紙にすると5,000円」である。
- 作者: W3C日本語組版タスクフォース
- 出版社/メーカー: 東京電機大学出版局
- 発売日: 2012/04/10
- メディア: 単行本（ソフトカバー）
- 購入: 1人 クリック: 7回
- この商品を含むブログ (3件) を見る
セミナータイトルは「電子書籍と日本語組版」だけど、がっつりと日本語組版について語る！というセミナーではなく、なんというか「出版おめでとう！お祝いセミナー」という感じで「W3C 日本語組版処理の要件（JLReq）」に様々な立場で関わっている人たちを呼んで、それぞれがJLReqへの関わりを語るというセミナーでした。がっつり！日本語組版！な話を期待した人にはちょっと残念だったかもしれない。
でも、なかなか面白い話がきけたし、最後には関係者のディスカッションなどもあったりして盛りだくさんだったので、レポート。例によって長いので、時間がない方は、最後らへんのまとめだけよんでくだされ。
「日本語組版処理の要件」とEPUB3前夜
トップバッターはイースト株式会社の高瀬 拓史氏。ろす氏（@lost_and_found）と言った方が通りが早いかもしれない。
EPUB日本語仕様策定などに関わっている方。EPUB日本語組版仕様の策定においてJLReqがどのような役割を果たしたか、について。
高瀬氏はEPUB仕様の日本語訳などをした関係で、JEPA（日本電子出版協会）のEPUB研究会に参加。2009年頃。この時点で日本語組版についての知識はほぼ皆無だったらしい。
EPUB研究会ではEPUBという規格の中で、縦書き、ルビ、禁則など日本語を扱うのに十分な機能があるかどうかを調査していた。（当然その当時のEPUBにはそういった機能はない）
そんな中、2010年1月27日 iPadの発表。同時にiBooks/iBooksStoreが発表。
このiPad発表によるインパクトは大きかった。EPUBの認知度が一気にあがり、高瀬氏の（EPUB情報を載せた）サイトのアクセスが、それまで一日数件だったところが、一気に3000件に増えた。
EPUB研究会ではEPUBに日本語を導入してもらうための文書を執筆することになる。当初はCSSのような独自スタイルシートなどによる言語の提案など技術使用を策定しようとしていたが、IDPF EPUB WGがEPUB仕様の改版を予定していることを知り（その要件にいれてもらうための）要求仕様の作成を行うことにした。
要求仕様は「日本語組版処理の要件（JLReq）」を参考にし、必要と思われる部分をピックアップした。日本語の組版用語がすでに英語で解説されていることで、日本語組版用語などを一から（英語で）定義、説明する必要がなかった。
組版仕様について「日本語組版処理の要件（JLReq）」をかなりの部分参照することで、短期間のうちにEPUBの要求仕様をまとめることができ、IDPFの「EPUB2.1 Working Group Charter」のドラフトに参照され、日本語を含む諸言語への対応が策定項目の一つとなった。
「日本語組版処理の要件（JLReq）」はEPUBの日本語対応において、重要な役割を果たした。特に、日本語組版の用語、解説がすでに英語で用意されており、仕様要求をつくる人間と、その要求を精査する側がそこを参照できるということが大きかった。
次に村田 真氏。IDPF EPUB WGのコーディーネーター。
EPUB3.0に日本語組版仕様が入るのに「日本語組版処理の要件（JLReq）」がどう関与したか、について。
EPUB3.0の日本語組版仕様策定にはいくつかマイルストーンがあるが、その一つがJEPAからの日本語組版の要求仕様がIDPFの「EPUB2.1 Working Group Charter」で取り上げられたこと。ここで取り上げられなければ、EPUBの日本語対応はなかった。
さらにもうひとつは、国際化サブグループで行った会議。EPUBの国際化について、日本、台湾、韓国、アメリカからの代表を札幌に招いて要求仕様をまとめる会議をおこなった。この会議で「何をやるのか、どこまでやるのか」を決定した。
この会議では「日本語組版処理の要件（JLReq）」は、様々な要求項目を整理する基準として働いた。
例えば台湾は、JLReqを精査し、JLReqの仕様で自国のニーズがほとんど満たされることがわかっていた。そのため会議ではJLReqにない部分（注印符号）のみに集中した。
JLReqにより、組版の言葉の定義ができていたので、議論がスムーズに進んだ。
JLReqにより、様々な分野が恩恵を受けるだろう。例えば、EPUB、CSS、XSL--FO、OOXML、ODFなど。また日本以外の国でも、台湾、香港、中国、内モンゴルなど。
韓国は現在JLReqを手本に自国の組版仕様を策定中である。
電子書籍関係のどの国内プロジェクトより、日本語話者にとっては重要ではないかと考えている。なぜなら、様々なプロジェクトや規格は今後なくなったり中止されたりする可能性があるが、JLReqは日本語がある限りなくなる事はないから。
JLReqの本質的な意義は、自分（日本語組版）を客観視して相対化したこと。客観視し相対化するということは、すなわち国際化するということである。
相対化されたそれを見て、他者（日本語組版を知らないもの）は違いを理解する事ができる。
次に、石井 宏治氏。CSS WGのエディター。
CSSの仕様に「日本語組版処理の要件（JLReq）」がどの程度組み込まれているかについて
JLReqは日本語を読めない人に日本語の組版仕様を説明する、という点でJLReqが果たした役割は大きかった。
JLReqの中で定義されている組版要件について、CSSやEPUBなどがどの程度カバーしているか、それぞれの対応度比較。
[縦書き]
| CSS | EPUB | Word | IE | Webkit | |
|---|---|---|---|---|---|
| 縦書き | WM3 | ○ | ○ | ○（2003） | ○（Windowsは△） |
| 文字の向き | WM3 | ○ | × | × | ○（Windowsは×） |
| 縦横混在 | WM3 | ○ | ○ | ○（2003） | ○ |
| 縦中横 | WM3 | ○ | ○ | × | △ |
| 自動縦中横 | WM3 | × | × | × | × |
[行組版]
| CSS | EPUB | Word | IE | Webkit | ||
|---|---|---|---|---|---|---|
| 禁則 | Text3 | ○ | ○ | ○ | △ | Webkitでは段階的禁則レベルの指定はできない |
| 両端揃え | Text3 | ○ | ○ | ○ | ○ | |
| 約物ツメ | Text4? | × | ○ | × | × | Text4へ先送りとなった |
| 和欧間アキ | Text4? | × | ○ | × | × | 当初四分空きを入れようとしたが、三分もいるなど声が上がりText3には間に合わず |
| ぶら下がり | Text3 | × | ○ | × | × | |
| 空白処理 | Text3 | × | N/A | × | × | |
| 欧文泣き別れ | Text3 | ○ | ○ | ○ | ○ | 実装すると禁則処理と競合する部分がでる |
| ベースライン揃え | Linebox | × | ○ | × | × | |
| 行長半端処理 | Linegrid? | × | ○ | × | ? |
[文字装飾]
| CSS | EPUB | Word | IE | Webkit | |
|---|---|---|---|---|---|
| 全角化 | Text3 | ○ | △ | × | × |
| ルビ大仮名 | Text3? | ○ | × | × | × |
| 下線 | Text3 | × | ○ | △ | △ |
| 取り消し線 | Text3 | × | ○ | × | × |
| 圏点 | Text3 | ○ | ○ | × | ○ |
全角化、ルビ大仮名などの機能はいれることによって、読み上げソフトなどでのアクセシビリティがあがる
[ルビ・行処理]
| CSS | EPUB | Word | IE | Webkit | ||
|---|---|---|---|---|---|---|
| ルビ | HTML5 | ○ | ○ | △ | ○ | |
| 二重ルビ | × | × | × | × | × | 日本でも必要ないとの声があり入らないかも |
| インライン表示 | × | × | × | × | × | ルビとして記述するがボックス囲みのインラインとして表示される |
| ルビ大仮名 | Text3? | ○ | × | × | × | |
| ルビ用グリフ | Fonts3 | × | × | × | × | フォントの中にルビ用の字母をもたせるか |
| ルビ揃え | Ruby3 | × | ○ | × | × | |
| ルビの行送り | Linebox? | × | ○ | △ | △ | 間にルビがあっても行送りを一定にする |
| 行グリッド | Linegrid? | × | ○ | △ | △ | |
| 行取り | Linegrid? | × | ○ | △ | △ |
ルビ用グリフ、ルビ揃え、ルビの行送り、行グリッド、行取りあたりの機能についてはまだ議論中であり、入らない可能性も高い
CSSの今後の課題としては、まず仕様を固め（Text Level3,Writing Modes Level3を)安定化し、使ってもらわないと話にならないので、実装をお願いする。さらに実装されたものを検証し、実装の差による違いを直し、相互運用性を確保する。
縦組みやルビなど日本語特有機能への取り組み。行揃えなどはまだまだ課題あり
より高度なレイアウト（Flexbox,Region ,Template）ページ組版（Paged Media,Page Float）等
ANTENNA HOUSE Formater V6による JLReqの自動組版
次に、アンテナハウス株式会社 石野 恵一郎氏。
「日本語組版処理の要件（JLReq）」を出版するにあたって、組版を行ったFormater V6のメーカーの方。
Formater V6はXML、CSSから組版を行える組版ソフトである。
書籍化はXHTML+CSS によって行ったそうで、その際の苦労話など。
書籍化するにあたっての苦労は、XHTML+CSSの組版といえど、Web用のXHTML+CSSと書籍で使うXHTML+CSSは同じという訳には行かず細かい調整や変更を行ったとの事
最後にモリサワ 小野 隆行氏
組版ソフトの中にJLreqがどの程度実装されているか、モリサワの実装例について説明。
モリサワで現在開発している組版システムとしては、紙出版用のシステム（MC-B2等）と電子書籍向けシステム（MC Book等）がある
それぞれがJLreqの仕様にどこまで添っているか
[日本語組版の基本]
| 紙出版 | 電子書籍 | |
|---|---|---|
| 日本語組版に使用する文字と配置の原則 | ○ | ○ |
| 日本語文書の基本となる組体裁 | ○ | ○ |
| 組方向（縦組と横組） | ○ | ○ |
| 基本版面の設計 | ○ | ○ |
| 基本版面の設計要素の各ページに対する適用 | ○ | ○ |
| 柱とノンブル | ○ | ○ |
細かな部分の差異はあるが、ほぼクリアしている
[組版性能]
| 紙出版 | 電子書籍 | |
|---|---|---|
| 約物などの組版処理 | ○ | ○ |
| 和欧文混植処理（縦中横含む） | ○ | ○ |
| ルビと圏点処理 | ○ | ○ |
| 割り注処理 | ○ | × |
| 段落整形、揃え及び段落末尾処理 | ○ | ○ |
| タブ処理 | × | × |
| その他の行組版処理 | × | ○ |
| 行の調整処理 | ○ | ○ |
| 文字クラスについて | ○ | ○ |
電子書籍での割注処理については、電子書籍において、文字を小さく表示する割注処理が必要か？という観点から搭載していない。
紙出版の処理でも未搭載の機能については（技術的に搭載できないのではなく）その処理が必要か？という考えから搭載していない。
[組版性能]
| 紙出版 | 電子書籍 | |
|---|---|---|
| 見出し処理（改ページ処理含む） | ○ | △ |
| 注の処理 | △ | △ |
| 図版の配置処理 | ○ | ○ |
| 表の処理 | △ | ○ |
| 行・段落などの行送り方向の配置処理 | ○ | ○ |
電子書籍での見出し処理については段抜き見出しには対応していない
電子書籍での注の処理についてはフローティングウィンドウという形で処理しているので、JLReqに添った注の処理ではない
モリサワの組版ソフトでは、必ずしもJLReqに添った仕様ではないところがある。
ただ、それは「実装できなかった」わけではなく「実装が必要ないと考えた、又は他の形で実装した」というもので、組版にこだわるモリサワらしいと感じる。
例えば、画像の下につくキャッチテキストなどで、電子書籍だと文字サイズが変わることによって表示できる文字数が変わってしまう。その時にその部分をどうやってみせるか、など、単純に組版仕様（JLReq）に添っていれば解決できるわけではない。
こういう変動する文字組版の見せ方というのはビューワー制作者がよく考えなければならない部分で、さすがにモリサワはそこをよく考えていると感じた（ちなみに文字数が増えたキャッチ部分について、モリサワは「スクロールをつけての表示」をみせていた）
JLReqは確かに日本語組版の仕様をまとめているけれど、すべてがそれに合わせなければならないわけではなく、合わせておけば100点というものではない。
特に電子書籍のように、デバイスによって表示が変わるものに対してどういう文字組版をすれば最適なのかは今後考えていかなければならないところ。
と、いうところで、前半終了。
ここから後半で、ディスカッションコーナー。
セッションを担当した各人に、小林龍生氏、小林敏氏を加えて（さらに途中で飛び入りもありの）ディスカッション。
[ディスカッション参加者]
高瀬 拓史（イースト株式会社）
小野 隆行（モリサワ）
小林 敏（日本エディタースクール 事務局長を経て、日本JIS X 4051の改正原案作成等に携わる）
石野 恵一郎（アンテナハウス株式会社）
小林 龍生（Unicode コンソーシアム ディレクター）
石井 宏治（CSS WG エディター）
村田 真（IDPF EPUB WG コーディーネーター）
ディスカッション
（あらかじめ書いておきますがこのディスカッションコーナーは私の手書きメモを元に再現したもので、当然書き漏らした部分もあるし、この通りの発言があったという保証はありません。こんな感じの話があったよ、という程度のものです）
――まず、皆さんの主張などコメントを一言ずつおねがいします。
高瀬「村田さんの発表にもあったが、自分の国の言語を客観化するというのはどういう事かという事を仕様策定をやるなかで実感しました。縦組みにするとこの文字はどうなるのか？とか、そういった日本人にとってはあたりまえの処理というのがきちんとルール化されていなかった。これを外の人（日本語を使わない人）に説明するそういった事をCSSなどで（ルール化した）これはターニングポイントだったと思う。JLreqの中には『体裁が良いように』という表現が何度もでてくるのだが、この『体裁が良い』という言葉は『ユーザーエクスペリエンス』という事なのではないかと思っています」
――
小野「自分は開発者で、あくまで決まった仕様を実装する、実装者の立場。なので、そういう主張とかコメントというのはないので…スキップさせていただきたい」
小林(龍)「じゃあ、質問させてもらおう。モリサワの組版ソフトのレンダリングエンジンあれはすごくいいと思うのだけど、あれを海外に売ろうという話はないの？」
小野「韓国とか、アジア圏ではあります」
小林(龍)「それはハングル用として？それとも日本語組版用として？」
小野「ハングル用として。MC Magagineのようなタップするとその部分がフローティングになって表示されるというあの処理がやりたいという話で」
（小林氏の質問の意図には、モリサワの文字組版エンジンがすごくよいものだからあれを売らないの？というようなニュアンスがあったように感じられたのだけど、小野氏の返答は単純に電子書籍システムとしての部分をうるという話になっているようだった）
――
小林(敏)「さっき（高瀬氏の）話にでた『体裁が良いという表現がJLreqに何度もでる』という部分だけど『体裁がよい』というのは自分の口癖で、それ以外に表現しようがない。誤読されない、読んでいて読みやすい、間違いがない、こういった言葉を『体裁が良い』という表現でひとまとめにしている。
『体裁が良い』というのは職人仕事で、経験の世界。これは学問にならないもので、経験してきた人間がJISの規格のようなものにまとめないといけない。（どこがどう体裁がいいのかというような部分を）このことに気がつきなさいと提示しないと見えない、気がつかない、（体裁が悪い組版の）何が問題なのか、という事を理解する事が必要。
本を読むにしても、その（体裁の）事を意識しながら読む、考えながらよむといった…常に組版を意識する事。電子書籍でもそれは同じ」
――
石野「自分も（小野さんと同じく）実装の人間なので…主張はスキップさせてください」
小林(龍)「（会場に来ているアンテナハウスの）小林社長に代わりに話してもらおうか？（笑）」
石野「それはちょっと…（笑）」
小林(龍)「では、Formater開発でタイ語版などをやってる、あの辺りの苦労話を」
石野「苦労と言っても…、まぁOpenTypeの仕様どおりに実装しておけばいいだろうと、そういう風に実装してます」
小林(龍)「それで売れた？」
（ここでアンテナハウス社長の小林 徳滋氏が会場から飛び入り）
小林(徳)「もちろんそのままでいいというものではないが、仕様がはっきりしていると、その言語を知らなくても実装できる。だから（JLReqがまとめられたことによって）たとえばインドの小さい会社の優秀な人が良い日本語組版ソフトウェアを作る可能性だってある。そういう風になると（今日本語ソフトを作ってる）モリサワさんだってあぶないですよ。お互いマーケットはひらけているのだから、われわれも外に出ていかなければだめ」
――
小林(龍)「日本語を知らない人がJLReqを読んでUTR50を書く、そんな時代がきている」
――
石井「自分は実装側の人間なので、ここに並んでいる（規格策定をやるような）皆様より、気が長いんです。たとえば自分はMSでWordの日本語化をやったが、海外のソフトで日本語が使えないけど良いソフトっていうのがたくさんある。こういったソフトで日本語が使えるようになるといいなと思ってやっている。Wordだって、日本語の縦書きはWordの6ではできなかった。それを実装するのにたくさんのフォントを集めて全部でテストして実装するのに5年かかった。そういう（長年かかって実装してきたという）事があるので、Webブラウザでの縦書きなんかもあと、10年ぐらいすれば縦書きもできるようになるだろうと思っている。自分は気が長いので。」
――
村田「Unicodeなんかね、今では標準だとかでいばってるけど、もともとXMLがUnicodeを使ったから広がったんだよ。JLReqだって私が採用したから広がったんだから、小林（龍）さんはもっと私に感謝をすべきだと思うね。」
――
（ここから会場からの質問を受けるコーナーに）
質問者「小形です。小林敏さんにJIS X4051について質問したい。JIS X4051はリフローには向いていない規格だと思うが、JLReqでは、行頭禁則などうまくまとめて、それをうまくリフロー向けに変えてあると思うが、JLReqに合わせて変えたところ、そのままにしたところなどをききたい」
小林（敏）「JIS X4051とJLReqの関係、基本的にはJIS X4051のままで変更はしていない。ただし、JIS X4051の改正でできなかった部分を変えたところはある。行末約物処理での文字クラスに従った空きの処理など。行頭禁則に付いてはJIS X4051内でも許容はされている。
JIS X4051は処理の方法しか書かれていない。読んでもわかりにくいところがある。JLReqではそれをもう少しわかりやすく、外国人に通じるように単純化と、あと図解した。日本語組版で一般的なのかどうかという所を統計というか雰囲気として、使用パターンとして書いた」
――
質問者「半角と全角の扱いについて。Unicodeだと半角全角というのは区別されないが、日本語では半角全角を使い分けていると思うが」
小林（敏）「それはそういう風に使い分けている例があるよ、というだけ」
石井「Unicode的には半角全角というのは区別はない。そもそも本来はレンダリングエンジンが（全角半角を）使い分けて表示するべきだが、それが追いつかないから文字コードで区別していた。いわば今が過渡期にある。そのうちレンダリングエンジンがやるようになるでしょう」
小林（龍）「（出版された）『日本語組版処理の要件』にはWeb版にないものが3つあって、まえがき、あとがき、索引。この3つはWeb版にはないんだけど、このあとがきのなかで、スティーブジェラスとの論争について書いてあるから読んで欲しいんだけど。ユニコードにおけるコンパチビリティについてだけど、全角という言葉にだまされてはいけない。文字の幅なんていうのはフォントがかってに表示していただけで、本来は組版エンジンが表示すべきもの。それができないから便宜的にフォントがやってるだけ。」
石井「Opentypeの機能として、特定の文字を半角化したり、全角化したりするというのがある。本来はそういった機能をつかい、半角文字を全角にすべきで、全角のコードポイントは使わない」
小林(徳)「全角半角はグリフの問題ですよ。グリフとコードは10年前ぐらいまで混同されていた。いまでは全角半角はコードポイントで区別されている」
――
質問者「藤原です。日本語組版の仕様がはっきりきまったJLReqは参考になるが、例えば欧文フォントなどでは、フォント自体にカーニングとか組版に必要な情報が入っている。日本語の組版もフォントに組版情報をもたせて、その情報をもとに組版をするようにはならないか」
石井「とくに欧米系の技術者なんかと話していると、そういう意見はよくある。技術的にもそういう方向はなくはないが、たとえば、既存の資産、いままでのフォントなどとの関わりはどうするのかとか、新しく（組版情報をもたせた）フォントを一から開発するそれだけのメリットがあるのかという問題があるとおもう。そもそも、フォントを作っている人たちは意外と組版については知りませんよ。フォントの機能だけで組版をしてよいのか、フォント開発者にそこまでの知識を求めるのかという問題があると思う」
小林（龍）「モリサワさん、これについては話したいでしょ」
小野「えー、まずフォントフォーマットを決めているところと、組版のアプリケーションを決めているところとは離れてるかなと。フォントを決めるときにどんな文字を入れるとか縦横のテーブルとかそういった意見は出しているけれども。そもそもフォントに組版までを決める情報を入れて欲しいというのは、どういう情報を入れる事を望んでいるんでしょう？」
質問者（藤原）「電子書籍のビューワーメーカーと書籍の表示について話していると『フォントが持つ情報どおりに表示している』（からあまり表示がよくない）とよくいわれるんです。だから、フォントにもっと組版の情報が入れば、よい表示ができるのではないかと」
小林（龍）「それはそのビューワーメーカーの人がサボってるんだよ（笑）」
石井「欧文のカーニング情報などはフォントメーカーが決める事でそれが文字組に関係するけど、でも例えば禁則情報などは前後の文字情報が関係するので、1文字に入れるのは無理でしょう」
石野「タイ語、アラビア語なんかはフォントの情報だけで組版できる。だけど、禁則やハイフネーション処理といった処理はフォントの情報だけでは無理」
小林(徳)「レイアウトにはレイヤーがあって、例えばアラビア文字なんかは1つの文字が4つの字形を持つ。先頭，行末などその文字がどこに来るかで字形が変わる。どの形をだすかというのは前後の文字で決まる。フォントだけの情報で決めるのは不可能」
質問者（藤原）「理由はわかりますが、希望としてはどんなアプリでも同じような組版を再現してほしい。そのためにはフォントに組版情報を持たせるのがいいかと」
小林(徳)「リコーなんかはスクリプトエンジンとフォントのセットを販売してるけどね」
石井「カーニングはフォントごとにテーブルが違うので、フォントの中にもつ必要があるけど、JLReqの様な組版情報はどこで使っても同じ情報で、それはフォント一つ一つに持たせるより、外に持たせる方が合理的ですよ」
――
質問者「MSの梶原です。日本語に関する標準規格をみると、ほとんどが、最初にでてきたところからどんどん膨らんでいってしまうのですが、JLReqについては最初から必要な要素がほとんど定義されていてすばらしいと思います。どうしてこんな事ができたのか、JLReqの策定がどのようなとこからスタートしたのか」
小林（龍）「それは全部あとがきに書いたので、ぜひ本を読んでほしいんだけど（笑）
2005年にUnicodeカンファレンスで、エリカ・フォンタサイというペルシャ系の女性がCSSの日本語を含めたマルチリンガルな環境の実現について報告していたんだけど、ルビについての仕様がはっきりしていなかった。その件について彼女に質問したんだけど、逆に彼女から質問されたことに自分が答えられなかった。日本人でありながら日本語組版について言語化できるほど理解できていなかった、それをなんとかしないとということで、そこから色んな人に声をかけてスタートした。
JLReqはRequirementsに徹した、というところがよかったのだと思う。CSS用でもEPUB用でもない、だから、どんなところでも使える。これが最大のポイントだったと思う。」
これでセミナーは終了。
【感想】
「日本語組版処理の要件（JLReq）」がW3Cに登録された事には、ふたつの大きな意味がある。
- 日本語組版を英語で解説したこと
- それを日本語組版の標準規格として登録したこと（http://www.w3.org/TR/jlreq/）
日本語組版の規格自体はそれまでもJISなどでまとめられていた。ただこれはあくまで日本国内の規格で、日本語を理解しない人がこれをつかうのは難しかった。JLReqとして英語にし、国際的な規格にしたことで、日本語を使わない人でも日本語組版を理解する事が可能になった。
ディスカッションの中でアンテナハウスの小林社長が「日本語をまったくしらない人でも日本語組版ソフトの開発が可能になる。それこそインドの会社からよい日本語組版ソフトがでてくるかもしれない」という発言をしていてそれがとても印象的だったのだけど、確かにそういう可能性は広がったと思う。
組版ソフトというより、電子書籍のビューワー、ブラウザーなど日本語を表示するものの開発など、日本語を使わない人でも日本語に対応した表示ブラウザーをいままでより簡単に作る事ができるだろう。
ただ、モリサワのセッションを見てもわかるけど、単純にJLReqに添っていれば100点の組版ができるわけではない。モリサワは自社の組版ソフトのなかで「どちらがよりよい組版になるか」を考えて実装しているように感じた。
JLReqはあくまでも今までの（紙の）組版の集大成だ。
とくに、電子書籍のように表示されるデバイスが様々で、リフローなど新しい表示型式をとるようになっている今「読みやすく美しい組版」というのもこれまでと違う形になるのかもしれない。新しい組版ルールは、作り手が常に「どうすれば体裁がよいのか」を考え続けているなかで生まれてくるのかもしれない。
