電子書籍の（なかなか）明けない夜明け

第12回　「意味による改行」をめぐる討論

リフローする電子書籍の組版を考える（4）

●「機械的な改行」と「意味による改行」

　シンポジウム「電子書籍の組版を考える」の報告、4回目は全体討議の模様をお届けする。今回も全体の中から行頭禁則や、行頭行末揃えにかかわる部分だけをピックアップする。なお、前回まで掲載前に発言者にレビューしてもらい、適宜原稿を修正していたが、今回からは発言の修正は用字用語など必要最小限にとどめ、補足が必要な場合はパネリスト自らに〔　〕で括り「○○補記：」の接頭辞を付けて書き入れてもらうことにした。その他、私が発言を補った部分は［　］で括り、中略は（…）で示すことにする。なお、修正前の原文は主催者のサイトを参照できる[*1]。

　さて、前回までの大きなトピックとして、意味による改行や行末不揃えをめぐる議論を紹介した。あらためて振り返ると、本間氏（第10回）は電子書籍ならではの組版として、意味のまとまり、つまり単語や文節、さらにはページまで禁則処理を拡張するというアイデアを打ち出した。ただし、行末の揃え／不揃えについて、この時は触れていない。
　また、村上氏（第11回）は電子デバイスにおいても、行頭行末揃えをはじめとした基本的な日本語組版ができることが前提とした上で、電子書籍ならではの組版の1つとして、リフローにも対応しやすくなる「意味による改行」を提案した。

　他方で、前田氏（第11回）は日本語表記の伝統から、行頭行末揃えは不変ではないが変化は緩やかな「基本ルール」の1つと位置付け、これを電子書籍でも守るべきと訴えた。全体討議の冒頭、マイクを握った前田氏が真っ先に取り上げたのがこの問題だった。

前田：私の、機械的な改行による行揃えという伝統を基本にすえるという主張と対照的に、意味による改行を問い直すということを、村上さんと本間さんがおっしゃったので、お二人に質問です〔前田補記：ここでの私の提起は、機械的な改行を保証する条件と意味による改行を保証する条件とについて討議し考えたかったのである。紙の組版での禁則処理自体、機械的改行の中で意味（読み）のかたまりをできるだけ連続させようという動機に由来し、機械的な改行と意味による改行とをどういう条件で折り合わせるかが問われていた。行長が変化するリフロー組版の中では、行末揃え vs 行末不揃えという対立ではないのである〕。

職業的に組版に携わってきた私としては、良い組版かどうかというのは、改行位置の発見に尽きます。しかし、読者にとってどうか。人が書物を発明して、なぜこんなに書物というのが生命力があるかと考えてみると分かるのですが、夢中になって読む時には、どこで改行するかというのは、意識しないと思うんですね。そこに機械的な折り返し改行のすごい力があると思うんです。同じ長さで、折り畳まれて。だから意識させないのが、良い組版だと思うのですが、どう思われますか？

　つまり、改行の方法として「機械的な改行」と「意味による改行」を対置させ、前者のメリットを説いた上で、「意味による改行」をする意味を問いかけた。これにまず村上氏が答える。

村上：はい、全くその通りだと思います。ま、ただし……行末を揃えない場合に、ギザギザになる改行であっても、機械的に意味の切れるところで、機械的に折り返すということもまた、意識しない読書を可能にするんじゃないかなと。例えばですね、（…）マンガの吹き出しの中は、読んでみると行末が揃ってないですね。（…）だいたい文節ごとに改行されていますね。（…）こういうことが、自動的にされた組版っていうのが、ひとつの今後の、機械的な、意識させない読み方を可能にする組版の方法の1つとして、確立していってもいいんじゃないかなと思います。

　続いて本間氏がマイクをとる。

本間：意識させないのが良い組版というのは、全く私も同じ意見です。先ほど、組版は「おもてなし」と言いましたが、「うちではこんなサービスしてやっているよ」とアピールするようなおもてなしと、（…）あとから「あれ、気付かなかったけど、あれは気遣いだったのかな、まさかな」と気付くような、さりげないおもてなしは違うわけで、私はその前者の押しつけがましいおもてなしよりも、後者の方がいいと思うんですね。

