「Markdown+CSS/TeXで冊子本を作ってみた」に参加してみた

開始前

記事中のAmazonのリンクはアフィリエイトにしていますので嫌悪感を抱かれる方は気をつけてください。

アンテナハウス株式会社*1様主催のセミナーに参加してきました。以前『PDFインフラストラクチャ構造解説』のPOD（Print On Demand）本を買ったときに存在を知り、ウェブサイトの「XMLに命をかけてくれ」というエピソード紹介が印象に残っていました。大規模、構造的ドキュメント用のソフトウェアに強みのある会社という理解です。

PDFインフラストラクチャ解説: 電子の紙PDFとその周辺技術を語り尽す

作者: 小林徳滋
出版社/メーカー: アンテナハウスCAS電子出版
発売日: 2017/02/26
メディア: Kindle版
この商品を含むブログを見る

開催が平日の13時30分からだったので、業務で来る人でないと辛いですね。業務で使う人がターゲット層だろうし、それはそう。

しっかり準備したと思ったらバッテリが2時間分くらいしか残ってなかったり、電源タップ持ってきていなかったり、以前間に合わせで作った名刺すら5枚も持ってきていなかったり。

以下、メモ内容は引用の形を取っていますが、話された内容そのままではないです。

挨拶

アンテナハウス社の小林氏による挨拶。それこそMS Office文書の実体などでよく使われるXMLですが、

「紹介をするときに『XML』というとは人気がないので『構造化文書』といっている」

とのこと。これを処理するソフトウェアは

「アンテナハウスの売上の $\frac{1}{3}$ は占める」

そう。けれど、

「もう少しソフトウェアへの門戸を広げたい」

ということで、簡易記法をやっていると。

10年ほど前からCAS-UBという記法を提供しているが、やはり難しいものになっている。そこで、Markdownなら使ってもらえるのでは

氏は技術書典にはこれまで落選1回を除けば6回参加。Markdown+CSS（+ AHFormatter）で冊子本が作れることを確認できた。

Markdownの扱いについてはアンテナハウスはまだ素人ということで、先達であるところの鹿野さんに発表してもらうことに。

「『冊子本』の概念について、社内では『冊子本とは』レベルだった。巻物に対しての定型製本が冊子本ということで今回はやっていく」

CAS-UBの記法はこれですね。

www.cas-ub.com

なんというか、必要なものを全部作ると実際こんな感じになるよね、という感じの記法です。 Markdownと比べると「覚える必要項目がこんなにある」という印象がでてしまう気がする。個人的にはreST*2あたりの配分はかなり上手いと思っていて、簡易な書き方のできるものと何のインラインorブロックなのかを書くタイプのものを用意した方が結果的に暗記しておくべき量は減るし見通しも良い気がする。

会場では技術書典7で頒布していた「簡単！ **Markdown+CSS**による冊子本作り」がまわされていました。今回のアンテナハウス社の発表内容の $\frac{1}{3}$ くらいはまとまっているので興味がでてきた方はどうぞ。私は書典で購入したものを持参しましたが。

web.antenna.co.jp

冊子本の原稿としてMarkdownを扱う

ラムダノート株式会社鹿野氏の発表。

ラム社の紹介

ラムダノート社の紹介。特色として挙げられたのは

原稿形式を著者に強制していないこと。

これまで出版した本では

本	組版
Haskell本	$L A T E X$
数式組版	$L u a L A T E X$
IPv6本	HTML
定理証明手習い	HTML
Goによるシステムプログラミング	reST（+Sphinx）
みんなのデータ構造	DocBook(to $L A T E X$ )
RubyでつくるRuby	Markdown (to HTML )

ラムダノートの出版物は直販サイトであると『紙版』『電子版』『紙+電子版』が選択できるのが嬉しいですね！電子版は内容アップデート時にも追従！

www.lambdanote.com

Markdownとは

daringfireball.net

オリジナル版としては

プレーンテキストの整形をする記法
それをHTMLに整形するツール（Perl製）

欧文圏は元々アスキー記号で文章をエディタ上で装飾する文化があった

