2010年9月 アーカイブ

　先日来レポートしてきた方法によって、"自前の小説" なんぞを "縦書き" 仕様の "PDF電子書籍" に仕立て上げるとどんな感じとなるか、それをご紹介することにしました。
　"iPod touch" に転送してみて、まずまず無難に読めることは確認済みです。
　"フォント埋め込み" 型の "PDF" に仕立ててありますから、表示サイズ問題は残るものの、従来型の "Kindle[キンドル]" でも読めそうです。
　正直言って、まだ "手を加えたい点" 、たとえば、目次の表題と本文各節との "リンク" 設定とか、余白ページへのちょっとした "挿し絵" の挿入とか......。
　また、現行の表紙の "容量" がバカでかいのも気になっています。全体のファイル容量の "軽量化" の方法をいろいろな角度から試行錯誤したいと思っています。
　まあ、今回は、こんな感じではどうですか？　という意味合いで、 "画像のサンプル" の掲載と、あわせて、閲覧用 "サンプル PDF" （ "2 MB 弱" でやや重い気配......⇒ "1.1 MB" へ更新）を用意しました。

　たとえば、 "小説風の読み物" を想定した "自前のText文書" を、"PDF 電子書籍" としてまとめ上げようと考えた時、やはり "縦書き" 仕様の "書籍" にすることで "趣き" を添えたいと考えたりする。
　別に "横書き" 仕様でも良さそうなものだが、"日本語としての文章" というものに意を傾けた "小説のようなもの" は、やはり "縦書き" 仕様である方が思考回路にも馴染みやすいような気がしている。
　もちろん、アルファベットの英単語などがしばしば混じるような類の論文・解説文などであれば、 "縦書き" 文章は読みづらく感じることになり、むしろ "横書き" 仕様が妥当だとも言えそうではあるが......。

　昨日の "続編・応用編" ということになりそうだ。
　"Text文書のPDF変換" で最も簡単な方法というのは、昨日も書いたように、任意のアプリケーションでそのアプリ自体の "印刷" 操作から、プリンタ設定で "仮想プリンタ" の "Adobe PDF" や "Primo PDF" などを選択し、後は "道なり" に操作を進めて行けば "PDF 変換" された "PDF 文書" が作成されてしまう、というものであった。
　しかも、この "PDF 文書" には "フォント埋め込み" もなされる、というのであるから申し分ない。
　もちろん、 "フォントの種類・サイズ" などは、"印刷" 操作時に思いのままに設定すればよいわけだ。また、 "レイアウト" なども同様である。

　ところが、たとえば "秀丸" などの "Text エディタ" （ Windows の"メモ帳" も同様）には、 "縦書き" というオプションがない。別に、"横書き" でも差し支えないと言えばそうなのだが、 "縦書き" のレイアウトが欲しい場合もないことはない。
　ちなみに、"Text文書" の "PDF変換" を "縦書き" スタイルで果たすフリーソフトとしては、 "青空文庫" 仕様を実現する＜ChainLP＞（＜"Text 文書"を"ePub"化するのに効果的な"変換&編集"ソフト／"ChainLP"と"Sigil"（ 当日誌 2010.08.15 ）＞） のあることは以前にも書いたとおりである。優れたソフトなので再度記しておく。

　ここ最近、 "PDF 電子書籍" の話題から遠ざかっている。決して、関心が薄れたわけではなく、むしろ逆であり、これに関するとある個別テーマに埋没しており、 "調べ直し" とでも言う作業に入っているため控えているというのが実情である。
　ということで、今日は、ちょっと "脇" の事柄ではあるが有意義かと思われる件についてレポートしてみようかと思い立った。

　 "Text 文書" を "iPhone、iPad、および iPod touch" （および "Kindle[キンドル]"）などの "端末" で表示させるために、"PDF"（あるいは "ePub" ）に変換する方法については以前から書いてきた。
　とりあえず、＜"Text 文書"のスマートな"PDF変換"方法!／"iBooks"の"本棚/PDF"でも実に快適に!（ 当日誌 2010.08.28 ）＞などを参照していただきたい。
　そこでは、 "その方法" が＜ "Adobe Acrobat" による"Text 文書" の "PDF 文書" 化の "正攻法" ＞だと書いていた。確かに、 "その方法" のメリットはあるにはあるのだが、実は、もっと "簡単な方法" があったのである。
　しかも、高価な "Adobe Acrobat" ならもちろんのことであるが、フリーソフトでも十分に可能な方法なのである。