それで、いくつか意味による改行のアイデアが発表の中でありましたけども、私の中では、あれは必ずしもラグ組み［行末不揃え］にしようという趣旨ではなくて、切りやすい場所、意味に基づく分割点で切って改行して、行末揃えにするでもいいんです。（…）

〔本間補記：前提として、意味による改行位置調整は、さほど読者に意識させない形で、少ない調整量で実施できる場合に限り適用する優先度の低い禁則処理と考えている。1行の文字数がある程度確保できる場合であって、小説などの地の文の場合は、行末不揃えは明らかに読者に意識させてしまうが、同じ追い出し文字数であっても行頭行末揃えにする方が調整を読者に意識させずに済むだろう。〕

●自動組版で「意味による改行」は実現可能か？

　次に前田氏は、やはり「意味による改行」を主題にしつつも、少し方向を変えて質問を試みる。

前田：村上さんに質問なんですけども、紙の精緻な組版では、例えば縦組みで、全角どりの点と半角どりの点を組み方を分け、概数の点を半角どりにし、普通のいわゆる読点（テンなど）は全角どりにする。これは意味による違いですよね。

　これは解説が必要かもしれない。組版ルールの多くは、下図のように、概数（およその数）を表す読点は半角どり（読点とそれに続くアキを、合わせて半角＝漢字1文字の半分）にする。その他にも、前田氏は触れなかったが漢数字で実数を表記する際、位取りに使う読点も半角どりにすることが多い。その一方で一般的な使い方の読点では、全角どり（同様に全角＝漢字1文字分にすること）が基本となる（図1）。ところがこの概数の読点と一般的な読点は外見だけでは区別できず、検索置換等の自動処理ができない。じつはこれ、DTPの世界ではよくぶつかる問題なのである[*2]。

図1　漢数字における概数・位取りの読点と通常の読点におけるアキの違い

　前田氏の質問は続く。

前田：で、組版の自動化っていった場合は、意味に介入しないで、形でやるのが自動化だと私は思うんです。つまり、意味に介入して、作者にこれはどういう意味ですかと、いうふうに聞かないと分からないようなものは、自動化はほぼ不可能である。例えば、ある人が縦組みだったら数字と数字、漢数字と漢数字の間を半角取りにすればいいんだよ、とかね、そういう安直なことをいうけど、それは意味によって違うわけです。そうすると意味に介入しないと自動化できない。それは矛盾じゃないでしょうか。

　つまり読点のように「意味」以外に違いがない用法が存在する以上、自動組版はできなくなるのではないかという指摘だ。これに村上氏はどのように答えるか。

村上：はい、私も読点を、意味によって半角［どり］にしたり、全角［どり］にしたりしなければならない、それが組版を自動化するのに問題があるということは、非常に問題だと感じていました。例えばDTPソフトのInDesignなんかでは、漢数字の間に点を打つと、自動的に［デフォルトで］半角［どり］になってしまうんですね。でも半角［どり］になって意味的におかしいところでも、そうなってしまう。それを防ぐ手段は（…）確立されていないということが、私は問題かなと思っています。例えばですね、一応今のUnicodeでも、（…）半角幅の点［U+FF64］というのがありますよね。例えば（…）半角幅の点と全角幅の点を、ちゃんと原稿段階で使い分けるようにしてくれれば、その問題はなくなると思うんですね。でも、残念ながら今の組版ソフトで、縦書きで半角幅の点を打ったりすると悲惨なことになってしまって大変なんですが、今後そういう使用方法が確立されて、それに対応したルールなどができればいいんじゃないかなと、私としては思っています。〔村上補記：Unicodeの半角読点［U+FF64］というのは、半角カナと同じく通常は使うべきものでありません。原稿段階で区別するために、それが使えたらというアイデアを示したのですが、別な記号を使うなどもっとよい方法があってよいと思います。〕

　つまり半角どりの読点にすべきところを、筆者になんらかの形で指定してもらえばいいのではという提案だ。この時は前田氏からの答えはなかったのだが、じつは後半でこの問題への返答とも思える意見が述べられていた。以下の部分だ。

