タグ別アーカイブ: XSL-FO

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>で、より自由に行えるようになります。

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

参考資料・関連記事


海外ウェビナー動画「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


関連記事


アンテナハウスの公開資料

ここ暫く外出が減り、外に出ていた時間を読書や学習にあてるという方も少なくないのではないでしょうか。
出版社による期間限定の書籍の無料公開も様々にあります。
以前から公開されている企業の技術資料をこの機会に読んでみるのも、新たな発見があるかもしれません。

何気なくWebページで技術資料を検索していたら弊社の記事だった、
なんてことを先週の休日にも体験しました。日本語情報自体が少なめなものでしたから、見つけて吃驚しました。日々技術や規格はアップデートされるものですから、資料の更新日時などには注意が必要ですが、そこさえ押さえてあれば色々と興味深い資料が見つかります。

アンテナハウスでは書籍や漫画のような形態の資料も公開しています。
トップページや製品ページからもアクセスできますが、折角なのでここでも一部紹介します。

マンガでわかる!! アンテナハウス システム製品利用例シリーズ
https://www.antenna.co.jp/system/PDFCase000.html
仕事の合間にもさらっと読める、漫画形式の製品利用例の紹介です。同じようなお悩みが見つかるかもしれません。
XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様
https://www.antenna.co.jp/AHF/ahf_publication/index.html#fo-basis
「XML組版に興味はあるけど、JISやW3Cのページをいきなり読むのは辛いなぁ」という方におすすめです。
CSSページ組版入門 第4版
https://www.antenna.co.jp/AHF/ahf_publication/index.html#CSSPrint
こちらはCSS組版での書籍作成の入門書になります。AH CSS Formatter用の拡張を使う箇所もありますが、CSS組版での基本を把握できるようになっています。
MathML 数式組版入門
https://www.antenna.co.jp/AHF/ahf_publication/index.html#MathML
数式マークアップ用の言語MathMLの入門書です。こちらも、「興味はあるけれど、いきなりリファレンスを読むのは辛い」という方におすすめです。

その他にも http://www.cas-ub.com/project/index.html で公開している書籍などがあります。「印刷された形で欲しい」という方にもPrint On Demand 本として購入いただけますので、ぜひどうぞ。


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 への対応など
盛りだくさんです。

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


[AH Formatter] line-heightプロパティ

こんにちは。
AH Formatterサポート担当です。

今回は XSL-FO の line-height プロパティのお話です。
line-heightプロパティは、行高さを指定するものですが、
その値は次のような種類があります。

normal:
line-height-“normal” のように指定します。既定値です。ユーザエージェント(AH Formatter)が適切な値に設定します。
AH Formatterではline-height=”1.2″ を初期設定としています。この値はオプション設定によって変更することも可能です。
<length>:
line-height=”20pt” のように数値+単位を指定します。
<number>:
フォントサイズに対する倍数を指定します。line-height=”1.5″ のように指定します。
<percentage>:
フォントサイズに対するパーセンテージを指定します。line-height=”150%” のように指定します。

ここで、1つ疑問に思われた方がいるかもしれません。
line-height=”1.5″ と line-height=”150%” って結局同じじゃないの? と。

実際に組版してみると、このようになります。
例1:
<fo:block line-height=”1.5″>line-height=”1.5″</fo:block>
<fo:block line-height=”150%”>line-height=”150%”</fo:block>
line-height プロパティ

そうです、”この場合”の行高さは同じです。
例えばフォントサイズが 30pt の場合、どちらもフォントサイズ 30pt × 1.5 で行高さは 45pt になります。
では、<number> と <percentage> で何が違うのか。
XSL-FO の仕様説明をみてみましょう。

<number>
The computed value of the property is this number multiplied by the element’s font size. Negative values are illegal.
However, the number, not the computed value, is inherited.

<percentage>
The computed value of the property is this percentage multiplied by the element’s computed font size. Negative values are illegal.

