カテゴリー別アーカイブ: XSL-FO・CSS

fo:bookmarkというマークアップから考えるしおり

『岩波国語辞典第八版』*1によれば、「しおり(しをり)」には2つの意味があります。

1. 本の読みかけのところに挟んで目印とするもの 2. 初めての人などにわかりよく説明した本。手引き

岩波国語辞典第八版

「目次」は次のように記されています。

(書物の)内容の題目を、書かれている順に並べて記したもの

岩波国語辞典第八版

しおりについて、1の意味では、読み手側が設定するものという印象が強いですね。ちなみに岩波国語辞典だとブックマークはWebブラウザのブックマーク(お気に入り)機能についての言及となっています。

さて、XML組版の仕様であるXSL1.1仕様にはしおりを作成するための機能fo:bookmarkfo:bookmark-titlefo:bookmark-treeが存在します。1.1の仕様に1.0との差異が記載されているのですぐにわかりますが、実は1.0のときには存在しなかった機能です*2

『XSL-FOの基礎 第2版』*3にしおりのFOについての解説があります。また、Antenna House XSL Formatterの*4サンプルFOのページ*5からしおりの設定されたPDFを確認できます。

<fo:layout-master-set>
    …略…
  </fo:layout-master-set>
  <fo:bookmark-tree>
    <fo:bookmark internal-destination="MARK001">
      <fo:bookmark-title font-weight="bold">
    目次</fo:bookmark-title>
    </fo:bookmark>
    <fo:bookmark internal-destination="MARK002"
                 starting-state="hide">
      <fo:bookmark-title>第1章</fo:bookmark-title>
      <fo:bookmark internal-destination="MARK003">
        <fo:bookmark-title>1.1</fo:bookmark-title>
      </fo:bookmark>
     ...
     </fo:bookmark-tree>
     ...
    <fo:page-sequence ...>
      <fo:block font-size="2em" font-weight="bold" space-after="5mm" id="MARK001">Bookmark sample-1</fo:block>
        <fo:block font-size="1.5em" font-weight="bold" id="MARK002">Lorem Ipsum</fo:block>
          <fo:block space-before="4mm" margin-left="2em" line-height="1.4">
         <fo:block keep-with-next="always" font-weight="bold" id="MARK003">Lorem ipsum dolor sit amet</fo:block>
            <fo:block>...</fo:block>
        </fo:block>
...
</fo:page-sequence>

ごく簡単に説明すると、fo:rootの子としてしおりのツリーを用意し、その子として、目的のIDやURLなどをプロパティの値に持つしおりfo:bookmarkとしおりの項目名fo:bookmark-titleを記述します。上の例ではfo:blockにそのIDが記述されていますね。ツリー構造ですので、階層も表現できます。

PDFなど、ページドメディアへの出力を意識したマークアップであるXSL-FOの機能として用意されていることから分かる通り、これは文書コンテンツ提供側が用意するしおりです。
XSL-FOは(中間形式にせよ)ページドメディアとしてかなり明示的なマークアップを求めますから「fo:bookmark*」は「この箇所をしおりとする」というはっきりとした意思表示となります。
文書コンテンツ作成者がコンテンツ頒布時に「この部分は読みかけ」というしおりを作ることは稀なことと捉えて良いでしょう。そして、fo:bookmark-titleというマークアップ名から分かる通り、しおりの項目名は長い段落などを記述する箇所でもありません。

目次項目は当然その項の内容を反映しまとめたものになりますから、しおりは多くの場合目次項目と同じ箇所でマークアップされ、対応したPDFビューアーでは「しおりを表示」といった機能でページ表示とは独立して表示できます。
特に数百、数千ページのPDF文書を頻繁に読む機会のある方は頷かれるのではないかと思いますが、紙の文書ではそれこそ「しおり」を挟んで分厚いページの束をまとめてむんずと掴んで目次に戻ったりできますが、PDFビューアー上で毎回目次ページへ戻って目次項目を確認するというのはそこそこ時間がかかります。

個人的には、しおりの重要な点として「ページ外の要素」であることが大きいのではないか、と考えています。目次で「2.3 詳細 200ページ」、文章中に「299ページに詳細」、索引ページに「fo:bookmark…300p」といったページ参照があるのはそれはそれで重要ですが、「本文を読みながら文書(あるいは文書外)の他の箇所への目印へすぐにアクセスできる」機能がしおりといえるのではないでしょうか。そして、XSLでは文書コンテンツ提供側がそれを提供することになります。

ところで、XSL-FOとXSL-FOプロセッサーによる処理ではPDFの作成時にしおりをマークアップすることになるので、すでにPDFとなっているものにしおりを付与することは範囲外です。Antenna House Formatterでは「PDFを画像のように埋め込む」といったことができるので、多少トリッキーな方法で後からしおりを付与することもできなくはありません。しかし専用のソフトウェアがあればもっと分かりやすく、そして効率的にしおりを付与できます。

antenna house webinar pdf bookmark

隔週で火曜に開催している「ちょっと一息 アンテナハウスウェビナー」、11月10日(火)16時からは「そもそも、PDFのしおりとはなにか ~目次と何が違うのか。どう作って活用するか~ 」というテーマでお送りします。この記事を書いているのが担当者でないため、発表内容の詳細はわかりません。しおりってなんなんでしょうね……。この謎を明かすためにも明日のウェビナーは必見です。

参考文献・資料

  1. *1 『岩波国語辞典第八版』(岩波書店, 2019年11月22日第1刷発行, ISBN 978-4-00-080048-8)
  2. *2 https://www.w3.org/TR/xsl11/#change10
  3. *3 https://www.antenna.co.jp/AHF/ahf_publication/data/xsl-fo-v2/201603282131.html『XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様』(アンテナハウス株式会社, 2017年3月, ISBN 978-4-900552-48-7)
  4. *4 Antenna House Formatter
  5. *5 https://www.antenna.co.jp/AHF/ahf_samples/sample-fo.html#pdf


LwDITAで(途中まで)ドキュメントを書いてみました

