2021/07/01
日本の本のルビ(ふりがな)の文字には出版社や時代ごとに2つに大別されるルールがあります。「小書きのカナをそのまま使う」か「大書きのカナに変換して入れる」かです。大書きルールの場合には拗音・促音を「っ」→「つ」のように置換して入れます。これは元々は活版の時代にルビサイズの小書きのカナは潰れてしまって読めなくなる懸念があったことからできたルールではないかと推測しているのですが、現在のように印刷技術が発達してサイズの小さな文字でも十分な可読性が得られるようになっても依然として「大書きのカナに変換して入れる」ルールは残っていたりします。EPUBでも場合によっては要求されますので、機械的に処理できないかと思い、Xhtml内でのルビを対象とした小書きのカナ→大書きのカナの置換スクリプトをPerlで書いてみました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
|
#! /usr/bin/perl use utf8; use Encode qw/encode decode/; #変換Textファイルのパスを取得 $convertTextFilePath = $ARGV[0]; $convertTextFilePath = decode('UTF-8', $convertTextFilePath); #各テキストファイルを展開、置換 open(IN,"$convertTextFilePath"); @importedTxts = <IN>; $importedTxt = join("",@importedTxts); $importedTxt = decode('UTF-8', $importedTxt); close (IN); #置換処理 my $replacedTxt = & textReplace ($importedTxt); #出力 $replacedTxt = encode('UTF-8', $replacedTxt); open(OUT,"> $convertTextFilePath"); print OUT $replacedTxt; close (OUT); exit; sub textReplace { #置換テキストの取得 my $targetText = $_[0]; my @rtBlocks; @rtBlocks = $targetText =~ m/<rt>[^<>]+?<\/rt>/g; foreach $rtBlock(@rtBlocks){ my $rtBlockConverted = $rtBlock; $rtBlockConverted =~ tr/ぁぃぅぇぉゕゖっゃゅょゎァィゥェォヵㇰヶㇱㇲッㇳㇴㇵㇶㇷㇸㇹㇺャュョㇻㇼㇽㇾㇿヮ/あいうえおかけつやゆよわアイウエオカクケシスツトヌハヒフヘホムヤユヨラリルレロワ/; $targetText =~ s/$rtBlock/$rtBlockConverted/g; } return $targetText; } |
ターミナルで
|
perl このスクリプトのパス 処理対象ファイルのパス |
の順で指定すれば処理されます。

こんな感じ。
なお、小書きのカナ→大書きのカナの場合には自動で処理できますが、大書きのカナ→小書きのカナの場合は小書きにしていい文字なのかそうでないのかの推測が機械的にはできませんので位置を特定しての手作業になるかと思っています。
(2021.7.2)
カテゴリー: 未分類 | コメントはまだありません »
2020/11/27
某所の会議でルビ/ふりがなに関する話題になった時に、ルビ的な組版処理をしているけれども少なくとも狭義の意味ではルビとは言いがたい組版要素の話が出ました。紙の本のデータのEPUB化の際にもしばしば取り扱いを悩む要素を多く含んでいますので、ちょっとまとめて書いておきたいなと思います。なお、InDesignやIllustratorなどのDTPアプリケーションでは「タブ機能を使った複数行テキストの位置合わせ」や、「アンカーボックスを使った要素の配置」に相当する話になるかと思います。JLREQ的には「3.6 Tab Setting タブ処理」に関連します。そのつもりで読んでください。
さまざまな例
例えば以下のようなものたちです。
- 語学学習系コンテンツでよく出てくる、例文に並行して記述される和訳、発音記号、品詞など
- DTPデータ内ではルビの機能を使用して行間に挿入されている注の合印
- 漢文訓読の返り点や送り仮名など
注の合印や漢文の返り点などは今は上付き・下付きの指定でコーディングされるケースが多いかと思いますが、本来的には本文テキストの横に並行して置いておきたいという要望が強いかと思います。実際注の合印などはInDesignでルビの機能を使って配置している例は良く目にしますので、ずっと組版的にはニーズはあったと見るべきでしょう。
また、円城塔氏が「文字渦」でやったような、ルビの体裁で本文とは違う内容のテキストをエンドレスで書くような表現も狭義での「ルビ」とは言いがたいでしょう。
こういった組版要素はいずれも本文と並行して記述され、またリフロー化の際には行末で本文と並んで折り返される挙動になることが表組みとは異なります。単純なHTMLのテーブル要素ではカバーできないのです。
ここでは仮にこういうものたちを「並行注」と呼称することにします。
無理矢理組版再現できなくはなさそうだけど…
上記の例のうち、おそらく一番複雑なものになりそうな語学学習系コンテンツをコード化できそうかを考えてみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
|
<div style="display:inline-block;width:11em;"> <span style="display:inline-block;width:100%;">Humpty Dumpty </span> <span style="display:inline-block;width:100%;">ハンプティ・ダンプティ</span> <span style="display:inline-block;width:100%;">名詞</span> </div> <div style="display:inline-block;width:4em;"> <span style="display:inline-block;width:100%;">sat </span> <span style="display:inline-block;width:100%;">すわった</span> <span style="display:inline-block;width:100%;">動詞</span> </div> <div style="display:inline-block;width:3em;"> <span style="display:inline-block;width:100%;">on </span> <span style="display:inline-block;width:100%;">〜に</span> <span style="display:inline-block;width:100%;">前置詞</span> </div> <div style="display:inline-block;width:3em;"> <span style="display:inline-block;width:100%;">a wall</span> <span style="display:inline-block;width:100%;">塀</span> <span style="display:inline-block;width:100%;">名詞</span> </div> |

