CL-PDF と ZPB-TTF の擴張

* きっかけ

文書生成にCL-PDFを利用させてもらふやうになつて久しいが、ある日某部門から、特定のPDFリーダ (Adobe AcrobatReader) で文字化けせずにテキストをcopy/pasteできるやうにとの要請を受けた。
ghostscriptを使ってpdf壓縮をすると、サイズは小さくはなるのだが、copy/pasteしたときに一部テキストが文字化けする。
とくにIPAMinchoを埋込んだ部分は壓縮前であつても文字化けする。[例]
これは Google Chrome や Safari でも同樣。ただし、Microsoft Edge や FireFox などでは、文字化けせずにcopy/pasteが出來る。

* pdf2text

一部browserでは文字化けしないのだから、文字化けする方に技術的不具合があることは容易に想像できるが、これを證明するために自分でpdf2text處理をprogramしてみた。
一部ブラウザは =/Encoding /Identity-H= 指定されてゐるとテキストを拾へないやうだ。
=/CIDSystemInfo= に =/Ordering(UCS)= とあるのだから、 UCS2 か UCS4 のコードだと思って解釋できさうなものだし、事實拾へるブラウザもあるわけだが、自分で書いたコードでは UCS2 として解釋しテキスト抽出に成功させた。

 CL-USER(93): (pdf:pdf2text "~/project/cl-pdf/PDFs/Identity-H.pdf")
;; Inside non-filter file
#<EQL hash-table with 1 entry @ #x1042bdf32>
("いろはにほへどちりぬるをあさきゆめみしゑひもせすわがよたれぞつねならむわがよたれぞつねならむ.....")

* Encoding

さうかうするうちに、 =/Encoding /UniJIS-UTF16-H= としてやれば、ブラウザの如何にかかはらず、テキスト抽出が出來る事に氣付いた。
ただし、 =/Identity-H= を =/UniJIS-UTF16-H= に置換へるだけでは cl-pdf が吐出す cidmap が =/Ordering(Japan1)= のオーダーになってゐないので、竝び換へが必要である。これを =read-ipa-file= で實現した。[iroha.pdf]

* フォント壓縮

CL-PDF で IPAMincho を使って、かつ、テキスト copy/paste が出來るといふ要求には答へることができたが、未だサイズが大きい。
フォント壓縮に ghostscript を利用すると、一部ブラウザでの一部文字の文字化けが置こる。とくに半角カナが拾へない。これは自分で書いたprogramでもedgeなど文字化けしないブラウザでも同じで、今のところ原因は追及してゐないが、IPAMinchoの埋め込みフォントだけでも壓縮できれば、サイズ輕減の上で ghostscript には及ばずながら、要求元部門は默らせることができさうである。

* zlib

CL-PDFではzlibを使ってstreamオブジェクトを壓縮する方法が提供されてゐる。
今迄宛ってこなかったが、この方式でどの程度壓縮することができるのが見てみると、zlib無（8361590）に對して zlib有（5914565）と、多少の輕減はあるものの、MByteのオーダは變はらない。

* zpb-ttf

CL-PDFではzpb-ttfといふ ttf font loader を利用してゐるが、このloaderを解析し、loadしたfontを逆にdumpできれば、解決の絲口となるかと思ひ、ひと先づ、loadしたものと全く同じものをdumpできるやう、zpb-ttfを擴張した。

* cmap

次に、IPAMincho には三つの cmap が定義されてゐるが、 cmap table のうち、UCS2 のものだけdumpし、他は無視しても、埋め込みフォントとしては問題のないことを確認した。

* glyph

しかし、これだけだと、せいぜい 1Mbyte 程度の削減にしかならない。
そこで本來の目標であった、glyphを減らす作業にとりかかった。
先づ試みたのは、埋め込むfontのファイルサイズはそのまま（cmap二つ分だけの輕減）とし、不要なglyphはnullで埋めて、必要なglyphだけを書出すといふ方法である。
glyphの大部分をnullで埋めておけばzlibがdeflateの際に縮めてくれるだらう、といふ期待である。
この方法でつくったPDFが、ghostviewで壓縮したサイズには遥かに及ばないものの、元々の大きさの 1/20 程度まで縮めることが出來た。iroha-font-subset-v1.pdf

* =/W=

=/FontDescriptor= が持つ =/W= のサイズが大きい。
現状154501に比べGhostscript版は437byte。これだけで150Kは縮まる。
幸、IPAMinchoはプロポーショナルフォントではないので、Widthは全角1000か半角500しか存在しない。
數の多い全角characterをCL-PDFが持つ width array から除去し、半角のものだけを集めると、數にして225しか存在せず、 =/W= の大きさを276byteまで縮めることが出來た。以上によりPDFの大きさを元々の 1/30 以下に壓縮できた。iroha-font-subset-v2.pdf（239512）

