igrepのブックマーク - はてなブックマーク

SNSの居心地をよくする - golden-luckyの日記

2023年、Twitterは名目上消失しました。ずっとMastodonとFacebookに馴染めなくて困っていたのですが、Blueskyのアカウントを作れたことでなんとか救われました。いまのところBlueskyは自分にとって﹁居心地がいいSNS﹂になっています。 Blueskyの居心地をよくするうえで自分にとって役立った機能として﹁フィード﹂と呼ばれるものがあるので、これについてpyspa Advent Calendar 2023 - Adventarの一記事として書かせてもらおうと思います。フォローするアカウントを増やすの難しいプラットフォームが押し付けてくる投稿は微妙だけど… タイムラインをアカウント単位で作るものといつから錯覚していた？﹁本とかを読む﹂フィードを作ったフォローするアカウントを増やすの難しい SNSで自分がふだん目にするコンテンツの大半は﹁他のアカウントをフ

igrep 2023/12/12

リンク

出版社を作って4年が経ちました - golden-luckyの日記

ラムダノートという出版社を作って4年が経ちました。 www.lambda note.com 去年に引き続き、今年もちょっとふりかえりをしてみます。この記事はラムダノートの技術 Advent Calendar 2019の25日めのエントリーです。第4期︵2018年12月～2019年11月︶のふりかえり﹃n月刊ラムダノート﹄はじめました今年は﹃n月刊ラムダノート﹄という不定期刊行誌を3月に発行し始めました。去年のふりかえりで第4期の目標として掲げていた﹁単発の本じゃない形で濃い技術情報をお届けする新企画﹂は、これのことです。ぶっちゃけ、技術書、読むの大変じゃないですか？正直なところ、作るほうもかなり大変です。技術書に限らず、いま出版社が次々に新刊を出しているのは、半ば商売を維持するためという構造的な側面があります︵それだけが理由ではないです︶。読む人も作る人もさまざまな無理感を

igrep 2019/12/26

お疲れさまです！

本

リンク

直販サイトを作って書籍を売ること - golden-luckyの日記

昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の話で締めくくろうと思います。現在、日本の出版事業の中心は、﹁版元﹂﹁取次﹂﹁書店﹂という3者︵いわゆる業界三者︶が担っています。メーカーと小売りの間に卸しがいるという構造は特別なものではありませんが、業界三者がちょっとだけ他と違うところがあるとしたら、書店と版元との柔軟な直接取引が少なく、取次-書店間、取次-版元間での委託取引が中心になっていることです。この構造を支えているひとつの柱は再販価格維持制度による書籍の定価販売なんですが、この構造のおかげで、日本はかなり書店の数が多い国であり続けました。 2000年代初頭には全国で2万店くら

igrep 2019/12/24

いい話だなあ

shopify
ec

リンク

抽象データ型を自作する - golden-luckyの日記

昨日の記事では﹁書籍のマクロな構造﹂について話しました。このマクロ構造はPandoc構造には組み込まれていません。そのため、Pandocで書籍を作ろうと思うと、どうしたってPandoc構造にない部分を扱う別の仕組みが必要になります。素のPandocでは、﹁書籍のマクロな構造を扱える外部の仕組み﹂を託す先として、主にLaTeXを利用しています。裏を返すと、LaTeXは、書籍のマクロな構造を扱える仕組みです。それなら最初からPandocではなく、LaTeXで本を作ればいいのではないでしょうか？この反論はもっともです。実際、本を作るプロは黙ってLaTeXであったり、あるいはInDesignであったり、あるいはFrameMakerであったりを使います。組版のプロの要求を実現するためには、これらのツールが持つ表現への自由度が必要だからです。しかし原稿をもらう立場からすると、この高い

igrep 2019/12/23

リンク

Markdownで書籍を作るとは - golden-luckyの日記

昨日まで何回かにわたり、多様なドキュメント形式の変換アプリケーションであるPandocのコアとなる仕組みを説明してきました。特に、Pandoc構造とそれを生成するReader、生成されたPandoc構造を変換するPandocフィルターについて、少し時間をかけて紹介しました。では、PandocのReaderとフィルターについて理解したところで、Pandocを使って本は作れるでしょうか？いままでの説明には登場しませんでしたが、Pandocの出力側を担うWriterには、﹁PDF生成のためのLaTeXWriter﹂や﹁EPUB Writer﹂など、﹁本﹂を作るのに使えそうなものがあります。それらWriterを制御するためのコマンドラインオプションはいろいろ用意されており、独自のテンプレートを指定することも可能です。ただ正直なところ、これらのWriterは、吊るしの状態では売り物の本を

igrep 2019/12/21

pandoc
LaTeX

リンク

Pandocをコマンドでなくライブラリとして使う - golden-luckyの日記