「Markup Language」は構造定義をするもの。「Markdown」は「装飾」のためにある、という出発点

それでもそれを凌駕する利点がある

Markdown は Free Software(BSD 系)

で、強調されたのは Markdownは装飾であり、構造化（Markup）ではない ということ。後にも出てきますが、これを踏まえて使う必要があるということでした。アンテナハウス社の発表を聞くと、確かにここの認識の差で苦しみが発生したのではないかという点があったり。

Markdownの現在

実装者の数だけある。オリジナルは多分現在ほとんど使われていないのではないか

Markdownの○○方言などと言われたりしますね。オリジナルからして「足りないところはHTMLで書けばいい」という思想なので、実装先で拡張されるのは必然なんですよね。

ところで $T E X$ はプログラミング言語なので、Markdown処理系も実装できるんですねぇ。突然鹿野氏ご自身で実装されたMarkdown on $L A T E X$ のデモが始まる。

note.golden-lucky.net

$L A T E X$ とは

プレーンテキストを整形する記法
- テキストエディタ上で文書の見た目を指示できる
- 構造化のためのものではない
そのテキストを「PDFへ変換」できるツール

:thinkng_face: になる人がいそうな文になっていますが、 TPO*3を考えるとこういう説明にはなりますね。構造的に書くことと構造的であることは別の話なんでその辺りが話されているのも良かった。

$L A T E X$ も「記法」であり、「表現への変換ツール」である 構造化文書のことは忘れろ

Markdown+[tex\LaTeX{}]

素朴な間違いの紹介として

LaTeXではPDFを作れるので、Markdownの記法をLaTeXに変換すればPDFが作れる？

という気持ちが紹介されました。分かる、分かるなあ。そして夢破れてMarkdownを物理本に使わなくなったんですが。

で、これは間違いなので

構造ではなく記法と表現の層で捉える。表現の層でのつらみをスタンスとして持っておく必要がある

HTMLでの表現の不足分はHTMLで書くように、 $L A T E X$ の不足は $L A T E X$ でカバーすることに。でも、それはしたくない。Markdownでは難しいのは数式、採番、相互参照を解決する必要がある。このあたりはMarkdownとHTMLの関係と似ている

そこでPandoc

pandoc.org

Pandocの本懐は多様なドキュメント形式が暗黙的にもつ構造を「Markdownの構造」で把えるためのツールであること

n月刊ラムダノートはmdからメタ情報を抽出注入してupLaTeX+dvipdfmx。7人くらいの著者でまわしてもらってると思う

Pandocの持つ型はMarkdownの記法から自然に得られる最低限のドキュメントの構造

最低限のみなので、見た目で原稿をごまかせる余地がある

表現力が限定的であることの利点は、複数著者の記事でも統一感を出しやすいこともあるようです。

構造を補う豊富なツールチェインも

冊子本で使える拡張

YAML Metadata Book

YAML自体が記法の一部になっているともいえる

YAMLが本当に使いやすいのかは置いておいて、本文要素とは独立した設定であるメタデータは設定記述言語で書けた方が嬉しい。それはそう。

XML/HTMLに慣れてしまった人は生タグで書くし、 $T E X$ に特化してしまった某塾などは何もかもアレな言語で書いてしまったりしますが……

pandoc-citeproc+CSL(citationstyles.org/)

LaTeXにサイテーションを任せるべきではない一瞬 :thinking_face: になりましたが、 $L A T E X$ 変換後に.texにサイテーションを足していくのではなく .mdの段階で書けるようにする、という話っぽい？

今新しく考える必要がない

codeblock

ハイライトなど、LaTeXに任せることもできる

脚注

アンカーと本体を分けて記述できる

メモから拡張名が抜けてました。 $L A T E X$ は、少なくとも基本はアンカー部分にそのまま本体を記述するのでパッと見分かりづらいんですよね。

Pipe Tables

PHP Markdown Extraっていってたかな。

これが多分一番分かりやすい。レンダリングを完全制御できるわけではない。キャプションの記法はイケてない