　"持続" させるということは、何にせよ大変なことなんでしょうね。"イチロー" の "10年連続200安打達成" にしても、 "横綱白鵬" の "連勝記録" （今日も上乗せで "61連勝" ！）にしても、その "持続" に向けてご本人が抱え込んでいる "重圧" は計り知れないものなんだろうと察して余りある。
　考えてみれば、現代という時代環境は、"瞬間芸" 的なパフォーマンスを多々生み出しつつも、この "持続" という点では結構 "脆(もろ)さ" を秘めているような気がしたりする。
　"変化" を最大の特徴とする現代であってみれば、"不変の......" とか、"持続的な......" であるとか、"恒久的な......" という現象は馴染みにくく、苦手なのであろうか。
　そんな状況下で、根性のあるスポーツ選手による "連続記録" が、逆に、"持続性" の困難さと貴重さとを知らしめているかのようである。

　世の中には、 "正当" なことであるにもかかわらず、常識的な感覚からすれば "妥当性" を欠くようなことってあり得るだろう。
　そんな時、人は「それは "正論" に違いない。だけどね......」と、 "分の悪い" 抵抗をしたりする。 "ごまめの歯軋り" さながらに......。

　今、 "ライセンス認証"、"アクティベーション" (※ 注.1) という、昨今のソフト・ベンダーの一般的営業スタイルのことを念頭に置いて書いている。

(※ 注.1)
＜アクティベーション
　アクティベーション（英: activation、プロダクトアクティベーションとも）は、一部のソフトウェアをインストールした後、正規のライセンスを保持していることを確認するために行われる認証処理で、非合法に入手したソフトウェア（Warezやカジュアルコピー、2台以上のPCにインストールなど）の対策のために導入された。
　ある機能をアクティブ（有効）にするという意味であり、有効化、活動化、活性化などと訳される。最近はクレジットカードなどでも特定のURLにアクセスしアクティベーションしないと有効とならないものも存在する。また一部のハードウェアでも、ファームウェアの機能による特定の機能（有料オプション）を有効化するために使用される。＞（「アクティベーション」／フリー百科事典『ウィキペディア（Wikipedia）』）

　 "気まぐれな人" のことを、よく "御天気屋" だなぁと揶揄したりする。
　しかし、昨今のご本家の "気まぐれ" の度合いには恐れ入ってしまう。例年にない秋の "猛暑" が続いていたかと思ったら、一晩で "１０度前後" も急変、急降下し、おまけに犬猫も怯える "雷鳴" がしつこく轟き止まないと言ったありさまだ。
　何か、地上の人間たちに "恨み" でもあるのかと邪推でもしたくなるような "荒ぶれ方" である。誰かがまことしやかに言っていたものだ。 "荒れる天候は、人の心や人の世の荒ぶれた状態と呼応している......" と。両者の相関関係は、あながち笑い飛ばして済ますにはリアル過ぎるよう気もする......。
　思えば、"虎の尾を踏む" ような "自然破壊" を敢行して来て、今なお続けている人の世の "荒ぶれ" が、結局ただでは済まない自然の大変容を招来しているのに違いなかろう。
　"のどかな秋" の天候や風情と、それらと溶け合うかのような人々の "平穏な心模様" などは、もはや遠い過去の幻となってしまったのであろうか......。感傷の域を超えてそんなことを感じている。

　今日は、"PDF 電子書籍" 云々といった話題とは打って変わった、まことに "爺むさい" 話を書くことになる。
　自身の "ローカルな話" はひとまず後回しとして一般論的な結論から言うならば、この深まり行く "高齢化時代社会" にあっては、 "高齢者なり加齢を自覚する世代に特有の医療情報" をもっと一般化してゆくべきではなかろうか、ということなのである。
　ひょっとしたら自分の情報不足、あるいは偏った思いでしかないのかもしれない。それらを否定するつもりはない。が、どうもこうした "情報" は必ずしも一般的に広まってはいないような気がするのである。

　その根拠を推定するならば、以下のような点が挙げられそうか。
　① 従来は、高齢者は "マイナーな存在" と見なされていたことや、 "生い先短い" 者たちへの "医療" は重視されてこなかった......。
　② 高齢者たちの疾患は、とかく "歳だから致し方ない" とか、"加齢に伴う症状" という "アバウトな括り" で対処されがちであった......。
　③ 高齢者たち自身も、"歳だからしょうがないか......" と諦め気味で、疾患に関して積極的に訴える姿勢を持たなかった......。だから、なおのこと医療関係側にも "臨床事例" の情報が蓄積されにくかった......。
　要するに、 "前途のある世代" の疾患への対処こそが医療の本命だと言わぬばかりの風潮のために、高齢者たちの特有の疾患は "後回し(?)" にされてきた嫌いが無きにしもあらずだったのではないか......。

