カテゴリー別アーカイブ: 構造化文書

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




瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識

Google Chrome開発者版(86)でタグ付きPDFを出力[8/4修正]

[8/4追記]社内で「Chrome出力ではなくAcrobat Readerの対応外のタグ使用によって表示が壊れている可能性がある」と指摘を受けました。記事内での表現を修正します。

当初の記事タイトルは「タグ付きPDFがGoogle Chromeのデフォルトに?」だったのですが、現状としては「今後Google Chromeでタグ付きPDF出力が可能になるかもしれない」あたりのようです。

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

  • Windows 10 Home 1909
  • Google Chrome バージョン: 86.0.4221.0(Official Build)canary (64 ビット)
  • Acrobat Reader DC – Japansese (20.009.20074)
  • 検証に使用したページ*https://www.w3.org/TR/xsl11/

2020年8月リリースのGoogle Chrome 85から、タグ付きPDFの出力がサポートされます[1]。関連する情報発信自体は以前からあったようですが、実際にリリースされるこのタイミングで俄かに活気づいているようです。活気づいてますよね?

早速Google Chromeをサイトからダウンロードしてみましたが、バージョンを確認すると2020年8月3日時点では84のようです。Google ChromeにはCanaryバージョンがあるのでこちらをダウンロード。試験運用版ですので、同様に検証される方はくれぐれも自己責任でお願いします。(84でもExperimentalの設定として「Export Tagged PDF」を有効化できます。)

バージョンを確認。86……86ですね。85ではありませんが、検証には問題ないでしょう

この後Chrome 84でのtagged PDF出力も確認しましたが、同様の結果になりました。

タグ付きPDFとは

ざっくりとまとめると「タグ付きPDFは、内部に文書構造を指定するタグを付与したPDFのこと」になります。
通常PDFは印刷物のデジタル表現、つまり視覚的な表現として文書構造が見られればよいわけですが、
PDF内部のデータを別の目的で使うときにこの情報だけでは不足することがあります。
別の目的としては、データの読み上げ、PDFから他形式への再変換などがあります。

また、PDFをHTMLのようにリフローで表示したいときにも、タグを用いることで文書の表示順序などを壊さないようにできます。
「HTMLのように」と書きましたが、このタグ付きPDFで設定できるタグの多くはHTMLでのタグと類似したものになります。

概要は[2][3]、詳細は[4][5]をご覧ください。

新ビューアは今のところリフロー表示に対応していないらしい

Canaryだと、PDF出力オプションの他に「PDF Viewer Update」オプションがあるんですね。

chrome://flags/#pdf-viewer-update

これを有効化すると、84ではExperimentalのオプションである「PDF Two-up View」もついでに使えるようになります。

ウインドウ画面と表示をフィットさせる場合に上下と左右どちらを優先するか、回転表示、PDF注釈の表示のオンオフ、アウトライン表示など、色々改善がされていることがわかります。とはいえ、全体的なPDFの表示機能についてはまだまだ頑張ってほしいところです。

さて、タグ付きPDF対応と聞いて真っ先に期待してしまうであろうリフロー表示ですが、とりあえず86の新ビューアではできないようです。
「タグ付きPDFの出力」と「PDFのリフロー表示」は重なる部分もあるものの別の話なので、そういうこともありますね。
今回の新バージョンについて、ChromiumのブログにChrome Accessibilityのリーダーからコメントがあります。improving Chrome’s built-in PDF reader to better consume tagged PDFsとあるので、それなりに可能性はあるのではないでしょうか。
> While this is an important milestone, we’re not done. Future work includes both improving the quality of generated tagged PDFs, and also improving Chrome’s built-in PDF reader to better consume tagged PDFs.

タグ付きPDFをChromeで出力する

本題のタグ付きPDF出力です。Experimentalな設定で次を指定するとタグ付きPDFが出力できるようになるとあります。

chrome://flags/#export-tagged-pdf

では、PDFを出力してみます。*のページを「PDFで保存」します。さて、本来はこれをAcrobat Readerで開いてみて「おおー」となる予定だったのですが、「表示」「折り返し」を有効にしたAcrobat Readerでのリフロー表示がうまくいってないようです。

W3Cのページはあまり変なマークアップのHTMLはないはずです。タグ付きPDFは検証した日時でのGoogle ChromeとしてはExperimentalな機能なので、こちらが原因でしょうか。タグ付きPDFとリフロー表示についてはAcrobat Readerの対応状況も関連するので、Chromeの出力が原因ではないかもしれないとの指摘をいただきました。Google Chromeには自分の出力の正しさを証明するためにもPDFリフロー表示に対応してほしいですね。
PDFの内部を確認したい方は、アンテナハウスのデスクトップ製品『
瞬簡PDF 編集 9
』[6]付属の『タグ編集ツール PDFタグエディターVer.2』を使うとよいかもしれません。