やっぱりプレーンテキスト状態を考えると、アスキーアート的な表現の表が1番見易いんですよね。左・中央・右寄せ用の指示記号もあるので大抵は困らないし。

でもやっぱり複雑な図表や記述と装飾後の見た目が不一致な項目には弱い。発表ではなかったものの、先に挙げたMarkdown+CSS本では「やっぱり図表はGUIが欲しい」旨がありましたが、完全にそう。

Pandoc フィルタ

Pandoc内部型の値を直接プログラムで操作できる

「本文内の行コメント」のような仕組みを導入するのも可能。文字置換も容易に自力でいける。

例えば、他社ではRust本の執筆をしてそうな『n月刊ラムダノート』ではパターンマッチの記事を書いた著者の方の名前表記はプレーンテキスト中の本文と実際の表記が異なり、これを変換時に処理するなどもしたとか。

課題

生のLaTeX記法を埋め込めるか（HTMLよりも構造化がないので厳しい）
- MarkdownにHTMLを埋め込めるのはHTMLが記法であり構造であるから
- 素のPandocで対処できないエスケープ記法の違い
- LaTeXの数式記法は今のところ一番楽だと思う
- 索引については検討中

$L A T E X$ では\から始まるとMarkdownには存在しない、コントロールシーケンスかと思われたり、 %ではコメントアウトになったりとか、そういうところですね。

XML的な、構造を埋め込む考えではなく、むしろ構造を暗に表す記法そのものは問題になる PandocはMarkdownに対し補完的に使える

Markdown+CSS?

CSS Paged Media Module によってWebブラウザで可能な表現をPDF表現側に持ってくる？

補足

n月刊ラムダノートにおけるMarkdown執筆のワークフローの紹介。かなりよくできていると思います。

記事の書き方

記事の執筆には、Markdown形式を利用してください。 Markdownにはさまざまな流派がありますが、GitHub Flavored Markdown（https://github.github.com/gfm/ ）をベースとした書式を採用します。

書籍を執筆するための形式として考えると、Markdownには不足している機能が多々あります。しかし、次のような利点があるので、Markdownを採用することにします。

最低限の構造しかないので、見た目でごまかせる余地が少ない
原稿を著者自身が再利用してもらいやすくしたい
ラムダノートで販売する際のスタイルは、原稿の形式がなんであれ、別に考えなければならない

以下では、節や項といった記事の大構造、および、段落やコードや図表といった記事の小構造について、執筆にあたって気を付けていただきたいことや記述方法のお願いをまとめます。

目次
- 記事の大構造：見出しの構文、考え方
- 記事の小構造：段落や図表、コードなどの構文、考え方
- 本文の書き方：本文の考え方
- 書式に関してサポートしないこと：スタイルに関する制限と注意事項

記事の大構造

記事全体をどう構成するかは、解説する内容や目的（情報の要約かチュートリアルか、など）によって異なります。論文ではないので定型はありませんが、困ったら下記の構成に沿って考えてみてください。

何のために記事を書くか（問題意識を読者と共有）
解説の前提となる情報の整理（読者を記事の土俵に上げる）
主たる解説
まとめ、練習問題、関連情報、参考資料など

最上位の階層に対する見出しには、都合により、Markdownのレベル2（ ## ）を利用してください。

通常、大構造の内部は、さらに構造化したほうが読みやすくなります。しかし、構造が深くなると読者が迷子になりやすいので、大構造の下位は原則として1段階のみとします。

上記をふまえると、記事全体の構造は下記のようになります。

## セクション1の見出し

段落要素

### サブセクション1の見出し

段落要素

### サブセクション2の見出し

段落要素

## セクション2の見出し

段落要素

…

記事の小構造

記事の本文のほとんどは、段落です。段落は、文章の意味の最小単位といえます。

以下では、段落および段落を補完する箇条書きや図表、コードブロックなどの要素についてまとめます。

段落の書き方

段落を書くときは、以下の2点を気にかけてください。

ある段落を1つ取り出したとき、その内容を簡潔に要約できるか
段落と段落の関係は、全体として伝えたい内容にとって適切か

