2019-11-26

Sphinx howtoとmanualのLaTeXでの設定を読む

LaTeX Sphinx

SphinxConJP2019に参加してきました。sphinx/tex_inputsにある $LaTeX{}$ のクラスについて掠ったのでメモ。

想定

$LaTeX{}$ の事前理解度の想定は「大学のレポートで使わされたなあ」とか程度。多分。

sphinxhowto.clsとsphinxmanual.cls

$\LaTeX{}$ でのオプションにhowtoとmanualがある。これで何が変わるかというと、tex_inputsデェレクトリにあるSphinx用クラスファイルのsphinxhowto.clsと sphinxmanual.clsからどちらを選択するがが決まる。

ところで、エンジンやクラスを選択可能なconf.pyのパラメータは別にある。

「articleとかもクラスなんじゃないの？」

これは正しい。Sphinx用のクラスはLaTeXにおける「拡張されたクラスファイル」で、 article.clsなどの設定をロードし、更に独自の要素を加えたものになる。

%
% sphinxhowto.cls for Sphinx (http://sphinx-doc.org/)
%

\NeedsTeXFormat{LaTeX2e}[1995/12/01]
\ProvidesClass{sphinxhowto}[2018/12/23 v2.0 Document class (Sphinx howto)]
...

LaTeX2eで処理されることを宣言し、次にクラスファイル名を宣言している。ここでのクラスファイル名は\documentclass{<class>} で呼ばれる名前。

% 'oneside' option overriding the 'twoside' default
\newif\if@oneside
\DeclareOption{oneside}{\@onesidetrue}

@onesideというブール値を宣言し、 \documentclass[<options>]{<class>}のオプションでonesideがあったらこれをtrueにするのが最初の部分。順が前後するが、このブール値は

% Default to two-side document
\if@oneside
% nothing to do (oneside is the default)
\else
\PassOptionsToClass{twoside}{\sphinxdocclass}
\fi

で使われている。

% Pass remaining document options to the parent class.
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{\sphinxdocclass}}
\ProcessOptions\relax

他にもオプションで入ってる値が何かしらあったら親クラス、ここでは\sphinxdocclassのクラスに渡してというのがこの部分。 \DeclareOptionは\ProcessOptionsの前に置かなくてはならないので((\ProcessOptionsのときに処理されるともいう)) \DeclareOptionをまとめて記述し\PrpcessOptionsで一段落ついた後 onesideに関するif処理がされる。 \PassOptionsToClassがオプション値を渡すところ。

\LoadClass{\sphinxdocclass}

\sphinxdocclassにはconf.pyで設定したarticleなどが入る。まあプログラミング言語におけるクラスの継承と大体同じ、いやわからんけど。

howtoで説明した。 onesideはページの偶奇でレイアウトが変わらず、twosideでは変わる。 manualではopenrightを強制する。openrightでは章の始まりが常に奇数ページになる。

他に標準で読みこまれるsphinx.styとsphinxmulticell.styがあるが、こちらはhowtoでもmanualでも共通するような設定が記載されている。multicellはそのうち解説、する、かなあ。

Sphinxクラスファイルの設定（LoadClass後）

項目	howto	manual
セクショニングの階層	2	2
目次の階層	2	1
タイトル表示(sphinxmaketitle)	""	""
目次	""	""
目次調整(sphinxtableofcontentshook)	""	""
参考文献	section	chapter

基本的にはbookなどになるmanualでは改ページ命令が入ったりするのがそれぞれの項目で異なる部分。

セクショニングの階層はどちらも2で、サブセクションまでは見出しに番号が表示されるということ。基本クラスをロードするなら大抵共通になるし要るのか？

ここでの目次の階層（topdepth）の設定によって目次に反映される見出しレベルが決まる。 2だとサブセクションまで表示。

目次表示の部分、態々ページ番号表示をローマ字にするよう\pagenumberingされているが、ナウい LaTeXのクラスでは\frontmatterや\mainmatterでページ番号の書式が変えられる。人がどれだけ古いクラスファイルを使うかは想定できないので、書き換えて新しくするより、ナウいクラス用のカスタムクラスを作るべきかもしれない。