前田：（…）電算写植の初期は英語の辞書は弱かったので、和文の時はきれいに組めるけど、和欧混植の時だけ［字間が］パラついちゃう、ハイフネーションがきれいでない、ていうんで、［写研の電算写植］SAPCOLは「予約ハイフネーション」というファンクションを発明して、ユーザーに決めてくれと［いうことにした］。その当時はそれでしか［仕方が］なかったと思うんですけども、誰がやるか。それは、ワークフローの問題として、今もやっぱり問われていると思うんですね。（…）それを組版ソフトの側、ビューアーの側がハイフネーション辞書を持つのか、あるいは全部ユーザー［コンテンツ作成者］が責任を負うか。私はユーザーが予約ハイフンみたいな形で負うというのは、たぶんしんどいだろうなあ、いうふうに考えています。

また、文章書く人は、書き手は、そういうことは予想しないで書きます。テキストを書くというのは、組んだ時の情報を持たない、素のテキストですから、改行予測はしません。もちろん、URLみたいな長いやつは、どこで切っていいかというのは新しいルールが出てますけども、やっぱりワークフローの問題としてしか解決できないと思っています。

　これは会場からの質問〈電子書籍になった場合には、リーダーの開発、設計をする人間と、コンテンツの設計をする人間と分かれると思うんですけど、その際、責任ですとか、分担は今後どうなっていくとお考えでしょうか。〉に答えたもの。読んで分かるとおり、前田氏は質問にはなかった筆者の役割（原稿段階での書き分け）も含めて話している。

　それはともかく、両者とも現状ではこの問題は自動組版の技術だけでは解決不能とする点では一致している。この問題は、自動組版がアプリケーションだけでできるものでなく、データを読み込ませるまでの過程（誰が、どのようにデータ／コンテンツを作成するのか）にも注意を払うべきということを示しているのかもしれない。

　とはいえ、ここでの議論は「意味による改行」を実現するための必要条件ではあっても、より本質に立ち入った議論につながるものではない。この点、少し物足りなさを感じるが、まだまだ討議は続く。

●行長と連動した禁則文字の変化

　話を戻そう。今度は前田氏が質問される番だ。

本間：前田さんに質問なんですけども、（…）電子書籍でリフローをユーザー自身が行った時に、文字サイズを大きくして新聞くらいまで1行の文字数が減ってしまって、それで強い禁則を行うと組版結果がひどいことになるというのはあると思うんですよね。ただ、文字が小さい時には、普通の文庫本並みの1行の文字数が確保できるわけで、字詰めに応じて禁則ルールが自動的に変われば、例えば文字が小さくて字詰めが多い時には強い禁則で表示し、文字が大きくなって字詰めが少なくなると表示も弱い禁則に変化するという形で対応できるんではないかと思うんですけども、行長の長い時でも、新聞のような弱い禁則であるべきでしょうか？

　要約すると、リフローでも適切な組版結果が得られるよう、行長の変化と連動して禁則文字の対象も変えればよいのでは、という質問だ。なお、「強い禁則／弱い禁則」とは組版ソフトInDesign（アドビシステムズ）でも使われている用語で、長音記号や小書きの仮名等を含めるものが前者、含めないものが後者だ。これに前田氏はどう答えたか。

前田：日本の電子出版の先駆である、ボイジャーの萩野さんが、リフロー型では、いわゆる旧来の組版ルールに依拠するのは間違い、とまで言っていることを真剣に捉えるならば、少なくともデフォルトは弱い禁則であるのは明らかです。本間さんが提案されたように、例えば行長が8文字以下なら、8文字以下は組まない［行長を9文字以上とする］とか、組むけども一切禁則しない、それ越えて20字くらいまでは、新聞型の弱い禁則。それ越えると、ちょっとずつ禁則を強めていく。そういう形でいいんですね。

