(Pandoc) docx 出力の場合、BlockQuote 中の HorizontalRule は別段落になる

コード読んだけどまだよくわかってない。

HRはそもそもBlock要素なんですが、ParaなどのBlock要素は正しくBlockQuote中に取り込まれるので、段落要素であることが原因ではないとはわかっていますが、コード見てもまだよくわかってません。docx形式で出力する、水平線がブロック引用（>ではじまる行）内に収まらないという問題です。

--to nativeすれば正しくHRがBQ中にあることは見えるので、Writer依存であることは確認できますね。

んで、あとは生成されたdocxを解凍して、中身のタグを見て、これをluaフィルタで置き換える形で対応すればよいという事で、昨日プロトタイプを書いた。

ここでいっか。これでいけるよ。

function Span(e)
if e.classes:find("hr", 0) then
tag = '<w:pict><v:rect style="width:0;height:1.5pt" o:hralign="center" o:hrstd="t" o:hr="t" /></w:pict>'
e = pandoc.RawInline('openxml', tag)
end
return e
end

— niszet (@niszet0) 2020年10月18日

このあとK4氏の返信見て、それもできるじゃんってことでもう一個かいた。

出来たね。2本目のhrも同じようになった

function HorizontalRule(e)
tag = '<w:pict><v:rect style="width:0;height:1.5pt" o:hralign="center" o:hrstd="t" o:hr="t" /></w:pict>'
return pandoc.Para(pandoc.RawInline('openxml', tag))
end pic.twitter.com/vcYMQeQ0x4

— niszet (@niszet0) 2020年10月18日

いずれ気が向いたときにPandoc/lua-filterにPR出します。

asciidoctor出力結果のチェックのために環境を整える

先人がいるのはありがたいことです。

asciidoc/asciidoctor形式の出力ファイルを見るために、指定したツールで正しくレンダリングされるかどうかが判断基準になるため、環境を作っていました。以下はメモ。

環境そのものは下記のブログの記事を参考に入れました（そのリンク先のrubyのインストールも）

ai-gaminglife.hatenablog.com

qiita.com

ただし、rubyのインストールはこのまま実行すると以下のようなメッセージ（抜粋）が出る。

Note, selecting 'libreadline-dev' instead of 'libreadline6-dev'
E: Unable to locate package libgdbm3

上は無視しても良かったが、下はエラーになるので、インストールする一覧からlibgdbm3を削除して再実行して問題なくインストールが進んだ。

rubyのバージョンは一覧中で最も新しかった2.7.2とした。

手元にあるサンプルのadocに不備があるのか、pdf化はうまくいかなかったのだが、最低限まで削除してたら出力は出来た。

しかし、以下のようにエラーメッセージがでて、 --traceつければ何かわかるかなと思ったら内部のエラー状況を出してくるだけで入力ファイルの何が問題なのかはsuggestしてくれないので意味がなかった。どうするのが良いのだろうか？

asciidoctor-pdf -r asciidoctor-pdf-cjk test.adoc
Prawn::Errors::CannotFit
  Use --trace for backtrace

pdf出力できたが、しかし日本語が出力できない。調べるとフォントの問題だったので調べたところ下記の記事の対応で出来そうだった。

qiita.com

ただし、私はrbenvを使用してasciidoctorをインストールしているのでどこにdefault-theme.ymlがあるのかわからなかった。結果としては下記にあった。

/home/niszet/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/asciidoctor-pdf-1.5.3/data/themes/default-theme.yml  

これに追記して、日本語出力が出来た。

なお、調べたかったのは改ページの<<<の扱いで、html出力の場合は無視され、pdf出力場合は正しく改ページがされているようであった。Pandocとしては別にasciidocの先がpdfかhtmlかは気にしないので一律挿入でよさそうだなという見解。

フォント周りはまだ色々ありそうなんだけど面倒くさいので必要になるまで放置。

rubyのインストールは結構時間がかかったのだが、progress bar表示とかしてくれるといいなぁ。動いているのか止まっているのか不安になりますね。

