OCR【1】

副題：アクションウイザ一ド この正月、３日かけてアクションウイザ一ド処理をしました。 別に千冊ほどあったと思う。 そして、つまり、OCR化する前の画像データという素材が既に備わっていた。 リアル本ではなくデータとしての本という有益さはかなりある。机から動かなくていい。あの本のあそこの記述を確認したい…という症状で作業が中断する。いまはほとんどボタンを押せば画面に現れる。でも５年前は2階まで降りていってリアル本を手にしなければならなかった。その確認作業の時間が長いほど思考が固まらない。めんどうだまた今度にしようとしたあの気持ちの悪さが重なってきっとガンマなんとかの数値が異常値になったのだと思う。 データ本が読み取り可能になれば桁違いにスピードが速くなる。 そのために、夜な夜な別で自炊された本に対し、①まずファイルを開きます。②次にOCR化します。そして③保存してファイルを閉じます。 ②のOCR作業には約10分かかりますので、次のパソコンで①をはじめます。これを待ち時間なく操作し続けるにはパソコン5台必要になります。つまり①②③の操作に各2分かかるのでしょう。４分Ｘ5台ですから。 アクションウイザ一ドとは、この①一番アタマのファイルを開く、②OCR作業をする、③終了したら保存してファイルを閉じる、④次の次のファイルを開く、これをフォルダ内のファイルがされるまで繰り返す、という単純だが、ヒトでないとやれそうにない作業を自動でしてくれます。 パソコン万歳！ 2分X千冊という時間が削減された。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時間を計測してみようと思う。

PDF【01】

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

Sharepoint【3】

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

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【1】

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

アウトライナ【11】

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

アウトライナ―【10】

 自炊書籍を分離したい。

★

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

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

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

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

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

★

★

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

★

うまくいかない。

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

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

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

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

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

FileblogとTag

 Fileblogのあの機能のTag付けは、PDFまたはword

素材の整理

素材フォルダは次である。

10 qanda：１問１答形式（問いがあるもの

20 Paper：論文形式・通達先例（判例）：それだけで完成

30 form

40 chapter：解説本解体（章）：隣接と関係

50 book;Shoko

60 note：雑多なメモ（ＮＳＲ）★、つまりその他だな。
70 server
 71mfile
 72mclient

結局、10～40を入れ物で鍛えて（整理、ファイル名変更、タグ）、それが軌道に乗るまで作業を続けなければならないのだろう。おそらくいま40%ぐらい。

まず入れてみる。ファイル名・タグに頼らずその段階で成立していなければ（効果が発生しなければ）ならない。この段階で効果がなければ、、、

常時バックアップの数

サブマシンには、毎日バックアップをしてもらう。

サブマシンは他にバックアップデータをクロールしており、スタッフの書庫になっている。

MS-Svr予備機は、スタッフと同じ数だけある。

常時バックアップの時間

後日談：ウインドウズバックアップはやめる、特殊ファイルにしかならないから。生のママがいい、それを素材にしてクロールするから。bunbackupにする。バックアップ間隔は、1日・3日などいろいろ試してみる。

～

設定された間隔でファイルの変更を監視し変更があった場合にバックアップが実行される。

ウインドウズの標準仕様の限界は10分らしい。ファイル履歴のバックアップ間隔が10分の場合、5分前に誤って削除したファイルは、バックアップデータには含まれていない可能性が高い。例えば、10時00分にバックアップが実行され、10時05分にファイルを削除した場合、次のバックアップは10時10分に実行される。そのため、10時05分に削除したファイルは、10時10分のバックアップには含まれない。ただし、ファイル履歴は、以前のバージョンのファイルを保持する機能がある。そのため、削除したファイルが以前のバックアップに含まれていれば、復元できる可能性がある。

完全なバックアップを考えるということは、これは入れ子理論に関係する。

バックアップの目的を「①交換」と「②取戻し」に区別し、「①交換」こそがバックアップ本来の意味であると定義づける。

当日作業が消滅しても仕方がないと考える。当日であればまだ記憶されているし、mfillの手前てあるメールなどに残っているから復元は難しくないと考える。だからリアルタイムのバックアップは行き過ぎだ。

そこで、時間は24時間とする。サブPCも1日1回であれば、楽ちんだろう。