\tableofcontentshookなのだが、 Sphinxの需要の大部分であろうライブラリリファレンスでの利用に耐え得るであろう値の決め打ちをしているので、独自のドキュメントで目次出力が気に入らない場合はconf.pyの値調整ではなく $LaTeX{}$ を書く操作が必要になる。

sphinxthebibliography、 sphinxhowto.clsでは \refnameがなかったら\bibnameを使うようにif文が入っている。これはクラスファイルによって参考文献の見出し名が\refnameだったり\bibnameだったりするからで、これはむしろ今までSphinxの恩恵を受けてきて急に $LaTeX{}$ を生で書く必要がでてくるとひっかかるポイントかもしれない。

memoirクラスを設定しているときだけ定義しない命令、呼ばないパッケージがあるが、他のドキュメントクラスでもこういった例はあるはずで、これもっと上手い方法があるんじゃないかなあ。

SphinxによってreSTから変換されたマークアップは、ほとんどがsphinx<latex command>のようにラップされたものとなる。 $\LaTeX{}$ を生で書く人間が初めて軽量マークアップ変換を改造しようとして戸惑うのはこういったところかもしれない。

「sphinxhowtoやsphinxmanualで基本的に問題ないが1つのマークアップだけ挙動を変えたい」

となったときsphinx.styを手で書きかえるのは嫌であれば、ここらへんを\renewcommandで書き換えるのが恐らくなんだかんだ最小限の変更になるはず。

ちなみにmysphinx.styを作って sphinx.styを流用するようなスタイルファイルをお行儀よく作るときは \LoadPackage{sphinx} などのようにしておくと、自分で書く部分を簡単に切り分けられる（\usepackage{sphinx}を\usepackage{mysphinx}に書きかえるようなことをする場合なので、このケースはかなり問題対処がチグハグ）。

\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{mysphinx} % スタイルファイル名

\LoadPackage{sphinx}

\renewcommand{<書きかえる動作の名前>}{%

}
...

2019-11-16

「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とその周辺技術を語り尽す

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

気になった点が2つありました。まず、冒頭付近の表、DocBookは『プロフェッショナルSSL/TLS』で、『みんなのデータ構造』は原著者プリプロセッサ付きLaTeXでした（これは言わなかった気がします。表のヘッダも組版より原稿形式がよさそう）
— keiichiro shikano λ♪ (@golden_lucky) 2019年11月16日

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

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の関係と似ている

よく鹿野さんが出す図！
— ひだるま (@hid_alma1026) 2019年11月14日

そこでPandoc

pandoc.org

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

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

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

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

もうひとつ、「見た目で原稿をごまかせる余地がある」は、「見た目で原稿をごまかせる余地がない」のほうですね
— keiichiro shikano λ♪ (@golden_lucky) 2019年11月16日

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

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

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

冊子本で使える拡張

YAML Metadata Book

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

パターンマッチの記事書いてそうなメタデータだ
— ひだるま (@hid_alma1026) 2019年11月14日

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

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

pandoc-citeproc+CSL(citationstyles.org/)

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

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

codeblock

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

脚注

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

あと、脚注用のPandoc拡張の名前は、そのものずばりfootnotesです
— keiichiro shikano λ♪ (@golden_lucky) 2019年11月16日

メモから拡張名が抜けてました。 $\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の標準がない

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

対処

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

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

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

HTMLとMarkdownの混在

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

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

冊子本の形を作る

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

見出しIDのマークアップ

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

図版マークアップ

HTMLタグ

表のマークアップ

脚注のマークアップ

参照のマークアップ

参照元はMarkdownlink

索引

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版
この商品を含むブログを見る

DITA
— ひだるま (@hid_alma1026) 2019年11月14日

JATS TEI
— ひだるま (@hid_alma1026) 2019年11月14日

