WindowsにてGhostscriptを使ってPDFのサイズを縮小する

Windows

ScanSnapにてA4サイズ32ページのカラー書類を600dpi設定で読み込むと、138MB程度のPDF (src.pdfとします) が生成されました。このままだと大きすぎて取り回しが悪いので、Windowsでサイズの縮小を試みました。用いたソフトはGhostscriptです。

GhostscriptはGhostscript: Ghostscript Downloads からインストールしました。バージョンは Ghostscript 9.23 for Windows (64 bit) です。

compression - How can I reduce the file size of a scanned PDF file? - Ask Ubuntu に5段階の縮小方法が記述されていたので、これを以下のバッチファイルで試します。

@echo off

set PATH=%PATH%;"C:\Program Files\gs\gs9.23\bin"

gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen   -dNOPAUSE -dQUIET -dBATCH -sOutputFile=01_screen.pdf   src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook    -dNOPAUSE -dQUIET -dBATCH -sOutputFile=02_ebook.pdf    src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/printer  -dNOPAUSE -dQUIET -dBATCH -sOutputFile=03_printer.pdf  src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/prepress -dNOPAUSE -dQUIET -dBATCH -sOutputFile=04_prepress.pdf src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/default  -dNOPAUSE -dQUIET -dBATCH -sOutputFile=99_default.pdf  src.pdf

Ghostcript PDF Reference & Tips — Milan Kupcevic によると、-dPDFSETTINGSの各設定の意味は以下のとおりです。

-dPDFSETTINGS=/screen   (screen-view-only quality, 72 dpi images)
-dPDFSETTINGS=/ebook    (low quality, 150 dpi images)
-dPDFSETTINGS=/printer  (high quality, 300 dpi images)
-dPDFSETTINGS=/prepress (high quality, color preserving, 300 dpi imgs)
-dPDFSETTINGS=/default  (almost identical to /screen)

バッチファイルを実行した結果得られたPDFのサイズは以下のようになりました。

設定 サイズ
元PDF (src.pdf) 138MB
/screen 3.1MB
/ebook 7.2MB
/printer 52MB
/prepress 74MB
/default 138KB

/screen, /ebookを使った場合は画質があまりに荒く、とても見れたものではありませんでした。/printer, /prepressなら許容範囲だと感じました。

次に、より柔軟に圧縮率を指定したいと思い、compression - How to reduce the size of a pdf file? - Ask Ubuntu の回答を参考に、DPIを数値で指定しようとしたのですが、なぜか縮小されませんでした。一応以下にスクリプトを載せます。

@echo off

set PATH=%PATH%;"C:\Program Files\gs\gs9.23\bin"

gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/default -dNOPAUSE -dQUIET -dBATCH -dDetectDuplicateImages  -dCompressFonts=true -r150 -sOutputFile=150.pdf src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/default -dNOPAUSE -dQUIET -dBATCH -dDetectDuplicateImages  -dCompressFonts=true -r300 -sOutputFile=300.pdf src.pdf
gswin64.exe -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/default -dNOPAUSE -dQUIET -dBATCH -dDetectDuplicateImages  -dCompressFonts=true -r600 -sOutputFile=600.pdf src.pdf

Pipenvを使ってみる

Pythonが公式に推薦しているという、PythonのパッケージングソフトであるPipenvを試してみました。Pipenvは、Requestsの開発者としても有名なKenneth Reitz氏が中心となり開発されています。

例えばPythonでアプリケーションを開発するとき、複数の開発者がそれぞれ自分の手元で独立にpipでパッケージをインストールすると、そのタイミングによって異なるバージョンのパッケージが得られてしまう恐れがあります。このPipenvはその問題を解決し、開発者間で必ず同じバージョンのパッケージが使われるようにするためのツールだと自分は理解しています。

このPipenvは、pipとvirtualenvのラッパーとして働くので、pipとvirtualenvを直接さわることはなくなります。

Pipenvのインストール

GitHub - pypa/pipenv: Python Development Workflow for Humans. を参照。

使い方

まず使ってみる

以下はUbuntu 16.04 LTS on Windowsで試しました。PythonにはAnaconda 3を使うよう設定しています。

まず作業用のディレクトリを作成します。

$ mkdir myproject
$ cd myproject

次に、このプロジェクトで使うパッケージをインストールします。ここではrequestsパッケージを入れてみます。

