ひとまず一区切りとして。10年ほど前の本ですが、Haskellの基礎の部分を学ぶのにとても良かったです。内容が濃いけどページ数はそこまで多くないので、気持ちが折れる前になんとか最後まで行った感じ。
とはいえ読んだだけなので、書かないとすぐ忘れると思います…。1週間くらいあけて、1章からざっと読みながら演習やるかなーという感じですかね。
この本はモナドのことはかなりさらっと触れているので、そのあたりを知るには別の本とかネットの情報をあたる必要がある。
その他、この10年ほどの間にあった新しい動きは当然反映されていないので、そのあたりも新しい書籍やネットの情報をあたる必要がありますね。
とはいえ、ひとまずPandocを解読するためのHaskellの理解を一歩一歩進めている、という感じです。先は長いですね…。
なんか2版が出るみたいな話があった気がするので、そちらの情報も要チェックですね。
pandoc.utils.normalize_dateという関数がある。これは日付っぽい文字列を受け取って、日付の形に返してくれる。
こいつの仕様がよくわからなかったので調べた。関数自体はLua filterのページのここに書いてある。
Luaから呼び出せるが実体はHaskellで書かれていて、pandoc/src/Text/Pandoc/Lua/Module/Utils.hs にある
これは実際には Shared.normalizeDate を呼んでいるだけで、処理の中身はText.Pandoc.Sharedを見に行かねばならない。場所は下記。
この関数はISO 8601っぽい形式で出力してくれるのだが、ISO 8601と違い、1583年からではなく1601年から9999年までしか扱えない。これはMS Wordの仕様のためらしい（と、コードに書いてある）
で、実際に日付を処理しているのはさらにその先のparseTimeMという関数。この関数についてはこのページで詳しく書いてあるので追加で書くことはなかった。まだ流し読みしかできていないので後でじっくり読もう。
このページを見れば、フォーマット文字列がそれぞれ何を意味しているかが分かる…。
ということで、とりあえずざっと調べた内容のメモ。
実行例はまた別の機会にやるかも…？
Enjoy!!
PandocのLua filterのページにはpandoc.typesモジュールを使ってPandocのVersionオブジェクト ^[厳密にはオブジェクトではないかも] を扱えるといった記述がありますが、実際はバイナリで配布されているPandoc2.7.3ではこれは使用できません。
ただし、PANDOC_VERSION自体は存在していて、これを
for k,v in pairs(PANDOC_VERSION) do print(v) end
のように回せば2, 7, 3の数値が得られることがわかります。
もし先行して使用したい場合はGitHubのソースコードをgit cloneで持ってきてビルドしてください。
なお、VersionについてはHaskell側で書かれたものをLuaで参照する構造となっていて、実体のコードはHaskellを読まないといけません
ただ、使い方としてはマニュアルに書かれていた通りなので特に困ることはないかなと思います。
Luaフィルタ側でPandocのバージョン指定が出来るようになるのは便利ですね。ただ、どの関数がどのバージョンから実装されていたのかは後から確認しづらいので、それがわかりやすくなるといいなぁと思ったり…。
Enjoy!!
Windows上でPandocをソースからビルドすることが出来ますが、そのインストール先は下記になります。
C:\Users\niszet\AppData\Roaming\local\bin
RStudioから呼び出すPandocのパスはrmarkdownパッケージの関数を使用して確認できます。通常は下記の場所を参照しているはずです。
rmarkdown::pandoc_exec() ## [1] "C:/Program Files/RStudio/bin/pandoc/pandoc"
しかし、先のパス下にPandocがあるとそちらを優先して参照するようです。
masterブランチから持ってきたPandocで遊んでいると未公開機能が既にあるように錯覚してしまうため注意しましょう（この情報が役に立つ人ほとんどいないと思いますが）
Enjoy!!
文中のCodeやCodeBlockは対象外にすると決めてしまえば、以下のシンプルなコードで対応できます。
function Str(e) text = e.text text = string.gsub(text, '．', '。') text = string.gsub(text, '，', '、') return(pandoc.Str(text)) end
テキスト情報はインライン要素のStrが持っているよねってことで対応できるわけですね。コード中のコメントに対しても対応する、ということも書けば出来ますが今回は見送り。
今回はこちらのツイートを見て自分もやってみよーってなった次第です。
そういや lua フィルタ書けば句読点の変換簡単なはずだから，やっておくべきな気がしてきた．
— atusy (@Atsushi776) June 30, 2019
Enjoy!!
半年くらい前からK4氏が見つけたこのIssueが解決しておらず、
春の技術書典で話聞いたときはふ~んって思ってましたが、掘り下げてみるとこれは結構厄介な問題でした。ので、とりあえず議論に参加してみた。
たぶん、非Ascii語圏特有の問題ですが、docx中のstyle nameとWord上で表示されるスタイル名は異なります。上記Issueでも書いた通り、Titleが表題だったり。その場合、docx中のstyle idはstyle nameとは異なる値となります。ただ、saveする前のdocxではstyle idは化けていないので、JP語圏とかで開いてsaveするとダメなのでしょう。
md -> docx で生成するときはstyle nameの一致を見ているようで（実行時の挙動からそう見える）、docx -> md はstyle idを吐いているようです。そのため、両者が不一致すると docx -> md -> docx で変換するとオリジナルのdocxと再生成したdocxでスタイルが異なってしまう。これが問題かなーという形で再提起してみました。
style id を使うとしてもJP語圏とAscii語圏でファイルやり取りするとダメっぽいんだけど、その場合はstyle nameを使うとかかなぁ…。この問題はMS Wordのイケていない挙動に引きずられているので解決はなかなか難しい気がします…。が、やっていきましょう。
ここね。 groups.google.com
PandocのGitHubのIssueはBug reportやFeature requestをする場であって、個別の、書き方がわからない系の質問をする場所ではないので、困ったら↑のメーリングリストに書いてみましょう。ただし、英語で、ですが。
と、pandoc-discussの存在を先日知って、たまたま見てみたらLua filterの質問があったので回答した。
書いたものはこんな感じ。
function Image(e) if string.match(e.src, "svg$") then return(pandoc.RawInline("html", '<object data="' .. e.src .. '"></object>')) end end
これの前身でPara内の要素を見るものを書いた（20分くらい）が、風呂入ってたらpタグいらないじゃん…というよりインライン要素だけ置換する、が正しいじゃん…ってなってこうなりました。やっていることはimgタグをsvg拡張子の場合のみobjectにするだけです。
これは出力がhtml固定だと思っているので、特にフォーマットの指定はしていない（他の拡張子の時にfilterをいれることは想定しない）ので、もし常にフィルターを使うようにしつつ特定フォーマットだけ、となる場合はフォーマット識別するif文を手前に入れてください。
他に使いたい人がいるかもしれないから、もう少し整備して
に送ってみましょうかね（そこまでする…？
という活動報告。でした。
Enjoy!!