他に数件確認してみましたが、ページが上のように壊れることはないものの、「いきなり何もかも上手く出力できる」とはいかないようです。Experimentalな機能なので詳細な検証をすることを避けました。

ちなみに、Chromeでのタグ付きでないPDF出力をAcrobat Readerの折り返し表示したときは、とりあえずは表示されています。

ちなみに、同じWebサイトをAntenna House Formatter V7.0 MR3でタグ付きPDFを出力した場合、折り返し表示でも問題はないようです(フォントサイズや余白、分割アルゴリズムの違いなどがあるので同じ条件にはなっていません。)。

ChromeでのHTMLとタグ付きPDFの補足資料

Chromiumのタグ付きPDF機能開発におけるデザイン資料[7]によればこれはマークアップを元にタグを付与するものなので(AIが何もかもやってくれるような話ではない)、求められるタグを出力できるかはページ製作者次第です。Chromeの開発過程で実際にはどうなったかは確認していませんが(資料中のメーリスやバグトラッカーを確認していけばよさそうです)、DOMツリーと描画用ツリー、そしてARIA属性などを基にした「Accessibility tree」を利用するデザインのようです。


The accessibility tree computed in Blink is another good possibility. The accessibility tree is derived from the DOM and the Layout Tree and also takes accessibility attributes such as ARIA attributes into account.
Chromium Tagged PDF Export Design Doc

We think the accessibility tree is the best fit and that’s the design proposed here.
Chromium Tagged PDF Export Design Doc

つまり出力が完璧だったとして、現在のところ多くのWebページについて実用的かと言われれば疑問の残るところ。残念ながら、ページによってはむしろ不要なノイズだらけになってしまうでしょう。[7]に次のようにありますが、こういった機能を機にアクセシブルなWebページを作ろうという気運が再燃したりすれば幸いです。

正常に出力されるページもあるかもしれませんが、現在Experimentalとある機能ですので、今回はここまでとします。

タグ付きPDFにご興味を持たれた方は、アンテナハウスのPDF製品を是非チェックしてみてください。


if you visit a web page that’s compliant with WCAG accessibility guidelines, then export it as PDF, then open that PDF in Chrome, the PDF in Chrome should have the same level of accessibility, modulo the limitations of a PDF file.Chromium Tagged PDF Export Design Doc

  1. [1] Using Chrome to generate more accessible PDFs – Chromium Blog
  2. [2] タグ付きPDFとはどんなもの
  3. [3] PDFのリフロー表示。タグ付きPDFとタグの付いていないPDFの比較。
  4. [4] 『タグ付きPDF 仕組と制作方法解説』
  5. [5] 『PDFインフラストラクチャ解説』
  6. [6] かんたん操作でPDFを自由自在に編集 瞬簡PDF 編集 9
  7. [7] Chrome Tagged PDF Export – Authors: dmazzoni[at]chromium.org
    November 2019





HTML on Word
WebページをWordで作る!


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

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


関連記事




瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識


HTML on Word
WebページをWordで作る!

CommonMark文書をcmarkでXML形式にする

CommonMark[1]処理系のリファレンス実装であるcmark[2]は、その抽象構文木(AST)をXMLとして出力できます。さらに、このASTの文書型定義(DTD)も存在します。公開されていて、身近でミニマルなDTD、また文書のASTとして学習にも有用です。cmarkのインストール、DTDについての詳細は割愛します。

次のようなCommonMark文書があるとします。

# 見出しレベル1

CommonMarkにはDTDがある。

## 見出しレベル2

docutilsにもDTDがある。

これをcmarkでXML出力すると、次のようになります(xml:space="preserve"プロパティを省略して表示しています)。

<document>
<heading level="1"><text>見出しレベル1</text></heading>
<paragraph><text>CommonMarkにはDTDがある。</text></paragraph>
<heading level="2"><text>見出しレベル2</text></heading>
<paragraph><text>docutilsにもDTDがある。</text></paragraph>
</document>

CommonMarkのDTDの一部を抜き出すと、次のようになっています(表示を省略した箇所は「…」のように記述しています)。

<!ENTITY % block
         'block_quote|list|code_block|paragraph|heading|thematic_break|html_block|custom_block'>
<!ENTITY % inline
         'text|softbreak|linebreak|code|emph|strong|link|image|html_inline|custom_inline'>
...
<!ELEMENT paragraph (%inline;)*>

<!ELEMENT heading (%inline;)*>
<!ATTLIST heading
          level (1|2|3|4|5|6) #REQUIRED>