* 更なる壓縮

ghostscriptで壓縮をかけたファイルの中身を見ると =cmap= 他 (=GDEF= =GSUB= =OS/2= =gasp= =name=) のtableが存在せず、また、使はれないglyfは、 =number-of-contours= を =0= として =end-pts-of-contours= 以下を省いてある。
さらに、使はれないcharacterの =CIDToGIDMap= はnull埋めすることで壓縮效率が増すやうな工夫がされてゐた。
上に倣ひ、不要なtableをdumpするのをやめ、glyfのdumpを改め、さらに利用されない =CIDToGIDMap= をnull埋めすることで、1/70 程度までの壓縮に成功した。iroha-font-subset-v3.pdf

* 更なる更なる壓縮

ghostscriptで壓縮をかけたファイルと比べ、 =loca= =hmtx= =vmtx= のtableサイズが目立って大きい。
=loca= に置いてはindexをshortで持つかlongで持つか (shortの場合は値を2で割って持つ) の違ひが大きさに關係するが、その判斷は、 =head= tableで指定されてゐる。IPAMinchoではlongで持ってゐたが、これをshortにすることで、25Kほどが節約できた。
また、metrics情報 =hmtx= =vmtx= は、glyphの數だけ情報があれば好いやうなので、これを font index の最大値に押さへ、結果、1/90 以上の壓縮に成功した。iroha-font-subset-v4.pdf

* FontSubsetの命名規則

Adobeの仕樣によれば、FontSubset には、Capital 6文字に =+= を加へた prefix を付けてやらないといけないので、それに對應した。iroha-font-subset-v5.pdf

: /BaseFont /IPAMincho

ではなくて、

: /BaseFont /TYGDXA+IPAMincho

のやうに。

これは以前横田に指摘されてゐたが放っておいたのを仕樣に副ふやうに改めた。

* 埋め込みフォントの除去

埋め込みフォントの除去ができるやうにした。

CL-USER(96): (pdf:remove-embedded-fonts "~/project/cl-pdf/PDFs/iroha.pdf" "temp.pdf")
#P"temp.pdf"

 のやうに使ふ。

CL-USER(97): (list (file-length "~/project/cl-pdf/PDFs/iroha.pdf") (file-length "temp.pdf"))
(8361590 314905)

ファイルサイズがあまり減つてゐないのは、FontFile2を除去しただけで、CIDtoGIDMapが未だそのまま殘つてゐるせゐである。

* ＭＳフォントの壓縮

ExcelがSaveAsで吐くPDFには無駄が多いやうだ。
FontFile2を節約すれば小さくできるのではと取掛る。
MS-Gothic, MS-Mincho, MS-PGothic と MS-PMinchoのFontFile2から餘分なtableを除くだけで50％以上の壓縮が出來る。
ただし、半角英數字が表示されないといふ問題に遭遇。
cmap table を入れてやるとうまく出た。何故cmapが必用なのかは解らない。 (GS版にcmapは存在しない)

: CL-USER(525): (pdf::compress-pdf-fonts "1-1-1.pdf" "1-1-1-compress.pdf")
: CL-USER(526): (list (file-length "1-1-1.pdf") (file-length "1-1-1-compress.pdf"))
: (520528 259549)

 不要なglyphを削ればさらに壓縮できるかも知れないと、やってみたが、ほとんどサイズは變化せず、しかも、未だ縱書きをサポートしてゐないため、問題が出る。

縦書きに對應し、ghostscriptを眞似て、フォントを一つにまとめてやれば、さらなる壓縮ができる筈だが…

Comments

Post a Comment

Popular posts from this blog

Common Lisp コーディングスタイルについて

