PDF2Cosense
保留しているところ
dos対策
これやる必要あるんだろうか
gyazoってAPIで提供されているし、普通にリクエストも多そうだし割と何もしないでも大丈夫なんじゃないかという気もする
pdf→画像に変換するところを、mupdfをそのまま実行している rustのlibraryとかではなく、シェルのmupdfをそのまま使ってる
todos
ocrエラーのログをもうちょい整理したい
devbox shellしてない時に、なんかわかりやすいエラーを出してほしい
今は正常に進んだような挙動になっている
pdf→image時のログがおかしい: 1冊しかないときは、最初からログが埋まっている状態になっている
複数dirでimage→cosenseする際のログがおかしい: MultiProgressの導入
ページ注入するやつを複数注入できるようにしたい
プロフィールページと、gpt-4のページを同時に注入したい
真っ白な画像があった時に、ocrがErrorになる
ocrしても入るテキストがない
しかし、5階ぐらいリトライしてocrが空だったらerrrorを返すような実装になってるから
せめて空でもいいのでページは作りたい
configはoptionとして指定できるようにする
binにしたときって、devbox内包できないんじゃない？
mutexがないと起こられることになる
test?
command駆動にしてみるか？
行っている各操作を非同期に実行できるコマンドとして整える
各自の結果はどこかのキューに入れていく感じ
a | b | cのようにコマンドを実行する
zxかbun shellで実装すればいい
以前に、全部やって回すか、1個ずつ回すかみたいなのを悩んでいたが、今思えばどっちも不適だった
JSで実装しているということも隠す
e2eテスト
- sample pdfをocrと通信して、文字の内容を比較する
bufferがdeprecatedというwarningがCLI上に出てる
わかる
スクボ読書済みのpdfをs3に投げる
1章が1ページのほうが良さそう
物理的な本の制約を食らってるだけな気がしてきた
改行しながら読む
視覚的に構造化する
Scrapbox読書のスクリプトにそういうのを入れる？
章の始まりのページをリストとして与えるとか、
それこそAIに解釈させるとか
OCRのテキストを信用できるかが味噌になってくるのか
そういう意味ではepubの方が良い
確かに、ocrしてる意味がそもそも薄いよな
最初からテキストで取れればいい
テストコード
Gyazo OCRが変な箇所で改行されているので、joinしてからjsonに変換しておきたい
単語中で開業されるとリンクにできないので困る
検索にも引っかかりづらくなる
ただし、これは数学書など記号や図が多いとぐちゃぐちゃになってしまうかもしれない(?)
types/の中が適当すぎる
翻訳できないかな
deepl使うよりgpt-3.5使うほうがいいらしい
目次の扱い
スクボで良い感じに目次を生成してリンクにできないか
英語の論文とか、1ページの中で2blockにわかれてるやつも多くあるが、あれもうまくOCRできるのか？
↓こういう形式のやつ
https://gyazo.com/0c1cc73324228236edcb92f576ab00aa
kindle
kobo
英文の自動翻訳も載せる、とかするのも便利そう
PDF画像、OCR、翻訳