$ pipenv install requests
Creating a virtualenv for this project…
Using /home/minus9d/anaconda3/bin/python (3.6.3) to create virtualenv…
...(略)...
Installing collected packages: idna, chardet, certifi, urllib3, requests
Successfully installed certifi-2018.4.16 chardet-3.0.4 idna-2.6 requests-2.18.4 urllib3-1.22

Adding requests to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (b14837)!
Installing dependencies from Pipfile.lock (b14837)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 5/5 — 00:00:06
To activate this project's virtualenv, run the following:
 $ pipenv shell

このコマンドにより2つのことが行われました。

1つ目は、仮想環境の生成です。Pipenvが裏でvirtualenvを使って、このプロジェクトのための仮想環境が生成されました。

2つ目は、Pipfile, Pipfile.lockという2つのファイルの生成です。生成場所はmyprojectディレクトリの直下です。これらのファイルは、このプロジェクトが依存する他のパッケージの取得元やそのバージョンに関する情報を格納します。ファイルの内容に関する詳細は GitHub - pypa/pipfile にあります。

従来、プロジェクトが依存するパッケージの管理には、requirements.txtというのが使われていました。例えばpip install -r requirements.txtなどとすると、requirements.txtに記述された依存パッケージをインストールできました。今回生成されたPipfile, Pipfile.lockは、従来のrequirements.txtにとってかわるものになるようです。これら2ファイルはいずれも構成管理ツールの対象になります（参考）。

Pipfileは以下のようになります。requestsのバージョン指定をしなかったので"*"になっています。

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
requests = "*"

[dev-packages]

[requires]
python_version = "3.6"

Pipfile.lockは以下のようになります。こちらには実際にインストールされたバージョンが記述されています。

$ cat Pipfile.lock
{
    "_meta": {
        "hash": {
            "sha256": "8739d581819011fea34feca8cc077062d6bdfee39c7b37a8ed48c5e0a8b14837"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "certifi": {
            "hashes": [
                "sha256:13e698f54293db9f89122b0581843a782ad0934a4fe0172d2a980ba77fc61bb7",
                "sha256:9fa520c1bacfb634fa7af20a76bcbd3d5fb390481724c597da32c719a7dca4b0"
            ],
            "version": "==2018.4.16"
        },
        "chardet": {
            "hashes": [
                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
            ],
            "version": "==3.0.4"
        },
  ...(略)...
        "requests": {
            "hashes": [
                "sha256:6a1b267aa90cac58ac3a765d067950e7dbbf75b1da07e895d1f594193a40a38b",
                "sha256:9c443e7324ba5b85070c4a818ade28bfabedf16ea10206da1132edaa6dda237e"
            ],
            "index": "pypi",
            "version": "==2.18.4"
        },
        "urllib3": {
            "hashes": [
                "sha256:06330f386d6e4b195fbfc736b297f58c5a892e4440e54d294d7004e3a9bbea1b",
                "sha256:cc44da8e1145637334317feebd728bd869a35285b93cbb4cca2577da7e62db4f"
            ],
            "version": "==1.22"
        }
    },
    "develop": {}
}

依存関係の可視化

pipenv graphとすると、これまでに入れたパッケージの依存関係が可視化されて表示されます。具体的には、requestsが要求するパッケージ、そのパッケージのインストール条件、実際にインストールされたパッケージのバージョンが表示されます。

$ pipenv graph
requests==2.18.4
  - certifi [required: >=2017.4.17, installed: 2018.4.16]
  - chardet [required: <3.1.0,>=3.0.2, installed: 3.0.4]
  - idna [required: <2.7,>=2.5, installed: 2.6]
  - urllib3 [required: >=1.21.1,<1.23, installed: 1.22]

仮想環境に入る

pipenv shellとすると、自分で入れたパッケージだけが使える仮想環境に入れます。出るときはexitです。

$ pipenv shell
Spawning environment shell (/bin/zsh). Use 'exit' to leave.
. /home/minus9d/.local/share/virtualenvs/myproject-yAY6_O7R/bin/activate
...(略)...
$ pip list
Package    Version
---------- ---------
certifi    2018.4.16
chardet    3.0.4
idna       2.6
pip        10.0.1
requests   2.18.4
setuptools 39.1.0
urllib3    1.22
wheel      0.31.0

上でもちょっと出てますが、インストールされたパッケージの場所はpipenv --venvによりわかります。

$ pipenv --venv
/home/minus9d/.local/share/virtualenvs/myproject-yAY6_O7R

デフォルトで ~/.local/share/virtualenvsの下に格納されるようです。知らない間に肥大化させないよう注意したいです。

他人が作ったPipfile, PipFile.lockに従いパッケージをインストール

Githubなどからレポジトリをcloneしてきて、そのレポジトリにPipfile, Pipfile.lockがあるような場合を考えます。この場合、pipenv install とすることで、レポジトリ製作者が使っているのと同じバージョンの依存パッケージをインストールできます。

$ git clone https://(somewhere)/myproject.git
$ cd myproject
$ pipenv install

仮想環境の削除

仮想環境を削除するときは、対象のディレクトリ（ここではmyproject）内で pipenv --rmとします（参考）。

$ pipenv --rm

これにより~/.local/shareに保存されていたパッケージファイルが削除されます。

requirements.txt の出力

pipenv lock -rとすると、requirements.txtと同形式の出力を得られます。

$ pipenv lock -r
-i https://pypi.org/simple
certifi==2018.4.16
chardet==3.0.4
idna==2.6
requests==2.18.4
urllib3==1.22

Anaconda Pythonのcondaとの接続

私は普段Pythonの環境構築にはAnaconda Pythonを使っています。その大きな理由の一つが、NumPyなどとくにWindowsでビルドするのが大変なパッケージについて、conda install numpyなどとconda installコマンドを使うことでビルド済バイナリを取得できることです。

今回紹介したPipenvでinstallコマンドを使うと、デフォルトではPyPIからパッケージが入手されるため、手元でパッケージのビルドが走ってしまうはずです。Pipenvの進んだ使い方 — pipenv 11.10.1 ドキュメント によると--site-packagesフラグを使えばcondaで入手したパッケージを再利用できるそうなのですが、私の手元ではうまくいきませんでした。

個人的には、ここが解決できない限り、Pipenvには移行できなさそうです。

[2018/05/24追記] 実は最近のNumPyなど多くのパッケージはwheel形式で配布されているためビルドなしでインストールできることが多いようです。なので実はPipenvを使う障壁は少ないのかもしれません。

参考URL

Jupyter Notebookの公開方法

python

Jupyter Notebookをどのように公開すると管理が楽かを考え中です。調査結果を以下に示します。

Github

Githubのレポジトリに登録された.ipynbファイルは自動的に整形されて閲覧できます。（例：python_exercise/matplotlib_exercise.ipynb at master · minus9d/python_exercise)

