niszetの日記

細かい情報を載せていくブログ

(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

で、変換対応を抜粋。以下が対応関係になっています。なお、docpdfの拡張子はサポート外なので、エラーとなります。また、--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を開いてみるとこんな感じのファイル構成ですね。

f:id:niszet:20201012223437p:plain

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

f:id:niszet:20201012223505p:plain

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

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

(Pandoc)OpenDocument形式出力でsyntax highlightingを(ただしインラインCodeかつODTではない)

簡単とは思っていなかったけどやっぱり大変…。

ODT形式の出力はシンタックスハイライトに対応できていません。そのため、これに対応するべくPandocの修正を試みています。

とりあえずissue建てた。

github.com

PRを1個出していて、これはOpenDocument形式での出力時に、対応するコードに対してシンタックスハイライト用のタグが埋め込まれるというもの。

ただし、styleの定義が存在しないのでLibreOfficeで(たぶんMS Wordも同じだけど)開いたときには標準の文字と何も変わらなく見えます。

styles.xmlを更新して対応する文字スタイルを追加しておけば、スタイルが正しくあたるところまでは確認しています。

問題はCodeBlockの処理がDocxのそれと違う事、そしてスタイルを自動生成するコードを作らねばならないことの2点です。

そもそも今のODTではautoのstyleを大量に生成してしまうのでそれってどうなの?というのもあるんですが。この辺りはODT/LOWの思想がどうなっているのかを確認していないので(LOWでファイルをつくってunzipして確認すればよい)追々やっていきまする。

作業時間は1日くらいですが、ほとんどコードとにらめっこしてる時間でしたね。Docxのコードをコピーして型合わせみたいな感じでしたし。

引き続き、PandocのODT形式出力の仕様の強化にむけてやっていきたいと思います(力尽きないといいなぁ…)

追記

そういえばコレはマージされました。さすにす。

あと、CodeBlock対応のために上記のCodeの処理を変えました。

github.com

これはdocxの処理を発想はそのまま、コードは合う形で移植したものです。

とりあえずtestを対応するものに書き換えれば、OpenDocument形式での出力は一応整合するかな。style名は修正したいのだけど。

問題はstyleを実装するWriter/ODT.hsの方で、これを修正するのが骨が折れそうなのです…。とりあえず動くところまでは頑張りたい

(Pandoc)Docx/ODT Writer中の文字コードの確認処理

時間を無駄に溶かしたのでメモをする。

はじめにPandocじゃない話を書いておくと、Rは"\uxxxx"でunicode文字を入れることが出来る。"\u2603"とかやれば☃だ。大文字のUを使えば、4桁で済まない文字も入れられるし、上4つを0で詰めておけば先と等価な文字コードとして"\U00002603"が得られる。これは下記のvignettesにもあるので読むとよろしい。

cran.r-project.org

最初、inlineのRのコードの`をescapeさせるにはどうするんだっけ?を調べていて、"\u0060"ってどうするんだっけ…と下記のブログとかを見ていたのでした。

rviews.rstudio.com

で、本題。

ODTやDocxの出力、同じような処理をしているくせに別々にWriter内(あるいはそのサブモジュール)で書いているし、構成というか思想が違うのでこれらの形式間で機能を移植しようと思っても簡単には出来なさそう。それぞれの内部で何をしているのかをみていかないと、思わぬところで詰まりそう…

ということで眺めていたのですが、文字コードの確認処理がそれぞれ入っています。

https://hackage.haskell.org/package/pandoc-2.10.1/docs/src/Text.Pandoc.Writers.Docx.html#isValidChar

https://hackage.haskell.org/package/pandoc-2.10.1/docs/src/Text.Pandoc.XML.html#escapeStringForXML

若干記述が違うし、いったいこれはなんなんだ…ということで、上記のRでの表現方法とあわせて沼ってましたが単に勘違いでした。Docxは上を閉じていないのでアレなんですが、基本的にはこれらの記述は等価ですね。しかしodtのこの上限はどこから…?

…が、よく見るとコメントにここを見ろって書いてある。で、Character Rangeにしっかり書いてあるわけでした。

www.w3.org

ここ由来で"\x10FFFF"が来ているんですね~。

ということでスッキリ。まぁ当面ここの仕様は変わらないだろうし、Docxの方に上限つけたらえぇんちゃう?っていうPRでも書いてみるか…(実害がないのでいらないのではと思うが)