上記の2点を達成するために、編集でかなり大胆な本文の修正を提案する場合があります。そのため、差分が見やすくなるように、段落内ではなるべく句点ごとに改行を挿入してください。

段落は次の要領で記述します。

空行から次の空行までの文章が、1つの段落になります。
途中で改行しても、新しい段落にはなりません。
むしろこまめに改行したほうが、差分がとりやすくなります。

段落内および段落間をうまく構成すると、言いたかったことが伝わりやすい記事になります。
各段落の内容を自分で要約しながら自分で読み返してみるのがおすすめです。

本文で利用可能な記法については、本稿の後半の「本文の書き方」の項を参照してください。

箇条書き

段落の主張を見やすく整理することを目的として、必要に応じて箇条書きを利用してください。言い換えると、箇条書きはあくまでも段落に従属するものとし、箇条書きのみで説明が終わることがないように注意してください。

箇条書きには、連番がつかないものと、つくものがあります。それぞれ以下の要領で使います。

箇条書き（Unordered List）

基本的には連番なしの箇条書きを使います。

* 項目1
  * サブ項目は1階層のみ可
* 項目2
  1. 連番つき箇条書きのサブ項目の例

連番つき箇条書き（Ordered List）

項目間の順序に意味がある場合や、あとで番号で参照したい場合は、連番つき箇条書きを使います。
```
1. 項目1
2. 項目2
```

図

段落の説明を補足することを目的として、必要に応じて図表を利用してください。

画像は以下の要領で配置します。なるべく見出しを付けてください。