今ではあまり意味がありませんが、nbviewerを通してもよいです。（例：Jupyter Notebook Viewer)

Gist

.ipynbファイルのテキストを全文コピーしてGistに貼り付けても、Githubと同じように閲覧できます。（例：jupyter_notebook_test.ipynb ）

以下のようにはてなブログのGist貼り付け機能を使うこともできます。

ただ、頻繁にページを更新するとなると手続きが面倒です。

binder

Binder (beta) は、トップページのフォームにGithubのレポジトリを入力すると、そのレポジトリにある.ipynbファイルを、ユーザが実行可能な形で提供するサイトを生成してくれるサービスです。現時点でベータ版です。

このサービスは JupyterHub — JupyterHub 0.9.0.dev documentation を利用しているそう。

Herokuの無料枠を使う

Herokuの無料枠を使ってJupyterサーバを立てる方法 - MyEnigma を参照。試していません。

HTMLやMarkdownへの変換

nbconvertコマンドを使ってHTMLやMarkdownに変換し、加工する方法もあります。以下はその例です。

HACK TO THE FUTURE 2018予選 参加記

programming contest

先週の大会に引き続きHACK TO THE FUTURE 2018予選 - HACK TO THE FUTURE 2018予選 | AtCoderにも参加しました。8時間フルで参加して23位でした。

思考ログ

まずは以下のようなgreedyに山を作る方法を試しました。

  1. 盤面Aと盤面Bとでもっとも差分が大きいマスを探す
  2. そのマスを中心とした山を取る。この時の山の高さは、盤面Bのいずれのマス目も盤面Aを超えない範囲で最大値を取る
  3. 1.に戻る

これで9.8953e9点。実装にハマってしまったお陰で、ここまでで約3時間浪費してしまいます。

次に、上記2で、800個目以降に山を作る場合は、盤面Bのマス目が盤面Aのマス目を上回ることを許すルールを追加しました。 これで9.9631e9点。

