Quick2PDFサービスの裏話(1) - 開発のきっかけ
弊社でQuick2PDFをリリースしました。
機能の紹介は、サービスサイト側を見てもらうとして、ここでは、これをなんで作ったの？や、どこが苦労した・・・とかの裏話をしたいと思います。
ただ、この話が何をいっているのかわかないと困るので、簡単にいえば、HTMLからPDFの変換コンバート機能です。
これだけ聞けば、「そんなの簡単そう！」って思う人もいると思いますが・・・・実際は、そうでもありません。
しかし、自分達としては、何か世界共通となりえる「技術」を売りにしたいと思っていました。
そう思いながら、何も思い浮かばず数年たってしまいました。
そんな、おり、あるお客さんとこんな会話がありました。
- お客「これをPDFにして出力してほしいんだけど」
- 開発者「HTMLでページを作って、それを自分達で印刷してもらえれば同じ物ができますよ。すごく簡単ですよ」
- お客「まあ、簡単なのは分かるし、それでなんとかやれないこともないけど、面倒なんだよね・・。」
- 開発者「なぜ、面倒なのですか？」
- お客「だって、レイアウトは思った通りとは微妙にずれるし、フッタにはURLが入るし、背景画像は消えてるし・・・・」
- 開発者「こうすれば、それらの問題は解決できますよ。」
- お客「へー、でもやっぱりそれを指定するのは面倒だよね。そもそも、こんなに簡単にできるなら、やっぱり直接PDFにしてほしいんだけど・・・」
この会話の流れを横で聞いていましたが、どちらの気持ちもよく分かるなーと思っていました。 お客の立場であれば、そんなに簡単なら簡単に作ってよ。と言いたいのでしょうし、開発者目線で言えば、作るのは難しいんですよ。でも、目的を達成するだけならこの作業ですよ・・・と。
そのとき、おもったのが「あれ、これできるんじゃね」と思ったのです。
まず、最初に思うのが、HTMLを画像化してそれをPDFにしてしまう。です。これならすごく簡単だし、ブラウザ画面を画像にするというソリューションはよくあるので結構簡単にできます。
特に最近ではテストツールやスクレイピングツールなどをお手軽に作る為にブラウザをサーバで動かすソリューションがあります。それらを使って、ページを画像化してPDFを作成してみます。
しかし、このソリューションでは、どうしても文字が汚くなるし、さらにデータが大きくなる。
最初から、この方針はないと思っていましたが、とりあえず、画像化したり、HTMLしたりはそれほど難しくないことがわかりました。
そうして、本格的な開発がスタートです。
構造としては、サーバでヘッドレスで動いているchroniumとChrome DevTools Protocol
でつないで、リモートからブラウザを操作し、PDF印刷まで行うというところです。
DevToolsのプロトコルを完全に制御出来るようにWebSocketクライアントを作り、それで制御するようにしました。そのため、時間はかかりましたが、なんとかPDF印刷をリモートから出力することに成功しました。
これで「成功！」なんて全然行きませんでした。
まあ、これで実用性が十分ならばみんな困っていないはずです。
ここからが本当の地獄の始まりです。いやー、開発ってだいたいがそうで、機能開発の見えている部分なんて、10%程度くらいしか時間がかかっていなくて、残りの90%がやった人しかわからないような対策や対応に時間をかけているのが普通なんですけど。
という事で次回からは、はまった問題について紹介していきます。
例えば、こんな内容について記載していきたいと思います。
- このHTML(Webコンテンツ)って、いつ準備完了って見なせるの？
- 無駄に処理を遅くてしている通信が邪魔です・・・
- なんか、ブラウザがたまに固まるんですけど・・・
- LoadAverageが高すぎて、システムが固まりました・・・
- 2000ページ超のPDF(ファイルサイズ300M以上)を作りたいって、それ本気ですか？