どちらの説明も前半の意味は同じですが、<number> にはこの一文が追加されています。

However, the number, not the computed value, is inherited.
日本語訳:しかしながら、計算された値ではなく、数値が継承される。

line-height プロパティの値は継承されます。親block で指定された値が子(子孫)block にも適用されます。
親block に line-height=”1.5″ または 150% が指定されていて、
子(子孫)の block でフォントサイズが変更されたとき、この “the number, not the computed value, is inherited.” が関係してくるのです。
例えば、次のような場合です。

例2:
<fo:block font-size=”30pt” line-height=”1.5″>
<fo:block font-size=”20pt”>line-height=”1.5″</fo:block>
<fo:block >line-height=”1.5″</fo:block>
</fo:block>
line-height プロパティ

例3:
<fo:block font-size=”30pt” line-height=”150%”>
<fo:block font-size=”20pt”>line-height=”150%”</fo:block>
<fo:block >line-height=”150%”</fo:block>
</fo:block>
line-height プロパティ

どちらも親block で line-height を指定しています。
1つめの子block で、フォントサイズを変更しています。

<number>の場合は、指定された数値が継承されます。
line-height=”1.5″ の場合、”1.5″ の値が継承されて
フォントサイズが変更になると、その block のフォントサイズ×1.5 の行高さになります。
例2では1つめの子block は、20pt×1.5 で35pt、2つめの子block が 30pt×1.5 で 45pt の行高さになります。

<percentage>の場合は、それが指定されたときのフォントサイズから計算された値が継承されます。
例3では、親block の font-size=”30pt” line-height=”150%” から行高さは 45pt と計算されます。
(line-height の指定がない)子block には、その “45pt” の値が継承されます。
1つめの子block も 2つめの子block も同じ 45pt の行高さとなります。

両者の違いに注意してお使いください。

AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

XSL-FO の基本仕様と『AH Formatter』の拡張機能をお試しいただけるよう「サンプル FO 集」もご用意しています。

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


AH Formatter へのご意見募集

こんにちは。
AH Formatter サポート担当です。

今年は春が早くにやってきたような気がします。
桜の開花予想も少し早いみたいですね。
こちらには高遠城址公園という有名な桜の名所があります。
毎年、桜の時期は多くの観光客で賑わっています。
タカトオコヒガンザクラというソメイヨシノより少し濃い色の桜で
ライトアップされた夜桜も綺麗です。

暖かいのはうれしいのですが、花粉の季節も早かったようで
花粉症のわたくしは毎日ぐずぐずしております。
周りの方、くしゃみうるさくてゴメンナサイ。

さてさて、お仕事の話をしなくては。

先日、均等割り付けの方法でお問い合わせがありました。
通常、text-align で均等割り付け(justify)を指定した場合に、
日本語(漢字やひらがなカタカナのとき)は文字間が広がります。
連続した英数字などでは単語間の空白が広げられますが、これを日本語と同じように
文字間を広げたい場合にはどうすればいいかということでした。
XSL-FO の仕様ではこの機能はありませんが、
CSS3(W3Cドラフト仕様)では用意されていました。
もちろん!AH Formatter V6では、拡張機能として XSL-FO でも対応しています。

axf:text-justify=”inter-character” を指定してください。

AH Formatter は XML自動組版ソフトとして、
これまでにも多くの機能を実装してお客様にご利用いただいております。
毎日お客様からご意見やご報告をいただいておりますが
こんな機能が欲しいというご相談も承っております。
時々、目から鱗なご相談もあって驚くことがあります。
その時点では実装されていない、実現が困難な場合もあるかもしれませんが
今後の検討課題として日々努めてまいります。
実際に業務で運用されているお客様やこれから運用を考えていらっしゃるお客様の
ご意見、ご要望は大変ありがたいです。
どうぞご遠慮なくご相談ください。

AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


Antenna House Formatter V6.6 のご紹介