ここでビジュアライザを使うと、盤面Aの外縁部の値を、盤面Bでは多く取りこぼしていることに気付きました。そこで、まず最初に盤面Bの全体にまんべんなく山を設置することで、盤面Bの外縁部の値が小さくなることを防げるのではないかと考えました。具体的には、盤面Bを5x5の小エリア400個に分割し、それぞれの真ん中に高さ75の山を並べました。このパラメータが結構シビアで、結果に意外と影響しました。これで9.9823e9点。ここまでで大体5時間経過です。

次に、終盤で盤面Bのマス目が盤面Aのマス目を許すときに、スコアが最良となる山の高さhを1から100まで全探索して決定するロジックなどを入れました。手調整が必要なパラメータがいくつか増えてます。これも効いて、9.9901e9点まで来ました。

次に、これまで作成した各山の高さを±5の範囲で全探索して、もっともスコアが上がるhに修正する、山登りによる最適化処理を処理時間いっぱいまで行うようにしました。これも効いて、9.9946e9点。6時間半経ってようやくこの問題で何をすればよいか分かってきました。

さらに山のx位置, y位置をそれぞれ±2、つまり今の山の位置を中心とした5x5のエリア内でスコアがもっとも上がる山の位置を全探索するコードを追加しようとしたんですが、WA連発で時間を浪費したのが非常に痛かったです。バグの原因はhの有効範囲[1, 100]とx, yの有効範囲[0, 99]を誤って混同していたしょうもないミスでした。終了15分前くらいになんとかバグがとれて、9.9971e9点。

最後に、山の高さの探索範囲を±2に狭める調整をして時間に追われるように提出して、9.9972e点。これが最終スコアでした。

感想と反省

終了後の動画解説を見たところ、方針をそれほど大きく外してはなかったのが良かったです。しかしいかんせん最適化処理の必要性に気づくのに6時間半かかったのはちょっと遅すぎでした。もう少し早くこの段階にたどり着けていたとしたら、山の位置・高さを変えたときのスコア計算の高速化（現状はすべて愚直にO(N2)の計算）、パラメータ調整、焼きなましの導入など打つ手は合ったかなと思います。

第2回 RCO日本橋ハーフマラソン 予選 参加記

programming contest

第2回 RCO日本橋ハーフマラソン 予選 - 第2回 RCO日本橋ハーフマラソン 予選 | AtCoder に参加しました。結果は16位で、青コーダーの自分にしては健闘。去年の本戦のパラレル | AtCoderでも2位という今後二度と取れそうもない順位が取れてしまっていたので、適当な解法をいかに早く投げるかが重要なこの形式は自分に合っているのかもしれません。

以下、問題Aと問題Bの思考ログです。実際はAとBを行ったり来たりしていました。

問題A - ゲーム実況者Xの挑戦

とりあえず完全ランダムに移動する解を投げて、6499点。

次に試したのは、制限時間いっぱいまで「ランダムな盤面選択＋ランダムに移動」を試して、点数がベストなものを選ぶ解法です。これで19677点。しばらくの間、なぜかマップの番号が1始まりであると勘違いしていたことが原因で点数の計算が合わず苦戦。実装完了まで1時間くらい無駄にしてしまいました。

次に、制限時間いっぱいまで「ランダムな盤面選択＋greedyに移動」を何度も試して、点数がベストなものを選ぶ解法を実装しました。ここで「greedyな移動」とは、上・下・右・左のうち、罠にかからない方向であり、かつ、コインがもっとも多くとれる方向を選ぶ移動法です。これで119800点。

終了間際に、「100個の盤面のうちよい盤面だけからランダム選択した方がスコアが上がるのではないか」と考えました。初期位置から取得可能なコインの数が多い盤面を良い盤面と定義し、100個の盤面から良いm個の盤面のみを使う方法を実装しました。しかし手元でmの値をあれこれ変えてもあまり効果は出ず、むしろスコアが下がることも。かろうじてスコアが上がった m = 95 を採用して、124540点。これが最終スコアで、52位でした。

心残り

本番中にvisualizerで挙動を確認すると、周囲にコインがなくなったときにプレイヤーの位置が振動してしまっていました。本番中に試しに2手読みを実装しましたが、かえってスコアが低下しました。バグがあったと思われます。

あと、たまにはランダムにプレイヤーを移動させることや、最終ターンが近づいたときに死人がでることを許容して移動させるようにすることも試そうと思っていましたが、記憶から落ちていたのと時間がなかったのとで実装できませんでした。

問題B - ゲーム実況者Xのデフラグ

