PDF

イオンとかスーパーへ行くと、かぼちゃをくりぬいたやつが飾ってある。

異教徒の祭り、かぼちゃ祭り、大仮装行列が執り行われる、あれが近づいているからだな。いつから日本は、こんな変なものを許容するようになったんだ。

それって、大体、毛唐の祭りだろうが！ああ、毛唐って言い方は、オイラーの英語の先生の口癖だったんで、伝染しただけだからね。きっとあの先生は、進駐軍のキャンプででも、英語を覚えた口だろう。そして、そこでいやな事があって、蔑んだんだろうね。結構、歳をめされた方だったんで、復帰軍人だったかも知れないな。喰うに困って、やむにやまれぬ就職口を求めたら、そういう所に行きついた。違うかな。まあ、いいや。

ハロウィンに解説が載ってた。ねずみランドが日本へ持ち込んだんか。売り上げ倍増を狙ったんだな。

チョコレート祭りとかマシュマロ祭りとか、来月はワインの新酒祭りがあるな。まあ、適当にやってくださいな。オイラーには、関係ねぇ。

姪子の子供が７５３なんだけど、祝いってあげるものかな？ぷち悩んでる。

印刷で四苦八苦

前回やった血圧グラフのPDFファイルを、Windows10でいざ印刷しようとしたら、白紙が出てきた。そんな馬鹿な！印刷前のプレビューでちゃんと印刷出来ますよって表示してくるんだけどね。

ひょっとして、Evinceと相性が悪いPDFをgnuplotが生成しちゃったかと思って、firefoxから印刷を試みるも、やっぱり白紙答案。ぐぐるさんのChromeでも白紙ですよ。

全く違うPDFで印刷するも白紙。しょうがないので、Windows7で試してみるも白紙。プリンターが白痴なのかな？どこのプリンターだ？年代物のキヤノンのiP2500と言う、インクジェット式のやつだ。

Windows7の時代に購入したはずだけど、その頃PDFなんて印刷したかなあ？もうすっかり記憶が飛んでいるぞ。Microsoft Windows 10対応状況(インクジェットプリンター)に載ってる、ドライバーの更新は関係なさそうだしなあ。

絶対に印刷出来そうな、車の保険の約款というやっかいな契約書も印刷出来ない。モンスタークレーマーになって、印刷出来ないから契約更新しないって言ったら、プリンターを進呈しますとか、ならないかな。

ともかく、PDFは印刷出来ないプリンター認定ですな。こう断言しちゃうと、観音さんは、そりゃ悪魔の証明ですよと諭してくるのかな。対抗の口答え（もとえ、主張）として、背理法を持ち出すか。全て、、、出来ないを否定するには、一つでも出来るやつを見つければ済むけど、全否定は、普通の方法では証明出来ないからね。

出来るとして、その矛盾を突ければ、最初の仮定が間違っていた事になる。これが背理法による証明。何とか適用出来ないか考えてみたけど、無理っぽい。

ぐぐるさんに聞いてみても識者に聞いてみても、納得できる回答はえられず。ただ、アドビが言う事には、印刷出来ない場合、PDFファイルの内容をビットマップに変換して印刷出来るよと苦肉の策が載ってた。そして、その実行手順も例示されてた。

一瞬くらっときたね。アドビ純正のアクロバットを入れようと！でも、寸での所で思いとどまった。なぜかというと、そんなウィルスの温床になりそうなのはだめ。JavaScriptを実行出来るって、誰が嬉しいの？機能てんこ盛りで起動に時間がかかるんで、あらかじめ起動させておいて、瞬時に対応しますって。（こうやって、一般消費者を騙す手口。これ昔の手口で、最近のやつはちっとも知らない。かれこれ10年ぐらいは疎遠になってますから。）

なんか間違ってないか。どこでも手軽に印刷出来ますっていう素朴な作りから始まったはず。ずっとそれに徹してればいいのに。機能増強病に罹患してるね。

で、PDFをPNGに変換するぐらになら、わざわざアクロバットを使う事もなかろう。ぐぐってみたら、色々出てきたけど、どうも胡散臭いんだよな。試用期間後に有料になるとか、金払うまで透かしが入るとか。これもそれも、一般ユーザーを対象にする、WindowsOSだからだな。

間口をUnix系に広げたら、OSSでなんとかなりそう。そう思ってぐぐったら、ImageMagikに付属してる、convertで変換出来るとの事。Debianには勿論入っているし、OpenBSDにも有るんで、有名なやつだな。（emacsが呼び込んでくるのだよ。）