XMLの使われ情報
— ひだるま (@hid_alma1026) 2019年11月14日

docs.oasis-open.org

jats.nlm.nih.gov

tei-c.org

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

目標

より良い欧文組版を目指すv7
— ひだるま (@hid_alma1026) 2019年11月14日

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

NEWS

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

段落内改行位置　BPIL
— ひだるま (@hid_alma1026) 2019年11月14日

box decolation、ページまたぎ時の調整
— ひだるま (@hid_alma1026) 2019年11月14日

table-row widows orqhans
— ひだるま (@hid_alma1026) 2019年11月14日

unbreakable wordsの強化
— ひだるま (@hid_alma1026) 2019年11月14日

DropCapsに画像を許容
— ひだるま (@hid_alma1026) 2019年11月14日

GUI改良
— ひだるま (@hid_alma1026) 2019年11月14日

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

質疑

索引ID, XSLT、その規則は？　A.内部処理
— ひだるま (@hid_alma1026) 2019年11月14日

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

これは参考です。

唐突に見せびらかしたくなったので見せびらかすんですが、索引のこれ、TeXで自動でやってます。 pic.twitter.com/aVYBCc1Mzv
— keiichiro shikano λ♪ (@golden_lucky) 2017年10月27日

note.golden-lucky.net

dailyportalz.jp

PandocでのJATS出力は壊れるか？　A.表現力低いので壊れることはないと思う。でも内部処理理解してないとクリティカルな文書はしない方がいい。XSLTでできるならその方がよいのでは
— ひだるま (@hid_alma1026) 2019年11月14日

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

CSSの標準も進んでるので対応強化すべき
— ひだるま (@hid_alma1026) 2019年11月14日

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の話は今回は関係ないので。

2019-10-18

ぼくのかんがえたさいきょうの軽量マークアップ言語のためのメモ

そんなものはない。

おもったこと

Markdownの好きではないところとして、拡張記法が実装言語によってバラつくところがある。
CommonMarkはちょっとNotForMeだった。
Re:VIEWの記法は結構好きだけど書籍用処理系と構造しか今はない。
EWBでは（変換先が決まっていたためでもあるが）意味マークアップと装飾用マークアップが分かれていて分かりやすい。
メモやブログの再利用時に手直しの負担が少ない方がよい。
技術書向け以外のための記法（具体的には小説の会話文など）もちょっと欲しい。
変換時に可能なら元のファイル構造を維持したい。
構造によってはパラレルに処理できると嬉しい。

やりたいことともんだい

Re:VIEWライクな汎用記法を考えてみる。
ドキュメントのインポート機構をつける。
セクションは明示的に閉じるようにする。同じドキュメント内で開いたセクションは閉じる。
RAWブロック（インライン）系とネスト可能なブロック（インライン）の記法は分けるべきか？
設定ファイル記法。CUE or TOML？ドキュメント本体とは別記法でドキュメントに仕込むことも可能に。処理時に明示する場合
結局ベストなテーブル記法はなんなのだろうか。
preproccess, postprocessは汎用言語仕様としては悪手っぽい。
不正なドキュメントは変換失敗でよい。
文書の想定種類 カード（カンバン, コメント部のドキュメントなど）。これを最小単位とする。 アーティクル（カードを内部に含む場合がある）。 ブック（アーティクル、カードを内部に含む場合がある）。 それぞれで可能なセクショニングレベルを分ける。ブックはh1 - h6相当まで, アーティクルはh1 - h5, カードはh1 - h4とする。変換時にブックからアーティクルが呼ばれているといったとき、アーティクルのセクションレベルは1段下がって解釈される。 ** メタデータとしては上位が優先される。セクションオーサーなどのメタデータは別に分ける。
一部のマークアップについて短縮記法を用意する。

Card

タイトル（メタデータ）とh1は共通
ドキュメントのネストを許容しない

Article

タイトル（メタデータ）とh1は共通
Cardのネストを許容する

Book

タイトル（メタデータ）とh1は別
Article, Cardのネストを許容する