昨日までの記事では、Pandocフィルターの基本と少しだけ実用味がありそうな例を紹介しました。 Pandocフィルターは、Pandoc本体の開発言語と同じくHaskellで書けますが、Pandocの内部動作を変えられるわけではなく、pandocコマンドによってJSONとして出力したデータを操作する仕組みです。内部に組み込まれたLua処理系で実行できる新しいフィルターの仕組みもありますが、いずれにしてもpandocというコマンドに対する補助的な機構です。一方で、Haskellというプログラミング言語から見ると、Pandocはライブラリでもあります。つまりpandocコマンドとしてでなく、自分が書くHaskellのプログラムで読み込んでそのMarkdownのパーサだけを使う、といったことも可能です。今日はそのような事例を紹介します。 XML原稿にあるMarkdownの島先週、このアド

igrep 2019/12/20

リンク

もっとPandocフィルター - golden-luckyの日記

昨日の記事では、いわゆる行コメントっぽい振る舞いを例に、2種類のPandocフィルターについて説明しました。今日は、もうちょっと非自明なPandocフィルターの例として、昨日のPandocフィルターをもうちょっと進化させたバージョンと、コードブロックのLaTeX出力に非標準的なパッケージを使う事例を紹介します。︵ちなみにLuaフィルターはお仕事で使ったことがないので、いずれも古典的なPandocフィルターによる事例です︶行コメントPandocフィルター、バージョン2機能の記事で例として挙げた行コメント用Pandocフィルターの実装は、段落の先頭が★だった場合にはその段落を出力しない、という中途半端なものでした。これをもうちょっと実用的に、Markdownで行の先頭が★だった場合にはその行を出力しない、というふうにできないものでしょうか？結論から言ってしまうと、これはPando

igrep 2019/12/18

pandoc

リンク

Pandocフィルター101 - golden-luckyの日記

昨日の記事では、PandocのReaderを自分で作り直す話をしました。いうまでもありませんが、ReaderはPandocの一部なので、改造Readerを使うためにはPandocをソースから自分でビルドする必要があります。ところがPandocというのは、Haskellで書かれているうえに、かなり巨大で依存関係がめんどくさいソフトウェアです。 GitHubからソースをcloneしてくれば誰でもビルドできるとはいえ、Haskellの開発経験がまったくないと、ビルドできる環境を整えるだけでもなかなか大変でしょう。 Readerを改造するしか手のうちようがない機能追加や修正については何ともなりませんが、Pandoc構造に押し込まれたコンテンツを他の記法として書き出すときに標準とは違うことをしたいだけなら、Pandocをソースからビルドしなくても済むような裏口が昔から用意されています。それが今

igrep 2019/12/17

Pandocをライブラリーとして使えばわざわざJSONを経由しなくてもHaskell製のフィルターが定義できそうだけど、そうしないのは単純に面倒だから？

リンク

PandocをreSTのリストテーブルに対応させる - golden-luckyの日記

Python界隈でよく見かける構造化文書のための記法として、reStructuredText︵以降はreSTと書きます︶があります。 reStructuredText https://docutils.sourceforge.io/rst.html 軽量マークアップ言語などと呼ばれることもありますが、reSTはかなり高度な表現力がある記法です。その記法をパースするために標準で使われているのはDocutilsという仕組みです。ただ、DocutilsはreST専用ではなく、他の記法のパーサを実装することもできるらしいです。その意味でDocutilsは、Pandocと同じく、内部の抽象的なデータ構造へと記法を押し込めるツールだといえる気がします。 Docutilsについては﹃マスタリングDocutils﹄に詳しいので興味がある方は購入しましょう。﹃マスタリングDocutils﹄マスタリン

igrep 2019/12/16

いいはなし

リンク

ライトウェイト構造化文書 - golden-luckyの日記

このアドベントカレンダーでは、先週まで、主にページメディアにおける﹁PDF﹂と﹁XML﹂の話をしてきました。この2つ、それぞれ﹁Webブラウザでのレンダリング﹂と﹁HTML﹂に言い換えると、ウェブメディアの世界観と似ている気がしてこないでしょうか。実際のところ、ウェブメディアとページメディアって互いに遠い存在ではなく、﹁平面に文字などを配置することを目的とした構造化文書﹂という視点に立てば、むしろ兄弟みたいなものです。﹁Webブラウザへの表示がHTMLだけで済むわけないだろ、CSSやJavaScriptの役割を知らないのか﹂という指摘が聞こえてきそうですが、ページメディアにもそれらに相当するものは存在します。というか、いろいろありすぎて、もはや収拾がついていません。ページメディアでわりと標準っぽいのは、CSSの役割がXSL-FO、JavaScriptの役割がXSLTという、いわゆ