その前に、pdfのグラフを作るgnuplotのスクリプトで、日本語を混ぜ込めるか？そりゃもう、原稿をutf-8にしておけばOK。

$ convert zzz.pdf hoge.png
$ file hoge.png
hoge.png: PNG image data, 595 x 822, 8-bit gray+alpha, non-interlaced

後は、このPNGをWindows10へ持って行って、Firefoxへドロップ。そして印刷。125%に拡大すると、収まりがよかった。（そんな、拡大・縮小は厳禁ってのを忘れるぞ！）

なお、モノクロを指定してグラフを書かせているんだけど、gnuplotが５系だと、線色が違うため、その表現で、点線に変換されてしまうので、gnuplotは4系が良い。

それにしても、印刷とフォントは、鬼門中の鬼門だな。GUIの特徴、見た通りに印刷されるなんて、大嘘じゃん、と貧乏人が申しております。

株馬で儲けて、レーザープリンターと言うか、postscriptを直接理解してくれる、プリンターでも買えよ。オイラーのプリンターは、5000円だか6000円だかのやつ。こんなプリンターが、 postscriptのエンジンを積んでいる訳がない。

分類上は、非PostScriptプリンター。オイラーの中では白痴プリンターが分かり易い。パソコンから送られてくるビットマップデータを印刷するだけの代物って事です。

別解

思わずPNGに走っちゃったけど、PDFで何とか出来ないか考えてみる。そう言えば、友人の所のプリンターが壊れ、どこかの工場見学の許可メールが印刷出来ないって相談が有ったな。その時のオイラーのアドバイスを思い出した。

メール文面を、Windowsの画面キャプチャでファイルに落として、それをUSBでコンビニへ持って行って印刷すればどうでしゃろ。コンビニに行ったら、PDFとJPGのファイルは受け付けるそうだった。だったら、メールをLiberOfficeに張り付けて、そこでPDF印刷で、PDFファイルにし、それを持って、コンビニへ。これで事なきをえたとか。

でも、オイラーの所は田舎で、医者までの道のりにコンビニなんてないぞ。それに、たとえ10円と言えども無駄金を払うのは負けた気になる。知恵を出せ。

自分宛に、PDFを添付したメールを送付。それをipadで受ける。メールを開いて、添付書類を見えるようにして、ipadをスリーブ。医者の所で、ipadを叩き起こす。おばちゃん看護婦さんでも、スマホの親分ipadぐらいは、説明なく使えるだろう。

こんなシナリオで、Wifi停止の飛行機搭乗モードにしてスリープ。そしてたたき起こしたら、メールの画面が再接続を求めて、PDF表示が消えちゃった。馬鹿ipad。状態を推測しろよ。

メールがだめなら、アドビのPDFビューアが入ってるから、それで何とかならないか。問題は、オイラーが作ったPDFをローカルに保存する方法。クラウド経由で（たぶん）取り込めるのだろうけど、オイラーは一切クラウドを信用してないので、封印してる。どうしても、ファイルを移すなら、Windowsに入れる、重厚なアプルのアプリ経由か。そこまでは面倒したくない。（ってか、Windowsには余計なアプリを入れない主義）

大体、医療機関で、ipadみたいな電子機器を使うのは、マナー違反と思われ。

ちょっとお勉強

フォントと印刷に弱い。PDFがオイラーの環境で印刷出来ないを相談した識者は、プリンターを３台も所有してるそうだ。仕事がら必要なので、買い替えていったら、いつのまにか３台持ちになり、古いやつはバックアップとして保有してるとか。

その彼が言う事には、Windowsの環境を7,10と切り替えても同じ症状（白紙答案）になるなら、 Linuxでどうなるかやってミレー。やはりそうなるよね。でも、純粋に丸ごとLinux機は無いので、そのアドバイスは採用出来ず。

ふてくされて、フォントの勉強でもするか。

$ fc-match :lang=ja
sazanami-gothic.ttf: "Sazanami Gothic" "Gothic-Regular"
$ fc-list
/usr/X11R6/lib/X11/fonts/75dpi/luIS08-ISO8859-1.pcf.gz: B&H Lucida:style=Sans Italic
  :

マッチで、日本語が扱えるフォントを確認。リストで文字通り、どんなフォントが入っているか確認出来るとな。

あと、ふらふらしてたら、

日本語フォントのインストール
$ sudo port install sazanami-font
gnuplot起動とグラフを出力
$ gnuplot
gnuplot> set fontpath '/opt/local/share/fonts/sazanami'
gnuplot> set terminal png font 'sazanami-gothic'
gnuplot> set output 'sample1.png'
gnuplot> plot x * x title '放物線'