TODO

既存軽量マークアップでの調査
PEG学習

とりあえずこんなところか。

2019-09-25

Sphinx再入門を決めた夜

これは技術記事ではなくて日記です。念のため。

技術書典7

1週以内にはこちら単体の記事を書きますが、弊サークル「Virtual Ones」は「き41D」で「LuaLaTeX微文書作成入門」という中綴じコピ本を頒布しておりました。おかげさまで前回比

! zero division error

も売れまして、何とか参加費と印刷費を回収できました。予告しておりました通り後日PDFを公開いたします。

Sphinx

配置されていたのがドキュメントクラスタ（終了前くらいに初めて知った）だったので、そういったサークルが近場になるワケですが、今回「マークアップ同好会」の@tk0miyaさんがお隣のサークルでした。確か技術書典5でもお隣にだった覚えがあります。そのときは遅刻していったのであまり時間は長くありませんでしたが。一体何hinxのコミッタの人なんだ……。

私がSphinxをひたすらに使っていたのは2014年頃で、Pythonを使っていたからreST+Sphinxを使い始めた流れだったかと思います。周りはmarkdownが蔓延し始めていたので少しアウェイ感が。当時はSphinxで縦書き組版したかった記憶があります。LaTeXを直接書くのがつらかったからSphinxになんとかしてほしかったんだと思います。まあSphinxじゃそこはどうにもならなかったんですが。

眠くなってきたのでまとめると、多少は知識が身についてきた（と思いたい）ので返せるものがあればという思いで再入門です。あとオレオレ軽量マークアップの開発の刺激にね。

とりあえずUbuntu16.04のサポートが2021年まであるらしいので、そのあたりのTeXLiveのバージョンで動く想定はしておいた方が良さそうということで、 2014か2015年あたりから使っているLXD/LXCにUbuntu16.04とTeXLive2016を入れた。

2019-08-08

薄荷ばあやと「義務教育の頃近所に住んでいた大学生のお姉さん」と「年下の姉」「年下のママ」と「年上の妹」

R-18 感想

Preface

薄荷少女5巻が知らないうちに出ていたので読んだ。アフィリエイト付きリンクを張っておきます。また、本記事ではセクシャリティの話題が登場しますが、創作上での話、更にステレオタイプをベースとしたものであることを強調させてください。ところどころ断定口調もありますが、もちろんそんなことはない。

5巻、あるいは物語的な意味での感想としては「幸せなバッドエンド」或いは「ノーマルネバーエンド」かなというのが私の感じたことである*1。

薄花少女（５） (サンデーGXコミックス)

作者: 三浦靖冬
出版社/メーカー: 小学館
発売日: 2019/03/19
メディア: Kindle版
この商品を含むブログを見る

Intro

薄荷少女を初めて読んだのは後輩の持ってきた永遠娘*2の巻末についてきた番外編だ。マコちゃん絵日記ではないが、「いや、趣旨はそう外れてないけどここに載せて（作者は）いいの？」みたいな感想が先ず出てきた。その頃にはIKKIやサンデーGXといった漫画雑誌を読まなくなっていたから、そういう層に対するこういった新しい導線としては実はアリなのかもしれない。まず滅茶苦茶柔らかいタッチの絵と、人物の空気に驚いた。永遠娘は「○リババア専門誌」というニッチジャンルだけあってタッチも主流とはちょっとズレたものも多い。彼らの描くヒロインたちの多くは「美少女」ではなく「可愛い女の子」なのだ。突然殴りこんできた一般漫画で見事にその雑誌の空気に（ピンク的なものは含まずに）馴染んでいたのだ。

「○リババア」は表現上アレなので以後は「のじゃ○リ」と便宜的に称する。「のじゃ○リ」自体は古風？（「〜のじゃ」）な話し方をする幼い少女くらいしか含意せず、キャラクターとしては多く「えらぶっているが寂しがり、耳年増、おばあちゃんっ娘、○リババア」のように登場するが本記事では便宜的表現であるので注意されたい。