　昨日は、「青空キンドル」というサイトで、端末 "Kindle(キンドル)" で読める "フォント埋め込み" 済みの "PDF" ファイルが出力されることについて書いた。
　"日本語非対応" であった "kindle" は、"PDF" 自体を受け容れるものの、日本語の "フォント埋め込み" がないがゆえに日本語表示されない、という難点があった。そして、「青空キンドル」は独自な方法でこれを解消しているという話であった。

　ナルホドねぇ、と感心しながら同サイトを開いていたら、いつしか "試す気" になっていた。
　もっとも、自分は、"Kindle(キンドル)" ではなく、"iPod touch" を愛用し、しかも「青空文庫」については、"iPhone、iPad、および iPod touch" などの "端末" 向けのアプリケーションソフト＜ポケット文庫 SkyBook＞を有料でインストールして利用していたから、さほど切迫感はなく、ついでに "試す" という程度の動機であった。
　つまり、多分、問題なく達成できるだろうという "目論見" 、即ちその "Kindle(キンドル)" 向けの "フォント埋め込み" 済み "PDF" ファイルは、"iPhone、iPad、および iPod touch" などの "端末" でももちろん流用できるはず、という点を "試す" ことなのであった。

　今のところ、"PDF電子書籍" への実質的な関心は、"iPhone、iPad、および iPod touch" などの "端末" で読めるそれらという限定付で話を進めている。
　だが、 "ツートップ" であるもう一方の "端末" の "Kindle(キンドル)" ではどうなのかという点にも目を向けるべきかと思い始めた。
　というのも、 "Kindle(キンドル)" もまた、"PDF 電子書籍" を "電子書籍" としてのまともな守備範囲、レパートリーに容れているからである。
　ただ、もう近々解消されるとの噂（ ※ "日本語対応新型 kindle" が2010年8月27日に発売されたらしい）も聞くところだが、 "Kindle(キンドル)" は "日本語対応" がなされていない、いや正確に言うと、 "日本語フォント" の搭載・内蔵がされていないために、日本語としてはほとんど読めないという "難点" があった "ようだ" 。（ちなみに、自分はまだ "Kindle(キンドル)" という "端末" を入手していない......）
　ところが、この "難点" を物ともしない "挑戦的" な方々もいらっしゃったとかである。遅ればせながら、そんなことを知ったのは、以下の著作のとある文脈からだったのである。

　このところ、蔵書のうちのとある一冊を素材にして、＜① スキャニング＞ ⇒ ＜② "PDF電子書籍"化＞ ⇒ ＜③ "Text 文書起こし"＝正確な "読み上げ"="全文検索" を可能とする前提作り＞ ⇒ ＜④ 複数ページを一ファイルの "透明テキスト付PDF"ファイルに再編＞という一連の手順と方法をめぐって試行錯誤してきた。
　＜① スキャニング＞～＜② "PDF電子書籍"化＞では、＜"ScanSnap S1500"＞とその同梱付属ソフト "ScanSnap Organizer(ビューアー)" を使用している。
　この段階でも「検索可能なPDFに変換」の機能を使って "とりあえず" の "Text 文書起こし" をすることは可能ではある。ほとんど "自動" 処理で行われるのはありがたいのだが、しかしそれはあくまでも「検索可能な」という達成水準でしかない。決して "読み上げ" とその聴き取りに耐えられるものとは言えない。この点については、この間に何度も書いてきたところだし、だからこそ "Text 文書起こし" という観点にこだわり始めたわけでもある。

　昨日書いた＜"読んde!!ココ"×"Adobe Acrobat"で、"紙"書籍からの厳密な"Text 文書起こし"！＞の詳細をついでに書いておきたい。
　まあ、この辺まで来ると、手順が幾分煩雑になるので、よほどこの種のテーマに関心を持っている方とか、いわゆる "マニア" 的な方にしか響かないような気もしている。
　しかし、逆に、ここまで "凝る" のでなければ、"透明テキスト付PDF" の真価であるところの＜正確な "読み上げ" = "全文検索" ＞という可能性を丸ごと享受することはできないのではないかと思っている。
　 "舌足らず" の説明に終わっている懸念がありそうだが、"凝り性" なあなた向けに下記のとおり記述します。前提となるアプリケーション・ソフトは、"読んde!!ココ" と "Adobe Acrobat" となります。どうぞ参考にしていただくとともに、もしほかに良い方法があれば教えていただきたいと思います......。