こういう事をやってる方に出会った。gnuplotの中で、使うフォントのパスを指定出来るのね。そりゃそうだね。manした時に出て来る、環境変数 GNUPLOT_FONTPATHとは別物みたい。

関連して、見落としていたターミナル pngcairo なんてのも引っかかってきた。この cairoってついてるのは、システムお任せのグラフィックライブラリィーを使うものらしい。これを使うと、OS寄りのフォント等が容易に使えるそうだ。

set terminal pngcairo mono font "Ryumin-Light-90pv-RKSJ-H,9" size 21cm,25cm

これで、pngファイルに直接日本語フォントを埋め込めた。いちいちunixへ持って行って、変換しなくてもいいな。但し

(gnuplot.exe:1860): Pango-WARNING **: couldn't load font
  "Ryumin Light 90pv RKSJ H Not-Rotated 180",
   falling back to "Sans Not-Rotated 180", expect ugly output.

180度回転したやつは無いから、お眼汚しごめんな、って言ってる。けど、そんなの関係ねぇ。

cairo, pango

上でcairoだとかpangoなんて言うよく知らないものが出てきた。懐炉ならよく知ってるんだけどね。ほっ懐炉は、雪国に必需品、そろそろ準備をしておかねば。

この際だから首を突っ込んでおく。

cairo: 2 次元画像描画ライブラリ

これ、懐かしいるびまに載ってた記事。なるほど、postscriptと親戚みたいだな。色々なフォーマットをサポートしてるんか。直接使う事は無さそうだな。

Pango の接続すべての言語でテキスト・レイアウトを可能にするフレームワーク

Pango の接続 Pango の実際

国際化文字表示機構って、かの昔にemacsのあの人達が苦労して開発してきたな。ああ、rubyの親分さんも、文字コードはUCS一択に抵抗されて、色々な表現を容認するよう苦心されてたなあ。

pythonは３系になって、堂々と世界統一文字コードを押して、もう勝敗は決してしまった感がある。相変わらずWindowsはSHIFT_JISが大手を振ってまかり通っているけど、いいかげんに世界統一文字コードにしろよ。

そりゃもう無理ですって。東日本の50Hz、西日本の60Hzみたいに、もう統一は不可能なのさ。ここで、いきなり電気が出てきたのは、今読んでいる、発電・送電・配電の本の影響ですよ。無暗やたらに、色々な事に首を突っ込むのは、暇人の特権です。

PDF

PDFってオイラーの所では見るための仕様であって、印刷するには適さないものになり下がっている。まあ、綺麗に見られれば、印刷しなくてもいいわいと、貧乏人の強がりであります。

でも、PDFのファイルの中身はどうなってるかぐらい、知っておいた方がいいかなと思って、ご隠居さんは、首を突っ込んでみるのです。ぴったりな記事を見つけたぞ。

実装して学ぼう！PDFファイルの構造とその書き方読み方

これ、素晴らしい。もう神棚に上げて、毎日拝みたくなるほどの内容。フォントの扱いが段々見えてきたな。ソースがHaskellで書かれているのもオイラーの心を刺激する。

知らないコマンド、xxdとかpdftkも知ったし、ddの面白い使い方もさりげなく披露されてる。

これはもう、実習してみる鹿。

$ ghci jamakepdf.hs
GHCi, version 8.2.1: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( jamakepdf.hs, interpreted )