「のじゃ○リ」の属性とギャップ萌え

のじゃ○リはその外見と過ごしてきた年月による老成した人生観のギャップを端的に表すが、その表れ方は当然作品によって異なる。

実際の年齢に比べて外見相応の挙動をするギャップ
実際の外見に比べて年齢相応の挙動をするギャップ
外見に引き摺られて年齢に相応しくない感情を抱く

あたりが箇条書き的な特徴となるだろうか。これに類する属性に「年下の姉」「年下のママ」といったものがあると私は考えている。「異様に若い母」と「年下のママ」については、母は「母らしくない挙動」をし、ママは「どこか背伸びした挙動」もしくは「異様な包容力」といったものであり、母については「女性性と母性」についての話題であると考えるので除外する。なお、「年上の妹」については「恐らく存在しない」と考えているということを補足しておく*3。しっかり者の妹は別に年上の妹ではなく、年齢が実際に上の関係上の妹はただの女性かもしれない。

これらの関係は「年齢から予想される振舞い」「関係性から予想される振舞い」という前提があって効果的に機能する。例えば100歳のキャラクターがいたとして、「100歳なのにあんなことをするのか」「100歳だから色々あったんだろうな」といったことだ。

薄荷少女においても、謎の薬で体が縮んでしまったがバットでは殴られない導入でのじゃ○リが誕生するところから物語は始まる。が、この方向からだけでは料理の感想に「うまい！」と言っているだけのようなもので、拙いなりにもう少しだけ掘り下げる。

「子供の頃の近所に住んでいた大学生くらいの異性」絶対的な距離の固定

友人曰く「おねショタの定義から証明を行っている」、「ペンギン・ハイウェイ」を観ましたか？　結末含め10000000000000000000000000000000点なので観てください。さて、皆さんの子供の頃、近所にはミステリアスな大学生はいただろうか。私はいなかった。しかし、「子供の頃の近所に住んでいた大学生くらいの異性」と言われてどういったものか想像ができない人間はいないだろう。「〽子供のころの夢は色褪せない落書きで」と歌う名曲*4もあるが、自我を形作る原風景として、義務教育*5時代の経験は重要である、はずである。その年頃の子供にとって、一番心理的距離の遠い関係性は、実は大学生ではないだろうか。勉強を続けて、高校生になる未来は見えても、更に続けて大学生にというのは高校2年生くらいまでは遠い距離の人間はそこそこ多いのではないだろうか。そこから一足飛んで「社会人」というのは家族や通学路までの道、自由時間から逆に想像が容易くなる。「なにをしているのかわからない、すごいかもしれないひと」という目と、「かつてあったはずの、その頃何を考えていたか分からなくなってしまったくらいの子」の目が交差する。大学生の多くは恐らく4年で、義務教育卒業までの期間より短い。1人暮らしの大学生は大学生でなくなると住居を変えることが多く、その辺りが関係の終焉となる。 10年後などに再会するとき、かつての大学生からは神秘が剥がれ、またあの頃の未知の前に立つ子供もいない。初恋に似た憧れは夢の中、思い出せない場所へと姿を隠しそれを侵すことを許さない。

ここでの関係性で重要なことは、ある程度の距離と越えられない溝である。子供の行動に大学生は距離を以て接し、大学生の思考は未だ子供の及ぶところに無い。これは世界の境界線の話かもしれない。原風景に固定化されるこの距離と溝は子供の心に傷となって残る。

言うまでもなく老人と子供にはこれよりも長大な距離と溝がある。しかし、普段は長大な距離故に溝が問題になることは無い。

薄荷ばあやと薄荷少女

本題に戻り、薄荷少女では、子供の頃自分の世話をしてくれていたばあやが童女になってしまうことでこの距離が縮んでしまうのだ。縮みすぎて相手が童女になっているが。特別掲載誌の主題とするところはのじゃ○リであるが、永遠娘の通常の作品は（誌の性質上）性的な交流を持つ。永遠娘でなくとも一般を含む多くののじゃ○リ作品では溝は一時的にせよ越えられるものとして描かれる。作品を通し描かれるのは縮みすぎた距離に戸惑う坊っちゃんの姿であるが、彼は5巻を通し遂に溝を越えることはなかった。

