PDF01

PDFソフトといえばAbobeです。だって、Adobeが開発したのですから。ふりかえると現在のDCの前に6.7.8.9の各バージョンを購入していました。これだけで私の開業年がわかります。

9より前のCDを探したが見つかりませんでした。9を大量購入したので無用と判断し廃棄したのだろう。9より後のパッケージを購入していない理由は9がいまだに現役だからです。

現在のDCはパッケージで売ってくれません。買い切りでない。DCは月々かなりの費用がかかる。これはAdobeの儲けの態度ではないだろう。DCは常に進化が必要で常時アップグレードが求められる製品です。 DC以外に買い切りをも廃止したのは、Adobeの儲けの態度というより保守コストだろう。

いっぽう買い切りを求める人は、ランニングコストだけを問題にしているのではないと思う。アップグレードを積極的に拒んでいるのだ。

DCの機能はすごい。DCは単に閲覧したり署名するだけに使用するにはもったいない。 この正月、我が事務所のDCくんは、千冊ほどの解本を、アクションウイザ―ドによる自動化で3日ほどかけてOCR化してくれた。 こんな芸当はJust-Pdfなどの他のソフトではできそうにない。 休むことなく電気代程度で働いてくれるDCくんと32MBくんのようなスタッフばかりだといいのだがと思う。

なお、この作業は簡単ではなかった。アクションウイザ一ドを組むのにかなり苦労した。最初は6時間も作業したところでフリーズしてしまう。マシンが弱いのだろう。CPUはそれほど関係なくメモリだと思う。32MBあるPCに選手交代して成功した(大須商店街で買ってきた。35万円もした)。ああ、いつも目の前のPCが強力であればいいのに…

ところで、DCが高価だから全PCにインストールしないわけではない。 使い勝手が悪いからだ。機能が多すぎる。機能の多さが重くしている。重さは、処理速度もあるが複雑さが問題だ。あっても困るものではない、使わない機能なら使わなければいいだろうというのは理屈だ。しかし、ほとんど使わないのならいっそのことないほうがいいというか、それは贅肉のようなものというか、こういう比喩をどう表現したらいいのだろう… 回転木馬のデットヒート acrobat9がちょうどいい。スタッフが15人いる時代だから15のPCまで使えるIDのはずだ。 あと、DCと9は同居できない。月に1回程度突発的にやってくる電子署名に対応するため他のソフトが必要になる。お金がかかる。 DCは重いので、使用する作業内容によっては前述のとおりフリーズしてしまう。というかパソコンが古い。正月そうそう嫌気さしてパソコンを買いに出かけたが、他のPCも全部新しいのにして、こういったストレスをなくしたい。必要なスペックは30万円ぐらいのもの。ノートは駄目だな。熱の問題と思う。お金はないが、AIや検索システムの導入に伴って助成金で可能らしい。でも、かっこ悪くてしたくないし、もとよりそんな助成金申請作業をするより、目の前の溜まった仕事をこなさなければ。

Inazuma Search(クロール時間)

nazuma SearchのSvrのクロールに36時間かかった。ハチPCだと倍の3日かかるだろう。

データを計らなければならない。

Cltだと24時間だと思う。Cltは外付HDDにしている。クロールデータ量をはからなけばならい。

Clt×1.5=Svr  内部ネットワークの障害はたいしたことはない。

クロール中はいずれもかなりのパフォーマンスを要求された。クロール後の検索速度等は申し分ない。サーバーデータが大きすぎてソフトの許容量を超えるのでないかという懸念があったが、無用だった。探三郎は許容を超えた。

ということは、おそらくFessも大丈夫だろう。素材の最適化以外のメンテナンスやチェーンナップは不要だと思う。

いずれも常駐クロールははずしておいてよいことになる(最新を求めるものではない)。

いずれにしても、更新クロールは連休しかやれない。

素材が安定したらSvrのみになるだろう。否、Cltはいらないだろう。

EverNote

¥1,550/月で3個使っている。

データパイプライン近接検索を夢見ている。が半分諦めている。しかし、完全とはいわないまでもある程度は勝手になるとは思っている。執着しないことにして別の道を模索してるということ。その別の道とは、地道なというより地味な「ただの検索」である。

「ただの検索」

ファイル名を最適にすることは大変なので、入れ物(乗り物)をEverNoteにすればよいと思った。ノートブックとタグの2軸がよさそう。タグがなんとかしてくれると思った。タグだけでの検索、というか絞り込み。タグは階層的となり世の中のモノコトに応じてどんどん増える。100はある。

EverNote はタグ検索に向いていないのではないのか。というよりタグで整理するのはそもそも無理ではないのか。またevernote は入れ物として適当ではないのではないか。という気がしてきた。このうちどれかが該当すればそのようになる。だから、いったんこの道は保留にする。

sharepoint【1】

prologue:表と裏/前者と後者/A・B・串刺し/0・1・2/3階層が認知の限界/ 内部秘密たるminos/外部公開たるmskura