これまでに数回Lightweight DITA(LwDITA)に言及したことがありました。LwDITAやDITAについては記事末尾の関連記事、参考資料をご覧ください。ざっくり書くと、リッチな文書フォーマットとその簡略化版です。

最近、社内でドキュメントにLwDITAを試用して執筆しています。これは少し正確ではなく、より正確にお伝えするなら「執筆していた」となります。現在DITA(ただし一部機能しか使用しない)に移行中となります。

そこそこ文量のあるドキュメントに使ってみての利点、欠点について記そうと思います。一部、実装と仕様どちらに対しての言及であるのか不明瞭である点がありますがご容赦ください。

LwDITAでできること

DITAとしての利点と、LwDITAとしての利点があります。DITAとしての利点はおおよそ次のようになります。

  • DITA文書の一部としてDITA-OTで処理可能
  • conref、keyrefが利用できる
  • トピック単位でファイルを分けて管理できる
  • メタデータに索引用のキーワードを集約できる

LwDITAはDITA文書の一部として、通常のDITAと混在して処理が可能です。管理の観点からすると必ずしも良くはありませんが、「最初LwDITAで書いてDITAへ移行していく」今回の私のユースケースや、「既存資産のDITAやXML形式を利用しつつ新規記述のコストを減らす」といったときに有用です。

conrefやkeyrefはDITAの機能で、簡単に言えばプログラム言語における変数をドキュメント中に使用できます。専門語の揺れを防いだり、URLの変更などに対応できます。長期的に同じドキュメントを使用したいときに便利です。

「トピック単位でファイルを分割して管理できる」、DITAがトピック指向の設計であるので、条件が合致するときは各ドキュメントの構成のシンプルさを保つことができます。後述する「索引の半自動化」に係わるところです。「メタデータに索引用のキーワードを集約できる」というのも大体同じメリットですが、メタデータを書く箇所がフォーマット側で各ファイル単位に用意されているものは実はあまり多くありません。

そして1行では書きにくいメリットとして、構造のどの位置で呼ばれたかによって、適用されるセクションレベルを変更できるという恩恵があります。簡単に例を挙げると、h2レベルの内容の途中で呼ばれた別ファイルの見出しトップレベルはh3と解釈されます。書いているうちにトピックを分割したくなったときなどに有用です。

LwDITAとしてDITAに対する利点は次があります。

  •  単純な最低限のマークアップ(em、strong、italic、リスト……)

メディアコンテンツ対応も地味に仕様としてはDITA1.3より進んでいるのですが、これは出た時期によるもので、実用的にはDITAでも対応されているはず。

さて、とくにMDITA(と一部拡張プロファイルとしてHDITA記法)を利用していたのですが、次の利点があります。

  • MDITAではYAMLフロントマターにkeyword、category、author、source、トピックIDを記述可能
  • DITAに限らず別形式へ変換可能という安心感

メタデータは単純なKeyValue、あるいは簡単な入れ子となるようなものが多いため、汎用エディタを使ってXML形式で記述するのは冗長に感じるときがあります。YAMLでとりあえずパパっと書けるのは楽でした。

最終形をPDFと考えたとき、DITAではやりづらくなる箇所もあるかもということで、別形式にしやすい意味ではMarkdownは安心感があります。その分表現力に制約がかかりますが。

「チームメンバーの記述可能なフォーマットの共通スキルがHTMLやMarkdown」といったケースもありうるかもしれません。

LwDITAでできないこと

  • 対応しているDITAメタデータ(prolog)が少ない
  • 対応しているプロパティ、要素が少ない(特にMDITA)
  • 独自拡張のDITAが対応できない

さもありなんといったところで、作業が進むと、簡易形式ゆえにオミットされた機能が使いたくなってきます。上に挙げた理由で、今はDITA化を進行中です。とはいえ、変換後もLwDITAと対応できない要素はあまり使っていません。

とくにMDITAの不満点として、<note> に対応する記法がありません。以前あった記法もなぜかdepricatedになったので、注やtipsなど、荒涼としたドキュメントにおけるポップでおしゃれなアクセントが書けないのです。

XDITAを飛び越えてフルウエイトのDITAに変換すると、<indexterm>、索引語の指定が使えるようになります。keywordとしてYAMLフロントマターに記述していた語へこのマークアップを行うと、トピックの開始位置に索引が自動でつくように設定できます。入れ子にもできるので索引のサブ項目もほとんど労力をかけずに可能です。

「特殊化したDITA」について軽く触れましたが、AH-DITAという拡張ではfo:propプロパティによってXSL-FO語彙によるスタイル付けをダイレクトに行うことができます。また、図表のフロート配置も<floatfig>で、より自由に行えるようになります。

その他細かいところや全体像などについても、そのうち記事にできればと思います。

参考資料・関連記事


W3C「日本語組版の処理要件」の最新版が8月11日に公開されました

日本語組版の処理要件(Requirements for Japanese Text Layout、略称 JLREQ)のWorking Group Note最新版が2020年8月11日に公開されました[1]。page2020のXMLパブリッシング交流会『ウェブ出版と日本語組版の未来』で言及されていたものですね[2]。

日本語組版におけるさまざまな事柄について触れられており、項目も多いので「最初から最後まで順に読む」というよりは「必要な箇所を探して都度読む」という読まれ方が多いかもしれません。
この記事を書いている人間はそうで、今まで序論などはあまりしっかり読んでいなかったのですが、この機会に一読することにしました。

序論の「この文書の目的」に次のようにあります。

すべての文化集団は,独自の言語,文字,書記システムを持つ.それゆえ,個々の書記システムをサイバースペースに移転することは,文化的資産の継承という意味で,情報通信技術にとって非常に重要な責務といえよう.

この責務を実現するための基礎的な作業として,この文書では,日本語という書記システムにおける組版上の問題点をまとめた.具体的な解決策を提示することではなく,要望事項の説明をすることにした.それは,実装レベルの問題を考える前提条件をまず明確にすることが重要であると考えたからである.

また、「この文書の執筆方針」には次のようにあります。