上の表現であると誤解を招いたかもしれないが、薄荷が常に老人の感性を以て接するわけではない。何せこの作品は「薄荷少女」であるのだし。坊ちゃんは目の前の少女に対し、子供の頃滿ちていたばあやの薄荷の香りを嗅ぐのだ。そして薄荷も少女であるから、ばあやであるから二人の関係性は坊ちゃんとばあやなのだ。

坊ちゃん

「坊ちゃん」自体は一般的な表現であるが、主人公が教職を持って、ばあやがいて、となると夏目漱石の「坊ちゃん」が有名どころだ。漱石の「坊ちゃん」に登場するきよは物語前半で退場し、その後彼を坊ちゃんと呼ぶ者はまあいなくなる*6が、薄荷少女ではばあやは奇跡の薬で坊ちゃんの元へ馳せ参じる。どちらの主人公も基本的に女っ気が無いが、これは果たして。自分よりも自分に期待してくれて、身の回りのことを嬉しそうにこなしてくれる存在は呪縛に近しいのでさもありなんといった風ではあるが。

Outro

考えていたら苦しくなってきたのでこの辺で終了。薄荷少女を読もう。5巻の物理本って世界がどうなったら出るんだろう。

薄花少女（１） (サンデーGXコミックス)

作者: 三浦靖冬
出版社/メーカー: 小学館
発売日: 2014/03/17
メディア: Kindle版
この商品を含むブログを見る

薄花少女（２） (サンデーGXコミックス)

作者: 三浦靖冬
出版社/メーカー: 小学館
発売日: 2015/02/16
メディア: Kindle版
この商品を含むブログを見る

薄花少女（３） (サンデーGXコミックス)

作者: 三浦靖冬
出版社/メーカー: 小学館
発売日: 2016/01/22
メディア: Kindle版
この商品を含むブログを見る

薄花少女（４） (サンデーGXコミックス)

作者: 三浦靖冬
出版社/メーカー: 小学館
発売日: 2017/01/24
メディア: Kindle版
この商品を含むブログを見る

TVアニメ「うたわれるもの」OP主題歌夢想歌

アーティスト: Suara,須谷尚子,未海,豆田将
出版社/メーカー: ランティス
発売日: 2006/04/26
メディア: CD
クリック: 21回
この商品を含むブログ (133件) を見る

*1:オタクはすぐADVのマルチエンディングで喩える……。

*2:18歳未満もしくは性的表現に嫌悪感を持つ方は調べないように

*3:「未来のミライ」を観てこの感想を述べたら友人にネタバレするなと怒られた。

*4:キン！キン！

*5:高校も行く人間が多い地域であれば高校まで含む

*6:記憶が多少曖昧だが、垂れ流し記事なので調べ直さない。まあきよと同じニュアンスで使う人はいなかったはず。

2019-07-05

Sphinxでナウいjsbook使うと章題ページだけページ番号がヘッダにいく

Sphinx LaTeX

結論

gist.github.com

preface

最近、フューチャーアーキテクト、というか多分ほぼ渋川さんから素晴らしいドキュメントが公開されました。

future-architect.github.io

これでTypeScriptにちゃんと入門しようと思って、Kidle Oasis にPDF入れて読んでいたんですが、目次タイトルや章題ページだけ、なんかページ番号の位置が違うしフォントも違う？

原因

SphinxでreStructuredTextから生成されているので、原因特定が比較的容易でした。ちゃんと触ってたの4、5年前だけど。