　 "紙" 書籍を "PDF電子書籍" 化することによる、よりパーフェクトな "読み上げ" 達成を目指し、"凝る" ことひとしおである。
　もはや、スキャン付属ソフトや "Adobe Acrobat" 組込まれた "OCR" 機能ソフトでは "物足りない" ことがジワジワとわかってきたのである。
　いや、"物足りない" というよりは、それらによって処理された "誤読認識" や "歯抜け" 読み取りなどでは、まさに "聴くに耐えない" 読み上げしかままならないからだ。
　まあ、 "キーワード検索" くらいならば何とか可能ではあるが、いわゆる "全文検索" などはムリと言うべきかもしれない。

　＜蔵書や "紙" 書籍の "PDF電子書籍" 化作業＞におけるひとつのターゲットは、やはり、可能な限り正確に "Text 文書" を "起こす" ことではないかと痛感し始めている。
言うまでもなく、"Text 文書" を "起こす" ということは "読み上げ" や "全文検索" と表裏一体の事柄だとも言える。
　しかし、これをより緻密に行おうとすると、結構、難易度が高いなぁ、とそろそろ気づきつつある......。今後、この辺の試行錯誤のあれこれもレポートしようかと......。

　ところで、かつて、いや今現在でも "夢想" している "とあるイメージ" がある。
　それはこうだ。蔵書なり "紙" 書籍なりをそれらとさほど大きさの変わらない何か "ボックスふうのＩＴ機器" に据え付けると、ページを捲る手間をかけることもない全自動で、その書籍のページの "読み上げ" が始まる、というものなのである。もちろん、"リモコン" 装置なんぞが付属していて、「開始」「ストップ」「戻る」「進む」などが思うままにできる。
　こんなことを言うと、笑われそうな気がしないでもない。と言うのも、そんなものを期待するくらいなら、はじめから "読み上げ" が難なく可能な朗読テープなり、ＣＤやＤＶＤを選べばいいじゃないか！　と言われそうでもあるからだ。
　確かにそうなのである。 "黙っている" 蔵書なり "紙" 書籍なりに無理矢理に喋らせることを望むくらいなら、同じコンテンツで "音声化" されているメディア商品を探す方が手間が省けるという卒ない判断もあるはずだからだ。

　 "癌" の治療法における "抗がん剤" や "放射線治療" は、今のところ止むを得ないのだろうがその "副作用" での苦痛や "コスト" 面などで癌患者たちを憂鬱にさせるようである。 "癌" に見舞われ既に亡くなった知人が、度重なる "抗がん剤" 治療で心身ともにやつれ果てていたことをいまさらのように思い出す。
　と言って、現時点での "癌" 治療には、ほかに画期的な治療法が見出されているわけではなさそうだ。
　こんな状況下では、以下のようなニュースは注目に値すると思われた。

＜がん細胞を内部から破壊＝「トロイの木馬」血液細胞－林原研究所
　林原生物化学研究所（岡山市）は１５日、臍帯（さいたい）血から発見した血液細胞が「トロイの木馬」のようにがん細胞に入り込み、がんを内側から死滅させる現象を確認したと発表した。研究成果は大阪市で２２日から開かれる日本がん学会学術総会で発表する。
　この細胞は同研究所が２００６年、新生児のへその緒の臍帯血から発見した「ホゾティ」。抗がん作用や免疫抑制作用があるという。
　竹内誠人主任研究員によると、試験管で実験したところ、ホゾティはがん細胞を選んで中に入り、２～４時間後に死んだ。その際、がん細胞を死滅させる効果があるたんぱく質を内部にまき散らし、がん細胞を死なせた。
　将来的にはホゾティを抗がん剤の運び役としてがん細胞に侵入させるなど、応用が期待できるという＞（＜がん細胞を内部から破壊＝「トロイの木馬」血液細胞－林原研究所／時事ドットコム／ 2010/09/15-19:28）

　現時点での"電子書籍" 化への関心は、＜蔵書や "紙" 書籍の "PDF電子書籍" 化作業＞という "部分" 的テーマに集中している。要するに、スキャニングを媒介とした "PDF電子書籍" 化のことである。
　そして、その中でも "全文検索可能なPDF" あるいは "読み上げ可能なPDF" の作成に凝っている。
　＜関連情報＞
　　◆＜PDF電子書籍化で"全文検索"や"読み上げ"を望む場合は、Scan解像度設定に要注意!（当日誌 2010.09.11）＞
　　◆＜小説などの"PDF 電子書籍"を､"合成音声"で読ませてみる( by "Adobe Acrobat" )（当日誌 2010.08.26）＞
　で、この関心がさらに煮詰まっているポイントはと言うと、スキャニング画像から "Text 文書" を "起こす" 機能を果たす "OCR" 機能を担うソフトなのである。