組版処理と読みやすい組版設計の関係は別問題である.しかし,両者は不可分の関係があり,解説でも両者を同時に説明する事項も出てくる.しかし,できるだけ両者を区別して記述することを心掛けた.具体的な方法としては,読みやすい組版設計の解説は,できるだけ注記で述べるようにした.

しばしば「Rule」あるいは「Specification」であるかのように捉えられることもありますが、
「Requirements」、それも(主には)組版処理への要件といえます。


さて、「J. Revision Log」に以前の版からの変更点が簡潔に記されています。
ルビについての記載の集約他、表現の修正、閲覧性の向上などが挙げられていますね。

Merged and simplified handling of overhanging ruby text on punctuation marks (former 3.3.8 f,g,h).

約物にかかるルビ文字の定義を集約し簡単化しました (以前の 3.3.8 f,g,h).
[Issue, PR]

English wording fixed.

英語表現の修正.
[Issue, PR; Issue, PR; Issue, PR]

Merged English and Japanese documents into a single document, with switches to allow readers to view the text in either language, or both.

英語版と日本語版の統合,および言語切替機能の導入.
[7dcc927; Issue, PR]

Link targets were assigned to each list item and note, making it possible to point into the document in a more fine-grained way.

文書内リンクがリスト要素とノートにつくようになり,文書内の特定の場所を指すリンクが利用できるようになりました.

Also minor editorial changes were made to structure and wording of the text. A detailed list of changes, including diffs, can be found in the github commit log.

また細かな構成・表記上の修正を行いました.変更点を含む詳細な変更履歴については github のコミットログを参照してください.

「以前の3.3.8 f,g,h」、つまりルビが親文字よりはみ出した場合の処理の調整で、ルビ後に一部の約物が来るようなケースですね。

1版の該当箇所をみると、確かにほぼ同じ文で、対象にしている文字が異なるものの、その調整処理も同じにみえます[3]。

Webページ上の話になりますが、英語版と日本語版を並列表示可能になったことによって、表現が適切であるか閲覧者が比較しやすくなったといえるでしょう。
煩わしければ片方だけにもできますし、データ量としては英語版の文章、日本語版の文章両方を合わせたところで大きいとは言えないはずです。
普段はあまり意識しないのですが、W3Cのページレイアウトも2012年のJLREQのそれと比べ、改良されています。画面が横に広いと目次がサイドバーについて行が画面端から画面端に伸びるのを防いでいたり、
Noteなどの表示スタイルが枠と背景色で見やすくなっていたりしていますね。

具体的にどのような変更があったかですが、コミットログを少しだけ見てみると次のようなコミットなどがありました。

  • 「processed」「processing is」などとしていた箇所をそれぞれ具体化
    • – it is processed identically to mono-ruby;
      + it is laid out identically to mono-ruby;
  • ルビの項での「letter」を「character」に修正する
  • 画像サイズを削減

JLREQについてのGitHubのissue[4]でOpenのものは2020年8月17日時点で63ありました。
内容とは別のissueもありますが、「question」「enhancement」「future」などのラベルから気になるトピックを見てみると良いでしょう。

以前のイベント参加レポート[2]でも言及しましたが、これは公開された活動です[4]。
英語での意見投稿はハードルが高いと感じている方も、日本語で投稿した内容をJLREQのチームが拾い上げ、翻訳を行ってくださいます。

過去・現在の書籍組版などからの要件もありますが、Webをはじめさまざまなメディアがこれからも変化を続けるにしたがい、「日本語組版の処理要件」自体も変化するでしょう。
これが継続的な活動として続けられていることに改めて感謝の気持ちを抱きました。


  1. [1] Requirements for Japanese Text Layout
    日本語組版処理の要件(日本語版)
    W3C Working Group Note 11 August 2020 https://www.w3.org/TR/jlreq/
  2. [2] 「2/7のXMLパブリッシング交流会に参加してきました」- アンテナハウス I Love Software!2
  3. [3] https://www.w3.org/TR/2012/NOTE-jlreq-20120403/ja/#adjustments_of_ruby_with_length_longer_than_that_of_the_base_characters
  4. [4] https://github.com/w3c/jlreq/issues/


Antenna House Formatter


海外ウェビナー動画「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(日本語字幕付き)

Xplor International(https://xplor.org/)主催のウェビナーにて、弊社副代表のMichael Millerが発表を行いました。

タイトルは「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(原題:CSS or XSL-FO: Which should I use for producing print publications)です。
「CSSとXSL-FO、どちらを使うべきでしょうか?」という質問をよくいただきます。こののウェビナーではCSSとXSL-FO、それぞれの特徴や歴史的な背景を昨今の出版を取り巻く環境も含めてご紹介しています。技術的な内容は少なめで、どなたでも理解しやすい内容となっています。

ウェビナーの様子はYouTubeでご覧いただくことができますので、ぜひご視聴ください。

なおYouTubeの字幕機能を使えば、日本語字幕付きでご視聴いただくこともできます。
字幕の設定方法は、

  1.  動画右下の設定アイコン(歯車マーク)をクリック
  2. 「字幕」をクリック
  3. 「日本語」にチェックを入れる

以上の設定で日本語字幕付きでご視聴いただけます。



XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!



アンテナハウス ウェビナー スケジュール一覧 2020


CommonMark文書をXSL-FO経由でPDFへ変換する

前回、cmark[1]でCommonMark[2]のASTをXML形式で得られることを確認しました。

記事中で登場するコードの動作についての保証はできかねます*1。ご了承ください。

今回の記事で使用した環境は次になります。

文書はその目的に適した構造を持ち、組版では多くの場合その構造に沿ってマークアップを行うでしょう[3]。
Markdownはそれらを放棄しているために、文書として組版するためには不足するものを補う必要があります*2。基本的には、「レポート」であるならレポートの見た目になるよう、Markdown文書とレポートの対応関係を用意する必要があるということです。例えば「<heading level="1">のテキストをレポートのタイトルとする」として、「レポートタイトルはフォントサイズは本文の2倍、中央寄せ、前後のアキは……」とスタイルを用意していきます。書籍を組むのであれば目次や索引などが補う対象となります。

記法の数が比較的少ないCommonMarkとはいえ、すべての対応関係について記述するのは労力が大きいため、一部のみとします。また、前回言及した「Markdown + XSL → PDF」[4]の記事ではリンク記法を応用して脚注記法を用意していますが、処理が複雑化しますのでこういった応用もしません。

変換するCommonMark文書

# CommonMark文書をAH XSL FormatterでPDFにする

## はじめに

[XSL](https://www.w3.org/TR/xsl/)は2部に分けられます。一方はスタイルシート言語としてのXML語彙(XSL-FO)、他方はXML変換のための言語XSLTです。

## 基本版面

`<fo:simple-page-master>`とその子要素に基本版面のサイズとそれぞれの区画を記述していきます。

* `<fo:region-before>`
* `<fo:region-after>`
* `<fo:region-start>`
* `<fo:region-end>`
* `<fo:region-body>`


startからendは*行進行方向*、beforeからafterは*ブロック進行方向*です。

## 本文

```xml
<fo:flow flow-name="xsl-region-body">
    <fo:block>
        ...
```

region-bodyの`region-name`の既定値は「xsl-region-body」ですが、**変更**できます。

基本版面が完成したら、ヘッダやフッタなど配置が固定的なものを配置する`<fo:static-content>`と、
見出しや本文の`<fo:flow>`を記述していきます。版面で指定したページマスタや区画を指定します。

ようやく紙面に文字を表示するための記述に入れます。LaTeXなどではクラスファイルとしてまとめられている箇所を自力で書いているようなものですので、慣れるまでは煩雑に見えるかもしれません。

XMLへの変換

このCommonMark文書をPDFに変換します。
cmarkによるCommonMark文書のXML変換はコマンドライン操作になります。標準出力に出力されるため、出力結果をファイルに書き込んでいます。変換結果のXMLで文字化けがしていたら、コマンドラインの文字コード設定などが関係しているかもしれません。

> cmark.exe doc.md -t XML > result.xml 

このXMLをXSLTで変換し、得られたFOをAntenna House XSL FormatterでPDFへと変換します。先に結果を見てみましょう。

PDF出力結果



源ノ明朝、源ノ角ゴシックを使用したPDFが出力されています。欧文はTimes New RomanとDeja Vu Sansです。

XSLTの抜粋

AH Formatterではソフトウェア側の設定をあまり弄らずともOpenTypeフォントを使用できます。

<!-- XSLT -->
<xsl:attribute-set name="mainfont">
 <xsl:attribute name="font-family">Times New Roman, 源ノ明朝</xsl:attribute>
 <xsl:attribute name="font-size">14q</xsl:attribute>
 <xsl:attribute name="line-height">1.7</xsl:attribute>
</xsl:attribute-set>

<xsl:template match="/"><fo:root>を置きます。


<xsl:template match="/">
 <xsl:variable name="varAuthor" select="'アンテナハウス'" />
 <xsl:variable name="varTitle"><xsl:text>CommonMarkからXSL-FOでPDFを作る</xsl:text>
</xsl:variable>
 <xsl:variable name="varMainPageName" select="'main'" />
 
 <fo:root xsl:use-attribute-sets="attsRoot">
 <!-- 基本版面 -->
 <xsl:call-template name="layoutMasterSet"> 
 <xsl:with-param name="mainPageName" select="$varMainPageName" />
 </xsl:call-template>
 <!-- 表紙 -->
 <xsl:call-template name="coverPage">
 <xsl:with-param name="mainPageName" select="$varMainPageName" />
 <xsl:with-param name="author" select="$varAuthor"/>
 <xsl:with-param name="title" select="$varTitle"/>
 </xsl:call-template>
 
 <!-- 文書内容 -->
 <fo:page-sequence master-reference="{$varMainPageName}"
 xsl:use-attribute-sets="attsPageSequence">
 <xsl:apply-templates />
 </fo:page-sequence>
 </fo:root>
</xsl:template>

<xsl:template match="md:document">

 <xsl:call-template name="header">
 <xsl:call-template name="footer" />
 <fo:flow flow-name="xsl-region-body">
 <xsl:apply-templates />
 </fo:flow>
</xsl:template>

基本版面についてはMarkdown側で干渉するところは特にないので名前付きテンプレートとして省略しました*3。coverPageテンプレートで本文とは別に表紙を作っています。
著者情報を「レベル1見出しの直後の段落を著者名にする」といった形でMarkdown側で記述するようにもできるでしょうが、
やはり「Markdownでは記述しない箇所を決める」という割り切りがある程度の単純さを保つために必要に思えます。

ブロックの例を見てみましょう。

<xsl:attribute-set name="attsCode">
 <xsl:attribute name="font-family">Source Code Pro, 源ノ角ゴシック Code JP, monospace</xsl:attribute>
 <xsl:attribute name="font-size">12q</xsl:attribute>
 <xsl:attribute name="xml:space">preserve</xsl:attribute>
</xsl:attribute-set>

<xsl:attribute-set name="attsCodeBlock" use-attribute-sets="attsCode">
 <xsl:attribute name="linefeed-treatment">preserve</xsl:attribute>
 <xsl:attribute name="axf:border-bottom-left-radius">3pt</xsl:attribute>
 <xsl:attribute name="axf:border-top-right-radius">3pt</xsl:attribute>
 <xsl:attribute name="border">solid 1.5pt gray</xsl:attribute>
 <xsl:attribute name="background-color">silver</xsl:attribute>
 <xsl:attribute name="padding">3mm</xsl:attribute>
 <xsl:attribute name="space-before">4mm</xsl:attribute>
 <xsl:attribute name="space-after">4mm</xsl:attribute>
</xsl:attribute-set>

<xsl:template match="md:code_block">
 <fo:block xsl:use-attribute-sets="attsCodeBlock">
 <xsl:apply-templates />
 </fo:block>
</xsl:template>

コードブロックです。CommonMarkのASTにはinfoとして最初の行の```xml、「xml」が格納されていますが、
1からシンタックスハイライトを行うのはつらいので、背景色やボーダー、等幅フォントを指定しています。< xsl:templatye match="md:code_block">の箇所はかなりシンプルにできていますね。

<xsl:attribute-set name="attsListBlock">
 <xsl:attribute name="space-before">1rem</xsl:attribute>
 <xsl:attribute name="space-after">1.4rem</xsl:attribute>
 <xsl:attribute name="provisional-label-separation">2mm</xsl:attribute>
 <xsl:attribute name="provisional-distance-between-starts">5mm</xsl:attribute>
</xsl:attribute-set>

<xsl:template match="md:item">
 <xsl:variable name="type" select="../@type" />
 
 <fo:list-item xsl:use-attribute-sets="attsItem">
 <fo:list-item-label end-indent="label-end()">
 <fo:block text-align="end">
 <xsl:attribute name="axf:number-transform">
 <xsl:choose>
 <xsl:when test="$type = 'bullet'">
 <xsl:text>circle</xsl:text>
 </xsl:when>
 <xsl:when test="$type = 'ordered'">
 <xsl:text>1.</xsl:text>
 </xsl:when>
 </xsl:choose>
 </xsl:attribute>
 <xsl:number />
 </fo:block>
 </fo:list-item-label>
 <fo:list-item-body start-indent="body-start()">
 <fo:block>
 <xsl:apply-templates />
 </fo:block>
 </fo:list-item-body>
 </fo:list-item>
</xsl:template>

<xsl:template match="md:list">
 
<fo:block-container column-count="2">
 <fo:list-block xsl:use-attribute-sets="attsListBlock">
 <xsl:apply-templates />
 </fo:list-block>
</fo:block-container>
</xsl:template>

箇条書き(リスト)です。それぞれの項目が短い場合、1段だと余白がかなり空いてしまいます。AH Formatterではブロックコンテナでも段組みを別に指定できるので、2段組にしてみました。今回使用してはいないものの、数字付き箇条書きでも動作します。CommonMarkのASTでは箇条書きは同じlist構造でtypeプロパティの値が違う形なので、HTMLのようにulとolが分けられているより対応が楽だと感じました。入れ子のリストでの記号の変更も、 <xsl:variable name="nest" select="count(ancestor::list)" />のようにすれば階層が割と簡単に分かりそうです。
ところでこの組版結果は想定とズレていて、ASTの<item>の内部で一度<paragraph>が使われているため、ラベルと項目の間に、通常の段落を想定した段落開始のインデントが入ってしまっています。

インライン記法の変換例を見てみましょう。

<xsl:attribute-set name="attsEm">
 <xsl:attribute name="axf:text-emphasis-style">dot</xsl:attribute>
 <xsl:attribute name="axf:text-emphasis-font-family">Kenten Generic</xsl:attribute>
 <xsl:attribute name="axf:text-emphasis-skip">spaces punctuation symbols narrow</xsl:attribute>
</xsl:attribute-set>

<xsl:template match="md:emph">
 <fo:inline xsl:use-attribute-sets="attsEm">
 <xsl:apply-templates />
 </fo:inline>
</xsl:template>

和文の簡易マークアップで悩ましいemとstrong。AH Fromatterでは圏点の拡張がありますから、emでは圏点を使用してみました。


今回の記事は『スタイルシート開発の基礎 XMLとFOで簡単な本を作ってみよう』[5]を片手に、適宜読み替えながら書き進めてみました。Markdownからの変換はLaTeXやHTML経由でのものが多く、それぞれに長所や特徴がありますが、XSL-FOで1つ1つ記法とFOを確かめながらというのも、組版全般やXSLTの学習がしっかり進んだように感じ、良いものです。
体感としては、一般的なプログラミング言語で同程度の内容を書くよりも3倍くらいの行数になっている感じがします。

*1XSLTとXSL-FOの記法について学習中の人間が執筆しました。誤りが含まれる箇所があるかもしれません。

*2 「不足する」他のものとしては、表示言語などもそうです。多くのXMLアプリケーションでは「xml:lang」や「id」といった情報は<xsl:copy-of>を利用して入力から出力へそのまま渡せますが、CommonMarkのASTにその情報は含まれません。<html_block>の情報としてマークアップを処理する、言語ごとにファイルを分けるなど、手軽な処理とはいかないでしょう。

*3 <template match="/">は個人的な感覚としては一般的なプログラミング言語におけるmain関数に近いので、切り出せる処理を適時追い出し、子の箇所で必要な値(で子からの取得が面倒なもの)については<xsl:with-param>で渡しています。<xsl:attribute>は調整する可能性がないものは<xsl:template>内でハードコード、そうでなければxsl:use-attribute-setsで別に切り出しています。2ページもない文書を処理するにしては冗長かもしれません。


参考資料

  1. [1] https://github.com/commonmark/cmark
  2. [2] https://commonmark.org/
  3. [3] 構造化文書とは – アンテナハウス
  4. [4] Markdown + XSL → PDF
  5. [5] スタイルシート開発の基礎 – アンテナハウス


Antenna House Formatter

DITA/XML Service Antenna House


関連記事


AH FormatterでXSL-FO 2.0 仕様DraftのWebページをPDF化してみる

業務を行っていると、W3Cで公開されている仕様を確認しにいくこと、例えばXSL-FO 2.0のDraft[1]を確認しにいくことがあったりなかったりします。
Webページの利点の1つはスクロール操作によって文書の目的の位置へいけることですが(もちろんそうでない作りのWebページもあります)、手元の電子ペーパー端末でページをめくるように読みたい場合もあります。
「WebページのURLを打ち込むだけでそこそこ読めるPDFを出力してほしい」、そんなときにもCSS組版が可能なお手持ちのAntenna House (CSS) Formatterが利用できます。

AH Formatterでファイルを読み込む際、通常はファイルパスを指定するかと思います(GUIではドラッグ&ドロップも可能です)。しかし、ここにWebページのURLを指定することもできます。マニュアルにも記載してありますね。「組版種別」によって、AH FormatterのデフォルトCSSを使用する設定、元のHTMLのCSSを利用するなど違いがあるので、マニュアルを確認してください[2]。

Windowsの場合、AH Formatterをインストールしたフォルダにhtml.cssがあります。これがHTMLファイルを読み込んだときにAH Formatterのデフォルトとして適用されるCSSです。
今回は「HTML」を指定しました。

全体的な文字サイズやページサイズなどを「組版オプション」で設定してみます。


XSLT2.0の仕様[3]を、ページサイズをJISB5、本文14ptとしてみたところ、673ページ程度になりました。

JIS B5サイズのPDFでXSLT2.0 仕様出力

記事冒頭で「例えば~」とXSL-FO2.0の話題を振っておきながらFOではなくXSLT2.0で例を出しているのは、XSL-FO2.0のドラフトだと1200ページ超え(JISB5、本文14pt程度)となり、GUIでプレビューを表示しながら操作をするには手元のマシンだと厳しいためです[4]。CUIで組版する分には問題ありません。

JIS B5サイズのPDFでXSL 2.0 Draftを出力

今回PDF出力してみたWebページの場合ですと、ソースコードや巨大な画像ではページサイズに収まるように表示できていません。元がリフロー型のWebページなので、デフォルトのCSSでは少し無理があったようです。とはいえ、手軽にそこそこ見やすいPDFを得ることができました。

Antenna House Formatterの評価版は、こちらのページからお申込みいただけます。
AH Formatter 評価版のお申し込み

CSSでのページメディアの印刷に興味がある方へ、アンテナハウスでは『CSSページ組版入門』という書籍を発行しています。

  1. [1] Extensible Stylesheet Language (XSL) Version 2.0
    W3C Working Draft 17 January 2012
  2. [2] ドラッグ&ドロップ組版 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス
  3. [3] XSL Transformations (XSLT) Version 2.0
  4. [4] ページ数上限自体は変更可能です。 制限事項 – Antenna House Formatter V7 マニュアル グラフィカルユーザインターフェイス

関連記事

  1. AH Formatter の CSS組版例「MathML 3.0 2nd Edition」

Antenna House Formatter V7XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!


Antenna House Formatter V7.0 リリースのお知らせ

2020年2月20日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter』をバージョンアップした『AH Formatter V7.0』を公開しました。

AH Formatter のロゴ

『AH Formatter V7.0』では、欧文組版における行分割処理の改良、BIDI処理の改良、GUI の改良、
ドロップキャップ・PDF 2.0 出力・PDF/X-4p 出力・Adobe Fonts・WebP への対応など
盛りだくさんです。

詳しくは「ニュースリリース」に記載しておりますので、是非ご覧ください。
 
 


2/7のXMLパブリッシング交流会に参加してきました

2020年2月7日、先週の金曜日に開催されたXMLパブリッシング交流会『ウェブ出版と日本語組版の未来』に参加してきました。アンテナハウスもブースを出展していた、page2020のイベントの1つという位置付けでした。

会場到着

会場は池袋サンシャインシティの文化会館7F会議室。最近の技術書典の会場として2F、3Fには来たことがあったので、まあ結構ギリギリの到着でも大丈夫かと高を括っていたのですが、素直にエスカレータを登っていたらスポーツジムに着いてしまい、慌ててエレベータを探しました。

そんなこんなで本当にギリギリの時間に会場に到着すると、席は前方から後方まで割と満遍無く埋まっていました。こくちーずでの申込数上限は80人で、終了後に確認したら登録者数は57人となっていましたね。

以下、スライドや発表に解釈を加えて記述している箇所がありますが、発表者の方の意図に沿えているか分からない箇所もございます。ご了承、ご指摘ください。

木田泰夫氏『JLReqタスクフォース』

Keynote for iCloud上の資料となるので、環境によってはご覧になれないかもしれません。FireFoxやSafariなら見られる筈です。

JLReq Task Force Chairmanの木田氏による、「W3C 日本語組版の処理要件」とその周辺の話となります。

原型としてはJIS X 4051:2004の「日本語文書の組版方法」となり、これを国際的な文書にまとめ直したもの、というのがJLReqの概要となります。

しかし、JLReqはJIS X 4051の単純な移植に留まらない、ということを発表を聴いて改めて意識させられました。

まず、非日本語話者にも要件を伝えるということから、JIS X 4051よりも詳細にその背景や用語の解説や図示が行われているということ。「ルビとはなにか」という説明が、ルビ文化が無い人のために必要になるといった例が挙げられました。

また、世界に向けて日本語組版における要件を発信したJLReqは、様々な言語における要件をまとめていく活動の先駆けとなりました。総称すると「xLReq」とでも言うべきこの活動は、世界が協力し多言語組版を実現していく上での重要なファクターとも言えそうです。

業界的な意味でも、W3Cの専門家と言語の専門家を繋ぐ架け橋としてxLReqがあるということでした。

JLReqTFとしても活動は続けられています。これは公開された活動で、GitHub上にインターフェースがあります。英語での意見投稿はハードルが高いと感じている方も、日本語で投稿した内容をJLReqのチームが拾い上げ、翻訳を行ってくれるとのことなので、積極的な参加を呼びかけておられました。

まず、JLReqの2版に向けた内容のアップデート。これは1版にドラスティックに変更が走るといった類のことではなく、

  •  正誤表の反映
  •  英語での記述の表現をより良くする、
  •  曖昧だった箇所の詳細化(ルビなど)
  •  参照文書としての完成度の向上

といった内容だそうです。

次に、JLReqの機能を滿たすようなCSSが定義されているか、あればその動作の検証の諸々と、そのドキュメント化までを行っているそうです。事前にキーワードとして挙げられていた「gap analysis」ですね。スライドの表にその例示があります。要件があっても実際にそれを実現できる仕組みがないとどうしようもないので、こういった調査を行ってくださっていることに頭の下がる思いです。GitHubで課題、意見の吸上げを行っているので、その整理自体も重要な仕事ということでした。

結びとして、「未来に向けて」という題で幾つかのお話をされました。

紙面とデジタルテキストとの違いということを軸に話されていたものの、多くは組版そのものが持っていた問題のうち、今まで人が都度なんとかしており、また完成したものが紙面など固定されたものであったために表に出ていなかったもの、という印象でした。

人間が監督するものと完全に自動で組版するものとの課題の例として、縦書きで左ルビの行と右ルビの行が隣り合うときの行間制御の例など(大抵は人間が位置をずらすことで対処)、画面サイズで文字の配置が変わる場合などに確かに考えねばならないものです。

また、世界で使われるということは、これまでの和文と欧文の高々2つの関係の独自の世界から、「多言語のうちの1つとしての日本語」ということを意識した要求にしていく必要がある、ということも「xLReq」、そしてインターネットとWebブラウザが登場してより顕在化した事柄ではないでしょうか。

そして、そもそも紙面上での組版の時代でも、媒体の事情に合わせて組版要件が変化していったということも、言われてみればその通りであるのに、見落としがちであった視点であったと思います。パラグラフマーク「¶」が、飾りではなく紙の値段が現在よりも高かったときに段落区切りを余白以外の手法で表していた、という例示がありました。

冊子の持っていた優位性の消失というのも興味深い話でした。ページを捲ることでのランダムアクセス(巻物はシーケンシャルですね)、これはデジタルテキストであればリンク機能で事足ります。新技術が登場するときに旧来の技術・表現を模倣するという視点での「デジタルテキストでの組版とその処理要件」は、どこに自分の立ち位置を合わせるかを考える上で重要なものだと感じました。

そして、参加者からの質問タイム。

「禁則処理や和欧文間のアキがJIS X 4051から引き継いでいるが、この要件を変更する議論はあるのか?」というもの。例えば「四分アキが適当な箇所と適当で無い箇所」といった具合ですね。「Tシャツ」という日本語としての単語の「T」と「シ」のアキが四分だと広すぎる、というような例が挙げられていました。

返答として、議論は行われているということでした。

関連して、和語の単語区切りのアイデアといったものも示されました。Webブラウザ表示では、日本語でも行末が不揃いであることもかなり受け入れられてきているので、今後そういった表現に関しての要件が必要になってくることも納得ですね。

「もっと皆さんに試してみてほしい」という言葉も印象的でした。

最後にされた「JLReqは今後『Rule』になるのか」という質問に対して「要件であり、複数あって良いものである」という姿勢が示されていました。その前にされたアキの変更議論なども含めての回答になっており、大変充実した内容でした。

田嶋淳氏『日本語組版に関連する CSS 規格の策定状況について』

https://speakerdeck.com/juntajima/ri-ben-yu-zu-ban-niguan-lian-surucssgui-ge-falsece-ding-zhuang-kuang-nituite

W3Cの作業草案(Working Draft)から勧告(Recommendation)に至る流れの解説の後、それに則って進められている本題のCSS規格の話へ移ります。

勧告候補まで行っても、状況によっては差し戻しされ議論に戻ることもあるというのは随時チェックする程でない身としてはショックがありました。

最新の仕様を追うならDraftを見ることになりますが、何せ草案なので揺れて怖いという話。

「CSS3」という呼称がCSS2.1までのバージョニングの話とは違うということは

不勉強であまり意識したことがありませんでした。CSS2.1に入っていた仕様をレベル3とし、各モジュールに分けて進行状況をレベルで表すということです。

各Webブラウザでの仕様の実装状況のチェック方法など、初学者に嬉しい内容のスライドとなっていました。

JLReqの発表でもあった、要件と対応するCSSのモジュールに関しても、そのモジュールを勧告まで持っていくには別のレイヤでの議論がある、ということでした。「行どり」のためのモジュールは2つほどあったけれどどちらもポシャってしまった話からも、その難しさが察せられます。

より高度なルビ機能の実装に向けたWebブラウザの動向という例も挙げられていました。FireFoxのみ両側ルビに対応を始めたものの、他ブラウザは行っていないといったズレがあるということでした。

定まっていない仕様が定まると、どのような場合に嬉しいのかということで、

text-spacingが規格化されれば、ぶら下げインデントでの約物の表示挙動が統一されたりする、といった例が挙げられていました。

自動縦中横のアイデアなど、どう実装するのか難しそうな話題もあるようです。

また、ルビと圏点を同時に使った場合の挙動といった、議論が定まっていないものもあります。ところで、Antenna House Formatterではルビと圏点の同時使用に対応しており、挙動としてはルビ文字の上に、親文字に対応する圏点を表示します。ルビ文字に合わせた圏点は行えません。

村上真雄氏『ウェブ出版と日本語組版の未来とCSS組版Vivliostyle』

https://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#b=/vivliostyle_doc/ja/events/page2020xpub/&spread=false&renderAllPages=true

発表スライドもVivlioStyle製です。

紙とWebでの出版コンテンツの違いについてから始まりました。

どちらかというとページメディアとスクロールメディアの違いについてと言えなくもない内容でしたが、「CSSの表現力によってコンテンツの表現力が変わる」という主張は恐らくVivlioStyleの開発陣の情熱の起点となるものではないかと感じました。

電子書籍の形態として普及が進むEPUB3の話題も当然深く拘わってきます。EPUB3.0の仕様に縦書き機能が入ったことでも話題になりましたね。これも、W3CにおけるCSS標準化の進みによるもの、JLReqが貢献した1例といえます。

そして提示された「EPUBはウェブ出版といえるか」という疑問に対し、村上さんとしては現状そうではない、という立場のようです。

Web Publications」というそのものズバリなW3C Working Groupの存在と、それが現状停滞してしまっていること。この試みをそのまま形にする筈であったEPUB4.0も現状ではどうなるか分からない、とのこと。

また、メタデータの付与をJSON-LD形式で行うPublication Manifestについての言及もありました。こちらは勧告候補。

通常のWebページにSchema.orgに沿ったJSON-LDを付与することも聞くようになってきましたし、Webを志向する上ではそういった流れなのかもしれませんね。

各Webブラウザが機能を実装するにはとても時間がかかります。CSS Paged Media関連など、通常のWebページを表示するためのWebブラウザとしては後回しになりがちなCSS仕様もあります。一方で「標準化」のためには、いち早くその仕様を実装し、検証し、フィードバックを行うことも必要です。

CSSでの機能標準化をより強く進め、同じソースからCSSによって複数のレイアウトを実現し、印刷、EPUB、Web出版を1つのラインに載せたいという情熱を感じました。

「ここから本題です」と村上氏が発言し、会場に笑いが。確かにまだVivlioStyleの話が全然出ていませんでした。

商用のCSS組版ソフトウェアについても言及。弊社の「Antenna House CSS Formatter」の名前も上がりました。

VivlioStyleはオープンソースのJavaScriptプログラムで、EPUB Adaptive Layoutの機能やPaged Mediaなどの、Webブラウザが対応できていない機能をJavaScriptによって補完するものになります。大きなトピックとして、2019年からJavaScriptからTypeScriptに移行しました。

個人的にはVivlioStyle Flavored Markdownの話が聞きたかったのですが、デモもそこそこに時間終了となってしまいました。デモでは、同じHTMLソースからCSSの設定変更のみでレイアウトを大きく変更する例などを駆け足で紹介していました。

小形克宏氏『CSS組版とVivliostyleの未来』

https://www.slideshare.net/ogwata_1959/cssvivliostyle-227189333

VivlioStyleの沿革から。スライド外の情報としては、もともとInDesignのレイアウトをWebで実現したかったのがEPUB Adaptive Layoutの思想だったということで、驚きました。

開発の活発さをコミットログから見ると、会社時代と法人化以後を比較してもあまり衰えていない様子が表示されました。開発に参加してくれているメンバーなどにアンケートを取ったところ、「VivlioStyleの開発に加わると最新仕様の実装ができる」というところに魅力を感じている方が多いとコアメンバーが驚いたとか。ちなみに、コアメンバーがそのあたりに無自覚的だったことに会場から驚きの声が上がっていました。

開発者会議を現在月1度ほどの頻度で行っており、濃密な場となっているそうです。

そして、これからも開発を継続していくために、現在法人としてのVivlioStyleに欠けている、開発者支援のための費用など用意していくために、VivlioStyleを利用したサービスを構想中ということで、「VivlioStyle Pub」の構想が紹介されました。

VivlioStyleを利用したオンラインエディタ「Viola」を元に、「ブラウザで原稿執筆可能」「PDF/X-1a出力可能」「(独自仕様の)Markdown原稿をサポート」を目玉にサービスを行っていくというもののようです。VivlioStyle Pubとしては技術同人誌出版などを当面のターゲットとし、印刷所との連携などまで持っていくつもりとか。

VivlioStyle開発メンバーでもあるspring-raining氏のCSS組版・パブリッシング交流会でのViolaの発表が去年の6月ごろだったことを考えると、こういったプロジェクトでの歯車が噛み合う瞬間の速度というものの凄まじさを感じずにはいられません。同じく去年のCSS組版・パブリッシング交流会で課題として挙げられていたPDFの規格問題もGhostScriptでのアウトラインフォント埋め込みを実装したメンバーがVivlioStyle開発メンバーに参加したということです。

CSSの未だ定まっていない仕様も、それを実際に実装し、フィードバックしていくシステムを調えていくこともまた重要で、どんな立場からでもその立場なりにできることがあるということを強く印象づけるXMLパブリッシング交流会となりました。



Antenna House Formatter

DITA/XML Service Antenna House


海外出展情報 その2

10月14から17日にロンドンで開催された S1000D User Forum は、航空宇宙および防衛分野の技術文書を作成する多くのアンテナハウスのパートナーおよび顧客と会うことができました。アンテナハウスは卓上展示とベンダーとしてのプレゼンテーションを行いました。フォーラムには世界中から300人以上の航空宇宙および防衛分野の専門家が集まりましたが、その出席者の多くに弊社の Antenna House XSL Formatter を使用していただいています。また同じく弊社の製品である Regressions Testing System と、OSDC (Office Server Document Converter) の PDF を SVG に変換する機能に大きな関心が寄せられました。航空宇宙および防衛分野で使用される技術文書においては、依然としてページ出力が非常に重要とされていますが、現在の目標はその文書をタブレット上に表示することです。SVG になぜ関心があるのかというと、そのページを表示する速度にあります。

プレゼンテーションでは Antenna House XSL Formatter を使用してS1000D サンプル文書をフォーマットし、PDF と SVG 出力を作成しました。次に Regressions Testing System のデモンストレーションでは2つのディレクトリにある8つのペアになっている文書(合計で2,000ページ)の内容の比較を行いました。 デモンストレーションでは各ペアの文書の全ての相違点を2分以内に発見することができました。


海外出展情報 その1

10月にAntenna Houseは、Xplor Webinarとロンドンで開催された S1000D User Forum / ILS specification day に参加しました。

今回はXplor Webinarのご紹介をしたいと思います。

10月16日に開催された Xplor International が主催する教育ウェビナーで、弊社のシニアアーキテクトであるトニー・グラハムはAccessibility Mattersを発表しました。多くのアンテナハウスの顧客とパートナーがこのウェビナーに参加し、Xplorのメンバーもこの話題に興味を持っていました。このウェビナーはデジタルの世界においてアクセシビリティがいかに、またなぜ重要であるかを学ぶ絶好の機会でした。

プレゼンテーションの中で、トニーはHTML、Web Content Accessibility Guidelines(WCAG)、およびPDF / UA(Universal Accessibility)標準のアクセシビリティ機能を調査しました。アクセス可能なHTMLやPDFを作成するために必要な情報は、通常ソースXMLに含まれているか、ソースXMLから推測できるため、ユーザーの行動よりもファイル形式に重点を置いて調査しています。ただしXMLそのものをユーザーが目にすることはほとんどありません。このウェビナーでは、神経障害や失読症などの学習障害のある人がアクセスしやすいように、コンテンツのスタイリングが持ついくつかの側面についても調査しました。

プレゼンテーションはこちらのYouTubeからご覧いただくことができます。

https://www.youtube.com/watch?v=X00icPURCvw&feature=youtu.be


Pages: 1 2 3 4 5 6 7 8 9 Next