なぜそういうことを言うかというと、他のことに先に力を注いでいるがために、行末揃えが疎かになっていることを、私は専ら批判したい。だから行長によって、禁則の仕様が変わるプログラムができるんであれば、面白そうだし、協力もしたい〔前田補記：意味による改行が即、行末不揃えに直結するかの誤解があるので正しておきたい。意味による改行を行末不揃い組版（ラグ組み）によって実現できるのは、パソコンや少なくともタブレット以上の大きさが前提になるだろう。スマートフォンや携帯ではかなり難しく、画面での折り返しと意味改行とで逆に読みにくくなる可能性が著しく増えることは覚悟しなければならない。当日私が配布した資料「組版とは本来、動的なものである」（http://moji.gr.jp/gakkou/kouza/ebook-typo/files/kumihanwadouteki3.pdf）の中で「版面、文字サイズ、行長（字詰）は判型のなかで動的に決定される」と強調したのはこのことである。意味による改行は機械的な改行に対比されるものであって、必ずしも行末揃えの対比物ではないのである。〕[*3]。

　このように前田氏は、長音記号や小書きの仮名等を行頭禁則としないことをデフォルトとした上で、具体的な行長の字数に応じた禁則処理の方法を説明した。なお、付言すると前回追記で村上氏が述べているとおり、現行『CSS3 Text』2012-01-19版ドラフトのline-breakプロパティのデフォルト値「auto」では、行長に応じて禁則の範囲を変える振る舞いを「してもよい」（may）と規定している[*4]。

●ボイジャーはどのような日本語組版をしているか

　さて、ここで前田氏が持ち出した話題について少し深掘りしてみたい。彼が触れたボイジャー萩野氏のインタビューを以下に引用する。

――縦書きの仕様はどう決めたのですか。

内部で決めましたが、出版社にもヒアリングはしました。基本的にはHTMLベースで、そこに特殊なタグを使っています。（…）

――特殊なタグとは、論理的な見出しを記すためのタグとか？

見出しや改ページのような決まりきったことはいいのですが、［出版社による］組版上の要求が特殊なものとして残っている。字下げとか、漢文のレ点返り点とか、本当のことを言うと電子的なものには合わない。なぜならリフローするから。文字を大きくしたり版面を規定しないというのが電子出版。作り手がどう思っても、ユーザーレベルで変えられるわけです。だから、［出版社が求めるように］組版ルールに依拠するのは間違いということは最初から分かっていました。とはいえ、それを言っては元も子もない。（…）（『OnDeck』2011年2月3日号　日本初の電子出版社ボイジャーの創設者に、その軌跡と本質を聞く（前編））[*5]

　このインタビューに関連して、前田氏は全体討議の後半で次のような発言をしている。

前田：さっき日本の電子出版の先駆、ボイジャーのお話をしました。何も調整をしないかのように見せて、じつは一番、抜きんでて良いのがボイジャーのT-Timeとazurだと、私は思っています。それは、天地がキチッと揃っているからです。どういうロジックになっているかは、ご覧になってください。

　では実際にazurの画面を確認してみよう（図2-1、2-2）。

図2-1　ボイジャーによる電子書籍リーダーazurの画面。赤線は筆者が付加したもの（以下同）。なるべく行頭行末揃えが維持されるような組版ルールが実装されていることが分かる[*6]。なお、設定は組み方向も含め全てデフォルトのまま

図2-2　参考までに、こちらは図2-1と同じ画面で、1文字ずつ等幅に赤線を入れたもの。行頭行末揃えを実現するためには、字送り均等が有効であることが分かる。ちなみに、データとしては最後から2行目の「％」は半角（U+0025）なのだが、azurは自動的に全角の文字（U+FF05）に置換している

　続けて前田氏は電子雑誌における実例を挙げた。

前田：で、もう1つ例があります。日本のEPUBなり、Kindleの、雑誌の先駆、インプレスから出ている『OnDeck』があります。去年［2010年］から出ています。EPUB版と、Kindle版と、PDF版があって、全部無料だったんですけど、つい先頃からPDF版だけ有料で、紙でも出ています[*7]。そこで重要なことを見て欲しいのは、専ら画面で見るEPUB版とKindle版では、欧字が和字として扱われているわけです。つまりパラついてカッコ悪いということを、これは読者に言われるまでもなく作る人達は思ったのでしょうけども、キチッと揃えたい、左右揃えたい、あたかも新聞なのに、ハイフンも何もなしで「DOOK」を「DO（改行）OK」とするようにやっているわけです。

