ご無沙汰しております。ここ数週間は例のPDFリーダーの２号機を作成していました。普段遣いできるレベルにはなってきているので近いうちにソースを公開します(公開しました。https://github.com/polymonyrks/poppyS)
説明動画
次のような感じで動いています。
https://youtu.be/C_5-JIJCbFY
以下、解説です。
読書時に構文解析を同時実行
今までは読書前に予め構文解析したデータを用意しておいて、それから読書開始みたいにやっていたのですが、
やはりテンポが悪かったです。同時だと快適ですね。それに読書中に構文解析結果を微修正して再度構文解析、
みたいのもこれでやれるようになりました。
パレットの廃止
やはり、パレットをいちいち表示すると、本文から目線がそれるので読書に集中できなくなる感がありました。
なのでパレットを廃止しました。これが結果的には成功だったようです（後述）。当初想定していないアイデアがかなり湧いてきました。
操作系をキーボードとマウスに集約
パレットに負わせていた多機能性を維持するためには、キーボードが必須と考えました。
なので１号機はタッチパネルオンリーでしたが２号機はマウスとキーボード操作にしました。
自分で作るといろいろやれますね、spacemacs(vim)的なキーバインドでいろいろな機能を追加できました。
spacemacs(vim)のキーバインドの実装
そうなると、キーボードに手を置くことになるのでvimのキーバインドを使いたくなります。
ページ送りをjk, 着色全解除をdd, 一部解除をx, 保存を:wといった感じで、直感的に操作できるようにしました。
（ご参考ですが、firefoxとかchromeでもvimiumというプラグインを入れるとvimキーバインドでブラウザを操作できますね。あの発想です。）
着色のトグル化
キーボードが利用できるので、着色時は
- マウスクリック
- 赤ならR、青ならB、緑ならG
とかやろうと思いましたが煩雑なのでボツ、マウスクリックでトグルすればいいじゃんと気づきました。
これは一号機でも実装すべきだったかもしれません(タッチパネルだと狙って複数クリックできたかは微妙な感がありますが、、)トグル時の方向（左クリック、右クリック）
方向を持ったほうがいいので、マウスの右クリックと左クリックで対応。この辺りもタッチパネルだと難しいのでマウスのほうが良いですね。
トグルのデフォルト値（過去履歴がある場合）
これがかなり重要でした。前から欲しかった機能です。というのも、際限なく着色した場合はかえって読みにくくなるので、
定期的というか、頻繁に着色を全解除していました。その後で、また着色したくなるときが多々あるわけです。
パレットだと、直近の過去履歴を追認、みたいなのにしようと思ったのですが、もう一度パレットをクリックするという手間は変わらないので、
ボツにしていました。これがマウスのトグルだといちいち最初の色（例えば赤）から開始するのはだいぶだるいので、実装に至りました。単語削り機能の削除
前は、単語をクリックしたあとでユーザがその単語を削ってから色を指定、みたいなことをやっていました。ユーザが自分で接頭辞を作っていたわけです。
しかしパレットがない状況だとこれはやれません。実際の文章中の文字を黄色とかで光らせて実装するとかやっても良かったのですが、
テクニカルでしんどいのと、あとはこの削除行為も読書を中断させる原因になっていたと考えました。
なので、クリック時には自動で接頭辞というか語根(root)をとってくる、着色対象となる名詞句はそれを含むものとする、
という自由度の低い感じにしました。お手軽ポンにするには自由度は低くある必要があるのはなるほど確かです。
なので、語根（root)をとってくる関数を強化する必要があると感じています。今の状態だとちょっと精度が悪いです。今後の課題です。トグルのデフォルト値（過去履歴がある場合）(再)
上の単語削り機能を削除したので、デフォルト値が活きてきます。このあたり自由削除となると条件指定がブレるので、
デフォルト値を設定しても再度同じ条件が出てくる頻度が低くなります。例えばfunction, functorとした場合に、うまくやればfunctのみをとってこれればいいのですが、
読者自信が指定した場合にはfunctiとかfunctorとかやってしまう可能性が高いです。functionとかfunctorをクリックした際には、functという語根をとる、
みたいにしておけば、条件指定がかぶる可能性が大きくなります。トグルのデフォルト値（過去履歴がない場合）
過去履歴がない場合には、条件が類似しているものからとってくるとかやれそうです。未実装ですがこの辺りは文法利用でもいいですし（アルファベットのdiffをとって何割一致）、
いわゆる機械学習技術を使ってもいいはずです。
前者は、Haskellのコンパイラもエラーでしてくれたりしますね、ああいう感じです（perhaps … というやつ）。
後者は、たとえばfunction, functorは類似ですが、map, morphismも概念的には類似しているので、そこを機械学習で補填すれば面白いことになると思います。2ページ表示
電子書籍の弱点は以下の２つ（あと後述で１つ）だと見ています。
- ランダムアクセスできない点
- 見開きできない点
タブレット縛りがなくなり、PCを使うことになったので２ページ表示を行う余地が出てきました。これもかなり重要だと思っています。
電子書籍が紙の本に劣る最大の点は見開きできない、ランダムアクセスできないの二点が致命的だと感じています。
これらは電子書籍の「窮屈さ」に関わってきます。PCで見開き表示は絶対に欲しい機能でした。
残りの弱点としては、 - ページ要素の表示時の位置が不定
何を言っているかというと、紙の本を読んだ際には、あの図がこの位置にあったとか、あの文章がこの位置にあったとか、
そういう情報も結構大事にしています。あとで思い出せたりしまう。これが電子書籍だとだめです。
上下にスクロールする系だとやはり位置が不定ですし、kindleとかもフォントが違ったりデバイスが違ったりするとレイアウトが変わったりします。
(この辺りのフォントサイズ変更ができるのは電子のメリットでもあるのですが、、)ページ自動クリップ、リサイズ
ただし見開きにする分、文字サイズが小さくなるので対策が必要です。
余白を自動で切り取る機能をつけました。
https://www.gigafree.net/tool/pdf/BRISS.htmlというソフトがあり、PDFの製本を頼む際に前処理で使ったりしているのですが、
そちらのアイデアを拝借しました。ただ、見開き２ページがサイズ、クリップ位置ともに違和感ない形にチューニングするのは結構大変でした。
この辺、いい機能をつけられたと自画自賛しています。Annual Reportとか余白が小さくてきつい文書もあるので、まだまだ対策要ですが、、