日本語組版処理の要件(JLREQ)改版に関するご意見募集のお願い

 W3C文書「日本語組版処理の要件(JLREQ)」の改版作業が始まっています。JLREQは海外のシステム開発者などに向けて日本語組版を扱うシステムで対応するべき要件を伝える目的で作られた文書で、現在最新の第2版は2012年4月に発行されていますが、これをより正しく、使いやすい形に直してゆく作業です。

 この流れで私もW3CのJapanese Text Layout task force (jlreq)の会合で現場サイドとしての参考意見を述べることになりました。せっかくですので日本の組版関係者からの意見も集約したく思い、このブログを書いています。あくまで私が出版・組版関係の人の意見を聞くために個人としてやる聞き取りであって、W3C公式でもなんでもないのでお間違いなきよう。GitHubにissue立てるの慣れてる人はそちらが早いと思います。

 一応「日本語組版処理の要件(JLREQ)」がどういう性格の文書なのかということについて触れておきます。これはW3Cの正式な文書なのですが、「規格書(Specification)」とは異なり、「要件(Requirement)」になります。ざっくり言いますと「日本語組版で行うべき処理(=紙の本の組版作業において行われてきた処理)をそれを実現する技術的な方法には踏み込まずに記述したもの」です。書かれている処理には従来手作業で行われてきたものも多く含まれていますので、Webなど自動流し込み処理を前提とせざるを得ないシステムでは実現困難なものも多く入っています。従って、「日本語組版処理の要件(JLREQ)」に記述があるからといって、将来確実にWeb等で使えるようになる、という話では全くありません。ただし、新たに海外のシステム開発者が日本語組版に関連するシステムを作るような場合に真っ先に参照される文書であることも間違いなく、実際W3C仕様の中には日本語組版処理の要件を参照先としたリンクが多数既に入っています。次世代の組版ソフトが開発される際にも当然参考にされるでしょう。このことから、やはり将来日本語の表示環境に今回の改訂が大きな影響を及ぼしそうとは言えるかと思います。

 つまり、「これまで紙の本作りで行われてきた組版処理の方法を自動処理的にできるかどうかは考えずにひとまず記録しておいて、(日本人だけでなく)誰もが参照できるようにしようよ」という話なので、「日本語組版処理の要件」に目を通していただき、普段やっている組版処理とは違う記述が標準とされていて違和感があったら教えて欲しいですし、普段の仕事で普通にやっていることが項目ごと抜けていたら指摘していただければ有り難いです。それは改版に盛り込む価値のある情報の可能性があります。

 私も参加していますJAGAT XMLパブリッシング準研究会では、過去数年にわたってJLREQに沿ってCSSの実装状況を見てきており、それについての議事録はこのブログの過去エントリにまとまっています。以下にリンクをまとめて掲載します。

JLREQとCSS(1)
JLREQとCSS(2)
JLREQとCSS(3)
JLREQとCSS(4)
JLREQとCSS(5)
JLREQとCSS(6)
JLREQとCSS(7)
JLREQとCSS(8)
JLREQとCSS(9)

 こちらなども参考にしていただき、JLREQ改訂に関してのご意見をいただければと思います。これはどういった要望がありそうかについてのざっくりとした意見募集ですので、技術的な実現の難易度などは気にせず自由に意見を寄せていただいて大丈夫です。ご意見はこちらのブログのコメント欄に書き込んでいただいても構いませんし(コメント許可制のため表示反映までに時間がかかりますのでご了承ください)、Twitterで私のアカウント宛てにメンションを飛ばしていただいても構いません。その際はハッシュタグ「#jlreq」等を付けていただけますと後日拾い上げる際に漏れがなさそうかなと思います。

 出版・組版関係者の方、よろしくお願いいたします。

(2019.4.25)

タグ: , ,

コメント / トラックバック 3 件

  1. Mako より:

    出版・組版関係者ではなく、ごくたまに私的に LaTeX を既存の cls で使う程度の素人です。私の目が節穴か、あるいは的外れでしたら申し訳ありません。

    和欧文混植の際に和字と欧字のベースラインをどう揃えるか、特に、ぜんぶが横組の場合と縦組の主たる和文の中に欧字を90度回転して配置する場合とでは、揃える基準線が異なってくると思うのですが、そういった考え方について「日本語組版処理の要件」に書かれているかと一通り読んでみても見つけることができませんでした。

    このことは、この文書の扱う範疇の外なのでしょうか。

  2. Jun Tajima より:

    ご意見ありがとうございます。ちょっと私ではわからないのですが、関係者にそういう意見があったことをフィードバックいたします。

  3. Jun Tajima より:

    「日本語組版処理の要件」執筆者の小林敏先生のこの件に関してのコメントを転載させていただきます。
    ————————————————————————————————–
       小林敏です

    和文と欧文を混植した場合,和文と欧文の行送り方向(行を並べていく方向,横組でいえば上から下への方向)の配置位置の問題は,JLReqで触れていません.それは諸説あり,統一した見解はないという判断から,あえて触れていないということです.また,欧文文字のxハイトの大きさ,キャップライン,ベースライン,デセンダー,アセンダーの位置によっても変わってきます.大文字だけの単語,デセンダーやアセンダーがある小文字を含む単語でも状況は変わってきます.また,和文の文字サイズと欧文の文字サイズを変えて配置する方法もあり,一筋縄ではいきません.

    ですので,いえるとしたら,“指定による”としか言えないと思います.個々の場合に応じて,判断していくしかないでしょう.

    では,デフォルトは何かといえば,欧文文字にも文字サイズを持っており,行送り方向の文字の高さでしょう.いってみれば仮想ボディであり,和文と欧文が同じ文字サイズであれば,その仮想ボディというか,文字の外枠をそろえて配置するということだと思います.

    で,この方法で配置すると,ケースによって,和文に比べ,欧文が上すぎるという意見が,活字組版でも,写真植字でも言われてきました.そこで,やや下げる,と,今度は,デセンダーが行間にはみ出す,ならば,デセンダーを小さくしたフォントを作ればと,それはおかしい,……

    ということで,この問題は,あまり深入りしたくない,というのが率直な気持ですが,気になるのは事実です.

    ある意味,和文と欧文という性格の異なり文字を混植することに無理があり,それをなんとか,なだめていくしかない.ということで,繰り返しになりますが,最初に述べたように1つのルールを決めるのは無理があり,個々に決める(“指定による”)とうことしかないのが現状かな,と思っています.

    以上,ご参考まで.
    ————————————————————————————————–

コメントをどうぞ

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。