●なぜ『OnDeck』は全角欧数字を使うのか

　これはキーになる指摘。ここで前田氏が言った「欧字が和字として扱われている」とは何か？　実際にEPUB版『OnDeck』の画面を見てもらおう（図3-1、3-2）。

図3-1　欧数字も全角どりにしているEPUB版『OnDeck』（2012年3月15日号）。リーダーはCopperReader ver.0.3.2（Android用）[*8]。全角欧数字（赤点線）を使うことで語の途中でも改行できるようになっている。ただしコンテンツがそのように記述しても、リーダーが「強い禁則」や句点（マルなど）の追出しを実装していれば、行頭行末揃えは崩れてしまう

図3-2　同じOnDeckの同じページをiBooks（ver. 2.1.1／iPad用 iOS 4.3）で表示させてみた。リーダーが変わっても行頭行末揃えはほぼ維持されている。不揃えになっているのは、前図と同様に句点が追出しになった個所だ

　つまり、全角の欧数字を使うことが「和字として扱う」ということなのだ。ここでのポイントは、世の中に流通するフォントの大多数において、半角の欧数字はプロポーショナル（文字ごとに字幅が違う）なのに対し、全角欧数字は等幅（字幅が均等）という点だ。加えて、前田氏が指摘するように大半のアプリは半角欧数字からなる語の途中では改行を許さないが、全角欧数字であれば許す[*9]。OnDeckはこうした実装状況を逆手にとった。あえて全角欧数字を使うことによって、等幅による読みづらさと引き換えに行頭行末揃えが実現しやすい誌面を実現させたわけだ（追記参照）。

　そこで気になるのは、欧数字の全角／半角によってどのくらい組版結果が異なるかだ。図3-1にある全角欧数字を、半角に全置換してみた（図4-1、4-2）。図3-1では行末がほぼ揃っていたが、置換後はガタガタになってしまった。逆に言えば、全角の欧数字を使うからこそ、行末が一直線に揃う確率が高いことが分かるだろう。

図4-1　図3-1と同じページを半角欧数字に置換し、同じCopperReaderで読み込んでみた。赤線の間隔は図3-1と同じ（この項、追記参照）

図4-2　参考まで、前図と同じ画面に1文字ずつ等幅に赤線を入れたもの。既定の行長どおり折り返している行は、赤線に1文字ずつ収まっている。半角の欧数字（青の点線）が、どのように半端な行長を作り出すか確認してほしい。ちなみにこのリーダーは、仮名や漢字についてもぶら下がりと似た振る舞いを許しているようだ

前田：しかし、PDF版では、そういう和字扱いの欧字ではなく［本来の］欧字として（…）指定しているわけです（図5）。だから、キチッとカッコ良く見えるわけです。そうなるまでに、どんだけ、いろんな試行錯誤があったのかっていうことを、私は想像するにつけ、やっぱりこれが、現時点では一番良いんだろうなあと思います。だから、EPUB版とKindle版で、和字扱いまでして行末揃えをなぜしたのか、それが他のと、どう優劣があるのか、行長の短さも含めてですね、考えてみていただけたらと思います。（…）

図5　前図と同じ記事のPDF版。欧数字は全角どりになっていないが字間を細かく調整することで行頭行末揃えが維持されている。これは一般的な出版物の組版ルールだ

　前田氏の言うように、確かに全角欧数字を使えば行頭行末揃えを実現しやすくなる。しかし問題点が多いのも確かだ。まず前述のとおり等幅ゆえに読みづらい。また、全角・半角の違いはあくまでフォントの実装に依存した違いにすぎない。例えばMS Pゴシック（マイクロソフト）のように全角でもプロポーショナルに設定されたフォントを使うと、行頭行末揃えにならなくなる（図6）。つまり、うまく行頭行末揃えになるかどうかはフォントまかせなのだ。