前者は、つねに堅固にしておく必要があるからつねにシンプルにしておく。
外部公開という(湧いた)需要は複雑さの種になるから、この段階で切り離したほうがいい。
mskuraの出現によって、フル権限の私がクライアント側にになるという新たな視点が生まれた。
まずこのことを歓迎して、この新世界の足場を固めることからはじめよう。
minosの根のセキュリティ設定がフルになったことによりシンプルになって嬉しい。
ナンバー記事と曼荼羅(マトリックス)からだな。

Sharepoint【2】

#0:minosメールは外部ユ―ザ一の一人。
yama#もしかり。
そうしてtokudメールなどの元々外部ユーザーと同一部類となる。
#1:フル権限たるminosなどの少数限定。
#2:閲覧のみたるteraoなどの不特定多数。
#3:guestまたはvisit。これがこの視点なのだがシンプルというか単純化してmskura@msoffice.biz gestもといmskuraの乱数表。
mikeメール・hatiメールがgest/縦軸は、kuro・hati・mukeの三つ。
実際はgest-kuro@msoffice.bizの一点物

Sharepoint【3】

visitたるmskura@msoffice.bizの乱数表
足し算ができる程度で予測可能なシステムにしておく。
非公開・機密秘密ではなく拡散や乱用を防止する措置。
1234 2345 3456 4567 5678 6789
機密情報ではないがゲー卜を設けています。入室にID・Passが必要です。 電話・メール・主要文書の補足情報であるので、利用者にフィルターをかけています。
Passwordは乱数表Aのとおりです。 1234 3456 5678 ====— 1234 3456 6789:これだな

アウトライナ―【10】

自炊書籍を分離したい。

わかりやすい本として「Q&A300問」という本がある。約700頁ある。自炊目次は、章立てとなって2階層となっている。

 第1章  総則
  1問 ***  …〇〇頁
  2問 ***  …〇〇頁

 第2章  各論1
  3問 ***  …〇〇頁
  4問 ***  …〇〇頁
 300問 ***  …〇〇頁

この***タイトル毎に分割し、且つこのタイトルをファイル名にしたい。

(分割後のファイル名を「しおり」にする方法がわからない)


私が推測するには、1「既存の目次からしおりを生成する」が頼りになる。2だから、この既存の目次が正確でなければならない。そこで、既存の目次をOCRしたものをワードに落として丁寧にチェックして差し替えるほうがいい。3その際頁番号は無関係。

うまくいかない。

★その他
スキャンしてOCR化しているので、テキスト化は完全ではない。

バラバラにして検索が目的であるから、はしがき・索引・あとがきは削除している。
また、N章の末紙の白紙には頁数が書かれているが邪魔だから削除している。

頁番号は、ほとんど100%フッター中央にある。

目次に頁番号が振られ、本文にもその連続した頁番号が振られている書籍がある。
 例 目次1・2・2、本文4・5・5…
いっぽう、本文に独立した頁番号振られることもあり、これが多い。

自炊目次を置き換え・はしがき等を削除すると、1ワード目次と、2自炊本文の2つになる。
1ワード目次には頁番号を無視しているし、自炊本文は連続していない場合がある。

アウトライナ【11】

ON しおりを自動生成する
ON 既存の目次からしおりを生成する
OFF 目次のページ番号でリンクを設定する とした場合の対応方法になります
対処方法ですが、下準備2で次のようにしてから自動生成ウィザードを使用してみてください

1問 *** — 1 2問 *** — 1 3問 *** — 1 4問 *** — 1 300問 **** — 1 とするとよいとのこと。

アウトライナ―( Antenna House)

Antenna Houseのアウトライナー

千頁ある自炊書籍を分割したい。
高度なAIならそのようなことが自動化できるかもしれない。ABBYY FineReaderがそうかもしれない。しかし、いまのところは手作業でないとできないだろうと思われる。

AIではないが標記のソフトがある

OCR1

この正月の3日間で、千冊ほどあったデジタルデータをOCR処理をしました。
アクションウイザ一ドでしました。
リアル本ではなくデータとしての本は便利です。机から動かなくていい。あの本のあそこの記述を確認したい…という症状で作業が中断してしまっている状態であったのが、」ほとんどボタンを押せば画面に現れる。5年前は2階まで降りていってリアル本を手にしなければならなかった。その確認作業の時間が長いほど思考が固まらない。めんどうだまた今度にしようとしたあの気持ちの悪さが重なってきっとガンマなんとかの数値が異常値になったのだと思う。 データ本が読み取り可能になれば桁違いにスピードが速くなる。
 OCR処理は、解本(自炊)した本に対し、まず①ファイルを開きます。②次にOCR化します。そして③保存してファイルを閉じます。 ②のOCR作業には10分程(待ち時間)かかります。そこで、別のパソコンで別の本の作業をします。これを待ち時間なく操作し続けるにはパソコン5台が必要になります。そして、かかる①②③の操作には待ち時間を除き2分程かかります。
 アクションウイザ一ドは、この①②③の作業を自動でしてくれます。
 パソコン万歳! 2分✕千冊という時間が削減された。33時間。 2×1,000 =2,000 2,000÷60 =33.333333333333 3日間、72時間。 3×24 =72 72×60 =4,320 4,320÷10 =432 432冊という計算になる。千冊という記憶が疑わしい。 今度、1ペ―ジあたりのOCR時間を計測してみようと思う。