もちろん、https://github.com/politza/pdf-toolsについてはすでに知っています。
Emacs 24.5.1を使用しています。
doc-viewがPDFファイルにmudraw / mupdfを使用しているとは思いません。
(require 'doc-view)
(print doc-view-pdfdraw-program)
出力
"mudraw"
"mudraw"
ただし、次のスクリーンショットはそうではありません:
Emacsは左側にdoc-view、右側にmupdfバックエンドを持つzathuraを使用しています。ほぼ同じレベルに手動でズームされた同じPDFファイル。PDFはこちらです。
ご覧のとおり、たとえば、「たとえば」で始まる文では、上付き文字pと下付き文字nがzathuraではるかに明確になっています。doc-viewでは、特にこのレベルのズームであっても、nはほとんど読めません。
私は明らかに何かが欠けていますが、何がわかりません。
(setq doc-view-pdf->png-converter-invocation
'doc-view-pdf->png-converter-invocation-mupdf)
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13164からは動作しないようです。
公式ドキュメントはあまり言いません。回答を検索すると、mupdfが存在する場合は自動的に使用する必要があるということになります。私はarchlinuxを使用していて、公式パッケージghostscript
とmupdf
パッケージをインストールしています。奇妙なことは、公式パッケージをアンインストールした後(およびemacsを再起動した後)(print doc-view-pdfdraw-program)
でも出力"mudraw"
されmupdf
ますが、これはおそらく無関係です。
読者がdoc-viewでmudraw / mupdfを正常に使用している場合は、おそらくそのpdfをダウンロードして(そしてzathuraを一時的にインストールして)、各プログラムで表示される品質をテストすることができます。私のスクリーンショットと同じまたは類似したものが表示される場合は、おそらくここに問題はありません。
おそらく、zathuraが使用しているmupdf は、元のmupdf / doc-view が使用しているものと実際には異なります。私が正しく思い出すと、zathuraは独自のわずかにパッチを当てたバージョンのmupdfを使用します。ただし、私の理解では、zathuraがわずかにパッチを適用するため、レンダリングパーツ自体にパッチを適用する必要はなく、zathura自体とより適切に機能します。このコメントは、mudraw / mupdfを使用するdoc-viewとmupdfバックエンドを使用するzathuraの間のレンダリング品質(および速度)の違いがあったとしてもごくわずかであることを示唆しているようです。
mudraw
?たとえば、私は使用しましたmudraw -o euclid.png euclid.pjm.1102986512.pdf
が、euclid.png
ファイルは空白(白い)ページです。
300
は-r
オプションを使用するために、より良い解像度を設定しました。i.imgur.com/P9kK9Sj.png。(setq doc-view-resolution 300)
ソリューションもそうです。(以降(doc-view-clear-cache)
)
144
ために、それは速度と品質の間のトレードオフであると思われるので、私はdpiに落ち着きました。
mudraw
docviewと同じ引数で実行して、結果のイメージの品質を比較してください。