図6　上は前図と同じEPUB版『OnDeck』（2012年3月15日号）を、全角文字が等幅に設定されていないMS Pゴシックで表示させたもの。下は同じページを全角を等幅に設定しているMSゴシックで表示させたもの。下の方はほぼ字送り均等・行頭行末揃えになっているが、上はなっていない。なお、リーダーは「Murasaki」[*10]

　さらに全角・半角の区別は、シフトJISという時代遅れの符号化方法が作り出したものだ[*11]。だから全角にできる欧数字はシフトJISの範囲内に限定される。それ以外は全角・半角という概念そのものが存在しない。だからそうした文字を使った場合、全角の文字と見た目が揃わなくなってしまう。

　例えば全角の「％」が使えるからといって、うっかりシフトJIS外であることに気付かずに10000分の1を表すパーミリアド記号も一緒に使うと、「％」は等幅なのにパーミリアド記号はプロポーショナルになって外見が揃わなくなる。もっとも、シフトJISに収録されている欧数字はすべて全角があると思ったら大間違いだ。例えば1000分の1を表すパーミル記号「‰」はシフトJISで符号化可能（0x81F1）だが、半角・全角の概念はなく、等幅かプロポーショナルかはフォントに依存する[*12]。

　とはいえ、インプレスを版元とするOnDeck編集部が、こうしたデメリットを知らないはずはない。彼等はメリットとデメリットを天秤にかけて全角欧数字を選択したのだろう。その理由は行頭行末揃えをなるべく維持することで、多様なリーダー、多様な画面サイズで最大公約数の読みやすさが確保できるからではないか。前田氏の発言「どんだけ、いろんな試行錯誤があったのか」も、こうしたことを指すように思える。

※追記：この部分の執筆後、『OnDeck weekly』2012年6月7日号からのリニューアルにともない、全角欧数字は使用せず半角欧数字を使用する方針に変更された。以下、同号掲載の「リニューアルのお知らせ」を引用する。

〈（…）本号より、創刊以来続けてきました英数字の全角表記を半角表記に切り替えます。
　英数字を全角で表記していたのは、創刊当時のiBooksの表現能力にあわせたためでした。当時のiBooksで英数字を半角で表記したEPUBを表示すると、両端揃えが正しく行われないばかりか、半角空白部分が不自然なほどに開いて表示されるという問題があり、それを解決する方法としてすべての英数字を全角文字で表記してきました。
　現在公開されているiBooksでは両端揃えも正しく処理され、それに伴い半角空白の扱いも自然なものとなっています。また、iBooks以外のEPUBビューワにおいても概ね問題なく表示されることを確認しています。〉

　じつは、このこの部分を執筆した時点で、手元のiPadはiOS 4.3のままだった。iBooksで図4-1の半角欧数字に置換した『OnDeck』（2012年3月15日号）を表示させても行末は揃わないことを確認していた。

図7　iBooks（ver. 2.1.1／iPad用 iOS 4.3）で半角欧数字に置換したEPUB版『OnDeck』（2012年3月15日号）を表示

　ところが5.1にバージョンアップした上で、あらためて試して見ると、『OnDeck weekly』が書くとおり、iBooksで行頭行末揃えがサポートされていた。

図8　iBooks（ver. 2.1.1／iPad用 iOS 5.1）で前掲『OnDeck』を表示。ほぼ行末が揃っていることが確認できる

　EPUBリーダーは確実に進化しつつある。グズグズと時間をかけて書いているうちに、この原稿自体が古くなり始めているようだ。お恥ずかしい話で、読者のミスリーディングを誘わないように追記しておく。

　それから、前掲「お知らせ」によれば、今まで全角欧数字を使用してきたのは、私が書いたように多種多様なリーダーへの対応を狙ったものというより、〈創刊当時のiBooksの表現能力にあわせたため〉、つまり特定のリーダーへの最適化が目的であり、この点買いかぶりすぎていたようだ。

●禁則の範囲と行頭行末揃えの関係

　少し寄り道がすぎた。話を戻そう。やがて本間氏が、言葉を選びながら次のような質問を前田氏に投げかけた。

本間：禁則するかしないか、どこまで禁則するかというよりは、行末揃えするかしないかという問題である側面がある気がして、（…）前田さんのお考えも、優先順位としては禁則という問題よりも、行末を揃えることの方が大事と、そういうふうに考えてよろしいですか。

　これは、ここまで語られてきた「行頭行末揃え／行末不揃え」という対比が、どういう意味を持つのかを聞くものだ。これに対する前田氏の答えは次のとおり。

前田：ルールというのは、とりあえず頭の中にあるけども、仕事によって変えるわけです。文章によって違うわけです。（…）ルールをあらかじめ完成されたものとして、手元にあるっていう考え方は良くないと思います。まずそれを捨てる。ルールは作るんです。もちろん経験の中から学んだものがあってのことですよ。

例えば1行35字詰めの書籍の組版とします。人間の目は、35字くらいの行長だと、字間が拡がっても、気が付かない。しかし詰まることの方が気が付きやすいです。ま、ちょっと詰まってるなと、いうことは、別に組版をやってる人じゃなくても、気が付きます。だから35字詰めだったら、33.5字を35字に引っぱって伸ばすということ、及び35.5字を35字に縮めること、つまりプラスの方を少なく、マイナス、拡げる方を多く、比較的ですね、こういうふうに設定して組んでみて、ルールを再構成する。それでここまでなら禁則をやっていいんじゃないかとか「ゃゅょっ」の行頭を許容していいんじゃないかとか。ルールの運用というのは、そういうものだ、と私は思います。

　これは本間氏の質問に対する直接の答えにはなっていない。むしろ答を考えるための方法を述べているように聞こえる。その意味で、少し禅問答めいている。この回答自体は以下の文章を読むと理解しやすいかもしれない。10年以上も前のもので、組版の考え方もいくらか変わっているようだが、根底は古びていない。

◆前田年昭『破綻しないルールは役に立たない能書きだ！』1999年4月18日
http://www.linelabo.com/kumi9904.htm

　詳細は全文をお読みいただきたいが、前田氏はこの中で〈《ルールは立てたとたんに破綻が約束されている！》――そう最初から割り切って自覚すること〉、〈破綻を恐れず最初から一貫してどういうルールかというのを考え抜く、なぜこうするのかということを考えて理屈を立てる、立て続けるというのがルールであるべきじゃないか〉と提言している。そうした覚悟を固めた上で、上に示されたような具体的なアプローチを繰り返し、ルールを決めていく、そういうことを伝えたかったのではと思える。

●次回に向けて

　以上をもって、シンポジウム「電子書籍の組版を考える」の報告を終える。今回の全体討議では、パネリスト同士の会話がうまく噛み合わなかったと思われる個所も、内容が興味深ければ取り上げさせていただいている。原稿の構成上、私が偉そうな解説を入れているが、会場で瞬時に応答しなければならないパネリストに比べれば、いくらでも時間をかけられる私の講釈などは後知恵にすぎない。この点、パネリスト諸氏には失礼を深くお詫びしたいと思う。

　さて、長い長いシリーズとなってしまったが、次回は締め括りとして、リフローに適した電子書籍の組版について、私なりの考えを示したい。まず、村上氏が提起した「意味による改行」を考えるところから始めたい。じつを言うと、この「意味による改行」は、既に多くの人が目にしている、あるウェブサイトでの先行事例がある。これを掘り下げるところから始めてみたい。では次回をお楽しみに。

●注釈

[*1]……文字の学校シンポジウム「全体討議」（http://moji.gr.jp/gakkou/kouza/ebook-typo/tougi.html）

[*2]……例えば『組む。InDesignでつくる、美しい文字組版』（2010年、ミルキィ・イソベ、紺野慎一、ビー・エヌ・エヌ新社）のPart2「「連数字処理」をオフにする」（P.112～P.113）を参照。

[*3]……この前田氏の「意味による改行と機械的な改行」の対比について、補足資料として、日本語の文字と組版を考える会による1999年の『第17回セミナー「組版が立ち現れるまでに」報告集』（http://www.pot.co.jp/moji/se17report.html）を挙げておこう。パネリストは鈴木一誌、向井裕一、そして前田年昭の各氏。こうした考え方が、どのように成立したものなのか、順を追って知ることができる。