最初は焼きなまし系の最適化問題かなと思いましたが、よく見ると、データの書かれているセクタ数16000に対してスワップ回数が4000回なので、半数以上のセクタは一度も移動されないということに気付きます。なので、以下の操作を4000回繰り返す解法に割と素直に行き着きました。

  • 全データセクタについて、フラグメントスコア（＝そのセクタの前のセクタとの距離と、そのセクタの後のセクタとの距離の和）を計算
  • フラグメントスコアが最大のデータセクタを選ぶ
  • 選んだデータセクタのswap先を全通り試し、もっとも全体のフラグメントスコアが改善するswap先を見つけ、そことswapする

最初はswap先を空セクタに限定することでプログラミングの難易度を下げ、225356点。次に、swap先をすべてのセクタから求め、380776点。これが最終スコアで、7位となりました。最終解の提出直後は一瞬総合5位くらいになれたので、このときがいちばん興奮しました。

心残り

何らかのランダム性を追加してスコアが上がらないかとも一瞬考えましたが、Aの検討を優先しました。

次回に向けたメモ

  • 「コードに加えた変更」と「手元のサンプルでのスコア」と「サーバのスコア」とをメモっておく。すると、手元のサンプルでのスコアをもとにサーバのスコアが予想できるようになる。各提出タイミングでのコードもコピーしてとっておくとよい。
  • 上の状態を作るために、できるだけ早めに解答を作ってサーバに投げたい。とはいえ、あまりに簡単な解だと時間のムダかもしれず匙加減が難しい
  • 手元のサンプルは基本的に最初からジェネレータに封入されている1個で十分
  • Emacsはやめて最初からVisual Studioを使おう

参考URLs

  • RCOスタッフによる模範回答

このブログのユーザー属性

hatena 雑文

このブログも早いもので開設から8年ほど経っていて恐ろしいことです。たまには定点観測のためにGoogle Analyticsで取得したユーザーに関する情報を記録しておきたいと思います。以下のデータはすべて2017年全体を対象に取得しました。

年齢と性別

f:id:minus9d:20180103210715p:plain

34歳以下の利用が多く、合計で72.35%です。45歳以上は8.18%しかいません。このブログはほとんどプログラミングの実際的な記事しかないことから考えるに、やはり45歳以上で現役でプログラミングを続けることは難しいのでしょうか。

性別は実に92.4%が男性で、女性は7.6％のみです。理系女子の就職事情と理系に人気の職業・業界はどこ？ - 工学スタイル によると機械・電気・情報系の学科の女性比率は5％～8％程度であり、この比率と同等です。今後女性率が増えてくれることを望みます。

言語

このブログには日本語記事しかないため、当然ながらjaとja-jpのみで96.13%を占めます。en-usが3.52%で続きます。

地域

やはり当然ながら日本が最多で98.10%。次がUnited Statesで0.59%です。

98.10%を都道府県別に細分化したときのTop 10は以下の通りです。Top 10のみで98.10%のうちの81.07%を占めている計算であり、人口比を考慮しても偏りが激しいです。IT企業や大学の所在地の偏在を反映しているのだと推測します。

都道府県 比率
東京都 38.34%
神奈川県 13.48%
大阪府 8.45%
愛知県 5.50%
京都府 2.88%
福岡県 2.72%
千葉県 2.66%
兵庫県 2.56%
埼玉県 2.44%
北海道 2.04%

デバイス

以下のように圧倒的にPCからのアクセス比率が高いです。世間と比べると異常です（参考：サイトのデバイス割合は業種によってどのくらい違うのかを調べてみた《Google Analytics》｜リスティング広告の運用代行ならカルテットコミュニケーションズ）

デバイス カテゴリ 比率
デスクトップ 97.86%
タブレット 1.69%
モバイル 0.44%

ブラウザ

Chromeが強いです。

ブラウザ 比率
Chrome 52.66%
IE 21.68%
Firefox 15.15%
Safari 5.80%
Edge 4.07%
Opera 0.35%

OS

世間に比べるとWindowsのシェアが若干低いです。（参考：Linux、Windows 10が増加 - 8月OSシェア | マイナビニュース）

OS 比率
Windows 76.61%
Macintosh 14.97%
Linux 6.76%
iOS 0.85%
Android 0.67%
SunOS 0.07%

Windowsに限定すると以下の比率です。

OS 比率
7 53.51%
10 38.15%
8.1 7.46%
Vista 0.42%
XP 0.25%