　＜書籍内移動の "リンク" 機能＞は、自前の "Text 文書" の "PDF電子書籍"化 ではもちろん活用している。
　つまり、"目次" の各章・各節の箇所をクリックなりタップなりをすれば、その箇所へと瞬時にページ移動する機能のことである。
　ちなみに、自前 "Text 文書" の "PDF電子書籍"化サンプルの "目次" 部分を見ていただくと、その仕組みが了解できる。

　　　［ 参照 ］　◆ 小説「海念と保兵衛」の閲覧へ

　この機能は "Web ページ" などでは頻繁に活用されているため、むしろこれがないとまどろっこしいとさえ感じるわれわれではなかろうか。

　＜"ScanSnap S1500" ＆ 断裁機 "PK-513L" コンビ＞を活用した＜蔵書の "PDF電子書籍" 化作業＞は、もはや "量産" 志向態勢(?)に入るほどに習熟してきた。
　ちょっとした間を見つけては、＜断裁機 "PK-513L"＞で待ち行列を作る(?)蔵書をバラしては、＜"ScanSnap S1500"＞の原稿トレイに流し込んでいる。
　そしてヒマを見つけては、＜"ScanSnap S1500"＞付属ソフト"ScanSnap Organizerビューアー"の "編集" ウィンドウで、チェックや修正作業を行っている。
　当初は、専ら "Adobe Acrobat" とそれとの連携が抜群の "Adobe Photoshop" とを使っていたものが、"量産" 志向態勢(?)に入ると作業効率を意識するようになったからか、より効率的な手立てに目敏くなった。
　そこで到達したのが、前述の "ScanSnap Organizerビューアー" の "編集" ウィンドウを "使い倒す" というスタンスである。実際、その気になってみると、このソフトの "守備範囲" はかなり広いことに気づく。
　先日、＜同梱付属ソフト"ScanSnap Organizerビューアー/編集"は｢傾き補正｣作業で効果的!（2010.09.10）＞とレポートしたばかりであるが、実はそれだけではなかったのだ。

　つい先日、＜「アシネトバクターは既に国内で広がっていることが否定できない。」という医療関係者からの警告が浮上している＞（＜多剤耐性菌アシネトバクターは既に国内で広がっている！？／抗生物質依存抑制？（当日誌 2010.09.09 ）＞）と書いたばかりである。
　だが、その際には、とは言っても "きっと、新たな「抗菌薬」が開発されるに違いない" という "安直な期待感" があったことも否定できない。たとえ "いたちごっこ" となろうとも、当面の最悪事態に医療関係者たちは挑むに違いないだろう......、と。

　ところが、今回明らかになった事実は、そんな "安直な期待感" に真っ向から冷や水を掛けるものである。

＜新規抗菌薬の候補なし　「危機的状況」と専門家
　多剤耐性アシネトバクターや「ＮＤＭ１」遺伝子を持つ大腸菌など、既存の抗菌薬に耐性を示す細菌の対策に欠かせない新規抗菌薬の開発について、国内では現在、専門誌への発見報告から発売に向けた段階にある新規薬の候補が一つも残っていないことを、専門家が厚生労働省の耐性菌に関する研究班で報告していたことが１１日までに分かった。
　抗菌薬の低い収益性が企業の開発意欲をそいでいるとみられる。報告者の藤本修平東海大教授（生体防御学）は「耐性菌との戦いは新規薬の開発に支えられてきたが、現在は危機的状況だ」と話す。
　報告によると、新たな抗菌薬が登場してから最初に耐性菌が報告されるまでの期間が約４年と短いことが、開発の手間の割に大きな収益に結び付かない理由。世界的にも１９８０年代から２０００年代にかけて、新規の抗菌薬の数は４分の１以下と落ち込んでいるという。＞（新規抗菌薬の候補なし　「危機的状況」と専門家／【共同通信】／2010/09/11 17:36）

　＜蔵書の "PDF電子書籍" 化作業＞の意味・目的を改めて問うならば、"紙の書籍" では望めない "全文検索"、"キーワード検索"、さらに "読み上げ" が可能になる、という点がどうしても浮かび上がってくるはずである。
　 "蔵書、紙の書籍" を "電子化" してＰＣなり、"iPhone、iPad、および iPod touch" などのポータブルな端末の PDF リーダーで読むという効用も有難いことではあるし、 "ペーパーレス" の結果に伴うメリットという点も小さくはない。
　しかし、"蔵書、紙の書籍" の "電子化(PDF化)" に託された期待は、やはりそれだけではないはずであり、 "全文検索"、"キーワード検索" が可能となることや、あるいは "読み上げ" も可能となることではなかろうか。
　もしこれらが可能となった場合のメリットは決して小さくないはずだ。"読み上げ" による "(聴き)ながら読み" は理解度を高めることにつながろうし、聴くだけでも内容に親しむことになろう。
　また、 "紙の書籍" が "貴重な文献" などである場合には、"全文検索" が可能となれば、 "調べごと" や "文献研究" などは大いに捗るのではなかろうか。
　また、 "コピペ" も思いのままとなるため、 "引用" 作業がラクになるというメリットもあろう......。