[*4]……“CSS Text Level 3” W3C Working Draft, 2012-01-19（http://www.w3.org/TR/css3-text/#line-break）

[*5]……『OnDeck』2011年2月3日号、聞き手・井芹昌信、text・柏木恵子、インプレス（http://lite.twepub.jp/book/20yhfoas8urp?page=Text/interview_hagino_110201.xhtml）

[*6]……なお、ここで使用したサンプルデータは以下の通り。

◆XHTMLファイル
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<title>CSS組版 test_5.xhtml</title>
<link rel="stylesheet" href="./test4.css" type="text/css" />
</head>
<body>

　紙の書籍にない電子書籍のメリットは……？　――そう聞かれ嬉々として「リフロ～！」と答える人も多いだろう。これは画面表示の方法の一つで“動的レイアウト”とも呼ばれる。旧来の書籍はページごとの行数や1行ごとの字詰めなどが固定されていた（これをfixed layout 〈フィックスド・レイアウト 〉 と呼ぶ）。それに対してリフローに対応した電子書籍は、画面のサイズが変わるのに従って行数・字詰めが動的に変化、ジャスティファイしてくれる。これにより特定の環境――デバイス／アプリケーションに依存しない読書が可能になる。‥‥これが実現されてこそ１００%の電子書籍と言う声は根強い。

</body>
</html>

◆test4.css
@charset "UTF-8";
body {
   font-family:"@IPAMincho","IPAMincho";
   font-size: 200%;
   line-height: 175%;
   letter-spacing: 0px;
   text-align: justify
margin: 3em 3em 3em;
}

[*7]……このシンポジウムの直後、2011年8月より『OnDeck』は月3回の『OnDeck weekly』（EPUB版）と、これを月1回まとめて発行する『OnDeck monthly』（PDF版）に再編、前者を登録会員に無償提供、後者を有償販売する体制に移行した。『発行方針変更のお知らせ』（http://on-deck.jp/about.html）。なお、体制移行以前の号は、ツイパブ（http://lite.twepub.jp/20yhfoas8urp）にて無償公開されている。

[*8]……『CopperReader』はAndroid専用の、縦書きやルビ表示に対応したEPUBリーダー。開発元はブログ出版局（https://play.google.com/store/apps/details?id=jp.cssj.android）。

[*9]……これはUnicode附属書、UAX#14 “Unicode Line Breaking Algorithm”（http://unicode.org/reports/tr14/）に基づく振る舞い。かなり多くのアプリケーションがこれを参照しているようだ。

[*10]……『Murasaki』はスクロールベースの簡易なEPUBリーダー（Mac OS X用）。開発元はGenji（http://itunes.apple.com/jp/app/murasaki/id430300762?mt=12）

[*11]……全角・半角の由来は、パソコン黎明期に主流だったシフトJISの時代にさかのぼる。この符号化方法では、主に欧米のソフトウェアと互換性を確保する目的で、JIS X 0201とJIS X 0208を「同時に」使えることが求められた。その結果としてシフトJISにおいては両者の文字セットの重複した部分、つまり欧数字とカタカナ、一部の約物・記号類が2種類符号化されることになった。JIS X 0201収録の文字を半角、JIS X 0208収録が全角と呼び分けられる。

[*12]……半角と全角の違いがある文字のリストは以下を参照。『図書館員のコンピュータ基礎講座』上綱秀治「ユニコード　半角・全角形」（http://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/uff00.html）。また半角・全角をはじめとした互換文字の曖昧さについては以下を参照。“Unicode Standard Annex #11 East Asian Width” 2012-01-17 （http://unicode.org/reports/tr11/）

2012/7/20 11:00

小形克宏

文字とコンピューターのフリーライター。2001年に本誌連載「文字の海、ビットの舟」で文字の世界に漕ぎ出してから既に10年が過ぎました。知るほどに「海」の広さ深さに打ちのめされる毎日です。Twitterアカウント：@ogwata

-ページの先頭へ-