jamakepdf.hs:9:1: error:
    Could not find module `Codec.Text.IConv'
    Use -v to see a list of the files searched for.
  |
9 | import qualified Codec.Text.IConv as IConv
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, 0 modules loaded.

日本語混じりの原稿をpdfにしてくれるという有り難いスクリプトをOpenBSDで実行したら、見事にエラーですよ。そんなモジュール入っていないですって。OpenBSDのghcは追加パッケージを作れない（Cabalがインストール出来ない）ので、諦めて、Debianで試してみる。

deb9:pdf$ stack ghci jamakepdf.hs

Warning: Couldn't find a component for file target /tmp/pdf/jamakepdf.hs. Attempting to load anyway.
Configuring GHCi with the following packages:
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( /tmp/pdf/jamakepdf.hs, interpreted )

/tmp/pdf/jamakepdf.hs:9:1: error:
    Failed to load interface for ‘Codec.Text.IConv’
    Use -v to see a list of the files searched for.
Failed, modules loaded: none.
Loaded GHCi configuration from /tmp/ghci1567/ghci-script

警告を出しつつ、本体はローディング出来た。勿論この状態では使用に耐えないけどね。

deb9:pdf$ stack install iconv
iconv-0.4.1.3: download
iconv-0.4.1.3: configure
iconv-0.4.1.3: build
iconv-0.4.1.3: copy/register

それで、iconvをインストールした。そしたら、ghciで文句を言われずにロード出来たよ。

*Main> :bro
data PdfElem
  = PdfNull
  | PdfBool Bool
  | PdfInt Int
  | PdfString BS.ByteString
  | PdfName BS.ByteString
  | PdfRef Int
  | PdfArray [PdfElem]
  | PdfDict [(BS.ByteString, PdfElem)]
  | PdfStream BS.ByteString
renderElem :: PdfElem -> Builder
data PdfObj = PdfObj Int PdfElem
renderObj :: PdfObj -> Builder
data PdfVer = PdfVer Int Int
renderHeader :: PdfVer -> Builder
data PdfXref = PdfXref [PdfXrefEntry]
renderXref :: PdfXref -> Builder
data PdfXrefEntry = PdfXrefEntry Int Int PdfXrefEntryUse
renderXrefEntry :: PdfXrefEntry -> Builder
data PdfXrefEntryUse = FreeEntry | InUseEntry
renderXrefEntryUse :: PdfXrefEntryUse -> Builder
data PdfTrailer = PdfTrailer Int Int Int
renderTrailer :: PdfTrailer -> Builder
data PdfFile = PdfFile PdfVer Int [PdfObj]
renderPdf :: PdfFile -> BS.ByteString
textsToPdf :: [[BS.ByteString]] -> PdfFile
splitN :: Int -> [a] -> [[a]]
main :: IO ()

後はゆっくりとコードを鑑賞する事にしよう。巷に溢れているオイラー問題を解きましたと違って、ちゃんと役にたつスクリプトを眺めるのは楽しいからね。

で、PDFでのハロワをやって、その構造を確認。

$ pdftk hello.pdf output aa.pdf
$ tail -6 aa.pdf
/Root 1 0 R
/Size 6
>>
startxref
441
%%EOF
$ dd skip=441 bs=1 count=100 if=aa.pdf
xref
0 6
0000000000 65535 f
0000000015 00000 n
0000000066 00000 n
0000000223 00000 n
0000000125 100+0 records in
100+0 records out
100 bytes transferred in 0.000 secs (952381 bytes/sec)

原稿のhello.pdfにはクロスレファレンス等が足りていないので、pdftkでそれらを補ってもらう。ファイルの最後にレファレンスへのseek値が書かれている。それを頼りに、ddでファイルの途中を覗きみる。bs=1 が、肝だなあ。

$ hexdump -C aa.pdf | head -2
00000000  25 50 44 46 2d 31 2e 37  0a 25 e2 e3 cf d3 0a 31  |%PDF-1.7.%.....1|
00000010  20 30 20 6f 62 6a 20 0a  3c 3c 0a 2f 54 79 70 65  | 0 obj .<<./Type|

一方、PDFファイルの２行目は、％のコメントマークに始まってMSBが立った4バイトの適当な文字が並んでいる。これで、バイナリーファイルだから、取り扱い注意とeditorに警告を与える役目をするとな。

上のハロワぐらいなら、editorで開いても何とかなるけど、本式のPDFだと、データ部は圧縮されてて、始末に負えない。血圧グラフの例を、emacsで開いてみると

%PDF-1.5
%\265\355\256\373
3 0 obj
<< /Length 4 0 R
   /Filter /FlateDecode
>>
stream
x\234\335]\313\256\344\270\221\335\353+rY\265\350l\361%\221\206\335^K^C\206^A^C\
  :
7\371\262\341w\333^?^@\)^\305
endstream
endobj
4 0 obj
   5498
endobj
 :

どうやら、stereamからendstreamの間が、人間には意味不のデータになってるんで、そんなの消してしまえーー。こういう時は、sedの出番ですな。

$ cat zzz.pdf | sed '/^stream/,/^endstream/d' > yy.pdf

15Kbyteあったファイルが3Kbyteになりました。おかげで、ファイルの構造がよく見えるようになったよ。180行ぐらいのファイルなら見るのも容易。

18 0 obj
<< /Type /Font
   /Subtype /CIDFontType2
   /BaseFont /OVVQFU+Sazanami-Gothic-Regular
   /CIDSystemInfo
   << /Registry (Adobe)
      /Ordering (Identity)
      /Supplement 0
   >>
   /FontDescriptor 17 0 R
   /W [0 [ 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 100\0 1000 ]]

OpenBSDに入っていた、さざ波フォントを使ったんだけど、アドビに登録してんの？それから、こんな証明書も入っていた。

19 0 obj
<< /Creator (cairo 1.14.8 (http://cairographics.org))
   /Producer (cairo 1.14.8 (http://cairographics.org))
>>

pdftk (pdf tool kit)

解説記事の中で、pdftkってのがさりげなく使われていた。WindowsのPDF用ツールと違って変な紐付けされていないので、安心して使えそう。どんな機能があるか、宣伝文句を調べてみた。

If PDF is electronic paper, then pdftk is an electronic staple-remover,
hole-punch, binder, secret-decoder-ring, and X-Ray-glasses.  Pdftk is a
simple tool for doing everyday things with PDF documents.  Use it to:

* Merge and/or split PDF Documents
* Rotate PDF Documents or Pages
* Decrypt/Encrypt PDF Documents
* Fill PDF Forms with X/FDF Data and/or Flatten Forms
* Apply a Background Watermark or a Foreground Stamp
* Report or update PDF Metrics such as Metadata and Bookmarks
* Attach Files to PDF Pages or the PDF Document
* Unpack PDF Attachments
* Uncompress and Re-Compress Page Streams
* Repair Corrupted PDF (Where Possible)

WWW: http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/

Uncompressって、圧縮を解くって事だよね。manしたら、懇切丁寧な例が出てきたぞ。早速試してみるか。

$ pdftk zzz.pdf output xxx.pdf uncompress

圧縮を解いてみたら、48Kbyte、1667行に膨れ上がったぞ。

開いてみると、フォントとかグラフのデータが展開されて見えてきた。一部展開出来ないものが混じってるけど、なんだろう？

[ 0.2 2] 0 d
q 1 0 0 -1 0 822 cm
54.449 350.199 m 570.551 350.199 l S Q
0.25 w
  :
0 0 0 RG q 1 0 0 -1 0 822 cm
95.801 165.25 m 102.5 134.949 l 109.199 122.852 l 115.898 134.949 l 122.852
  :

アフィン変換

1. 0. 0. 1. 50. 720. cm
a  b  c  d  e   f           % 後の説明の為に記号を定義しとく

説明の中に、この６つの数値は、アフィン変換用のパラメータと有った。よう知らないので調べてみた。

アフィン変換とは

画像処理ソリューションアフィン変換

遊べと言われたので、遊んでみる。例によって、gv -watch aa.pdf しておいて、emacsで書き換えて保存を繰り返し、変化を観察する。

deb9:tmp$ gv -version
gv 3.7.4

但し、Debianのgvは非寛容。文字数の増減でエラーになる。対してOpenBSDのgvはDebianのそれと同一バージョンだけど寛容な振る舞い。文字数が増減しても、何喰わぬ顔をして描画してくれる。(更に驚いた事に、xrefが無いものでも描画した)この違いは何処にあるの？

aは、横倍率。２とすると2倍の横幅になる。負数にすると、起点から左に向かって描画される。（Y軸に対称になるって事だな）

dは、縦倍率。２とすると高さが２倍になる。負数にすると、X軸に対して反転する。

bは、１で45度反時計回りに回転。負で時計回りに回転。

cは、正数で、イタリック体のように、右側に寝る。負数で、左側に寝る。

eとfは、文字列の左下側の起点位置。ペーパーの左下が (0,0)の原点だ。

但し、上記は a-f を、単独で変化させた場合の挙動です。

さて、元になってる行列の演算を試してみるかな。この所よく使っている maximaだと、こんな感じ。ちょっとうざったい気がする。

(%i4) a: matrix([1, 0], [0, 1]);
                                   [ 1  0 ]
(%o4)                              [      ]
                                   [ 0  1 ]
(%i5) a . [1,2];
                                     [ 1 ]
(%o5)                                [   ]
                                     [ 2 ]

こちらは、octaveの例。入力がプチ楽だ。さすが行列が命ってアプリだけあって、よく考えられた入力方式だな。

octave:1> a = [1 0; 0 1]
a =

   1   0
   0   1

octave:2> a * [1; 2]
ans =

   1
   2

そして、計算方法を復習。何でも、行列の積を下記のように定義すると、非常に都合がよいので、そう決めたらしい。数学らしからぬ所作ですよ。この分野は、江戸時代の数学者、関孝和さんが有名。絵馬で問題を掲載。それを解いた人も絵馬を奉納。なんとゆるやかな佳き時代。

 |a  b|   |x|      |ax + by|
 |    | * | |   =  |       |
 |c  d|   |y|      |cx + dy|

行列というものはベクトルを変換するものなんだな。

『円周率の謎を追う：江戸の天才数学者・関孝和の挑戦』鳴海　風　作（中学生向け課題図書）。オイラーも中学生になった積りで、読んでみたよ。