2018年8月30日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter』をバージョンアップした『AH Formatter V6.6』を公開しました。

AH Formatter ロゴ

『AH Formatter』は XML で記述されたマニュアル、契約書、報告書・書籍などを XSL-FO または CSS によりレイアウトを指定して、PDF に出力したり印刷するソフトウェアです。

XSL-FO は W3C が XML に対するレイアウト指定の標準として勧告している世界標準です。国内外で『AH Formatter』は最も優れた XSL-FO 準拠製品との評価を確立しており、現在、自動車、携帯電話、航空機、OA機器のメーカ等のマニュアル制作システムなど数千社のお客様にお使いいただいています。

『AH Formatter』は Webページ用に普及している技術である CSS もご利用いただけます。CSS3 のページモデルにも対応しているため、高品質なページ組版が実現できます。

マニュアルのような複雑なレイアウトには XSL-FO を、比較的単純なレイアウトには直感的な CSS をお薦めしています。

詳しくは製品ページをご覧ください。

AH Formatter の組版フロー

 
続きを読む


海外出展情報 XML Prague Czech Republic

XML Prague は、ヨーロッパ最大の XML 会議です。 チェコ共和国のプラハの経済大学で、毎年 2 月に開催されています。(寒いですが、宿泊はシーズンオフのため格安です)。

xml-prague-1

この会議の形態は、会議前の日と呼ばれる Unconference Day という日が設けてあり、本会議の前に開かれる、自由スタイルの形式から始まります。90 分のセッションが開かれ、その後は 2 日間のシングルトラック会議が行われます。 昨年は、ほぼ 30 分の講演だったと思います。 今年の公演は、30 分間または 15 分間とされています。 会議のスケジュールはまだ公表になっていないので、30 分になるのか 15 分になるのかまだはっきりしません。

アンテナハウスは数年間、この会議のスポンサーとなっています。 アンテナハウスは過去 2 年間、主催者からスポンサーに与えられる 2 名参加分のフリーパスを学生に提供しています。

xml-prague-6

XML Prague 2018 の会議前の日(Unconference day)に、アンテナハウスは、「XSL-FO、CSS、およびページメディア」セッションで Antenna House Formatter の紹介、「ページメディア向けCSSの紹介」と題したチュートリアルの両方を発表します。アンテナハウスが 会議前の日(Unconference day) にユーザーミートアップと呼ばれるものをを主催してから 4 年目で、聴講率はよく毎回好評をいただいております。弊社社員トニーグラハムは、ここで最新の「ページメディア向けCSSの紹介」と題したチュートリアル文書を組版するのに使用している CSSスタイルを紹介する予定です。 またトニーグラハムは、「スキマトロン ユーザー ミートアップ」セッションでも講演する予定です。 スキマトロン(Schematron)は、XSL-FO ファイルをチェックするための  ‘focheck’  oXygen フレームワークで使用する技術の1つです。

xml-prague-3
xml-prague-5

本会議でも、トニーグラハムが 「人生、宇宙そしてCSSテスト」を発表します。 これは、W3C CSS テストスイートの中から 17,000 件に及ぶ自動組版テストを行うために、Jenkins サーバーおよび eXist-db XML データベースとともに、Antenna House リグレッションテストシステム(AHRTS) を使用して、社内プロジェクトの開発を行った時のケーススタディです。

xml-prague-2

この会議で人気であるものの一つに、本会議の最初の日の夕方に行われるソーシャルディナーがあります。 ディナーの後には「デモジャム」というものが行われ、ボランティアで各自が XML アプリケーションのデモを5分間行うものです。 デモジャムの優勝者は、最も大きな拍手を受けるプレゼンターです。弊社社員マイケルミラーは、2013 年の XML Prague でのデモジャムで弊社製品 AHRTS のデモンストレーションで受賞しました。

xml-prague-4


Pages: Prev 1 2 3 4 Next