![キャプション](/path/to/image.data){#fig:id}

キャプションとIDを指定した図は、本文から下記のようにして図番号により参照できます。

……。図[-@fig:id]に〇〇のようすを示す。

表

表の書式についてはPHP Markdown Extraの書式（Pandocでいう pipe_tables 拡張）が使えます。

PHP Markdown Extra のTableに関する説明

表の記述例を下記に示します。表のタイトルは、 Table: で始まる行をテーブルの下に記述してください。本文からの参照方法については後述します。

| 右寄せ | 中央寄せ | 左寄せ |
| -----: | :------: | :----  |
| 123456 | 〇       | ABC   |
| 00     | ✔       | あいう |

Table: タイトル{#tbl:id}

キャプションとIDを指定した表は、本文から下記のようにして表番号により参照できます。

……。表 @tbl:id に〇〇の一覧を示す。

コードブロック

技術書において、プログラムの一部を示したコードブロックは主要な解説対象です。したがって、コードブロックの提示をもって説明を終わらせるのではなく、そのコードについて日本語で説明を施すようしてください。具体的には、次のような内容を説明してください。

なぜ本文のこの位置でそのコードを提示するのか
何を実現するコードなのか
コードの各部にはどのような役割があり、どのように動作するか

プログラミング言語のコメント機能を使ってコード中に動作の説明を付記するのは、上記のうち3のみにしてください。コメント機能によるコードの動作の補足説明は、コードの中身をしっかり読む段階にある読者にとってはとても有用ですが、初見ではあまり読まれません。特に上記の1と2の内容については、本文でしっかりと解説するようにしてください。

コードブロックを示すときは、原則として下記の書式を使ってください。本文からの参照方法については後述します。

```{#lst:id python caption="あいさつ"}
def greeting():
   print ("Hello World!")
```

以下は実行結果。

```{#lst:id sh caption="実行結果"}
$ python greeting ⏎
Hello World!
```

キャプションとIDを指定したコードブロックは、本文から下記のようにしてリスト番号により参照できます。

……。[-@lst:code1]に〇〇の例を示す。

コードブロック開始行の {...} 内には、本文でコードを参照するときのIDとキャプションのほか、さまざまな属性を記述できます。

構文ハイライト

主要なプログラミング言語については構文ハイライト（モノクロ）に対応しています。

sh もしくは console は入力画面であるとみなし、次のような特別な表示上の扱いを受けます。

出力の背景色と文字色を反転させます（通常は白地に黒文字であるものが黒地に白文字になる）
末尾が ⏎ の行はユーザ入力を表すものとして太字化する

行番号

コードブロックの左側には原則として行番号を出力します。

行番号が不要な場合には、コードブロック開始行の {...} 内に number="no" を指定してください。

ページ分割

コードブロックは原則としてページ分割されません。

長いコードブロックでページ分割を許可するものは、コードブロック開始行の {...} 内に break="allow" を指定してください。

引用

他の文書からの引用には、下記の書式を使ってください。

本文

> 引用文
> 引用文

本文

引用のみで説明を済ませることは絶対にしないでください。引用は、本文を補足する目的に限ります。出典も必ず明記してください。

補足説明（NOTE）

引用のスタイルの1行めを「node」にすることで、本文から脱線する話題や注意書きを記述できます。

ここは通常の段落。

> note
>
> コラムの本文は、インデントさせた段落として執筆してください。
> コラム内にも箇条書きや図表、コードなどが挿入できます。
>
> * サブ項目a
> * サブ項目b
>  
> ```
> Hello World!
> ```
>
> コラムの終わりには、空行＋インデントしていない行が必要です。

ここからは次の段落本文になります。

脚注

脚注が使えます。

脚注を挿入する場所に、 [^anchor] （角括弧の中に^を先頭文字とした一意な文字列）の記法でアンカーを記述
脚注の中身は、本文より後ろに、空行を挟んで行頭から [^anchor]: … のように記述（アンカーの直後に : で挟んで改行なしで文を入れる）

ここは本文です[^anchor]。
文末に脚注を挿入する場合は、この例のように、句読点の前にアンカーを設置してください。

[^anchor]: 脚注の本文。本文に設置したアンカーと同じ文字列段落をには改行を入れないでください。

アンカーに使う文字列（上記の例では anchor）は、単純な連番でなく、脚注の内容を表す一意なものとしてください。

ディスプレイ数式

$$ のみの行から、次の $$ のみの行までの間に、下記の要領でLaTeXの書式を記述してください。どのようなLaTeXコマンドに対応するかは未定なので、そのつど相談してください。

$$
\hoge
$$

この形式で数式以外のもの（図表など）を入れ込むことはしないでください。

参考文献

refs.bib と命名したファイルに、BibTeXの形式で書誌情報ファイルを用意してください。

@article{foobar2019,
     author = {Doe, John.},
     title = {FooBar},
     year = {2019},
     url = {http://example.com/foobar},
     ...
}

本文では以下のようにしてcitationを記述します（読点の位置に注意）。

…… [@foobar2019]。

本文の書き方

段落などを構成する本文は、敬体でも常体でもかまいません。

以下では、本文における装飾や約物の使い方などを簡単にまとめます。これ以上に細かいシンタックスやレギュレーションを設定する予定はありません。

本文に対する装飾

本文中では、文字列に対する装飾として、下記の書式のみを利用してください（␣ は半角スペース U+0020 を意味します）。

␣**文字列**␣ （文字列を強調）
␣`文字列`␣ （文字列を等幅で表示。` を含める場合には、連続するバックチックで囲む ␣`` `を含む文字列``␣ という書式を使う）
文字列（[URL](URL)） （文字列に対して外部のURLを参照。「URL」の部分は同一の内容を入れる。 [文字列](URL) のようなURLを見せないリンク形式は不可）
␣$TeX書式$␣ （インライン数式）
行頭の ★ マーク（行末までを、本文ではなくコメントとして扱う。行頭以外の ★ マークは非コメント）

句読点

とくにこだわりがなければ、 。 と 、 を推奨します。 ． と ， 、もしくは 。 と ， などでもかまいませんが、編集で 。 と 、 に変更する可能性があります。

いわゆる半角の . および , は句読点としては使わないでください。

疑問符および感嘆符をどうしても使う場合は、それぞれ全角記号を使用してください。すなわち、 ？（U+FF1F）および ！ （U+FF01）を使ってください。

コロンやセミコロンを使う場合も、全角とします。すなわち、 ： （U+FF1A）および ；（U+FF1B）を利用してください。

和欧文間のスペースについて

日本語の文字と英数字間にスペースは入れないでください。

括弧類について

本文中での補足には、なるべく全角の丸括弧 （ および ） を使ってください。それぞれ、具体的には U+FF08 および U+FF09 です。

本文中で文字列を意味的に切り出したい場合には、基本的に鍵括弧（「 および 」）を使ってください。言い換えると、日本語を切り出す際にダブルクォーテーションは使わないでください。

書式に関してサポートしないこと

書式に関して期待されるであろう事項のうち、下記の点に関しては最初からサポートしないものとします。

一定の見た目

WebブラウザやPDFで、上記の書式がどのような見た目で表示されるかは、書式から一意には定めないことにします。 GitHubに貼り付ければ、そのWebサイト上で一定のスタイルでレンダリングされると思いますが、そこでの表示を整えることはがんばらないでください。

そもそも上記の定義には、GitHub上で意図したようにレンダリングされない要素もいくつかあります。たとえば、そもそも数式に関しては、GitHubで意図通りにレンダリングされることはありません。コメントについても同様です。脚注についても、本文以外の場所に表示されるようなものはありません。

view raw writing.md hosted with ❤ by GitHub

記事の書き方 · GitHub

マークアップへのスタンスについては

golden-lucky.hatenablog.com

も良い記事だと思います。

Markdownでどうやって原稿を書くか

こちらの発表はアンテナハウス小林氏。

Markdown概観

対象の内容を散文に限定して読みとり、編集を容易に
- そのままではドキュメント、冊子には向かない？

HTMLメタタグ

HTML全体ではなくbodyの一部
Markdown部分はMarkupが少なく可読性が高い

CommonMark

Markdown like をMarkdown記法
HTMLタグもどきをHTML記法と呼ぶ。MarkdownはHTMLとHTML Likeを区別しない
複雑なのはHTMLでいいやんという方針だったので
CAS記法つくってたけど、Markdownの方がええやんと思ってたけど、曖昧さがある
- Standard Markdownの動き(2012~)
- 原作者から不評、2014にcommonMarkに改称
めっっっっちゃ複雑な仕様。600くらいサンプルがあるが……。リアルタイムプレビューと併用すれば現実的？
参照実装CとJavaScript(BSD)
Pandocの人が中心

<hoge>fuga</hoge>のようなHTMLに含まれないのがHTMLタグもどき。XMLによってはXMLタグになったりするのもありますね。

Markdown

Markdown記法の説明が主なので、メモで抜けてるところは普通にMarkdownのドキュメントで補完できます。

Unicodeで本文
PlainText, ASCII句読点文字, 空白, 空行で構造を付加（マークアップ）
- まだASCII句読点を使いきっていない
ブロック要素(HTML5ではフロー)内容はフレーズのみ
- p, headings, codeblock, hr
コンテナブロック
- フローかつネストフローがネスト可能
Headings
- ATX方式（# hoge）
- setext方式（= の下線h1, -の下線h2）, 複数行対応？
CodeBlock
- 4indent式
- コードフェンス記法方式（3~または3```）
水平線
- 3以上の-、直前に文字を置くとh2になってしまう
list
- Bullet List
- Order list
強調
- _ or * _の場合スペースが要る
コードスパン ```
link, 外部と内部, リンクテキスト
- full, collapsed, shortcut
- autolink, email auto link < abspath >
Image
- inline
- ref link
- full
強制改行。オリジナルでは2スペース、 CommonMarkでは\

MarkdownにならないHTMLタグ

Ex: section,がない
div, span の範囲指定
Tableの標準がない

構造化というか、任意のブロック・インラインを作る仕組みがない。当たり前なんですが、アプローチを結構変える必要が出ますよね。

対処

HTML直書き
処理系で工夫
Markdownを拡張
- Ex: GFM,

1がいいと思ってたけどPandocもありかなと先刻の発表を聴いて思った

Pandoc詳しくは知らなかったんですね。道理でつらみが極まるコードががが。

HTMLとMarkdownの混在

マークアップの文字扱いが異なる
- HTML文脈でのASCII句読点文字マークアップは解釈されない
CommonMarkではHTMLブロックが明確。7種
- 開始条件、終了条件
インラインでは形式的にタグとみなせればHTMLとしておく
- OK: Foo <responsive image src="hoge.jpg" />
- NG:

同じ文字でも、改行空白などの文脈で解釈が異なる

冊子本の形を作る

版面
図版の大きさの別途マークアップ
索引
脚注

索引

CF.W3C JLREQ

冊子本の構造について、スライドの図ではAppendix前にあとがきが。

あとがきはJLREQでは索引後では？みたいなバトルをした

Markdown+CSS+AHFormatterによるPDF化

処理の流れを説明する発表。

に書いてあるので（というかバッテリが切れたので）メモ省略。

ドキュメント用のMarkdownは全て結合してから処理をしていく流れのよう。

Balisage: Markup 2019 発表の抄

Balisage フランス語で「マークアップ」

元文書は45ページ、今のスライドでは無理なので抄で

この発表はかなり新鮮味の強い内容でした。おっしゃられたようにかなり駆け足だったので抜けがあるかも。

https://www.antenna.co.jp/AHF/ahf_jirei/pdf/201909/Loose-leafPublishingUsingAntennaHouseAndCSS-J.pdf

ルーズリーフ出版とは

Page番号は変更せず内容を更新していく出版方法
「加除式書籍」の名が一般的
法令出版などではよく要請される
ページ更新が入ると1.10など

需要

低コスト出版手段がない時代は一般的だった（版をつくるコスト）
法文書
- 古い版の保持の必要
- 2000ページなどの量
- ライフサイクルがめっちゃ長い
- 日常業務で紙に書きたしたりしている

Municodeとは

アメリカの地方自治体条例出版のサプライヤ
XPP製品で作成
- SGMLで作成

AHFormatter+CSS との関連

XPPを従来の組版システムとして使っていたが、使いこなしていない XPPのオペレータが限界今回交換時期と判断 AHFormatterにはそのままではポイントページ番号・参照生成の直接生成機能がない

CSSなら敷居が低い。ルーズリーフ機能はAHFにもなかった

課題

diffのとりかた
参照生成

エリアツリー 概念

TOCなど、組版更新DBがいる

ビジネス要件

条例はWEBでも公開されているので

ワンソースマルチユース
XPPの変換が安定していなかった

CSS 組版の課題

オペレータのハードルが低い
素ではXMLに対して不十分
各種参照の生成
構造化ヘッダフッタ
ソース順序関係ない要素の並べかえ
多くの要件では通常のCSS技術で可能

XML用意

この辺りはスライド公開待ち。

ページ端にのせる情報

エリアツリー

構成されたページのXML表現
段落が複数ページにまたがると複数のエリアツリーが含まれる
AHFはエリアツリーを入力から生成
これをもとにPDF

info

各変更の開始と終了 (Municode ではtake)

process

形式、番号の設定
更新

今後

更新の自動化
- DeltaXMLなどの古いツールでは2エリアツリーの比較、シーケンスの変更を判断、必要に応じてマーカーを足す
更新履歴の反映するエリアツリーへ変更ページ挿入の自動化
Municodeでは現在PDFで手動、これを必要に応じてエリアツリーを変更するものへ自動化を実現

AHF次期バージョンと目指すもの

概略

20周年
大量多言語データに最適な自動組版ソフト.
XSL-FO, CSSでXML/HTML
XSL1.1に対応

XSL-FOが元々の強み

各種形式への出力

多言語が要る企業でのマニュアルなど

タグ付きPDFもできるとのこと。

タグ付きPDF: 仕組と制作方法解説

作者: アンテナハウス株式会社
出版社/メーカー: アンテナハウス株式会社CAS電子出版
発売日: 2017/10/09
メディア: Kindle版
この商品を含むブログを見る

XSL-FOはW3Cの勧告するXMLをドキュメントとして綺麗に出力するための規格、でいいのかな。

www.w3.org

XSL-FOの基礎　第2版: XMLを組版するためのレイアウト仕様

作者: アンテナハウス株式会社
出版社/メーカー: アンテナハウスCAS電子出版
発売日: 2017/03/28
メディア: Kindle版
この商品を含むブログを見る

docs.oasis-open.org

jats.nlm.nih.gov

tei-c.org

世の中は知らなかった仕様でいっぱいだ……。

目標

海外の顧客が増えてきたとのことで、必然と要望が上がるようです。

NEWS

http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-part0-overview.html

欧文分割アルゴリズムがTeX系ライクな挙動にってことでいいのかな。

質疑

ラムダノート社代表からMarkdown+CSS+AHFormatterへの質問。回答をちゃんと聞きとれていないかも。とりあえず索引用マークアップを機械的（素直に？）に処理していると。

これは参考です。

note.golden-lucky.net

dailyportalz.jp

JATSをバリバリに利用している方からPandocの利用可能性についての質問。応答は鹿野氏。軽量マークアップ変換ツールの類使ったことのある方は分かると思うんですが、デフォルトの挙動って「よく分からないけどいい感じにしてくれる」方向のがほとんどなので、謎の補正処理的なのが色々くっついたりするんですよね。出力を予想できるレベルにならないとクリティカルなブツは本当につらいと思います。況んやMarkdown to Pandocをや。

Vivliostyle代表からAHFormatterのCSS対応レベルについての質問。これから更に頑張る旨の返答。

blog.antenna.co.jp

会社としてのVivliostyleは更にトリムマーク株式会社になって、というのはおいておいて、 HTML+CSS 組版のVivliostyleの源流はここにあったんですね。

vivliostyle.org

終了

名刺交換会の時間、こういう身分だとかなり萎縮してしまう……。何人かご挨拶させていただきました。

軽く会話した内容ですが、

note.golden-lucky.net

この辺に集約されるなあ。

あとアドベントカレンダーへのプレッシャーが上がったりしました。自業自得……。

adventar.org

なんか情報量ない割に長くなってしまったのでスライド公開とかされたら不要箇所削りたいですね。

*1:

https://www.antenna.co.jp/

*2:http://docutils.sourceforge.net/rst.html

*3:DVIやPSの話は今回は関係ないので。

別名：Laughing and Grief 雑記

「Markdown+CSS/TeXで冊子本を作ってみた」に参加してみた

開始前

挨拶

冊子本の原稿としてMarkdownを扱う

ラム社の紹介

Markdownとは

Markdownの現在

LATEXLATEXとは

Markdown+[tex\LaTeX{}]

そこでPandoc

冊子本で使える拡張

YAML Metadata Book

pandoc-citeproc+CSL(citationstyles.org/)

codeblock

脚注

Pipe Tables

Pandoc フィルタ

課題

Markdown+CSS?

補足

記事の書き方

記事の大構造

記事の小構造

段落の書き方

箇条書き

図

表

コードブロック

構文ハイライト

行番号

ページ分割

引用

補足説明（NOTE）

脚注

ディスプレイ数式

参考文献

本文の書き方

本文に対する装飾

句読点

和欧文間のスペースについて

括弧類について

書式に関してサポートしないこと

一定の見た目

Markdownでどうやって原稿を書くか

Markdown概観

HTMLメタタグ

CommonMark

Markdown

MarkdownにならないHTMLタグ

対処

HTMLとMarkdownの混在

冊子本の形を作る

見出しIDのマークアップ

図版マークアップ

表のマークアップ

脚注のマークアップ

参照のマークアップ

索引

CF.W3C JLREQ

Markdown+CSS+AHFormatterによるPDF化

Balisage: Markup 2019 発表の抄

ルーズリーフ出版とは

需要

Municodeとは

AHFormatter+CSS との関連

課題

ビジネス要件

CSS組版の課題

XML用意

エリアツリー

info

process

今後

AHF次期バージョンと目指すもの

概略

目標

NEWS

質疑

終了

$L A T E X$ とは

CSS 組版の課題