　＜蔵書の "PDF電子書籍" 化作業＞でのスキャニングには、何度も書いているように "ScanSnap S1500" を利用している。
　このスキャニング作業にはかなり習熟してきたかと思える。が、そんな状況だからこそ気づいたことがある。
　とにかく、"ScanSnap S1500" の "オートフィーダー（原稿自動送り）" 機能は実にスピーディであり、 "両面スキャン" であっても原稿は "立板に水" のごとくスムーズに流れて短時間で処理される。
　これは歓迎して余りあることであろう。また、このスキャニングの結果も概ね "概ね良好" だと言える。
　が、このスピードだから "止むを得ない" と言えばそうなのだが、ひとつ気になることを自覚し始めた。スキャニング結果の画像ページ中に、まま "回転" や "傾き" のあるページが発生することなのである。
　この点については、以前にも以下のように書いた。

＜ただ、スキャニング完了後、一応、そのスキャニング状態を面倒でも一ページ一ページ目視チェックをしておいた方が良さそうだ。と言うのは、時として、ページが "回転" している場合があるからである。 "９０度" 左右に、あるいは "１８０度" も "回転" してしまっているケースが１～２％の割合で生じていたのだ。
　これも、さぁーて、閲覧しようかという段になって発覚したのでは興醒めとなるに違いない。そこで直後にチェックするようにして、 "修正作業" （このための手立ては "ビュアー" に用意されているので心配無用）を済ませておいた方が良さそうだ。＞（＜蔵書の"PDF電子書籍"化作業！"ScanSnap S1500"＆断裁機"PK-513L"コンビで驀進！（ 当日誌 2010.08.23 ）＞）

　どうしても "抗生物質" に依存しがちとなるのが現在の医療現場なのであろうか。ちょっとした風邪でも、なにかと "忙しい" 生活を送る患者側は、効き目が早く現れる "抗生物質" を期待し、医療側も安易にそれに応じる。
　こうした抗生物質依存の医療の現実が、"菌" 類を "鍛え上げてしまう" 結果となり、今、警戒されている "多剤耐性菌アシネトバクター" の登場をもたらしていることは容易に想定される。
　また、"多くの抗生物質に耐性を示す「ＮＤＭ１」という遺伝子を持った新たな菌" の広がりが懸念されているインドでは、医療現場で "過剰な抗生物質投与" がなされていたとの指摘もある。
　インド（やパキスタン）などでは、先端医療を海外の患者に提供する「医療ツーリズム」が盛んで、その市場主義傾向が "過剰な抗生物質投与" という傾向と相関関係を持っていないとも限らない。
　いずれにしても、"副作用のないクスリは無い" という謂われと同様の理屈で、 "抗生物質" における"即効性のある効き目" は、 "耐性を持った菌" の蔓延と引き換えにしていたことが、ここに来て如実に判明した格好なのであろう。

　相変わらず、＜蔵書の "PDF電子書籍" 化作業＞についてはヒマを見つけてはせっせと進めている。もちろん、＜"ScanSnap S1500" ＆ 断裁機 "PK-513L" コンビ＞を活用しての実に効果的、効率的な処理方法によってである。
　当然かもしれないが、同じ作業を継続していると、慣れるだけではなくて、これまで気づかなかった "より適切な方法" に気がついたりもする。そのいくつかをアトランダムに列挙してみようかと思う。

　すべからく自然界の現象は、"人為へのリアクション" なのだろうと痛感する。 "作用と反作用" は万物の基本原理のはずだが、"人為" 作用が累積してゆくならば、それらへの "反作用" が自然界から巻き起こるのは避けられないのが道理だ。
　 "人為" 作用以外ではない "ＣＯ2" 過剰排出が、 "地球温暖化" 現象を誘発していることもそのひとつであろう。
　その結果だと言って間違いではないと見える "異常気象" 、記録的な "夏日"・"猛暑日" の数珠繋ぎ現象が、今夏は北半球の生きものたちを否応なく不快にさせ、苦しめている。おそらくこの現象は、今夏の "猛暑" だけに留まらず、これがトリガーとなったさらなる "異常自然現象" を数珠繋ぎ的に引き起こして行きそうな予感がしてならない。
　気象予報士が、「この暑さは、今後、 "数百年" は続くものと思われます......」とコメントするといったブラックジョークはいただけない......。