html出力は

asciidoctor  test.adoc -r asciidoctor-diagram -a allow-uri-read -a data-uri -a toc=left

できれいに出力されたので特に深追いをしていない。pdf化出来なかったadocがhtmlは出力できたので、何かキラーパターン的なモノがあるのかもしれない。いずれまた調べるかもしれない。

（Pandoc）Pandoc内では`--to asciidoc`と`--to asciidoctor`が区別されている件

そういえばそんなこともあったわね…。

先の記事に書いた通り、Pandocは拡張子を見ているんですが、asciidoctorにはならないようです。

しかし、この形式たちは内部で差異があり、出力ファイルの文法が異なるので注意です。ていうかasciidoctorの方が標準でいいんじゃねーのかコレ…。

ということでざっとコード読む。対象はコレ。

github.com

差異はinlineだけっぽいので適当にコード例を書いて、あとは見てくれ～の流れ。

入力ファイルはこんな感じで準備。

DoubleQuote of \"text\" is converted to "text"

SingleQuote of \'text\' is converted to 'text'

Code of \`a+b\` is converted to `a+b`

InlineMath of \$a + b\$ is converted to $a + b$

DisplayMath of \$\$a * b\$\$ is converted to $$ a * b $$

asciidocの場合。これは拡張子が.adocなら勝手に判断される。今回は標準出力に表示したので--toでの指定が必須（そらそう）

pandoc input.md --to asciidoc

DoubleQuote of "text" is converted to ``text''

SingleQuote of 'text' is converted to `text'

Code of `a+b` is converted to `a+b`

InlineMath of $a + b$ is converted to latexmath:[$a + b$]

DisplayMath of $$a * b$$ is converted to

[latexmath]
++++
\[ a * b \]
++++

次。asciidoctorの場合。

pandoc input.md --to asciidoctor

DoubleQuote of "text" is converted to "`text`"

SingleQuote of 'text' is converted to '`text`'

Code of `a+b` is converted to `+a+b+`

InlineMath of $a + b$ is converted to latexmath:[a + b]

DisplayMath of $$a * b$$ is converted to

[latexmath]
++++
 a * b
++++

おわかりだろうか。私はAsciiDoc形式に詳しくないのでどう使い分けるのかわからないですが、コレの差が効いてくることもあるのでしょう。知っておくと良いかもしれません。

（Pandoc）Pandocはファイルの拡張子を見ている

でも明示されていなくない？

いつものことデスね…。

対応するコードはここにあります。

github.com

で、変換対応を抜粋。以下が対応関係になっています。なお、docとpdfの拡張子はサポート外なので、エラーとなります。また、--toや--fromを指定していればそちらが優先のはずです（ちゃんと確認していないけど）

この表にない拡張子でかつ--toなどで形式を指定しない場合はエラーになるはずです。

拡張子	対応するファイル形式
.adoc	asciidoc
.asciidoc	asciidoc
.context	context
.ctx	context
.db	docbook
.doc	doc
.docx	docx
.dokuwiki	dokuwiki
.epub	epub
.fb2	fb2
.htm	html
.html	html
.icml	icml
.json	json
.latex	latex
.lhs	markdown+lhs
.ltx	latex
.markdown	markdown
.md	markdown
.ms	ms
.muse	muse
.native	native
.odt	odt
.opml	opml
.org	org
.pdf	pdf
.pptx	pptx
.roff	ms
.rst	rst
.rtf	rtf
.s5	s5
.t2t	t2t
.tei	tei
.tei.xml	tei
.tex	latex
.texi	texinfo
.texinfo	texinfo
.text	markdown
.textile	textile
.txt	markdown
.wiki	mediawiki
.xhtml	html
.ipynb	ipynb
.csv	csv
.bib	biblatex
.1,.2,...,.9	man

（Pandoc）2.11が出ましたね！

一応書いておこうかなと。