表示例
以上のような感じで、一応ブラウザレベルでの動作は確認できました(図ではわかりやすくするために各ブロックに背景色を指定しています)。きちんと行末でブロックごと折り返されています。
ただし、1点解決不可能な問題があります。「各ブロックの幅を明示的に指定する必要がある」点です。表示フォントをコンテンツ作成側が強制できるような環境であれば問題にはならないですが、そうでない場合に、例えば「ユーザーがプロポーショナル幅のフォントを表示フォントに指定した」ような場合に各ブロック間に不規則な幅のスペースが空くことになりそうです。
また、コードも正直相当煩雑になりますし、さらにdisplay:inline-blockの入れ子はかなりトリッキーにも思えますので、ビューアによっては表示の問題が出そうです。本によってはこういうものはかなり頻出しますので、可能ならばもっと簡単な記法で書きたいところです。
ルビの記法の延長で書けるようになれば嬉しい
より簡単な記法の候補として思いつくのが、「ルビ」のそれです。ルビはまだCSSの規格としては審議中の段階ですが、肩付きルビや両側ルビのような複雑な指定が将来使えるようになるかどうかはともかく、基本的なルビはもう現在使用して問題ない状況なのでその延長は考えてもよいかと思います。例えば、以下のような形はどうでしょうか?
|
<span class="parallelnote"><span class="main">Humpty Dumpty</span><span class="note1">ハンプティ・ダンプティ</span><span class="note2">名詞</span></span> <span class="parallelnote"><span class="main">sat </span><span class="note1">すわった</span><span class="note2">動詞</span></span> <span class="parallelnote"><span class="main">on </span><span class="note1">〜に</span><span class="note2">前置詞</span></span> <span class="parallelnote"><span class="main">a wall</span><span class="note1">塀</span><span class="note2">名詞</span></span> |
当然まだ専用タグなどはなく、全部spanタグにclass名で書いたので複雑に見えますが、要するにrubyタグ内のrt要素に当たるものをrb要素の後に複数個連続で並べただけなので構造としてはシンプルかと思います。このような記法で書いてきちんと「並行注」的な挙動が得られるようになるなら嬉しいところです。
(2020.11.27)
タグ: ルビ, 注
カテゴリー: 未分類 | コメントはまだありません »
2020/11/13
先日、メディアドゥからVR/AR用の電子書籍ビューア開発開始というニュースリリースの発表がありました。また、Facebookはスタンドアロンで動作する普及版VRビューア、Oculus Questの後継機に当たるOculus Quest 2を販売開始し、これがいよいよ家電量販店で売られるなどという話も出ています。そろそろ本格的にVR/AR普及が見えてきた感がありますので、ちょっとVR/ARでの読書について期待するところを書いてみたいと思います。
VRによるデバイス画面サイズの制約からの解放
今、私たちは電子書籍を例えばスマートフォンで、あるいは専用機やタブレットで、もしくはPCの画面で読んでいます。これらの「画面」は、いずれも物理的な実サイズを持っていて、必然的に表示できる文字やイラストの大きさにはデバイスの物理サイズによる制限がかかります。これを緩和するために行っている作業が「テキストリフロー化」で、そうすることで紙の本からの電子化であってもスマートフォンの小さな画面でもとりあえず読めるようにはなります。