　この＜自然界の現象は、"人為へのリアクション" ＞という思いを痛感させる "イヤな事実" がほかにもあった。＜ほとんどの抗生物質効かない新耐性菌＞という実に怖い事実のことである。
　各種疾病と "抗生物質" 投与とのまるで "イタチごっこ" 傾向についてはこれまでにも警戒されてきた。また、この "イタチごっこ" 傾向は、細菌だけではなくウイルスについても見出されてもいる。とうとう来るところまで来てしまったかという感がある。
　こうした、 "人類の危険な綱渡り" は避けられれば避けたい。少なくとも、これを最大限に警戒した "医療体制" が望まれる。高度な "人為" 的 "医療体制" で、最悪の事態をやり過ごすしかなさそうだからである。
　にもかかわらず、その "人為" 的 "医療体制" が予想外に "杜撰(ずさん)！" だとしたら、＜新耐性菌＞に襲われる前に "病気の気分" となりかねない。
　以下のようなニュース２本を添えておきたい。

　"Text 文書" から "PDF 電子書籍" を仕立て上げる手順をいろいろな角度からトライしているところである。
　ちなみに、手元に "Text 文書" としての自作の "小説もどき" があるため、これを素材にして Web 上の場を借りて、自前 "PDF 電子書籍" 作りのプロセスを "実演" しているといったところなのである。
　で、いよいよ "仕上げ" 的な段階に入り、"Text 文書" から "PDF 電子書籍" を作った場合の "ひとつの関門" とも言えそうな課題、＜"画像"（ "挿絵"、"表紙" etc.）の組み込み＞の方法を吟味しているわけなのだ。
　この点がクリアできれば、"圧倒的極小化" される "PDF テキスト文書" は "電子書籍" として申し分がないということになるからである。
　このトライのいくつかの結果が以下のとおりとなる。具体的な手順は既に ＜"PDF 電子書籍"の頁余白に"挿絵"等の"画像"を組込む知恵！(by "Adobe Acrobat") (2010.09.04) を参照していただくとして、今回はそのアウトプットをご紹介したいと思う。

　かつては、何かにつけてコンテンツの "File 容量" に気を遣ったものだった。
　先ず、種々の "ストレージ" の容量サイズが、今のように "何百ギガ" なんぞではなく精々 "何百メガ" でもあった。また、ＰＣなどの処理速度も遅かったため、大容量のコンテンツだと鬱陶しくなるばかりか、"フリーズ" さえしかねなかった。
　また、 "ネットの通信速度" も今から思えば想像を絶する遅さだったと言える。したがって、 "Web ページ" を作る者は、様々な箇所のパーツを如何に "小容量" に抑えて全体を "軽く" するかに否応なく傾注しなければならなかった。
　それに比べれば、現在は、各ユーザーが使うＰＣの処理速度も速ければ、"ストレージ" の容量サイズも余裕であるし、"ネットの通信速度" も超スピードである。そんな事情から、コンテンツの "File 容量" にはかつてほどにこだわる必要がなくなったはずだ。
　しかし、それでもコンテンツの "File 容量" は小さく、軽いに越したことはなかろう。結局、最後には使用上の処理速度、サクサク感に確実に反映してくるからである。

　その点、"PDF 文書" の "軽さ" には定評がある。たとえば、 "Word" で "27,730 KB" もあった文書が、"PDF" ではたったの "2,777 KB" という "小規模ファイル" になったという例もある。文書の中身にもよるが、まさに "十分の一" になってしまうほどなのである。

　先日、"Text 文書" からの "PDF 電子書籍" 作りについて以下のように書いた。

＜ただ、"Text 文書" からの "PDF 電子書籍" 作りで "不満な点" が残るとすれば、文面中に "挿絵" のような "画像" を適時挿入しにくい点であろうか。次善策として、一ページ丸々の "画像"・"挿絵" ページを差し込む形式ならば比較的手間をかけずに可能ではあろうが......。＞（＜自前"Webページ(スクリプト)"の "PDF 電子書籍" 化／この種の作業は"職人仕事"!（当日誌 2010.09.01）＞）

　これは、"Adobe Acrobat" の機能を使った "PDF 変換" での話である。この詳細については、＜Text 文書"のスマートな"PDF変換"方法!／"iBooks"の"本棚/PDF"でも実に快適に!（当日誌 2010.08.28）＞でレポートしているのでそちらを参照していただきたい。