ずっとリリース待ってたんですが、（日本時間の）深夜になるとは読みが浅かったけど、リリース直後に反応できたので、ヨシ！

今回の一番大きな変更は、citeprocのPandoc内部への取り込みでしょう。今まではフィルタで動いていたものがPandocに同梱されたので、リリースが

pandoc.org

これによって、実行時に必要なファイルはPandoc本体だけになりました。2.11のzipを開いてみるとこんな感じのファイル構成ですね。

ちなみに2.7のときはこんな感じでした。

あと、今回、私のコードが取り込まれたのでうれしいですね。

Syntax highlighting for inline code (#6711, niszet).

まぁ最終的にODTでもdocx並かそれ以上に使えるようになってほしいなという気持ちです。先はとても長いことが分かっていますが…まぁゆっくりやっていきましょう。Haskell力をつけていかねばですね。

（Pandoc）出力ファイルのチェックをするならテストに使っているファイルを使うのが一番。

そらそうだ。

PandocもCI使ってテストをしています。手元でもstack testとかでテストできますけどね。

この際に使っているファイルがコレ。native形式で書かれているので、native parserがしくじってなければ、コレが一番Readerに依存しない形ですね。賢い。

github.com

で、これを

pandoc --data-dir=../data --quiet testsuite.native -r native -w opendocument --columns=78 --variable pandoc-version= -s > writer.opendocument

みたいにすればいいわけですね。実際、test/下にはwriter.opendocumentがいますので、テスト時はこいつとdiffとって差異がなければpassという事になります。

自分でwriterを作ったらとりあえずこれを入力にして結果を見てみると良いと思います。他の形式、たとえばhtmlなどの出力と比較して、renderされた結果が意図した通りかな？みたいに見ていくのかなーと思います。最終的にはドキュメントの見た目の構造も含めてチェックしないといけないので、文字列だけ光うしていてはダメというのが面倒くさいですね（構造だけみてOKとしてもいいけど僕の目ではそれは出来ない…）

odt形式の場合、--to opendocumentだとcontent.xmlが出力されますが、このうち画像のリンクはおかしくなってしまうので注意。見るなら素直に --to odt してチェックした方が良いと思いますよ、3-4日前の私…。

odt形式はファイルそのもの、LOW、スタイルなど色々なものによって挙動が決まるので、全体像を把握しきれていないと無限に時間が溶けますねぇ…（ぼやき

(Pandoc) VerbatimChar文字スタイルはスタイル一覧に表示されないが、これはSourceCode段落スタイルのリンクスタイルなのであった。

linkスタイル死すべし慈悲はない

以前からPandocのdocxのスタイルについて調べていましたが、最近はHaskellのコードも読んでいるので以前よりもさらにわかってきました。

以前…

niszet.hatenablog.com

いつかちゃんとまとめたいですね…。

でもそれは大変なので、とりあえず1つだけ。

今まで、skylightingによってシンタックスハイライトがつく際に生成される***Tokの文字スタイルはVerbatim Charスタイルを基準にしているのに、そのスタイルがWord上でスタイル一覧に出てこないのでどうやって変更すればよいのかさっぱりわからん…という状態でした。

色々と調べて分かったのですが、SourceCode段落スタイルはVerbatimChar文字スタイルをlinkしています（これは、docx中のstyles.xmlファイルを見ないとわかりませんが）そのため、SourceCodeの文字情報は実はVerbatimChar文字スタイルなのです。つまり、***TokスタイルはSourceCode段落スタイルの文字スタイル情報を更新すればそれに連動する、ということなのでした。

もし、VerbatimCharを分離して出したい場合、SourceCode段落スタイルのlinkの行を消してあげればよいわけです。これで、VerbatimCharスタイルが一覧に出てきて直接変更することが可能となります。

が、これを変更するべきなのかどうかというと、使い方が分かればまぁ大丈夫でしょ…ということで、Pandoc本体の更新を伴うような変更はしなくてもいいかなと思って、知見共有のwikiとかがないかを聞いています

groups.google.com