...
<!ELEMENT text (#PCDATA)>

CommonMarkの処理系を実装するときに厄介な、ある記法の途中での他の記法の割り込み処理などは変換後のASTには登場しませんから平和な見た目です。さて、このCommonMarkのDTDですが、コメントや見た目の調整のための改行を含めても90行程度。さらにこのXMLは変換前はCommonMark文書ですから、おおよそどんな見た目の記述がこの構造になるかの対応付けも整理をつけやすいのではないでしょうか。「<html_block>」や「<custom_block>」(あるいはこれらのインラインマークアップ)について真面目に考えるならもう少し難しくなりますが、CommonMark文書のASTとしての文書型定義は相当にシンプルです。


こんな記事[3]を見つけました。Markdownからの変換としては多くはLaTeX、近頃はCSS組版などがありますが、ASTをXMLで出力できるならこういったアプローチも可能ですね。目的によってはMarkdownを変換したXHTMLから更に変形するよりも単純な記述で求めるPDF出力を得られるでしょう。
ところで、アンテナハウス製品には最近のフォントも組版できるXSL-FOプロセッサー、Antenna House Formatterがあります。次回、CommonMarkのASTをFOに変換したものをAH Formatterで出力してみる予定です。


参考資料

  1. [1]https://commonmark.org/
  2. [2]https://github.com/commonmark/cmark
  3. [3] Markdown + XSL → PDF


Antenna House Formatter

DITA/XML Service Antenna House


関連記事




HTML on Word
WebページをWordで作る!


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識

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に変換!




瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!

XMLをMarkdownに変換することについて

前回はMarkdownをDITAに変換する方法について紹介しました。
今回のテーマはXMLからMarkdownへの変換についてですが、見方を変えると、これは「なぜ情報量を落とす不可逆な変換をするのか」ということについてを考えることになります。
もちろん様々なニーズにより行われるのでしょうが、1つの文書型を扱う上でのこと、複数の文書型を扱う上でのこと、そして文書型のことを考えないときのことをみてみましょう。中間形式としての軽量マークアップについて扱っていますが、ライティング形式として扱いやすいといったメリットは今回は省きます。

XMLの欠点として挙げられることの多い点に「複雑」「冗長」といったワードを聞くことがあります。ここでいう「複雑」は構造の話であり、「冗長」は単純に統一された要素と属性のマークアップ記法によって起こる話といえるでしょう。軽量マークアップの多くはまさにこの点を克服するものですが、これは構造の表現力や記法の統一性とのトレードオフでもあります。

ある1つの文書型について考えてみます。文書型情報を持つ「XMLアプリケーション」と呼ばれるもの、XHTMLやDocBookやDITAといった文書では、「それらの文書型を背景に持ちつつ軽量な記法を使う」、今までの記事で取り上げてきたMDITAでいえば「トップレベルの見出しはtopicのtitle、最初の段落はshortdescにする」といったことが可能です。つまり、軽量の記法と変換される構造の対応を一対一に近いものにできます。文書型にもよるでしょうが、「XMLの構造を潰す」ものとしては最小限、不可逆ではあるものの復旧が行える可能性が高いものです。

複数の文書型を扱う上での軽量マークアップを経由する変換について考えてみます。ある文書型Aの文書から文書型Bの文書を変換、生成したいというときにはXMLにおいてはXSLTを使う方が大抵の需要に沿うでしょう。XSLTを逐一用意する必要こそあるものの、明確な構造の対応が取れるのであれば落とす情報、残す情報の選択も自在です。

この場合に落ちる情報には文書型Aの構造aに対応するBの構造がない、といったものもあります。ここで落ちる情報がXSLTを用意する手間を上回り、かつそれでも変換の必要があり、Aの文書もBの文書も相互にやり取りする頻度が高いといった場合には軽量マークアップを保存の形式に選択するのも考慮に入れてもよいかもしれません。変換先に該当の構造がなければその構造は潰れるしかありません。ある軽量な構造Mを、Aのときはこの構造になることにして、Bのときはこの構造を、とするのであれば、処理系の実装言語や環境の問題を除けばMからA、MからBの変換と、ABのXML+XSLT変換はそう変わらないことになります。この場合のMは、PandocやDocutilsの扱う抽象的なデータ型となるでしょうか。


アンテナハウスでは以前に『Markdown+CSS組版で冊子本(PDF)を作ってみる』[1]という書籍を作成しました。また、「Markdown + CSS/TeXで冊子本を作ってみた」[2]というセミナーを開催しました。このセミナーでは、Pandocを使用し、Markdownの拡張機能から抽象データ型にしたものをLaTeX用に変換し書籍を作成するラムダノート様による第一部と、Markdownと、HTMLタグで不足する構造を補ったものをXHTMLに変換し、CSSでスタイルを付与しAntenna House Formatter[3]で書籍を作成するアンテナハウスの第二部となり、対照的なアプローチでの発表となりました。少し話が逸れますが、Markdownそしてその他の軽量マークアップを最終的にHTMLやPDFといった閲覧用の形式にするにあたり、変換におけるどの層にカスタマイズのウエイトを置くのか。様々なバリエーションがあり、必要なスキルセットも方法によって異なります。これは、(できていたかは別として)構造と分離していた表現をどの段階で付与するかということでもあります。抽象データ型の変換で難しいことが起こるときは、(この記事筆者の体感的には)概ねこの部分の感覚の不一致です。


さて、最初のテーマ設定に戻ります。「なぜ情報量を落とす不可逆な変換をするのか」の答えとしては、「落として問題のない情報であるから」ということになるでしょうか。
当たり前の結論ではあります。
しかし「保存形式はXMLより必ずMarkdownがいいのだ」といった話ではなく、「補完可能」あるいは「変換不能」の情報があるとき、元のリッチな表現力の形式に固執すべきかということを考えてみてもよいかもしれません。

参考

  1. ラムダノートの技術 Advent Calendar 2019

関連資料

  1. [1]『Markdown+CSS組版で冊子本(PDF)を作ってみる』 アンテナハウス CAS-UB出版
  2. [2]Markdown + CSS/TeXで冊子本を作ってみた※終了しています
  3. [3]Antenna House Formatter V7

DITA/XML Service Antenna House

Antenna House Formatter

関連記事

  1. Markdown+CSS組版で冊子本(PDF)を作ってみる
  2. XMLエディタで始めるリッチなMarkdown入門?
  3. MDITA(LwDITA uses Markdown)の書き方
  4. DITAとしてのMDITA
  5. Markdown DITAとMDITA
  6. MDITAをDITAに変換する



瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


アウトライナー
PDFを解析して しおり・目次を自動生成

MDITAをDITAに変換する

さて、前回の記事ではMarkdown DITAとMDITAの違いについて確認しました。
Markdown DITAはMDITAと比べDITA形式へ変換するためのライティング形式の向きが強いという感想を書きましたが、MDITAをDITAへ変換することもそう難しいことではありません。

DITAパブリッシングエンジンDITA-OT[1]には、標準的な出力形式として「Normalized DITA」があります。
Normalized DITAについてはDITA-OTの出力形式についてのページ[2]や弊社の「DITA入門 パブリッシング」のページ[3]でも軽く紹介をしています。外部プロジェクトなどで使用できるように、内部パスの依存関係などを処理した状態のDITAを出力するものです。DITA-OTを使ってMarkdownファイルをDITAのXML形式にするには、この出力を用いるのが便利そうです[4]。XMLオーサリングソフト[5]などではより簡便な方法が用意されているかもしれません。

今回処理するMDITAファイルは次のsample.mdとします。DITA-OTのバージョンは3.4.1を使用しました。

---
id: sampleofmd
keyword:
- markdown
indexterm:
- md
---

# Markdownサンプル {.task}

これはMarkdownのサンプルです。

この文書は`dita --format dita`でDITA形式に変換されます。

## MDITAでセクション

これはMDITAでのセクション例。IDは自動で振られています。

後からの比較のために、MDITAでは記法として有効でないものを含んでいます。

通常のDITAファイルであればDITA-OTは単体ファイルでも変換が可能ですが、
このsample.mdを直接処理しようとすると、エラーを吐きます。

dita -i \topics\sample.md --format=dita -o .
Error: Failed to run pipeline: [DOTJ012F][FATAL] Failed to parse the input file 'file:/d:topics/sample.md'.: file:/d:topics/sample.md Line 1:Content is not allowed in prolog.

とりあえず今回はマップ経由で変換を行うことにします。

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map id="index">
<title>map title</title>
<topicref href="topics/sample.md" format="mdita" />
</map>

結果を見ると、指定した場所にマップファイルとフォルダ構造を保った
トピックファイルがあります。フォルダへ移動すると、sample.mdファイルがありますね。
……? md? と思いながらファイルをエディタで開いてみると、拡張子はともかく
DITAのTopic情報タイプになっています。


<?xml version="1.0" encoding="UTF-8"?><?path2rootmap-uri ../?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="sampleofmd"><title>Markdownサンプル {.task}</title><shortdesc>これはMarkdownのサンプルです。</shortdesc><prolog><metadata><keywords><keyword>markdown</keyword></keywords></metadata><data name="indexterm" value="md"/></prolog><body><p>この文書は<codeph>dita --format dita</codeph>でDITA形式に変換されます。</p><section id="mditaでセクション-secid"><title>MDITAでセクション {#secid}</title><p>これはMDITAでのセクション例。IDは自動で振られています。</p></section></body></topic>

topic のidはYAML Frontmatterで指定した通りになっています。
{」「}」囲みで要素の追加マークアップを行う記法は処理されず、
そのままタイトルに残っていますね。

本文の最初の段落はshortdescに格納されています。

YAML Frontmatterと変換後のPrologを見ると、
keywordskeywordは想定通り処理されています。
一方でindextermは汎用のdata要素
namevalueとして格納されてしまいました。
YAML FrontmatterのKeyValueはLwDITAの対応範囲内で処理されていることが分かります。

セクションを切った箇所では、Markdown記法の見出しが、
sectionidの値として自動で振られています。ここも記法が対応していないので、
{」「}」で囲われたマークアップは処理されていません。id内では記載できる文字の関係か、
微妙に表記が変わっています。

本文段落、
`」「`」で囲われた箇所が<codeph>に変換されているのが確認できます。
もし<pre>になることを意図していた場合はExtended Profileでタグを直接書きます。

それでは、md.ditamapのtopicrefformatを書き換え、
これをMarkdown DITAと認識させてDITAに変換してみましょう。

<topicref href="topics/sample.md" format="markdown" />

先程と同様にマップをDITA-OTの入力に指定します。

<?xml version="1.0" encoding="UTF-8"?><?path2rootmap-uri ../?>
<!DOCTYPE task
PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">
<task id="markdownサンプル"><title>Markdownサンプル </title>
<prolog><metadata><keywords><keyword>markdown</keyword></keywords></metadata>
<data name="id" value="sampleofmd"/>
<data name="indexterm" value="md"/></prolog>
<taskbody><context>
<p>これはMarkdownのサンプルです。</p>
<p>この文書は<codeph>dita --format dita</codeph>でDITA形式に変換されます。</p>
</context>
</taskbody>
<task id="secid"><title>MDITAでセクション </title>
<taskbody>
<context><p>これはMDITAでのセクション例。IDは自動で振られています。</p></context>
</taskbody></task></task>

トピックタイトル行で設定したtaskが反映されています。一方で、YAML Frontmatterに記述したidは先程のindextermのように扱われ、topicのidにはなってくれていません。さらに、構造が色々壊れたものが出力されていますね。変換のコード実装を読まないとなんとも言えませんが、Strict Taskを想定しているのであればsectionは出現しませんから、Markdown DITAを書く場合には、より取り得る要素に注意しながら記述する必要があるということでしょうか。

MDITAをDITAに変換しました。Markdown DITAとの違いに注意する必要はありますが、
ドキュメントの段階的なDITAへのステップとして、
あまりピーキーではない制約のMarkdown文書をDITAの形式へ変換できることは
確かに悪くないと感じました。

DITAやDITA以外のXMLをMarkdownに変換する方向の試みも存在します。
次週はこのアプローチについて述べる予定です。

  1. [1] DITA-OT
  2. [2] Normalized DITA – DITA-OT
  3. [3] DITA-OTの対応する出力形式
  4. [4] Markdown content – DITA-OT
  5. [5] XML/DITA関連製品 – アンテナハウス

DITA/XML - Antenna House

関連記事
XMLエディタで始めるリッチなMarkdown入門?
MDITA(LwDITA uses Markdown)の書き方
DITAとしてのMDITA
Markdown DITAとMDITA
XMLをMarkdownに変換することについて



瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!


瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成

Markdown DITAとMDITA

前回、MDITAのDITAとしての機能について紹介しました。
MDITAからDITAへの変換の前に、DITAのパブリッシングエンジンDITA-OT[1]の対応している「Markdown DITA」について、MDITAとの違いをおさえることにします。

DITAの軽量化版を作るという思想はLightweight DITA(LwDITA)[2]以前からありました[3]。というより、それらを受けた流れでLwDITAが登場します。ともかく、LwDITAは「標準化」という大きな違いはあるものの「唯一の軽量化されたDITA」ではない、ということです。

DITA-OTが対応する「Markdown DITA」は、LwDITAとは別にページが用意されています[4]。
LwDITAが策定中であるということもありますが、こちらは「フォーマットの仕様」というよりも、
「処理系に独自実装されたMarkdown(派生の)簡易記法」という理解をするのがよいでしょう。

Markdown DITAとMDITAはともにYAML Frontmatterにはよるメタデータの記述に対応していたり、Markdownとしての基本的な記法は共通しますが、(少なくとも今のところ)Markdown DITA側でしか対応していない記法があったり、それによる記述順序や変換時の要素の違いが存在します。

Pandoc header_attributes

PandocのMarkdownで拡張される見出しの記法に対応します。

# header {#id .outputclass}

見出しと同行で、半角空けて「{」「}」で囲まれた箇所に「#」とくっつけてid、「.」とくっつけてoutputclass(説明は省略します)を見出し情報に付与できます。見出しレベルが1、つまりトピックタイトルとなる見出し要素の場合、ここに「.task」「.concept」「.reference」と記述すると、それぞれ「task」「concept」「reference」としてMarkdownファイルが扱われることになります。他のものはoutputclass属性として扱われるだけです。

セクションレベルの見出しでは、「section」「example」が同様に特殊な扱われ方をします。

Hard Line Break

「文末に半角スペース2つ以上」としてMarkdownに一応用意されているもののDITAの書式に存在しない強制改行(HTMLにおける<br />)は<?linebreak?>として変換されます。

画像

画像の記法自体はMDITAでも対応していますが、Markdown DITAでは画像のタイトルを挿入できます。タイトルなしであればインラインの画像、タイトルがあれば<fig>の子として画像を変換するようです。


![alt](url "title")

keyref

リンク記法でURLを記載する「()」を省略した場合、keyrefとして扱われるとあります。URL参照するリンク、画像がこの対象です。変換されると<xref keyref=”key” />のようになります。

[key]
![key-2]

shortdesc

MDITAではショートデスクリプションは「本文の最初の段落要素」のようになっていましたが、Markdown DITAにはありません。

特殊化

「Pandoc header_attributes」の箇所で触れたように、Markdown DITAでは汎用トピックではなくtaskなど特殊化した情報タイプへ変換される場合があります。その場合、本文最初の段落がcontext要素として扱われたり、続く番号付き箇条書きがstep要素として扱われるなどします。

ここまで見てきましたが、Markdown DITAは「DITAを書ける人間が、XMLオーサリングツールがない環境でライティング形式として使用する」という用途が向いているようです。かなり近い性質の構造へ向かう文書のMarkdown記法に、こうした違いがあるというのはなかなか趣深いことではないでしょうか。

  1. [1] DITA-OT
  2. [2] Lightweight DITA: An Introduction Version 1.0
  3. [3] インテリジェントコンテンツにおけるAXの役割と考察 (2016/11/18, 関根哲也)情報処理学会研究報告 Vol.2016-DC-103 No.2
  4. [4]Markdown DITA syntax reference – DITA-OT

DITA/XML Service Antenna House

関連記事
XMLエディタで始めるリッチなMarkdown入門?
MDITA(LwDITA uses Markdown)の書き方
DITAとしてのMDITA



瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!


アウトライナー
PDFを解析して しおり・目次を自動生成

DITAとしてのMDITA

前回の記事で、MDITAで使えるMarkdown(派生)の記法について紹介しました。
しかし、MDITAの特徴は「Markdownの文法でトピック指向ライティングしたものをDITAに取り込める」ことに限りません。
DITAの機能(の一部)をMDITAから使うことができるのです。
とはいっても、Extended ProfileでHDITA(HTML5)の記法を使用してのもので、
「MDITAの機能」と言っていいのかは微妙なところですが。
前回の記事内容ではMarkdownとしてMDITAを各種ツールで扱うことができましたが、
今回紹介する機能を使用して期待した出力結果を得るには、
DITAのパブリッシングエンジン[1][2]を使用する必要があります。

conrefやkeyrefでは、リンクのURLやファイルのバージョンなど
変更される可能性がある(そして文書自体に変化は無い)要素の
文書中には参照を残しておき、その内容を別ファイルに
置くことができます。動作のイメージ図は「DITA超入門」[2]をご覽ください。

<!-- about.md -->
AH Formatterの最新版は<span data-conref="latest.dita#ver" />です。
<!-- latest.dita -->
<ph id="ver">7.0</ph>では...

パブリッシュした結果では次のように表示されます。

AH Formatterの最新版は7.0です。

また、出力に表示する要素をフィルタできる機能も限定的に使用可能です。
data-props属性に値を指定することで、トピック側の準備は完了です。


...XSL-FOでは上のように記述します。
<p data-props="notxslfo">もしCSS組版なら......</p>

フィルタの動作を記述する.ditavalファイルの中身はXMLで記述する必要があります。


<!-- ifcss.ditaval -->
<prop att="data-props" action="exclude" val="notxslfo" />

パブリッシュした結果では

...XSL-FOでは上のように記述します。

と、excludeした値が消えています。

これらの機能は、HDITAではdata-conrefdata-keyref属性にidを指定することで利用できます。

HDITAにはフレーズ要素<ph>が無いので、
単語などのkeyrefconrefでの置き換えには
<span>を用います。

LwDITAについてのより詳細な情報は、OASISによるイントロダクションのページ[4]や、前回の記事などをご覧ください。
次回は、MDITAからXDITA、DITAへの変換と編集についてを予定しています。

参考

  1. [1] DITA入門 パブリッシング
  2. [2] DITA-OT
  3. [3] DITA超入門 – アンテナハウス
  4. [4] Lightweight DITA: An Introduction Version 1.0

  5. DITA/XML - Antenna House

    関連記事

    1. XMLエディタで始めるリッチなMarkdown入門?
    2. MDITA(LwDITA uses Markdown)の書き方
    3. Markdown DITAとMDITA
    4. XMLをMarkdownに変換することについて



アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

MDITA(LwDITA uses Markdown)の書き方

「『Markdown文書』は一意ではない」ということを以前の記事で少し触れました。
Lightweight DITA(LwDITA)[1]のMarkdown形式「MDITA」について、もう少しみていきます。
まだ固まった仕様ではありませんので、記事で触れた挙動が変更される可能性があります。
内容に誤りがあった場合はおしらせください。

DITAについての説明は弊社サイトの情報ページ[2]やOASISのDITA Committe[3]、DITAコンソーシアムジャパン[4]といったサイトをご覧ください。

さて、LwDITAの目的ですが、ざっくりとは「複雑でとっつきにくい仕様だから、簡単な所だけ抜き出して簡単に書けるようにして、今までと違う層にも使ってもらおう」というものです。

LwDITA導入のためのOASISのページ[5]がDraftながら存在します。
説明が「DITAのこの機能をこう表現できる、この機能はない」といった方向によっていて、目的のひとつである「XMLで巨大なDITAを使っていない層へのアプローチ手法」としては難しいところです。このページのドキュメントのソースはGitHubリポジトリにあり、最終更新が2018年なので少し不安になりますが、SubCommitteのページには2020年5月のやり取りのログが公開されていたりするので動いているはずです。
Work In Progressな状態ではありますが、DITAをサポートするエディタのMarkdown対応が始まり、DITA Open Toolkit[6]でLwDITAのPreviewサポートが入った状況を考えれば、すぐに破棄される状況ではなさそうです。何より、そのような場合でも通常のXMLや他形式への変換がそう難しくないようにLwDITAは設計されています。

LwDITA以前にあった軽量記法への取り組みなどの歴史もあり、「現在使える仕組み」についての資料はWeb上から探すには
少し労力が要ります。正道としてはLwDITA導入のページ[5]からReferenceを辿っていくことになりますが、前知識のない状態でリーチするには難しい情報がそこそこあります。LwDITAについての書籍は1冊刊行されていて[7]、LwDITA SubCommitteeの現在のco-chairであるCarlos Evia氏によるものですから、ある程度信頼して良いでしょう。オンデマンド印刷版は4千円で手に入ります。

GitHubでホスティングされているリポジトリでLwDITA、というよりMDITAによるドキュメントのソースも幾つか見つかりますが、
基本的にセクション、リスト、リンク、コードブロックといった、GitBookなどでも登場するような要素のみ登場していました。
LwDITAの機能を使い倒すよりは、XML経由のMarkdownビルドに使用しているという印象です。
勿論それも付き合い方の1つではあるのですが、もう少しアピールできそうなポイントもありそうです。

今回はMDITAで使う記法について紹介します。次回はMDITAで使える(HTMLタグを書くことになりますが)DITAの機能を紹介する予定です。

DITAの、というよりLwDITAのファイルは基本的に、ひとつの事柄について扱うトピックを単位としてファイルを分割します。
トピックファイルを構成する要素は次の4つです。

  • トピックタイトル
  • Prolog(メタデータ)
  • トピックのShort Description
  • トピックの本文(Body)

MDITAの記法はCore Profileと呼ばれる基本の部分と、Extended Profileと呼ばれる部分で構成されます。
Extended ProfileはMarkdown方言(派生)の記法で有名、有用なものを採用して、Core ProfileではHTMLタグを書かなかければいけなかったところを補うようになっています。とはいえ、どれがCoreでどれがExtendedなのか、LwDITA導入のページ[5]でも表記にばらつきがあるようです。

まずCore Profileの部分を紹介します。

MDITAのトピックタイトルは次のように、<h1>レベルに変換されるような見出し記法で記述します。
行頭に「#」を置いて見出し内容とは半角スペースを挟む、ATX形式と呼ばれる見出しの記法です。
見出し内容の後に半角スペースを置き、「#」を重ねて見出し行、区切りを強調もできます。


# トピックタイトル

もうひとつ、Setext形式と呼ばれる記法もあります。<h1>:相当の見出し内容の行の下に「=」を並べる記法です。


トピックタイトル
===============

MDITAで段落の区切りは空行を挟みます(つまり、2連続で改行を入れます)。
基本的に要素同士の区切りは空白行です。

Short Descriptionはある意味簡単である意味難しいものといえるでしょう。トピックタイトルの行から1行空け、
最初の段落がそうなります。記法としてはそれだけですが、トピック全体を簡潔に記述した内容とする必要があります。
DITAのShort Descriptionの書き方として、
「Short Descriptionを重視し、そこで完結するなら本文は空でもよい」と薦められることを考えれば、簡易記法としては合理的です。
SubCommitteeのログを見ると、そのうちに記法のバリエーションが増えるかもしれません。

残りの部分は本文となります。

見出し項目はトピックタイトルの紹介で登場した、ATX形式とSetext形式の記法があります。


## ATXの見出し項目 ##

Setextの見出し項目
-----------------

仕様的な強制はありませんが、同じ文書内で同じ見出しレベルの記法を、
ATX形式とSetext形式で混在させるのは避けるべきでしょう。個人的には、後述するYAML Frontmatterの区切りに「---」を使うので、見出し項目にSetext形式を使うことは避けています。

一般的なMarkdownでのATX形式の見出し記法は、「#」を追加し<h3>から<h6>に相当する見出しが可能ですが、MDITAで使用可能なのは<h2>相当までです。この制限はトピック指向で文書を記述する際の目安になります。
つまり、これより低い見出しレベルが必要ならばトピックを分割すべきかもしれないということです。

箇条書きは行頭に「*」または「-」または「+」、半角スペースを空けて箇条書き内容を記述します。行区切りで次の箇条書き項目を記述します。
文書中で箇条書き記号の混在はしないようにしてください。入れ子の場合、行頭から親のラベルと半角スペース分の空白を空けて同じように記述します。番号付き箇条書きはCoreなのかExtendedなのか微妙な書き方をされていますが、「1」から「9」の数字始まりの半角アラビア数字と「.」または「)」、半角スペースを空けて箇条書き内容で同様に記述します。


* 箇条書き1
* 箇条書き2
* 2-1

1. 番号付き
2. 番号付き

表は単純な表を記述できます。見出し列、寄せ方向の指定ができますが、複雑な表は書けません。
縦の区切りを「|」、見出しと内容の区切りを「-」で記述します。「-」の個数はひとつでも構いません。行末の「|」は省略する場合もあります。内容の途中で表示を改行したい場合<br>が使えます。
寄せは区切りを「:---:」のように「:」で囲むと中央寄せ、「---:」なら右寄せというように表記します。


|見出し項目1|見出し項目2|
|----------|-----------|
|   内容1  |  内容2     |

整形済みテキストは、「“`」のに挟まれた箇所になります。コードブロックを意図している場合はExtended ProfileのHTMLタグでブロックを記述した方が確実かもしれません。


package main
...

インラインの記法として、次があります。LwDITA導入のページ[5]からはCore ProfileなのかExtended Profileなのか判然としないところですが、Markdownの基本的な記法であるはずです。

  • *」または「_」で囲んだ<em>。ただしXDITAだと<i>
  • **」または「__」で囲んだ<strong>。ただしXDITAだと<b>
  • [表示する文字](URL)」でリンクテキスト。
  • ![代替表示文字列](URL)」で画像

インラインの整形済みテキスト記法の「`」囲いについては記述が見つけられませんが、
DITA-OTの処理を見ると有効のようです。

さて、Extended Profileについてです。

メタデータはYAML Frontmatterと呼ばれる記法で記述できます。ファイルの先頭、つまりトピックタイトルよりも先に、「---」と書かれた行に挟まれた部分に、設定記述用言語のYAML[8]を用いてトピックのメタデータを記述します。

メタデータに記述できる内容についてMDITAのイントロダクションページにはあまり記述がなく、例も次しかありません。

  • id
  • author

MDITA(のExtended Profile)と同じ表現力のXDITAにはDTDがあるので見てみると、
厳密には設定されていないようです。また、『Creating Intelligent Content with Lightweight DITA』[7]には次のようにあります。

Those attributes can provide information like the language of a topic, critical dates for a topic (creation, last revision, expiration, etc.), and much more.

DITA-OTのMarkdown Contentのシンタックスページは厳密にはMDITAのページではありませんが[9]、keyword, category, sourceといった項目をメタデータに設定している例があります。DITA的な文書の記述を行うなら、こういった情報を記載することはファイルの取り回しに有用でしょう。


---
id: topic-id
author: antenna
category:
- "markup"
keyword:
- "mdita"
- "markdown"
---

HTMLタグでの記述もExtended Profileの分類です。この部分の書き方の詳細はHDITAについての記述を読むことになります。
注意点として、HTMLタグで始めて閉じるまでの箇所の内部はMarkdownの記法は使えません。
先ほどのメタデータもHTMLタグで記述が可能です。

Creating LwDITAのサポートページと見なしてよいであろう、Carlos Evia氏のlwdita-bookのリポジトリ[10]に、MDITAの追加サポート記法として
定義リストと脚注の記法が記されています。



DT
: DD

空白行の後に行頭からタイトル<dt>、次行の行頭に「:」、半角スペースから<dd>、内容の記述を行います。空白行で終了、
行頭に「:」と半角スペース始まりで次の<dd>です。PHP Markdown Extra記法から、とあります。

脚注は、アンカーに「[^アンカーID]」、脚注内容を「[^アンカーID]: 内容」で記述します。


XML[^xml]は、…

[^xml]: Extensible Markup Languageは、…

他に、noteを記述する記法として「<div data-class="note">」がありましたが、MDITAでは非推奨となったということです。

次週にLwDITAで使えるDITAの機能について紹介する予定です。

参考資料

  1. [1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-lightweight-dita
  2. [2] アンテナハウス XML/DITAサービス
  3. [3] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
  4. [4] DITAコンソーシアムジャパン
  5. [5] Lightweight DITA: An Introduction Version 1.0
  6. [6] DITA Open Toolkit
  7. [7] Creating Intelligent Content with Lightweight DITA
  8. [8] https://yaml.org/
  9. [9] https://www.dita-ot.org/dev/topics/markdown-dita-syntax-reference.html
  10. [10] https://github.com/carlosevia/lwdita-book

DITA/XML Service Antenna House

関連記事

  1. XMLエディタで始めるリッチなMarkdown入門?
  2. DITAとしてのMDITA
  3. Markdown DITAとMDITA
  4. XMLをMarkdownに変換することについて



瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成
Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 49 50 51 Next