igrep 2019/12/15

リンク

LaTeXソースを出力するときのエスケープ - golden-luckyの日記

昨日までの記事では、XMLの構文で書かれた原稿を他のマークアップにどうやって変換しているかを紹介しました。こういった変換をするときに一般に悩みの種になるのが、変換先の記法で特殊な意味を持つ文字の扱いです。たとえばTeXでは、次の10種類の文字は﹁原稿の入力にそのまま使えない﹂とされています。最終的な印字結果にこれらを出力したい場合には、原稿上で何らかの﹁処置﹂が必要です。 \ { } $ & # ^ _ % ~ 今日は、これらをLaTeXのソースでどうエスケープしたらいいか、という話です。 TeXのエスケープ文字は文字のエスケープをする文字ではないプログラミング言語などで特殊な文字を入力したい場合、一般には﹁エスケープ文字を前置する﹂という方法を使います。エスケープ文字としてお馴染みなのは、バックスラッシュ記号﹁\﹂でしょう。 "\n"とか、"\\"とか、"\""といったやつです

igrep 2019/12/13

LaTeX
pandoc

リンク

XMLをつぶす機械を作る機械を作る - golden-luckyの日記

昨日は、ドキュメントの構造をプログラムのように実行できるというアイデアの話をしました。具体的には、「ドキュメントの構造をS式で表現し（SXML）、そのタグをLispの関数と見立て、それを要素に関数適用する」というアプローチです。たとえば、XMLで表したときに段落を意味する<para>のようなタグに対する変換処理は、こんな感じのLispの関数として定義できます。 (define (para arg) (print arg "\n\n")) 今日は、これをもうちょっと真面目に定義する部分と、これを評価する部分、それに実用的に使うためのフレームワークについて書きます。以降、Lispの処理系としては、GaucheというSchemeの実装を使います。 Gauche https://practical-scheme.net/gauche/index-j.html ドキュメントをS式で書くの？ま

igrep 2019/12/13

リンク

PDFから「使える」テキストを取り出す（第5回） - golden-luckyの日記

昨日の記事では、PDFのコンテンツストリームから文字を読めたことにして、その文字をテキストとして再構築する話をしました。今日は昨日までの話の締めくくりとして、﹁PDFごとにカスタムなテキスト取り出し﹂の話をするつもりだったのですが、その前に文字とコンテンツストリームについて落穂拾いをしておくことにしました。というのは、昨日までの記事への反応を見ていて、この本のことをちょっと思い出したからです。 John Whitington 著、村上雅章訳﹃PDF構造解説﹄︵オライリー・ジャパン、2012年5月︶この本、PDFのドキュメント構造を知りたい人が最初に読むにはぴったりだと思います。自分で簡単なPDFを手書きしながら﹁PDFの中身がどうなっているのか﹂を学べるように書かれているので、ドキュメント構造やコンテンツストリームの雰囲気を手軽に体験できる良書です。しかし、この﹁自分で簡単な

igrep 2019/12/13

PDF

リンク

PDFから「使える」テキストを取り出す（第4回） - golden-luckyの日記