Common Lisp コーディングスタイルについて 一つの文章は、一つ若しくは幾つかの單語から成り立つてゐるのでありますから、 單語の選擇のよしあしが根本であることは、申す迄もありません。そこで、 その選び方についての心得を申しませうなら、 　異を樹てようとするな と云ふことに歸着するのであります。それを、もう少し詳しく、 箇條書きにして申しますと、 　一 分り易い語を選ぶこと 　二 成るべく昔から使ひ馴れた古語を選ぶこと 　三 適當な古語が見付からない時に、新語を使ふやうにすること 　四 古語も新語も見付からない時でも、造語、─ 自分で勝手に新奇な言葉を拵へることは愼しむべきこと 　五 據り所のある言葉でも、耳遠い、むづかしい成語よりは、耳馴れた外來語や俗語の方を選ぶべきこと 等であります。 　　　　　　　　谷崎潤一郎 『文章讀本』 はじめに 先づ始めにお断りしておきますが、 ここで述べるコーディングスタイルを コーディング規則のやうな馬鹿げたものと同じにしないでもらひたい。 スタイルはあくまで指針であつて規則ではありません。 規則とはそれを強制するだけでなく、それが何故さうあるか考へることを禁ずるものです。 スタイルは、それが何故さうあるかを理解しない者に押し付けることが不可能な種類のものです。 自分で考へようとしない人にいくらスタイルを説いたところで無駄である。 このことを踏まへた上で次に進むことにしませう。 何故にスタイルが問題となるのか わたしも含め、たれもがつい忘れがちなことは、「プログラムは人に讀まれる」といふことです。 コンピューターに向かつてゐると仕事とは本來「人」相手のものだといふ、 あたりまへの意識が薄れてきてしまふ。 しかしプログラマーが相手をするべきは、コンピューターよりもむしろ人だと考へるべきです。 あなたが今日書いたプログラムは明日たれか別の人が讀まんとも限らない。 たとへあなたしか讀まないプログラムであつても、 一年もたてばその「あなた」もまた「別人」になつてゐるのだ、 とたしか G.M. ワインバーグが何かの本で言つてました。 プログラムを書く上で留意すべき事項は多々ありますが、 人が讀んでわかるやうに書く...
Read more

The Art of the Metaobject Protocol を讀む

The Art of the Metaobject Protocol を讀む はじめに The Art of MetaObject Protocol といふ本があります。略してAMOPなどと呼ばれることもありますが、西暦1991年に出版されてから、かれこれ30年近く經て、今尚、コンピュータ科學分野上、樣樣な示唆に富んだ良書だとされてゐます。 本書のIntroductionには讀者對象として、 Programming Language Designers , Programmers and software engineers , People working with object-oriented languages , People interested in reflection , The CLOS Community 等が擧げられてをりますが、これを見ても、II部を除けば 1 140頁にも滿たないこの書が、如何に中身の濃いものであるかは容易に想像できます。 それだけに、なかなか取っ付き難い本でもあって、無目的に讀み始めると、大抵は Chapter 1 の、それも最初の方で返り討ちにされたまま、ツンドクといったことになりかねません。しかし、逆に云ふと、 Chapter 1 それも、 1.3 Representing Class あたりまで讀み進めることができれば、後は、さう苦勞なく讀了まで持っていけるものです。 といふわけで、本稿では、以下、 The Art of MetaObject Protocol の第一章 1.3 迄を解説しながら讀んで行かうと思ひます。 Table of Contents 1. CLOSの實裝 1.1. 實裝しようとするサブセットの定義 1.2. 裏舞臺の基礎構造 1.3. クラスの構造を定義する 1.3.1. defclassマクロ定義 1.3.2. 親クラスの正規化 1.3.3. スロットの正規化 1.3.4. Class Options 1.3.5. ensure-class 1.3.6. Class Metaobjects の初期化 1.3.7. 繼承 1 CLOSの實裝 Metaobject ...
Read more

CLOS Grand Tour

Table of Contents 1. はじめに 2. クラス 2.1. クラスの定義 2.2. クラス定義の例 2.3. インスタンス生成 3. 繼承 3.1. クラス優先順位 3.2. スロットの繼承 4. 總稱函數とメソッド 4.1. 總稱函數とメソッドの定義 4.2. メソッド選擇 4.3. メソッド結合 4.4. 標準メソッド結合 4.5. 標準メソッド結合の例 4.6. 他のメソッド結合 5. オブジェクトの生成とその初期化 5.1. インスタンス生成 5.2. 初期化引數 5.3. オブジェクトの生成とその初期化をカスタマイズする 6. クラス再定義 7. 結論 1 はじめに Common Lisp Object System (CLOS) は、當初 Common Lisp の擴張仕樣 として提案され、其の後 ANSI Standard に組み入れられました。 CLOSは他のオブジェクト指向言語と同じやうに、クラス、總稱函數、メソッド、多重繼承の概念に基いたものですが、CLOSを他と際立たせてゐるものは、これら、クラス、メソッド、總稱函數、メソッド結合など全てが、そのインスタンスと同樣に、 first-class object として、programmer が參照操作できる點にあります。 しかし、ではこのことが日日の我が身にとってどんな御利益があるのか、については、あまり明確なイメージを持てないでゐる人も少なくないのではないでせうか。 Linda G.DeMichiel による An Introduction to CLOS では、上を簡潔に、且要點を外すことなく解説くれてゐるのですが、生憎この論文が掲載されてゐる本 Object Oriented Programming the CLOS Perspective は今ではなかなか入手が難しいやうです。 ここでは、 An Introduction to CLOS に沿って、CLOSを概觀しつつ、より具體的なイメージが持てるやうCLOSの舞臺裏をも覗いてみようと思ひます。舞臺裏を覗く道具としては主に Meta Object Protocol (MOP)...
Read more