リフロー型電子書籍では紙の版面情報の再現は難しい
ただし、例えばもとの本が大判のものであった場合などには必然的にそれに収録されている図版のサイズもそれに合わせたサイズになりますし、その図版を画面の小さなスマートフォンで眺めることが快適な読書体験かと言われれば当然そこには疑問符が付きます。
読めはすることと快適に読めることはイコールではないのです。これは、リフローでの電子化を仕事としてやっていると強く実感します。
さらに、テキストリフロー化はその過程で多くの情報を強制的に削ぎ落とす行為です。例えば実用書などでは見開きの片方のページに大きく図を表示し、もう片方のページに解説文を載せるといったレイアウトのものがありますが、これはテキストリフローでは再現できません。このため、図版の挿入位置を工夫し、テキストの文言を調整するといった作業を行いますが、当然限界はあります。
VRによってデバイスサイズによる縛りがなくなり、任意のサイズの仮想的な画面を展開できるようになればそのあたりの悩みは一気に解消されるはずです。なにしろ仮想画面なので、例えば「新聞の見開きサイズの画面を展開する」といったことも可能になるわけです。これはとてつもなく大きな進化です。
仮想画面はいくつ出してもよい

複数の「画面」を並べて行うPCでの読書
さらに、VRでは例えば今PC上でウィンドウを複数出しているように、
仮想画面を複数並べて「読書」することも可能になるはずです。このメリットがピンとこない方は、
今自分たちが(エンタメではない)本を読むときにいくつの「画面」を並行して見ているのかを考えてみればよいかと思います。
まず、読書対象の本そのものの版面。用語がわからなければそれを調べるために辞書を引くこともあるでしょうからそれも「画面」の一つ。ネットを使って検索して調べることもあるでしょうし、文章中で他の本を引用している箇所があれば、その本を持ってきて該当箇所を調べるようなこともやるでしょう。内容を書き留めるための手元のノートも「画面」と見ることができそうです。
さらには読書対象の本の中に注が設定されていれば、それと本文を相互参照しながら読むこともしますので、これもそれぞれ別の「画面」と見ることができるでしょう。つまり「読書」というのはそういう多くの「画面」を随時参照しながら行う行為なのだと思います。
そう考えると、今電子版で売れているのが圧倒的にコミックスやライトノベルのような軽いエンタメで、カタい本が売れにくい状況になっているのも理解できます。コミックスやライトノベルを読むなら「画面」はひとつで済みますが、カタい本を読むにはひとつでは足りないのです。VR技術によって、物理的に多くの面積を専有することなしに多数の「画面」を並べて本を読めるようになれば、それはかなり幸せな読書体験になるのではないかなと思います。
必ずしも全てが仮想画面でなくてもよい
さて、そうは言っても「やはり紙の本がいい」という方はたくさんいるのではないかと思います。でも例えば、紙の本を読みながら辞書や参考文献などを仮想画面として適宜呼び出せるとしたらどうでしょうか。単に別画面を見せるだけなら「スマホを横に置いておけばいいじゃん」という意見が出そうですが、おそらくGoogleやAppleあたりはそれだけでは済ませない世界を構想しているように思えます。紙の本を読みながら、わからない用語があったときにタッチペン的なものでなぞれば視界内に辞書の用語解説ページが仮想画面としてポップアップしてきて参照できる、そんな世界が来るように思うのです。
そういった現実世界のものに電子情報をオーバーライドして見せる技術は「AR(Augmented Reality/拡張現実)」と言い、こちらは現在GoogleやAppleが熱心に研究を進めている分野です。今はまだ視界全てを置き換えるVRとは別物として開発されていますが、VR機器の前面のカメラで周囲の映像を取り込んで内部ディスプレイに投影すればAR的な表示ができますので、本質的に地続きの話です。なのでMicrosoftなどはMR(Mixed Reality)という用語を使っていたりもします。

Google翻訳ではスマホをかざすだけで翻訳文が表示される
今、GoogleはGoogle Glassプロダクトを継続的に進めていますし、スマートフォンでGoogle翻訳のアプリを起動すれば対象のテキストを写すだけでリアルタイムに翻訳文がスマホ画面の中で見られたりもします。また、
Google ブックスの展開を見れば理解できるように、彼らは本の世界へのコミットにも熱心です。
もちろん超えなければならない技術的な壁はまだいくつもあるでしょうが、もう想像できないほど先の話ではないように思います。5年後、10年後にはARメガネをかけながら読書している人はちらほら見かけるようになるのではないでしょうか。期待をこめてそういう世界の到来を待ちたいと思っています。
(2020.11.13)
タグ: AR, VR, リフロー, 電子書籍
カテゴリー: 未分類 | コメントはまだありません »