　アップルは、早くも "既存ユーザーを悔しがらせる！"　自分もまたその一人である。
　もともと自分は、画像装置ならカメラでもＴＶでも、その "解像度" について結構こだわる方であった。
　そして、気に入って使っている "iPod touch" にしても、 "極小画面" でありながら
比較的 "高解像度(480×320)" であったことに魅力を感じたのだった。
　まして、ここに来て、 "電子書籍" 作りにはまってみると、"小さな文字" をどの程度鮮明に表示するのかといった "解像度" の問題が気にならざるを得ない。
　そんな矢先なのである、大幅に "解像度アップ" された "新型 iPod touch" がリリースされるというニュースが飛び込んだのは。確かに今後への期待感が膨らむとともに、まだ買って間もない "旧機種" を手にしながら、ああ、もうちょっと待てば良かったかなぁ......、という悔しい思いが走るのも禁じえない。

＜アップル：新型ｉＰｏｄ発表　小さく、高機能に　新携帯ＯＳも
　米アップルは１日（日本時間２日）、米サンフランシスコで開いたイベントで、携帯音楽プレーヤー「ｉＰｏｄ（アイポッド）」の新商品を発表した。発表されたのは「ｓｈｕｆｆｌｅ（シャッフル）」「ｎａｎｏ（ナノ）」「ｔｏｕｃｈ（タッチ）」の３種類で、来週から販売を始める。同社のスティーブ・ジョブズ社長は「ｉＰｏｄ史上最も革新的なラインアップだ」とアピールした。
　「シャッフル」は従来より小型化したうえで操作ボタンを付けた。記憶容量は２ギガで、価格は４８００円。「ナノ」は、ボタン部分を省いてタッチパネルで操作することにより、これまでのモデルの約半分の大きさに。８ギガモデルが１万３８００円、１６ギガモデルが１万６８００円。「タッチ」は液晶画面を携帯電話「ｉＰｈｏｎｅ（アイフォーン）４」と同程度の高解像度にしたほか、内側のカメラを使ってビデオ通話ができる。８ギガモデルが２万９００円、３２ギガモデルが２万７８００円、６４ギガモデルが３万６８００円。
　このほか、携帯端末向け基本ソフト（ＯＳ）「ｉＯＳ」の新バージョン「４．１」と「４．２」も発表。「４．１」は「ｉＰｈｏｎｅ」と「ｉＰｏｄ　ｔｏｕｃｈ」向けで、写真撮影機能などを高機能化した。「４．２」は「ｉＰａｄ（アイパッド）」向けで、「４．１」と同等の機能が使えるほか、無線経由での印刷などができる。
　また、楽曲購入などができるソフト「ｉＴｕｎｅｓ」の新バージョン「１０」も発表。「１０」には、お気に入りの音楽などを友人らと共有できる「Ｐｉｎｇ」のサービスなどが新たに加わっている。【毎日jp編集部】＞（アップル：新型ｉＰｏｄ発表　小さく、高機能に　新携帯ＯＳも／毎日ｊｐ／2010年9月2日）

　　　　【 今回の "PDF 電子書籍" 化作業で仕立て上げた二本の "小説もどき" 】
　　　※ いずれも、 "閲覧可" 、"iPod" などの端末への "転送・閲覧も可" です。ご自由に試して下さい！

　　　　　　　　　　　　　　　◆ 小説「海念と保兵衛」の閲覧へ
　　　　　　　　　　　　　　　◆ 小説「かもめたちの行方」の閲覧へ

　"Text 文書" を素材とした "PDF 変換" 作業を通した "PDF 電子書籍" 作りは、コツが呑み込めればさほど厄介な作業にはならない。
　その意味では、昨日書いた自前のコンテンツの "PDF 電子書籍" 化は、最も手数の掛からない "電子書籍" 作りであるのかもしれない。
　ただ、"Text 文書" からの "PDF 電子書籍" 作りで "不満な点" が残るとすれば、文面中に "挿絵" のような "画像" を適時挿入しにくい点であろうか。次善策として、一ページ丸々の "画像"・"挿絵" ページを差し込む形式ならば比較的手間をかけずに可能ではあろうが......。

　そんなこともあって、文面中に "挿絵" を適時挿入できる＜"HTML" ファイルの "PDF 変換"＞の方法について試行錯誤してみた。つまり、 "Web ページ" の"HTML" スクリプトのファイルを "PDF 変換" するのである。
　もともと、先日に紹介した＜"Text 文書"のスマートな"PDF変換"方法!／"iBooks"の"本棚/PDF"でも実に快適に! (当日誌　(2010.8.28)＞ "方法" は、＜Web ページから PDF を作成＞するのが本命のアプローチであり、したがって＜"HTML" ファイルの "PDF 変換"＞については何の問題もないわけなのである。
　むしろ、"HTML" スクリプトで設定済みの "文書内リンク" の構造などもそのまま活かされるために好都合でさえある。