自己顕示欲の開放治療所

erg, programming and something.

別名：Laughing and Grief 雑記

Latin and Greekは習ったこともない

真面目な記事の他、特定の方には不快と思われる事柄に関して言及を行うことがあります。ちょっと頑張りますが、Blog内で解決できなかった場合要望があれば別ページに技術記事は書き直します

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

Markdown LaTeX CSS LWML PDF

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

connpass.com

2019/11/16 訂正 訂正いただきました箇所、打ち消し線と + 記号で大体わかるように、なっているといいな、しました。

開始前

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

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

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

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

開催が平日の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本 \LaTeX{}
数式組版 Lua\LaTeX{}
IPv6本 HTML
定理証明手習い HTML
Goによるシステムプログラミング reST（+Sphinx）
みんなのデータ構造 DocBook(to LaTeX) + 原著者プリプロセッサ付きLaTeX
RubyでつくるRuby Markdown (to HTML )
+ プロフェッショナル SSL/TLS + DocBook

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

www.lambdanote.com

Markdownとは

daringfireball.net

オリジナル版としては

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

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

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

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

Markdown は Free Software(BSD 系)

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

Markdownの現在

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

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

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

note.golden-lucky.net

\LaTeX{}とは

  • プレーンテキストを整形する記法
  • そのテキストを「PDFへ変換」できるツール

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

\LaTeX{}も「記法」であり、「表現への変換ツール」である 構造化文書のことは忘れろ

Markdown+[tex\LaTeX{}]

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

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

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

で、これは間違いなので

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

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

そこでPandoc

pandoc.org

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

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

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

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

  • 読み返してみると、訂正前のメモ論理おかしいですねここ。申し訳ないです。

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

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

冊子本で使える拡張

YAML Metadata Book

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

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

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

pandoc-citeproc+CSL(citationstyles.org/)

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

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

codeblock

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

脚注

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

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

Pipe Tables

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

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

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

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

Pandoc フィルタ

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

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

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

課題

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

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

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

Markdown+CSS?

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

補足

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

記事の書き方 · 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の標準がない

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

対処
  1. HTML直書き
  2. 処理系で工夫
  3. Markdownを拡張
    • Ex: GFM,

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

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

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

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

冊子本の形を作る

見出しIDのマークアップ

同じ名前の見出しのID重複を避けるため処理がいる

図版マークアップ
  • HTMLタグ
表のマークアップ
脚注のマークアップ
参照のマークアップ
索引
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とは

AHFormatter+CSS との関連

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

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

課題
  • diffのとりかた
  • 参照生成

エリアツリー 概念

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

ビジネス要件

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

  • ワンソースマルチユース
  • XPPの変換が安定していなかった
CSS組版の課題
  • オペレータのハードルが低い

  • 素ではXMLに対して不十分

  • 各種参照の生成

  • 構造化ヘッダフッタ
  • ソース順序関係ない要素の並べかえ
  • 多くの要件では通常のCSS技術で可能
XML用意

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

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

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

process
  1. 形式、番号の設定
  2. 更新

今後

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

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

概略

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

XSL-FOが元々の強み

各種形式への出力

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

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

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

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

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

www.w3.org

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

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

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

note.golden-lucky.net

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

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

adventar.org

adventar.org

adventar.org

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

*1:

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

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

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