ラムダノートという出版社を作って4年が経ちました。 www.lambdanote.com 去年に引き続き、今年もちょっとふりかえりをしてみます。 この記事はラムダノートの技術 Advent Calendar 2019の25日めのエントリーです。 第4期（2018年12月～2019年11月）のふりか…

昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の…

この記事はTeX & LaTeX Advent Calendar 2019の24日目の記事です。23日めはwtsnさんの記事でした。25日めは☃さんの記事です。 TeXの脚注は出力されない場合がありますね TeXはなぜ脚注を期待どおりに扱えないのだろう 脚注をMVL上で可視にすればよい ページ…

昨日までの話をふりかえってみます。 構造化文書というと、どうしてもXMLタグの書式で構造を示すあの世界観が想起されやすい しかし、書式はあくまでも記法にすぎないと思うことにして、構造のほうだけ抽象データ型でかっちり用意するという世界観もありうる…

昨日の記事では「書籍のマクロな構造」について話しました。 このマクロ構造はPandoc構造には組み込まれていません。 そのため、Pandocで書籍を作ろうと思うと、どうしたってPandoc構造にない部分を扱う別の仕組みが必要になります。 素のPandocでは、「書籍…

昨日まで何回かにわたり、多様なドキュメント形式の変換アプリケーションであるPandocのコアとなる仕組みを説明してきました。 特に、Pandoc構造とそれを生成するReader、生成されたPandoc構造を変換するPandocフィルターについて、少し時間をかけて紹介しま…

昨日までの記事では、Pandocフィルターの基本と少しだけ実用味がありそうな例を紹介しました。 Pandocフィルターは、Pandoc本体の開発言語と同じくHaskellで書けますが、Pandocの内部動作を変えられるわけではなく、pandocコマンドによってJSONとして出力し…

Pandocフィルターの便利さと限界が見えてきたところで、最後に実用的かもしれない例を1つ紹介します。 Markdown原稿に索引のエントリを指定するための「記法」を考えてみる話です。 どういう記法にするか そもそもMarkdownの方言で索引に対応してるものはな…

昨日の記事では、いわゆる行コメントっぽい振る舞いを例に、2種類のPandocフィルターについて説明しました。 今日は、もうちょっと非自明なPandocフィルターの例として、 昨日のPandocフィルターをもうちょっと進化させたバージョンと、コードブロックのLaTe…

昨日の記事では、PandocのReaderを自分で作り直す話をしました。 いうまでもありませんが、ReaderはPandocの一部なので、改造Readerを使うためにはPandocをソースから自分でビルドする必要があります。 ところがPandocというのは、Haskellで書かれているうえ…

Python界隈でよく見かける構造化文書のための記法として、reStructuredText（以降はreSTと書きます）があります。 reStructuredText https://docutils.sourceforge.io/rst.html 軽量マークアップ言語などと呼ばれることもありますが、reSTはかなり高度な表現…

Pandocのいいところは、構造をさまざまな記法から暗黙に読み取ってくれる点です。 ただし、その構造はPandocの内部で定義された抽象データ型であり、利用者の目的に合わせて増改築することはできません。 XMLやLaTeXでやるフルフルの構造化文書に比べると良…

このアドベントカレンダーでは、先週まで、主にページメディアにおける「PDF」と「XML」の話をしてきました。 この2つ、それぞれ「Webブラウザでのレンダリング」と「HTML」に言い換えると、ウェブメディアの世界観と似ている気がしてこないでしょうか。 実…

近年、出版社でも原稿管理にGitの導入が進んでおり[要出典]、GitHubのようなWebサービスへの需要が高まっている[要出典]。 これに伴い、WebブラウザでGitHub上の原稿に対する特定のコミットを開き、そこに行コメントを残すといった利用も増えている[要出典]…

昨日までの記事では、XMLの構文で書かれた原稿を他のマークアップにどうやって変換しているかを紹介しました。 こういった変換をするときに一般に悩みの種になるのが、変換先の記法で特殊な意味を持つ文字の扱いです。 たとえばTeXでは、次の10種類の文字は…

昨日までの話を整理します。 ドキュメントのXMLによる表現は、プログラムの抽象構文木に相当し、ドキュメントの意味構造を示したものであった なので、XMLの構文をS式で表せた すると、XMLの要素名がLispにおける関数、要素がその関数への引数に見えた そこ…

昨日は、ドキュメントの構造をプログラムのように実行できるというアイデアの話をしました。 具体的には、「ドキュメントの構造をS式で表現し（SXML）、そのタグをLispの関数と見立て、それを要素に関数適用する」というアプローチです。 たとえば、XMLで表…

昨日は、ドキュメントとは木であり、その木はXML、さらにいうとXMLアプリケーションとして形作られる、という話をしました。 一般にドキュメントは、生のままの構造として読み手に与えられるものではありません。 ドキュメントの構造が何らかのXMLアプリケー…

昨日は、ドキュメントにおける構造というのはセマンティックな構造である、という話をしました。 今日は、そのセマンティックな構造をどう扱うか、という話です。 ドキュメントの構造は一般にXMLを使って表されている 結論から言うと、ドキュメントの構造は…

よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言…

去年に引き続き会社の近況報告をしようと思ってpyspaアドベントカレンダーにエントリしたけれど、今年は会社の話はやめて、メタアドベントカレンダーを書きます。 今年は一人でアドベントカレンダーをやることになり、とりあえず6日間、必至で書き続けました…

今日まで延々と「PDFからテキストデータを取り出すのは大変」という話を続けてきましたが、その構造を見るにあたっては、 hpdft という自作のツールを使ってきました。 大変とはいっても、まあ実現困難な話ではなく、この程度のPDFパーザであれば趣味プログ…

昨日の記事では、PDFのコンテンツストリームから文字を読めたことにして、その文字をテキストとして再構築する話をしました。 今日は昨日までの話の締めくくりとして、「PDFごとにカスタムなテキスト取り出し」の話をするつもりだったのですが、その前に文字…

昨日までで、PDFからテキストを取り出すにあたり、グリフから文字を手に入れるところまでを説明しました。 いや本当のことを言うと、まだ全然説明できてないんです。 でも、文字の話ばかりしていても先に進めないので、今日は（可能な場合には）PDFから文字…

昨日の記事では、PDFのページに表示されるコンテンツはPDFのドキュメント構造を掘っていくと手に入れることができて、それはこんな姿をしているぞ、というところまで話が進みました。 $ hpdft -r 66 NML-book.pdf [ /Filter: /FlateDecode /Length: 381.0, q…

昨日は、PDFの本来の用途は「人間がPDFをビューワーで開いて読む」ことなので、そこから文字を抜き出すのは一筋縄ではいかない、という話をしました。 ではどうすればPDFファイルの中からテキストを取り出せるの、というのが今日の話の出発点です。 まず昨日…

PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵（「グリフ」）をコンピューターで扱えるような「文字」にする方法です。 …