章題ページだけヘッダを取るくらいならデザインかな、という感じだけどページ番号の位置は大抵は揃えてなんぼなのでSphinxというかLaTeXのどっかでpagestyleが上書きされているのかな、とあたりをつけて調べることに。 sphinxmanual は現在のデフォではjsbookをロードして拡張してるっぽいので、jsbookの chapter を見ると、\plainifnotempty なるものが呼ばれてるので、まあコレだろうということで、どうにかする方法を考えます。jsclassesも最近使ってなかったし、使ってたときは中身読んでなかったのでこういう不都合がでたのは最近かもしれないし以前からかもしれません。

修正

chapter を再定義するのが正しい気もしますが、Sphinxのベースで将来的に弄ったらそれを更に〜というのはグチャグチャになっていきそうなので、お行儀悪く \plainnotempty で定義されるページスタイルを書き換えてみます。一応、fancyhdrがあって、chapterがあってという状態で、\plainifnotemptyが存在する場合のみ再定義するようにしたので他のクラスで使ってもパッケージのロード時間が僅かに増える程度で害はないかと思います。

chapterfoot ページスタイルを新たに用意しているのは、\thispagestyle{normal} だとヘッダも他のページと同じになってしまうのでどちらの動作が正しいか判断がつかなかったため。

使い方

Gistの方にも書きましたが。

コピーして、conf.pyの latex_additional_files でビルド時コピーできる場所に置いて設定し、

latex_elements = { 'preamble': '''
\\usepackage{sphinx-jsbook-mod}
'''}

としましょう。

2019-04-23

コンテナでopam入れようとして失敗するときの対処

LXD opam container

手元のUbuntuのバージョンが18.04でglibcのバージョンが2.27でSATySFi0.0.3がduneのインストールでコケるなど、よくある事態がありますが、皆さんLXDユーザなので

「LXCのコンテナにUbuntu19.04入れたろ」

という対処を思いつくのではないでしょうか。

で、いざやろうとするとopamのソースコードからのインストールで躓いたりするわけです*1。 opam init 時にsandbox環境をつくって色々やろうとするときに /dev/pts がマウントできひんみたいなとこで詰まるわけですが、対処法opamのFAQに載ってるやん。つまりこのブログ記事の必要はなし。

opam.ocaml.org

「unprivilegedなコンテナなど初回のinitのときに --diable-sandboxing つけて」ってありますね。ハイ、解決〜。

コンテナじゃなく18.04で普通に入れたい場合でもこれでいいらしい。 qiita.com

*1:19.04ならaptで入るバージョンでも大丈夫かも

別名：Laughing and Grief 雑記

想定

sphinxhowto.clsとsphinxmanual.cls

Sphinxクラスファイルの設定（LoadClass後）

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

開始前

挨拶

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

ラム社の紹介

Markdownとは

Markdownの現在

とは

Markdown+[tex\LaTeX{}]

そこでPandoc

冊子本で使える拡張

YAML Metadata Book

pandoc-citeproc+CSL(citationstyles.org/)

codeblock

脚注

Pipe Tables

Pandoc フィルタ

課題

Markdown+CSS?

補足

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

Markdown概観

HTMLメタタグ

CommonMark

MarkdownにならないHTMLタグ

対処

HTMLとMarkdownの混在

冊子本の形を作る

見出しIDのマークアップ

図版マークアップ

表のマークアップ

脚注のマークアップ

参照のマークアップ

索引

CF.W3C JLREQ

Markdown+CSS+AHFormatterによるPDF化

Balisage: Markup 2019 発表の抄

ルーズリーフ出版とは

需要

Municodeとは

AHFormatter+CSS との関連

課題

ビジネス要件

CSS組版の課題

XML用意

エリアツリー

info

process

今後

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

概略

目標

NEWS

質疑

終了

おもったこと

やりたいことともんだい

Card

Article

Book

TODO

技術書典7

Preface

Intro

「のじゃ○リ」の属性とギャップ萌え

「子供の頃の近所に住んでいた大学生くらいの異性」絶対的な距離の固定

薄荷ばあやと薄荷少女

坊ちゃん

Outro

結論

preface

原因

修正

使い方

$\LaTeX{}$ とは

CSS 組版の課題