昨日までで、PDFからテキストを取り出すにあたり、グリフから文字を手に入れるところまでを説明しました。いや本当のことを言うと、まだ全然説明できてないんです。でも、文字の話ばかりしていても先に進めないので、今日は︵可能な場合には︶PDFから文字を入手できるものとし、そこからテキストを再構築する話に進みます。文字については改めて明後日にでも補足記事を書くかも︵このシリーズはいちおう今日と明日で終わる予定︶。 PDFオペレータを読むとグリフを置く場所がわかる昨日に引き続き、次のようなテキストセクションで考えます。グリフから文字の解決は済んでいるということにして、TJオペレータの引数は文字そのものに置き換えました。 BT /F1 12.4811 Tf 125.585 -462.55 Td [(#1)] TJ /F2 13.2657 Tf 19.932 0 Td [(代数的データ型とパター

igrep 2019/12/13

PDF

リンク

PDFから「使える」テキストを取り出す（第3回） - golden-luckyの日記

昨日の記事では、PDFのページに表示されるコンテンツはPDFのドキュメント構造を掘っていくと手に入れることができて、それはこんな姿をしているぞ、というところまで話が進みました。 $ hpdft -r 66 NML-book.pdf [ /Filter: /FlateDecode /Length: 381.0, q .913 0 0 .913 0 595.276 cm q 462.33906 0 0 655.95015 -3.064 -652.208 cm /Im24 Do Q 1 G 1 g BT /F1 12.4811 Tf 125.585 -462.55 Td[(#1)]TJ /F2 13.2657 Tf 19.932 0 Td[<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>] TJ

igrep 2019/12/13

すごいたらい回しだ…

PDF

リンク

なんでドキュメントといったらXMLが出てくるのか - golden-luckyの日記

昨日は、ドキュメントにおける構造というのはセマンティックな構造である、という話をしました。今日は、そのセマンティックな構造をどう扱うか、という話です。ドキュメントの構造は一般にXMLを使って表されている結論から言うと、ドキュメントの構造は、XMLで扱うのが一般的です。ドキュメントの構造を表すのにXMLがよく使われているのには理由があって、それは、ドキュメントが木構造だからです。本当はここで﹁XMLとは何か﹂みたいな話をする必要があると思うんですが、ここではXMLというのは﹁木構造のデータを表現するときの標準的な構文﹂くらいの意味で使います。つまり、表現する﹁木構造のデータが具体的にどんなか﹂については別の問題ということにして、木構造で表せるようなデータにとって共通で必要そうな構文だけを定めたものが、︵ここでいう︶XMLです。ちなみに、﹁木構造のデータが具体的にどんなか﹂のほう

igrep 2019/12/08

"ぶっちゃけ木構造を表すなら、山かっこタグよりも優れたシンタックスがあります。そう、S式です。S式をシンタックスとするXMLをSXMLといいます。" だよねー。 ●xml

リンク

ドキュメント技術とプログラミング言語の相似について - golden-luckyの日記

よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言及される「構造とスタイルの分離」における「構造」です。昨日までの話ではPDFにもドキュメント構造というのが出てきました。あれは、この「構造とスタイルの分離」というときの「構造」とは別物なので注意してください。たぶん、PDFのドキュメント構造には、「ドキュメントを表すデータ構造」くらいの意味合いくらいしかありません。一方、ドキュメントの話において「構造とスタイルの分離」というときの「構造」は、もうちょっとこうなんていうか、セマンティックな話です。データをどう構成するかではなく、ドキュメントで表したい意味をどう構成するか、という話。し

igrep 2019/12/08

「記法・構造・見た目」と「ソースコード・AST・実行ファイル」

リンク

PDFから「使える」テキストを取り出す（第6回） - golden-luckyの日記

今日まで延々と﹁PDFからテキストデータを取り出すのは大変﹂という話を続けてきましたが、その構造を見るにあたっては、hpdftという自作のツールを使ってきました。大変とはいっても、まあ実現困難な話ではなく、この程度のPDFパーザであれば趣味プログラミングで自作できる範囲です。しかし、べつにわざわざ自作しなくても、﹁PDFからテキストデータを取り出す﹂ためのツールなら世の中にはすでにいくつもあります。特に有名で昔からよく使われているのは、Xpdf由来のpdftotextでしょう。 pdftotext http://www.xpdfreader.com/ XpdfからはPopplerが分派しているので、Poppler版のpdftotextもあります。また、pdfminerというツールもあります。 pdfminer https://www.unixuser.org/~euske/py

igrep 2019/12/06

PDF

リンク

PDFから「使える」テキストを取り出す（第2回） - golden-luckyの日記

昨日は、PDFの本来の用途は﹁人間がPDFをビューワーで開いて読む﹂ことなので、そこから文字を抜き出すのは一筋縄ではいかない、という話をしました。ではどうすればPDFファイルの中からテキストを取り出せるの、というのが今日の話の出発点です。まず昨日の記事で、﹁PDFには国際的な規格があり、これはAdobeから﹃PDFリファレンスマニュアル﹄という形で無償で入手できる﹂という話をしたことを思い出してください。昨日は話のついでみたいな感じで書きましたが、実を言うと、このリファレンスの中に、﹁PDFファイルの中に書き込まれているグリフを表示するための情報からUnicodeなテキストを取り出す手法﹂がちゃんと書いてあるのです。具体的には、﹃PDFリファレンスマニュアル第6版﹄の §5.9 "Extraction of Text Content"に、その情報が一応整理されています。ただし、言

igrep 2019/12/02

pdf

リンク

PDFから「使える」テキストを取り出す（第1回） - golden-luckyの日記

PDFからテキストを取り出すのは、意外と大変です。それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵︵﹁グリフ﹂︶をコンピューターで扱えるような﹁文字﹂にする方法です。これには2つのアプローチが考えられます。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る PDFファイルの中身を解析してテキストを抜き出すこのうち2つめの話は明日以降にして、今日は1つめの話をします。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を﹁視覚的に読む﹂ということです。これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ︵文字の形︶をページ上に表示するための汎用の仕組

igrep 2019/12/01

PDF

リンク

はてなブックマーク

タグ

ブックマーク / golden-lucky.hatenablog.com (24)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第1週）

月間はてなブックマーク数ランキング（2024年6月）

今週のはてなブックマーク数ランキング（2024年6月第5週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス