【自炊】電子書籍ビューア　４【出来合い】

前スレ
【自炊】電子書籍ビューア　３【出来合い】
http://pc11.2ch.net/test/read.cgi/mobile/1080365767/

電子書籍とそのビューアに関連する話題を扱う総合ｽｯﾄﾞﾚです。今後ビューア
の表示に主に使われてゆくであろう電子ペーパーについてや電子書籍が普及
する場合に出版業界はどう変わるか等、どんな話題もOKです。

【関連スレ】
電子書籍専用端末総合スレ 3
http://hobby9.2ch.net/test/read.cgi/dgoods/1167055004/
【PDA】PDAで読む電子書籍【専用】
http://pc8.2ch.net/test/read.cgi/mobile/1080391499/

□電子書籍閲覧端末
PC・WordsGear（ワーズギア）で読む『最強☆読書生活』
ttps://www.saidoku.com/wordsgear/index.html
ネットワーク電子辞書−セイコーインスツル株式会社
ttp://www.sii.co.jp/cp/n-dictionary/index.html
LIBRIeソニー公式サイト
ttp://www.sony.jp/products/Consumer/LIBRIE/
Sony - Reader (Sony Reader商品情報)
ttp://www.sony.com/reader
iRex Technologies (iLiad開発・販売元)
ttp://www.irextechnologies.com/

乙

>>1乙
まさか>>997でdat落ちするとは…
722氏はここに辿り着けただろうか？

ｽﾚ検索くらいはできるだろう……たぶん……

　　　　　　　　　　　　　　　　　　　　 　 厂刀､　 　 　 　 　 　 , ヘ _　
　　　　　　　　　　　　_,　-‐…‐-　､___/／: : : ＼＿＿＿＿／: : : : ＞r
　　　　　　　　　_＞'´: : : :_,.- " : :／弌》__: : : : : : : : : : : : : : : : : : , : : }
　　　　　 , イ￣｀: :　: : : : : : : :¨ ‐-､ : :＼⌒＞､: : : : : : : _: :-: :¨: : ／
.　　　　 /: : : : : : : : /: :.,': : : : :: : : : : ＼ ∧　 　 ￣￣フ : : : : : :／
　　　　/:/: : : /: : :.ﾊ : :ﾄ､ ＼: : : : ＼ : :Y i|　　　 　 / : : : : : ／
　　　　| ｌ: : :./: : :./ハ: :{　＼j＼j : : ∧, j: :|.　　　　/: : : : :／ 　 　 　 　 　 ､
　　　　| |: : :| : : ,`匕 　`‐z匕 　＼ : : }Ｋ: j. 　 　 /: : : : :/　　　　　　　　　 }＼
　　 　 j,ﾊ: : |: :∧fて!　　ｲfて)'ｙ　 Y: :jF'},ﾉ　　　,': : : : :/　 　 　 　 　 　 　 |.: :.＼
　　　　　 ＼ﾄ､{ ﾊ ﾋﾘ 　 　ﾋ::ﾘ '　　j /rソ　　　 ｲ: : : : :.{　　　 　 　 　 　 　 ﾄ､: : ハ
.　　　　　　 　 j,从 " ､　　　""　　 ﾑ／　　 　 ,{|: : : : : ﾄ､_＿＿＿＿＿_ イ: :）: : :.}
　　　　　　　　　　 ゝ､　rっ 　　, イ,|_⌒　　　　ハ: : : : : : : : : : : : : : : : : : : : : : : : /
　　　 　　　 　 　 　 　＞-r＜＿／　iﾄ､　　＼　　＼､: : : : : : : : : : : : : : : : : : 彡ｲ
　 　 　 　 　 　 　 ｘ＜7ｲｘ公､　　 ／/　＼　_〉＼_ 　￣￣￣￣￣￣￣￣￣
　　　　　 　 　 rく　　//　〉::::fゝ_イ /　　 　 |　　　 ￣￣￣￣￣￣￣￣￣￣ .!
　　　 　 　 　 ∧, 　//　/⌒i|　 / /　 　 　 i|　こ、これは>>1乙じゃなくて　　|
　　　 　 　 　 {　j　{ {　/:::::::::| ,/ /　　 　 　 |　ポニーテールなんだから.　　 j
　　　 　 　 　 |　| ∧∨:::::::::::ﾚ' /　　　 ﾍ, 　|　変な勘違いしないでよね！ 　|

>>1乙

落ちてたのでビックリしたけど、無事たどり着けました。

サイトが用意できたので、小説画像再配置ツール置いときます。
http://no722.cocolog-nifty.com/

iRexの日本代理店が出来たり、
ワーズギアにPDFコンバータが出そうだったり、
富士通が電子ペーパー発表したり、
少しずつ状況が明るくなってきたっすね。

>>1
>>7
激しく乙！

>>1
>>7
ﾂｫ

>>1ｵﾂ
>>7君に幸あれ

>>7
otu

これだけほったらかしでもdat落ちしないとはさすがモバイル板

板によっては数ヶ月くらい問題無かったり

>>12
モバイル板では、5日程度は「これだけほったらかし」には入らないな。
1か月レス無しのスレは沢山あるぞ。
>>13
昔のPC板あたりだと、半年放置でも落ちないな。
モバイル板も似たようなものか。

もっとも、圧縮でのdat落ちの心配はなくても、「即死」が恐い出だしではある。

再配置のときに下にだけ余白を多めに取るってことできますか？
出力余白だと上下左右に余白を取ってしまいます。
補正のみ下余白は再配置の時には効果ないですよね？

ごめんなさい。
小説画像再配置ツールのことです。
携帯で小説を読むときに使わせていただいております。

スレ立て直後は落ちやすいんじゃなかった？

>>15
小説画像再配置ツール V08-12b
http://no722.cocolog-nifty.com/blog/2007/04/v0812b_156f.html

余白パラメタを独立して設定できるようにしました。
確認してみてください。

仕事はやっ

>>18
ありがとうございます。
うまく配置できました。
うちの携帯は全画面表示にしても
左下にメニューボタンが表示されて
画像が隠れるんですorz

たまーに文章が縦にばらばらになるのは
しゃーないのかな。
一応読めてるから問題ないかもしれませんが。
それにしてもすっげー便利。感謝感謝。

>>21
ばらばらになるサンプルがないので直し様がないっす。

多分、文の途中に句読点があり、
そこんとこで二段組と誤認識して、
上下に分割してるんだとは思うんだけど。

では二段組かどうかをパラメタとして与えれば、
誤認識することはない・・・。
と思っても、実際には一段組みのものでも、
上に文、下にイラストという構成もあるので、
なかなか難しいんですよね。

現在の段組の認識を自動モードということにして
それ以外に
無条件で１段組で処理する文庫モード
無条件で２段組で処理する新書モード
というのを選択できるようにするのは難しいのでしょうか？

自分の環境では挿絵と本分がページで別れているものがほとんどなので
上に文、下にイラストという構成の認識が甘くてもあまり問題がありません。

あと２段組の新書の場合、段組単位の補正(１ページを上と下の２ページに切り出す)
ことはできないでしょうか？

>>22
あ、すまそ…。
ttp://up2.viploader.net/pic/src/viploader465637.jpg
こんな感じで縦に細く分かれる感じで、多分もとが斜めになってる
せいかもしれません。読めるんですけどたまに
次の行の左側と前の行の右側が合体されて1行になったり。
どうしてもというわけではないです。すいません。

こちらはできたらでいいのですが
「スキャン範囲余白」のとこ
上下左右の数字が設定できるとうれしいです。
下だけたくさんゴミがあったりするときとか。
下にノンブルがあるやつとか。

>>24
拝見しました。それは二段組とかには関係なく、
単に画像が傾いていて、それで本文がルビと誤認識して
ぐちゃぐちゃになったように見えます。
傾き補正に失敗している原因は不明です。

元ページ画像があれば、調査可能ですが、
この画像で分かるのは、この程度です。
スキャン余白の件ついては、時間見つけて直したいと思います。

>>23
段組を切り出すのは、現状かなり難しいです。
なぜなら、このツールは段組を認識しているわけではなくて、
たまたまそのページだけ、文章のブロックが上下に分かれていると識別し、
それがたまたま全ページ続いている、という認識で変換を行っているからです。
つまり、1段組が前提の内部構造なのです。

複数段組の構造を前提として認識することは不可能ではありませんが、
元々は再配置用ツールなので、そろそろ改造は限界に近づいています。
そろそろ再配置用ツールと補正トリミング用ツールに別けないと難しいです。
一応、考えてはいるんですが、今気力がちょっと。

>>25
あーやっぱり斜めなせいですよね。
ありがとう。
乙カレサマです。

最近PDA買ったんですが、これで文庫本読めないかなあと思ってここにたどり着きました

文字の再配置ですか、すごいアイデアですね
僕はOCRで取り込もうとばかり考えてたんで思いもよりませんでした
すでにツールも実装してるとは、すばらしいです

ところで、前スレもう読めないんですが、OCRで取り込むとかはやってる人居ないのでしょうか？

>>27
方向が違うかも。
というかＰＤＡで読みたいだけなら
これで十分ですよ。ＯＣＲする必要がなくなる。
ありがたいです。

OCRは校正が必要で、自分で読むだけなら手間がかかりすぎる。

>>27
OCRはどうがんばっても識字率100%にいかないからね。
今のがどれくらいか知らないけど、ちょっと前でも90〜95%位はあったかな？
それでも200ページ位の小説だと10〜20ページ分が丸々誤字脱字のページと
考えるとそれほど話題にならないかということが分かるかと思う。

現状の普通の人が使うOCRはPDFに透明テキストで貼り付けて検索の補助と
して使ってるのが一般的かな。

>>27
OCRはもう使ったことあるのかな？
昔、PDAで読むために何冊か小説をテキスト化したことあるけど、
校正するためにしっかり隅々まで読むからせっかくテキスト化できても
もうそれを読む気がなくなってる。
PDAで読むだけならこのツールを使えばわざわざOCRする必要もないと思う。

>>27
ちなみに前スレね。
http://p2.chbox.jp/read.php?url=http://pc8.2ch.net/test/read.cgi/mobile/1080365767/

>>27
OCRは他の板だよ。しばらく行ってないからどこの板だったか忘れたけど・・・

[OCR] 画像→テキスト化総合
http://pc11.2ch.net/test/read.cgi/software/1141635878/

好きなミステリとか、何十冊かtxt化してるけど、だいたい10-20時間くらいはかかる
その上、確かになかなか再読しないしね
利点は押しつけスキャンでもOCRできるんで本をバラさなくてもいいことぐらいかな

皆さん、ご意見ありがとうございます。
やっぱりOCRは手間かかりそうですね。
ただ、僕は動機が好きな本を電子化して手元に置いて置きたいってのと
好きな本は何度も読み返す性質なんで、校正とかむしろ楽しめるかもｗ

この世界（？）、足踏み込んだばかりなんで、
しばらく情報集めと試行錯誤してみます（＾＾

>>35
なんか微妙に勘違いしていそうな気もするな。

ぶっちゃけ、辞書のような頻繁に文字列検索をする必要のある文書じゃない限り、
「小説のページをスキャンした画像」と「OCRしてテキスト化した文書」は、
普通に読む分には大差ないぞ。特に、今は722氏のツールがあるしな。
「OCR」は「小説を自炊して電子化」の、更に次のステップだと考えた方が良い。

OCRは職場で苦労してる人も多いだろ？

正直、俺はもうOCRって言葉は聞きたくないわｗｗｗｗ

>35
小説の校正なんつーのは、正規表現とかperlとかrubyとかエディタのマクロの世界。
OCRの設定とかテキスト化後の校正みたいな実戦的情報はRinGOchにある小説系スレくらい。
校正すると否応なく正規表現覚えられるから、その点はお徳かも。

和姦物のエロ小説をテキスト化していると、思考が蒸発していい感じにトリップできる
緩衝材のプチプチを潰しつづける感じ
まさに写経

>>7
自分は、ADFスキャナーで大量にコミックの画像データ化を行うのにコミック傾き補正ビューアを使っています。
自動検出なのに、かなりの精度で傾きが補正されるのは衝撃です。
722氏、本当にありがとうございます。
既に画像データ化作業に欠かせない神ツールですが、図々しくも、対応してもらえればうれしい件を。

�@起動するたびに各種設定が初期設定状態になってしまいます。
ツールメニューのパラメタ設定には保存機能がありますが、毎回読み込まなければなりません。
ツールメニューのパラメタ設定、入力(出力)フォルダ、トリム設定などについて、前回終了時の設定をiniファイルに記録して、次回起動時にはそれを読みこむか初期設定かを選択できる設定があるとありがたいです。

�A傾き補正については、水平ないし垂直の直線を検出し、それらの傾きの平均値により補正する仕様となっていますが、コミック画像データ化の一般的な手順では、ページの最内(本の綴じ目に近い辺)の垂直線により補正することとされています。
パラメタ設定の[傾き線採用]項目に、最右垂直線優先、最左垂直線優先、ファイル名末尾の奇数は最右・偶数は再左垂直線優先のようなモードを追加してもらえるとありがたいです。

�Bコミック画像データ化の一般的な手順では、高解像度でスキャンして、縦横数千ピクセル(BMPで10MB以上)の大きなサイズのまま各種補正を行い、最後に画像の縦横のサイズを縦1400ピクセルぐらいに縮小することとされています。
コミック傾き補正ビューアで補正データの出力に使用するファイル形式についてはPNGがデフォルトとされていますが、PNGは読み書きが遅く、TIFF形式(LZW圧縮)とでは
補正に使う大きな画像の読み書き時間が1枚当たり10秒ぐらい違うため、数百枚処理すると処理時間の差が1〜2時間違ってきます。
そこで、入力・出力ファイル形式にTIFF形式(LZW圧縮)を追加してもらえるとありがたいです。
あるいは、Susieプラグインに対応していただければ、読み込みの方だけでも速くなるので助かります。

�C補正データ取得時及び変換時のビューアの表示を切る設定があると、処理時間が短縮され、ありがたいです。

以上、ダメモトで書かせていただきました。
気に障る点がございましたら、申し訳ございません。忘れてください。

>>40
了解です。善処いたします。
コミック傾き補正ビューアは使っているひと居るのか少々不安でしたが、
ニーズがあるようで何よりです。

設定をファイルに落とせればよいよね。
PSP用設定とかVGA用設定とか。

>>41
ありがとうございます。
今のままでも致命的な問題はないので、722氏のお気の向いたときに
対応していただければ幸いです。
あと、このコミック傾き補正ビューアについて、下記のコミック画像データ化関連スレ等で
紹介してもかまわないでしょうか？
(実は【初めての】スキャン職人養成スレ弐【自炊】のレス744で
既に誰かが>>7のサイトを貼ってしまっているのですが。)
【コミック】 自炊技術スレッド 26冊目 【書籍】
http://tmp6.2ch.net/test/read.cgi/download/1170955468/
【初めての】スキャン職人養成スレ弐【自炊】
http://tmp6.2ch.net/test/read.cgi/download/1169181743/744
自炊技術Wiki
ttp://wikiwiki.jp/bookjisui/

ぁ〜ぁ。
ツール自体はまっとうなのにやっぱりそっち系の人に需要あるのね……。

>>44
板はそっち系ですが、スレ住民は必ずしもそっち系ではありません。
自分は個人用途です。

>>43あたりは、間違いなく日本有数の自炊技術情報交換場だからな。

コミック傾き補正ビューアで、

垂直優先、垂直のみで傾き補正を行っても、
どうも水平線で傾き補正を行っているみたいだったので
内部演算プレビューを見てみると、
メイン画面の傾き補正角度と、内部演算プレビューの補正角度が違います。

内部演算プレビューの方は垂直線で補正を行っている。
メイン画面の方は水平優先で補正したものが表示されるみたいです。

>>24
小説画像再配置ツールの「スキャン範囲余白」の件
修正しました。
ttp://no722.cocolog-nifty.com/blog/2007/05/v0813b_c42b.html

>>40
>>47
コミック傾き補正ビューア、いろいろ修正しました。
設定値の自動記録、TIFF対応、プレビュー抑止、垂直優先が効かないバク
以上の修正です。あと高速化など。
ttp://no722.cocolog-nifty.com/blog/2007/05/v0301b_aae5.html

小口側垂直線優先は、もうちょっと待ってください。
ツールの紹介はblogに書いてある通り、好きにして頂いて構いませんよ。

>>48
いただきました。
早速の対応、大変ありがとうございます。
あと、自炊技術Wikiの「ツール」紹介メニューに下記のとおり
>>7のblogへのリンクを貼らせていただきました。
ttp://wikiwiki.jp/bookjisui/?%A5%C4%A1%BC%A5%EB

>>48
スキャン範囲余白、ありがとうございました。
∩( ・ω・)∩ばんじゃーい。

>>48
いただいたコミック傾き補正ビューア V03-01bを少し使ってみました。
大きなことではありませんが、以下、気づいたことです。

�@ツールメニューのパラメタ設定の出力画像形式選択でTIFFがaと表示されています。

�A再起動時に、パラメタ設定については前回の値を再設定してくれますが、
入力(出力)フォルダ、トリム設定などについては初期設定状態になってしまいます。

>>51
TIFFがaと表示されるのは、難読化を掛けたとき、化けたようです。
後で直しておきます。

入力(出力)フォルダが保存されないのは仕様です。
トリム設定はデフォルト値をプレスキャンした画像から計算する仕様なので、
これも仕様です。

前回プロジェクトと前回フォルダがメニューに記録されるので、
再現する必要はないと思うのですが、どうなんでしょう？

>>52
722氏の考えは分かりました。
自分の方の事情は、次のとおりです。

�@スキャナーから読み込んだ画像を格納するフォルダ、その画像を加工するためのフォルダが決まっています。
1冊加工が終わったら、加工途中までのフォルダの中身は削除します。
そして、新たにスキャンした画像が入ります。

�Aスキャナーから読み込んだ画像は、紙の外まで読み込まれています。
トリム設定は、傾き補正後に紙の部分の画像だけを切り出すために使用します。
紙の大きさは、大体そろっています。

>>53
スキャナーから読み込んだ画像を格納するフォルダが決まっているなら、
起動してから、起動画面の左にファイルか加工したいフォルダをD&Dでいいんじゃない

トリム設定の保存や読み込みは欲しいです。

>>54
おっしゃるとおり大した問題ではなく、このままでも十分で、ありがたく使わせていただきます。
ただ、フォルダが決まっていて中身が入れ替わっていくので、
入出力フォルダ固定で再プレスキャンボタンでもあれば、なお便利ということです。
再プレスキャンボタンは、パラメタ設定変更時にも役立つかもしれません。

>>55
コミック傾き補正ビューア V04b
ttp://no722.cocolog-nifty.com/blog/2007/05/v04b_67d5.html

フォルダを再現する機能は、このツールの開発コンセプトが
「画像データと補正データを保持するビューアである」
という方針から外れるので、折衷をとって、
フォルダ名を記憶していて、フォルダダイアログを開いたときに、
前回のフォルダ位置を指し示すようにしました。

あと、トリム強制をありにしてもらうと、
毎回、トリミングサイズが反映されるようになっています。

それと、のど垂直線優先設定が選択できるようになりました。
連番ファイル名から奇数ページ偶数ページを判定しています。
ただ、枝番が付けられている場合は判定をミスします。

>>56
いただきました。
ありがとうございます。
さっそく使わせていただきます。

>>7
722氏、小説再配置ツールいつも使わせてもらっています
非常に便利で助かっています

ノンブル種類を、今の「左右」、「中央下」、だけではなく
「左右＆中央下」を追加することは出来ないでしょうか？
普段ノンブル再配置をＯＦＦにしているのですが、本文の左右上に目次（？）、中央下にページ番号
がふってあって、どちらか一方しか消去できない本がたまにあってちょっと困っています
そこで「左右＆中央下」があれば両方きれいに消すことが出来ると思ったのですが……

サンプルサンプル

タイホタイホ

こんなの見つけました　どう思います？
http://scanbooks.jp

>>61
たけー。
裁断料金も高いし、fi-5120cも、週一万も払って借りるほどの機械でもないぜ。
このクラスの機材で自炊しても、余程集中的にとりかかったとして、コミックスなら
一日5冊もスキャンできれば御の字。
一週間だけじゃ本人の技術もついてこないだろうし、満足する結果を出すのは難しいだろう。
何か特別な事情でもない限り、お薦めは出来ん。

>>61
・・・と>>62を書いてから他のスレ見たら、俺の行く先々で同じ書き込みが。
なんだ、業者の宣伝かよ。つまんね。

セキュア対応のやつはマジックゲート・メモリースティックなどを用い、テキストファイルを暗号化してから転送せねばならないし。
SonicStageとソニーのウォークマンでの音楽ファイルの転送と同じく、使えない。

テキストファイル閲覧対応であっても、Unicodeに対応していなかったり、内部処理がShift-JISのみであったりといろいろ制限が多い。

ほ

PPC2002のQVGA機で、722氏のツールを使った画像ファイルで読んでる人いる？
フリーのビューアで使いやすいのとかないかね……

色々使ってみたけど、メモリ使い切って困ることが多い@zero3

>>66
いるよ。
ビューワーはマンガミーヤもしくは、AJCです。

×AJC
○AJV
でした。スマソ。

>>68
みーやは2002に対応してない気がするが……
とりあえずAJV使ってみますた
起動時の挙動と、設定の少なさが気になるけどいいソフトですね
どうもありがとう

コミック傾き補正ビューア V0.5β
http://no722.cocolog-nifty.com/blog/2007/06/v05_2e35.html

リサイズ機能が付きました。
あと高速化と一括補正機能です。

>>71
大変乙です。
いただきます。

>>71
乙です。
はやくなるのはうれしいなぁ。

eTilTran V0.1β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v01_9a35.html

えちるとらん = コミック傾き補正ビューア + 小説画像再配置ツール - 再配置

コミック傾き補正ビューアに小説画像の傾き補正をする機能を取り込みました。
視覚的に補正できるので、以前より操作が楽だと思います。
小説の余白をトリミングする機能があるので、電子書籍ビューアで見るための画像作成にも使えると思います。
お試しあれ。

ありがたや

>>74
いつもありがとうございます。
いずれは再配置機能をも取り込んだり取り込まなかったりですか？

>>76
今の再配置ツールは、文字の認識精度をあまり向上できないので、
手作業での編集ツールが必要だなあ、と思ったり思わなかったりです。

eTilTran V0.2β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v02_f48e.html

小説優先を実装したので、小説画像の読み込みが高速化したと思います。
あと、横書きをサポートしてみました。
多分、洋書にも使えると思うんですが、あいにく洋書は所持してないので実際のところは分かりません。
お試しあれ。

おおグレイト！

連日乙です。

横書きめっちゃ嬉しい！

このツール初めて使ったけどSUGEEEEEE！
横書きに再配置はできないんですよね？

eTilTran V0.3β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v03_2dfa.html

細かいバグ修正をしました。
赤焼けした小説画像を読み込んだ際、
カラーページと認識して、傾き補正されないのを修正しました。
変換出力の際、エラーが発生するのを修正しました。

>>82
再配置機能は、もし実装するとなると、ちょっと先になりそうです。
別のライブラリを導入して、変換の高速化などを試したいと思ってます。

日々是感謝
日々是感激

>>83
eTilTran使ってみました。
読み込みはたしかに速くなってます。

感想
トリミングの結果を目で見て判断できる点は◎
出力画像形式に複合が無い点が×

>>85
複合を追加してみました。お試しあれ。

eTilTran V0.4β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v04_40f3.html

・カラー原稿として認識されたものは、「カラー漫画」として表示するようにしました。
・コミック優先のときに認識失敗したものは、「漫画」に分類するようにしました。
・ファイル一覧の項目を右クリックして、種別を変更できるようにしました。
・ファイル一覧の項目を右クリックして、再スキャンできるようにしました。
・ファイル一覧の項目を右クリックして、削除できるようにしました。
・保存画像形式として「複合」を選択できるようにしました。

更新乙です。

>>87
85です
複合を追加ありがとうございました
自動認識の精度も上がっていい感じです
種別が「不明」になるページがほとんどなくなりました

>86
eTilTranいただきました。
トリム設定ボタン押すとエラーが出ます。
System.ArgumentOutOfRangeException: Value of '0' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'.

>>89
後でエラー直しておきます。
とりあえずオプションを開いて、
トリム関係のパラメタが、多分
トリム強制ありで、高さと幅が変な値になってるとおもいますので
トリム強制なしで、高さと幅に適当な値を入れてみてください。
多分、高さと幅のどっちかが0に設定されていると思います。

eTilTran V0.5β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v05_c61b.html

直しました。
あんまり意味ないかも知れないですけど、
ついでに拡大縮小できるようにしてみました。

PDFビューワにもなるSonyの電子ブックリーダ「PRS-500」
ttp://pc.watch.impress.co.jp/docs/2007/0621/pda60.htm

E-INKは電池食わなくて良さそう。
応答速度の速いものが早く登場しますように……。

>>92
thnks!

ちょっと質問なんですけど
eTilTranの設定で「傾き線のど垂直基準」の偶数奇数はどう見ればいいんでしょうか……
一応、補正しようとしてる画像は、全ページ右側にのどがある状態です。

>>94
不安なら内部演算プレビューで確認してください。
逆になるようなら、[傾き線のど垂直線基準]を[奇数ページ]に設定してください。

う〜ん、どうにものど方向を見てくれたり見てくれなかったりでうまくいかない……
もうちょっと設定見直してみます、レスどうもでした。

>>96
のどを完全に判別できるわけじゃなくて、
条件が悪いと、のどの縦線は取れないです。
そのため、のどがとれない場合は横線を第二候補として取ります。
手作業で角度を入力できインターフェースなのは、判別が完全ではないからです。
多分、パラメタ設定しても、改善はされないと思いますよ。

>>722氏
えーっと、誠に恐縮ながら要望を。
自分はフラベスキャンの際、裏写り防止用に普段「黒い板」を原稿に重ねてスキャンをしているのですが、
この時出来た「ページ外の余白が真っ黒な画像」に対して、傾き認識が効かずに困っています。

サンプル画像
PASS:sage
http://vista.jeez.jp/img/vi8286796004.jpg

現在、一度画像を別ツールで階調反転した上でeTilTranで角度補正して、また階調を戻して
補正をするという手順を取っているのですが、流石にちょっと手間と時間が・・・。
この手の画像に対して、何とか対応をお願いできませんでしょうか？

>>98
補正は写真屋で行っていますか？

>>99
そうですね、PhotoShopやwisteria、炊飯器など色々です。

>>98

eTilTran V0.6β
http://no722.cocolog-nifty.com/blog/2007/06/etiltran_v06_f51f.html

「モノクロ反転」により、
内部２値化データを反転して処理するようにしました。

ただ、見たところ、裏写り防止板が、ほぼ黒で、
本文のインクは濃い灰色としてスキャンされるので、
この情報を利用して、黒板と本文が分離できないかテストしたところ、
なかなか良好だったため、その機能を実装してみました。

といっても、なんのことはない、モノクロ化しきい値に下限を設けて、
ほぼ黒の領域を無視するようにしただけです。

ただ、うちのスキャナはADFのため、
あまりテストしていないので、
スキャンの状況によっては、機能しないかも知れません。
試してみてください。

のど基準って、ひょっとして奇数偶数でのどの方向が変わる事が前提ですか？

>>101
うお、神の如き対応の早さ、お疲れ様です。

新Ver、早速幾つか原稿の種類なども変えて試してみたのですが、モノクロ閾値下限0、
モノクロ閾値上限150、モノクロ反転有りが当方の環境では一番安定した結果を出すようです。
閾値下限上限方式の方はパラメーターの調整がかなりシビアで、中々結果が安定しない印象を受けました
（自動トリミング機能の方も、原稿四辺の内二辺だけ認識したりと、調整が難しいです）。

実は>>98のサンプルですが、元々紙に色の付いた雑誌（マガジンです）を提出に当たって白黒化した物でして、
その辺の前処理がサンプルとして不適当だったかも。・・・申し訳ないです。
もしお入り用でしたら、以下に「素のスキャン原稿／状態のいい同人誌編」を別にUPしましたので、
サンプルとしてお使い下さればと思います。

PASS:sage
http://vista.crap.jp/img/vi8296103105.jpg

とは言え、私個人の要望は「モノクロ反転機能」の実装でほぼ満たされた状態です。
どうもありがとうございました。
と言うか、自動トリミングまで踏み込んでくださるとは思ってもいませんでしたｗ
自動傾き調整＆自動トリミングはマジ夢の機能です。それが出来れば、スキャン後の処理はALL全自動！
ちょっとﾜｸﾃｶｗ

>>101
いつも乙です。

>>100
レスどうも。
写真屋使いかどうかを伺ったのは、「モノクロ反転機能」がなくても、
>>101と同じ発想で写真屋→eTilTran→写真屋の処理を行い、
自動傾き調整＆自動トリミングが可能だからです。
そのため、722氏には申し訳ありませんが、私は、「モノクロ反転機能」
「自動トリミング機能」は使いません。
必要ならば、【コミック】自炊技術総合スレッド27冊目【書籍】で
私の方法を紹介します。

>>103
PASS:sageとは？
パスなしで表示されるような。

>>104
ありゃ、pass付きのつもりで、付いてなかったみたいですね。まあいいか。

自動トリミングですが「PhotoShopで出来るよ」と言う話を聞くと、実際出来る
ような気がしたので試してみました。
104さん言う用に、自炊技術スレ向きの話題かとも思いましたが、一応ここで
（興味のない方は読み飛ばして下さい）。以下、自分の方法です。

1.eTilTran「モノクロ反転機能」をつかい、原稿の自動角度補正
2.Rチャンネル抜き出しによるグレスケ化、若干の明るさ・コントラスト調整
3.自動選択ツール（許容値は80）で黒下地部分を選択
4.選択範囲1ドット拡張 x4回
5.選択範囲の反転
6.切り抜き
7.一定サイズにカンバス範囲の調整

1、2は選択をし易くするための下処理です（PhotoShopは2番から使ってます）。
3、4で選択。PhtoShopの切り抜きは1ドットでも残っている部分は切り抜かないので、
原稿内部に選択が掛かっていても問題なし（黒縁部分が確実に選択できていればいい）。
5、6で切り抜き。
このままだとページ単位で若干サイズに誤差が残るので、最後7で一定サイズになるよう
周囲を再度刈り込みます。

この手順で>>103のサンプルはほぼ確実に自動トリミングできるようになりました。
722氏、104さん、色々お世話様です。
取りあえず、一冊二冊バラしてもう少し確かめてみよう・・・

MeTilTran V0.1β
http://no722.cocolog-nifty.com/blog/2007/06/metiltran_v01_fe9d.html

めちるとらん = 小説画像解析 + 解析データ編集 + 再配置

再配置ツールを作り続けていたんですが、
いつになったら完成するか分からないので、
とりあえず現時点のものを公開します。

複合形式がない以外は、以前の再配置ツールの機能は実現できています。
また、編集機能があるので、変換に失敗した部分は手直しできます。

まだまだバグが多く、未実装の機能も残りますが、
良かったら使ってみてください。

なお、横書きの認識はしますが、まだ編集と再配置には対応していません。

大変乙です。

再配置統合キター

一括でコントラストもいじれるとうれしいのですが、
なんか、無駄に高機能化してこれひとつあれば取り込んだ書籍類はどんとこい
な状態になってくれたらお金を払いたいくらい

まぁ、今の機能のまま有料化されても払いそうですが

>>109

MeTilTran　V0.2β
http://no722.cocolog-nifty.com/blog/2007/07/metiltranv02_e33f.html

自動レベル補正を機能するようにしてみました。
コントラスト補正ではないけど、多少はマシかも知れません。

画像処理の教科書通りに実装しようとしたら、
輝度の最大値と最小値を求めて、そこから線形補完するんですが、
そうすると紙やインクの部分が薄い灰色と濃い灰色にしかなりませんでした。

そこで正しいかどうか分かりませんが、
ヒストグラムの明るい山のピークと、暗い山のピークを求めるようにしてみました。
ひょっとしたら問題あるかも知れませんので、試してみてください。

ありがとうございます。

>>110
携帯で読むのに使わせていただいております。
せっかくデジタル化してもPC上でしか読めなかったものが
外で手軽に読めるようになったので大変重宝しています。
910Tを使っているのですが、ボタンを押すたびに
バックライトがピカッと光るので目が痛くなる。
かなり大きくて重たいし、閲覧には向いてないかも。
画像ビューワーにしおりがつけられる携帯とかないですかね？

>>110
　ありがとうございます、早速利用してみますね

>>112
　スマートフォンという選択肢
　今のままSoftbankで行くなら夏ごろにTのスマートフォンが出ます。
　後はPDFを読める機種でどこまでいけるか・・・という現状ではないかと

>>110
　うーん・・・こっちの取り込んだソースも悪いのでしょうが、あまり
　体感できない感じでした。
　補正強度を3パターンくらい選べてちょっと極端なものも含んでもらえると
　うれしい感じです
　
　エチル、メチル、チェインが統合化されてUIが良くなっていったらと、
　今後の妄想なんかをしながら楽しみに使わせていただきます。

MeTilTran　V0.3β
http://no722.cocolog-nifty.com/blog/2007/07/metiltran_v03_f982.html

圧縮ファイルから直接入力できるようになりました。
自動レベル調整では、調整しきれないことが分かったので、
ヒストグラムを表示して手動調整できるようにしました。
また調整結果を別ページにコピーできるようにしました。
お試しください。

更新ありがとうございます。

>>114
エチルとメチルを統合するつもりは全く無いです。
あくまで、前処理用と後処理用としています。
完全統合すると、機能が多すぎて使いづらいと思うんですね。

そういった意味で、チェインの圧縮ファイル入力をメチルに取り込みました。
PDF出力は双方に取り込む予定です。

このツールで4コマ漫画などのほぼ固定位置に枠があるような画像を
自動でセンタリングしたりする処理は可能でしょうか？

>>118
　トリミングで余白カットは可能かと思います
　ただ、最近は割と多くの4コマ漫画がコマをはみ出て自由に動いていることが
　あるので、気をつけてください

ツール使わせてもらってるんですが、いろいろ試しても再配置の設定等うまくいかないので、
いまのところ、ノンブル除去、トリミング、リサイズで調整して使ってます。

めちるなんですが、設定→全般→再配置をなしにしても、再配置
されてしまってるんですが、確認していただけないですか？

エチルはノンブル除去できないんようなんでまだ使ってないです

>>120
メチルは小説再配置専用ツールなので、再配置なしの設定は出来ません。
再配置なしのパラメタは、昔のパラメタの残骸が残っています。
それ以前に、まだまだ全然作り足りていないことに注意してください。

再配置なしはエチルでやってください。
ノンブル除去は、トリミングするときに、
ノンブル領域に重ならないようトリム領域を設定すれば可能だと思います。

MeTilTran　V0.4β
http://no722.cocolog-nifty.com/blog/2007/07/metiltran_v04_e130.html

不要パラメタの残骸を掃除しました。
今までまぎらわしくてすみません。
あと、レベル調整で中間調が効かなかったり、
前回フォルダの細かいバグを修正しました。
新規では、PDF出力と、しおり機能が追加になっています。

しおり機能は、設定したしおりテキストが
ファイル名として付加されるようにしてみたんですが、
確かマンガミーヤなどで、目次構造をxmlで持っていたような記憶があるんですが、
そういう感じのデータ構造を出力できたほうが良いんですかね？
どこかでちらっと読んだだけなので、詳細は知らないですが。

いつも乙です。

レベル調整使いやすくていいですね。
文字もくっきりにできるようになってかなりいいです。
0.3はHDDがちょうど土曜日の夜に壊れてしまって、復帰に忙しく
いじれてませんでした。


これ、エチルのほうにもつけてもらえると漫画もだいぶ助かるので
もしよければお願いします

>>124
了解です。
ちょうど今、eTilに圧縮ファイル入力とPDF出力を実装中なので、
ついでにレベル補正もつけておきます。

個人的には、傾き補正以降の作業はPhotoshopでやるのですが、
簡単に補正したいだけのニーズもあるみたいですね。

>121
開発乙です。

>120じゃないですが。
ノンブルを削除する場合、エチルはトリミングをいじってもノンブルを含めて
センタリングするので、以前の「小説画像再配置ツール」に比べると設定が
難しいです。
小説だとセンタリングよりも画像上端から文章領域までの距離をピクセル指定する
ほうが設定が簡単だし、センタリングだとたまに本文位置が上下してしまうことが
あるんで、以前のピクセル指定の復活を是非お願いしたいです。

>>126
了解です。ちょっと検討してみます。
以前のツールは再配置の都合で、
一旦、白紙の画像領域を作成して、そこに転送するしかなかったんですが、
エチルは元がコミック用で、元の画像をトリムする考え方なんですね。
でもまあ、コミックと小説の区別は分類されているので、
なんか手段を考えてみます。

>127
ありがとうございます。
楽しみに待ってます。

>>722
　ありがとうございます
　時に、一括補正でページ指定をすると指定ページ以外が除外されるのは
　意図的なものですか？

>>722
　あと、個人的な使い方としてですが、基本的には書籍のデジタル化を進めているので
　1ページ単位で細かく直す時間をかける気がありません。
　DR-2050にて取り込み後、PDFをJPG変換とフォルダわけを同時に行い、
　eTilで調整をして、eTilで調整しきれないものがあればPhotoShopで修正後、
　ChainでPDFへ再変換（保存用）とワーズギアでの持ち運び用に縮小したもの
　を作って完了

　が、今の基本的な流れです。
　一部書籍のみ、携帯で見れるようにMeTilを利用しています。
　以上、1ユーザーの使い方のパターンでした。

eTilTran V0.7β
http://no722.cocolog-nifty.com/blog/2007/07/etiltran_v07_2bb8.html

配置のやり方を大幅に変えたので、かなり時間をとられましたが、
ひとまず完成しました。
ノンブルとテクスト領域の配置は、以前の再配置ツールと似たようにしてみました。
ただ、そうするとコミックの補正が難しくなるので、なんとかバランスをとって、
コミックでは全体をテクスト領域とすることで、
とくに設定を触らずに傾き補正できるようになっています。
あと、圧縮ファイル入力とPDF出力に対応しています。
まだちょっとバグが残っていそうな雰囲気ですが、試してみてください。

>>130
どういう使い方をしているかお知らせありがとうございます。
なにぶん、自分の使い方や、あとは想像で作っているところが多いので、
結構参考になりました。

ここの神は精力的で凄いな

>>131
現人神に感謝

いつのまにかサイトのデザインが変わってて驚いた

前のデザインの方がちょっぴり好きだったおいら

前のデザインは、なぜか落ち着く感じがする

OCRした本を蓄積するフォーマットを探しています
・手軽に全文検索可能(GREP、Namazu等。正規表現が使えると尚良い)
・縦書き対応
・挿し絵もレイアウトして入れられる
・ルビ対応
・改行、改ページ対応

いくつか検討してみたのですが
　HTML：縦書き、ページ単位の観覧が難しい
　PDF：検索に制約有り。Windows以外での観覧に制約多い
　青空文庫形式：挿し絵が入られない、改ページが無い
　XMDF：仕様が公開されていない
　TTZ：仕様が公開されていない

青空文庫形式に挿絵挿入と改ページ機能を追加したようなマークアップ言語
みたいなのがあれば良いかなと思っています
良さそうなフォーマットがあったら教えて下さい。よろしくお願いします

青空文庫に挿絵を入れた形式のあるよ。
HTMLのタグで画像を指定する。
マンガミーヤとかがビューワーとして対応している。
詳しいことは良く知らないけど。

>>137
それなら青空文庫形式でいいでしょう
扉やsmoopyという青空文庫Viewerは挿絵タグ・改ページタグが使えます

>>137
青空文庫の挿絵対応ビューア、結構ありますね。
改ページは［＃改ページ］とかのタグを書いておけば
対応するビューア結構ありますよ。
azurなんかもタグ対応してますね。

MDFについては、シャープの中の人が昔
「オープンフォーマットとして公開する」って発言してたけど、
結局公開する気はないのかねえ。
ttp://premium.nikkeibp.co.jp/ebook/part2/bunko.html

意外なくらい、反応良いな。

>137
T-Timeのttzというかttzのソースになるhtmlの仕様は以前は公開されてたけどね。
T-Time2.3まではタグのヘルプも付いてたし、web archiveでVoygerのT-timeタグ講座も
まだ読める。htmlに独自タグをいくつか付加しただけだから作成は難しくない。
青空文庫形式のテキストはずっと簡単だけど、ttzほどの自由度はない。

でもどっちにしても、画面表示状態で正規表現検索できるソフトはない。単純な検索で
あれば扉やT-Timeは対応してる。単純な検索で我慢するか、ルビや傍点なんかのタグを
削除した検索用の版を別途作成するかしか現状道はなさそう。

T-Timeは青空文庫形式テキストには対応してない、azurも青空文庫のxmlにしか対応して
いないはず（以前試したときはそうだった）。

レスありがとうございます

青空文庫形式でも挿絵、改ページをできるとのことなので青空文庫形式でやってみようと思います
青空文庫形式のタグについてまとめてあるサイトって無いですかね？
公式にはルビくらいしか書いていないですし…

>>142
>画面表示状態で正規表現検索できるソフトはない
正規表現による検索は必ずしも表示状態である必要はないです
表示状態での検索は前方一致の検索が付いていれば間に合います
本を電子化してデーターベースみたいに検索(GREPなり、Namazuなり)したい
のですが、検索するときにPDF等の専用形式だと検索できるツールが限られてしまうので
プレーンテキストベースのフォーマットを探していました

>>143
Viewerが認識できるタグならヘルプに書いてあります
smoopyのドキュメントが見やすいかな

eTilTran V0.8β
http://no722.cocolog-nifty.com/blog/2007/07/etiltran_v08_c8e5.html

前回のβ7でテクスト領域とノンブル領域に別けて処理するようにしたんですが、
どうも単純に角度補正とトリミングだけしたい場合には、ちょっと使いにくいので
β7以前の操作も、モード切替で可能にしました。
デフォルトではβ7以前の操作モードで、
β7のテクスト領域とノンブル領域の操作をしたいときは、モード切替が必要となります。

テクスト領域には、縦書き、横書き、挿絵が含まれるのですが、
それ以外の不明な領域や、薄い背景のパターンが含まれず、
プレビュー時や出力時にテクスト領域以外が消滅してしまうので、
やはりこれは問題だろうと判断しました。
（ページの種別を「漫画」などに切り替えれば戻せるのですが、
たくさんページがあると面倒ですからね）

多謝

>>143
工作員マニュアルにあるよ
http://attic.neophilia.co.jp/aozora/task/annotation/

MeTilTran V0.5β
http://no722.cocolog-nifty.com/blog/2007/07/metiltran_v05_921a.html

画面インターフェースが一段落したので、
二段組と、章タイトルの排除について見直してみました。
うちには二段組の小説が皆無なので、ちょっと自信がないのですが、
以前頂いたサンプルで試したところ、大丈夫っぽいです。

あと、お手軽に再配置だけしたいこともあるので、
入力後すぐに再配置する機能をつけてみました。
ただ、今のところ再配置パラメタの入力画面が出ないので、
予めパラメタ設定しておく必要があります。

乙哉

いつも精力的な更新お疲れ様です

eTilTran愛用してます
トリム設定自体は使い勝手良いのですが、できればβ6にあった｢自動トリミング｣機能の復活希望です・・・

モバイル系サイトでMeTilTranを知って使ってみたのですが
かなりの検出精度ですね
余白カットに非常に便利です

所がちょっと使いにくいかなと思う部分があって
コミックを認識する際に小説優先で読み込んでしまうので
挿絵モードで全画像を読み込めないんですかね？
それと全画像の再認識モードも欲しいです
これは現状で解決できますか？

まずちゃんと読め。話はそれからだ。

読めと言ってもマニュアルもヘルプも無いから
勘で使ってる状態なんで

eTilTranの方を使えば問題は解決したみたいだけど
こちらだと有効リージョンの認識が
MeTilTranより弱いと言うか仕様みたいで
余白を思うようにカットしてくれないんだよね
まあ使い方が悪いのかもしれないけど

>>150
要らないかなと思って削除したんですが、
後で何かの機会に復活させておきます。

>>151
MeTilTranは小説専用なので、コミックは対応していません。
eTilTranは小説とコミックの傾き補正とトリミング専用となります。

コミックは余白があったり無かったりが激しすぎるので、
傾き補正と、指定位置でのトリミング以外は無理だと思っています。
実装もあきらめています。

それでも有効領域を画素の見える範囲でなるべく設定するようにしています。
ただ、コマの位置を正確に把握しているわけではないので、有効範囲があやふやなのは仕様です。
(正確に把握できるなら、今ごろコマ単位の切り出しツールをMeTilTranに実装しています)

151さんが何をしたいのか残念ながらよく分かりません。
多分、私が想像もしていないニーズがあると思うんですが、
そのあたり書いて頂けると有難いです。

マニュアルについては、付属のドキュメントを読んでください。
読みづらいとは思いますが、このツールはβ版で、
どんどん機能が変わっていて、詳しい解説を作る余裕はありません。

>>154
ありがとうございます

自分の場合、取り込んだ小説はメチルの再配置機能は使わず画像のまま読むので、
読みやすくするための作業として余白削りは必須なのですが、
その際に自動的に余白をトリムくれる機能があると嬉しかったりします・・・

コミックのコマ単位での切り出しなんですけど、
4コママンガ専用でも良いのでとっても欲しいです。
コミックを電子化した場合、4コママンガはコマが小さく見づらいので、
1コマづつ切り出したいのですが、手作業や、座標で指定しての切り出しは、かなり大変です。

のど基準じゃなくて、左右どちらか一定の縦線を優先するなんて処理は出来ますか？

>>156
>座標で指定しての切り出しは、かなり大変
座標にばらつきがあって大変って事？
作業負荷の問題ならImageMagick(必要なら適当なスクリプトも使って)で自動化するとか

両方かな。
4コマでも完全にそろっているわけではないので、

>>154
それほど複雑な事ではなく
アスペクト比はそのままで横幅を出来る限り詰めたいわけです
そうすれば多少なりとも拡大されて文字が読みやすくなるし
上余白も出来る限り切り詰めればスクロール量も少なくて済むわけです

これがメチルのほうで挿絵として認識させるとかなり上手く切り詰められます
エチルでは全頁単純縮小されている感じです

従って出来ればメチルに一括で固定読み込みモードを実装するか
エチルにメチル相当のアルゴリズムを実装すれば便利になるんですが

eTilTran β8-1
http://no722.cocolog-nifty.com/blog/files/eTilTran08b1.zip
[注]急遽、機能追加しただけなのでblog記事はありません。

>>160
自動領域補正に
「ページ全体にテクスト領域をズーム設定して合わせる」
という機能をつけましたので、これで我慢してもらえますか？
(なお、有効領域モードでしか効きません)

eTilTranはあくまで対話的に補正を行うツールなので、
プレビューされて後から変更が可能な操作が前提です。
だから、出力時に自動配置する機能をつけるつもりはありません。
申し訳ないですが、これはポリシーなので変えられません。

>>157
右垂直線基準と左垂直線基準を追加しました。
ちなみに、なぜこの機能が必要なのですか？

>>150
自動領域補正に
「トリミング範囲自動設定」をつけました。
お試しください。

>>161
わがまま聞いていただいて恐縮です
今晩早速試してみますね！

>>161
素早い対応どうもです。

一応必要な理由は、スキャンする時とトリミング時の効率化のために
偶数ページを逆さにスキャンしているので、のど方向が常に一定になるんです。

自動領域補正の
「ページ全体にテクスト領域をズーム設定して合わせる」を
早速試してみました
かなり使いやすくなって便利です

それからいくつか少し気になった点を
傾き補正が行われない画像ですと上手くズームが働くようですが
補正が行われると補正した傾き分の領域は余白となってしまい
画面全体にズームできないようです

多分処理順の問題だと思いますが
全ての処理が終わったあとにズームする事は可能ですか？

それからこれも同じ原因かもしれませんが
上下の余白がかなり出てしまうようです

いずれも画面上では青いラインで示される認識領域は
非常に上手く働いているようです

主にモバイル用途向けに変換をしたいので
コマ以外の余白を出来る限りカットして
大きく拡大した状態で読みたいのです
もし可能であればよろしくお願いします

>>161
乙です。

>>164
>それからこれも同じ原因かもしれませんが
>上下の余白がかなり出てしまうようです

トリミング領域の設定が、有効領域に対して縦長過ぎるからじゃね？
意図的に横長に指定してみたけど、ちゃんと縦ギリギリで出てたけどなぁ。
基準テクスト領域ギリギリにトリミング領域入力しては？

>>164

eTilTran β8-2
http://no722.cocolog-nifty.com/blog/files/eTilTran08b2.zip

傾き補正してからテクスト領域を取得するようにしました。
これで試してみてください。

ちなみになぜ今まで補正してなかったかというと、高速化のためです。
漫画を細かくトリミングするニーズがなかったので、
正確な位置は不要と判断していました。
なお、「漫画テクスト領域高精度化」を「なし」で元に戻せます。

>>163
>偶数ページを逆さにスキャンしているので、のど方向が常に一定になるんです。

なるほど、理解できました。
なにぶん意味も無く機能をつけるのは、心理的障壁になるもので、
理由があるとありがたいです。

サイズ自動検出を失敗した画像で気付いたけど
絵が大幅に切れてしまうため、絵が切れないようにトリム位置ずらしても、
最初のX=0、Y=0時に表示された部分以外は白になってしまう

適当にいじっていたら
解決しましたごめんなさい

>>166
早速の対応感謝します｡
本日は色々多忙だったため試用は明日になりますが
報告させていただきます｡

それから今までこう言うニーズが無かったとの事ですがそれが驚きでした
あまり出先用に圧縮して持ち運んで読もうという人は居ないんですかねえ

722様
MeTilTran V0.5β
大変ありがたく使わせていただいております。
電車の中でzero3esで小説を読むのに重宝しております。

文庫の小説で挿絵の直前のページが二枚に分かれるようなとき、その二枚目が
何回やっても出力されない気がします。
その前後だけ取り出してやってみてもなります。
なにか設定がまずいのかもしれませんが・・・。
設定は高速解析のりサイズ高さを1600有効高さを1000補間法をHighQualityBicubic
検出領域の左右を15、ノンブル再配置なし、出力画像サイズ720,960くらいしかいじっておりません。
サンプルが必要なら
ttp://www.katsakuri.sakura.ne.jp/src/up26712.bin.html
の
up26712.bin
をダウンロードして .binを ..zipに変えて解凍してみてください。

忙しいとは思いますが、お時間あるときにでも確認よろしくお願いします。
すばらしいソフトだと思うので今後もがんばってください。

>>170
MeTilTran V0.5β-1
http://no722.cocolog-nifty.com/blog/files/MeTilTran05b1.zip

サンプルありがとうございます。
再現するにはサンプルの存在は大変ありがたいです。
とりあえず修正してみましたので試してみてください。

あと、挿絵が見つかると強制改ページしていたんですが、
すぐ改ページせず、１ページ完成したあと挿絵を配置する機能をつけてみました。
また、挿絵が２回連続する場合、連結して見開き配置してみました。

それと、画像出力するさい、最終画像サイズだけを指定すれば、
文字を縮小して配置する機能もつけてみました。
(実際には拡大縮小のサイズ計算を自動でやっています。)
再配置ダイアログの「文字サイズ」にパーセンテージ指定してください。
文字が大きすぎるとき、使ってみてください。

色々途中で、まだバグ取りが済んでませんが、
ちょっと手が空かないので、ファイルだけ置いておきます。

>>169
よく読むコミックのタイプにもよるんではないでしょうか。
コマから頻繁にはみ出すコミックだと、トリミングが厳しいですからね。

>>171
さっそく対応ありがとうございます！
試してみましたが問題なさそうです。

見開き配置も出来ました。
ありがとうございました。

MeTilTranで、「」の多いページだと認識がかなり狂うのは俺だけかな……
ノンブルは認識しないし、行は縦書きじゃなくて挿絵の複合で認識？するみたい
それともこれは設定でどうにかなるのでしょうか

>>171
MeTilTranで、手動で大まかな傾きを入力してから改めてその傾き画像で
再認識させる様な事が可能になると助かるのですが、ご検討頂けませんでしょうか。

自分の場合、一回メチルにて補正後全ページ目視確認・補正しており、
認識された大半の画像はトリミング含めほぼそのままで済むんですが、
傾きが大きく認識不可なものはイチから修正の必要があり、
少しでも省力化できないものか、と思いまして．．．。

>>173
その認識しないページの元画像データを見ないと、
なんともいえません。
認識に大きく関わるものは、ダイアログに出てるので、
他の設定は、変更してもそんなに変わらないはずです。

>>174
ページ編集画面で角度入力して「再認識」ではダメですか？
なぜか「再認識」を２回押さないと効かないバグがありますが、
入力した角度で再認識できるはずです？

傾き補正には、補正限界の設定がありますので、
大きく傾いていて補正が蹴られる場合は、
「傾き補正上限」をもう少し大きくするのも手です。
初期値は2度以上の角度を補正しないよう設定してあります。

>>175
申し訳ありません、eTilTranの方でした．．．
まさにその「再認識」がeTilTranにもあれば、と思いまして．．．

補正値についても、少しパラメータを振って再トライしてみます。
ありがとうございます。

>>176
名前まで間違ってるし．．．orz　スレ汚しすみません。

RSSに対応した電子書籍ビューアって無いかな？
外出前にニュース記事などをコピー、外出先でじっくり読む。

>>178
　現状だとそういう目的にはスマートフォンが適してるかと

>>178
ちょっと違うかもしれんけど、取得しといたのを出先で読むっていう目的なら iLiad で OK
PC側の MobiReader で RSS 巡回+ダウンロードしといたのを iLiad とシンクロしてからお出かけ。

>>176
eTilTran β8-3
http://no722.cocolog-nifty.com/blog/files/eTilTran08b3.zip

設定角度で再認識する機能ですが、
ファイルリストで右クリックしたときの「補正角度を計測角度にコピー」
または「一括補正」画面の「再認識」で出来るようにしてみました。
これで試してみてもらえますか？


所で、一つ忘れていましたが、エチルもメチルも小説スキャンするとき、
「傾き検出文字数」が20文字にデフォルト設定されていて、
それ以下の行を、角度検出の計算から除外します。

よってラノベのように短いセリフ主体のページだと、
傾き検出されず＝挿絵として認識されることになります。
では文字数を減らせば良いか？ということそうではなく、
今度は角度計算の精度が悪くなり、角度を誤検出します。

角度検出ミスが気になる人は調整してみてください。
ただ、私としては手動調整することをお勧めします。
このあたりは好みの問題ですね。

>>175
確かに元画像がないとダメですね……失礼いたしました。
読み込み時の状態と、その元画像をアップしました。ご参考にしていただければ幸いです。
この手のソフトの扱いは慣れてないので、見当違いのことを言っていたら申しわけありません。

パス：MeTilTran
ttp://www.uploda.net/cgi/uploader4/index.php?dlpas_id=0000017163.zip

>>182
貴重なサンプルありがとうございます。
1枚目の画像については、ルビが多すぎるため、行の取り出しに失敗して、
角度が正確に取れていないようです。

行の取り出しやルビの切り出しは、正確に角度補正が行われないと、
行同士が融合して、大きな文字で構成された行があると判断され、
１行分がルビに、１行分が本文にと変化してしまいます。
赤い四角が本文で、マゼンタの四角がルビなのがプレビューで見て取れます。

こういうページはまれに発生して、本ツールではフルオートでは対処できないため、
手動で修正できるようになっています。
ひとまず、ページ編集の補正角を-0.4度前後に設定して「再認識」してください。


２枚目のページが誤認識する原因は、ちょっとわかりません。
デフォルトで試したところ、こちらでは発生しませんでした。

もし発生するとなら、ノンブルが左右上に設定されていないか、
「グループ融合割合 文字幅」に大きな値が設定されるかだと思います。
一度、MeTilTranを展開したフォルダにある、default.xmlを捨てて、
デフォルト値に戻したほうが良いかもしれません。
「グループ融合割合 文字幅」は1.00にしたほうが良いでしょう。


1ページ目の角度補正については、フルオートで出来ることが望ましいのですが、
今のところ、良い解決策を思いつけません。
今後の課題として心に留めさせていただきますね。

ただ本来、ノンブル+章タイトルから章タイトルが分離されるはずが、
この例では効いていないので、何かバグがありそうな予感です。
見つけしだい修正したいです。

ところでメニューの編集から一括設定を選ぶと無反応なんですがうちだけ？
アイコンでは動作しているのであんまり支障はないのですが

いまいち最近のVerでのトリミングがうまくいかない･･･
出来上がり画像の中で表示領域が制限されるのはどの辺の設定が影響するのでしょうか
設定がよくわからないのでトリミングは旧バージョンでやってたり(笑

>>184
メニューから外れているのは今気づきました。
後で直しておきます。

トリミングの件は、具体的に書いていただけると有難いです。
私としてはうまく動作しているつもりで作っているので、
うまく行かない状況がよく分かりません。
表示領域が制限とは、どういう意味でしょうか？

>>181
遅くなりましたが、再認識対応ありがとうございました。
スキャン→角度不明画像を粗修正→一括再認識・領域設定→目視補正
の流れで使っていこうと思っています。

また、角度不明の画像を内部演算プレビューしてみた所、
複数行が1行に認識されているものがあり、
初期仮定文字幅を実際の値よりやや低め(計測17に対し10)に
してみた所、検出精度が上がったようです。
もしご参考になる様でしたら、初期文字幅を変えた
検出結果などうｐします。

>>186
情報ありがとうございます。
今手持ちのデータでやったみましたが、
今ひとつデータが合ってないのか、結果は微妙でしたが、
情報として参考になります。
よろしかったら参考データをぜひ拝見したいです。

ちなみに、この角度計測については、
半分は意味をわかって作ってはいるのですが、
もう半分は、なぜほぼ正確に角度取得できているのかは、
あまり理解していなかったりします。
半分勘で実装したら、うまく取得できているので、
「まあいいか」と、そのままなのが実情だったり(笑
案外、そんなもんです。
だから研究して、もう少し分析してみると、
もっと精度を上げられるかも知れませんね。

ただ、あまり複雑なことをすると、それだけプレスキャンに時間を要するので、
現状の「だめだったら人間が判断して手動で」というのは
バランス的には合っていると思っています。

>>183
確認ありがとうございました。
角度補正を手動でやってみたら結構まともになってきました。
ページ数が多いのでかなり修正が必要になって疲れますがorz
色々勉強になりましたありがとうございます。

>>187
ttp://www.dotup.org/uploda/www.dotup.org1366.zip.html
受p：scan

初期仮定文字幅を10/50に切り替えた際の設定と検出結果と、
何枚か抜粋した画像のセットです。
うｐ用に原寸、圧縮率高めでjpeg化してありますが元はbmp。
ご参考になれば幸いです。

>>188
もう少し角度計測が正確になればいいんですが、
時間見つけて研究したいと思います。
MTilのほうは角度の補正が数値入力で面倒なので、
まずは手動補正が楽になるような仕組みをつけたいと思います。

>>189
参考データありがとうございます。
欲しいと思っていた二段組データなので、そっちの意味でもありがたいです。
参考にさせていただきますね。

>>190
てか、角度補正の仕組みってどういうのでやってるの？
「てにをは」を抽出して各ページごとに角度差分を測ってー　とかじゃだめかな
素人考えで申し訳ないのだが

すいません。馬鹿の戯言でした
無視してください

>>192
誰だよお前ｗ

>>193
俺だよお前

ttp://rd.vector.co.jp/magazine/softnews/070807/n0708071.html?ref=top
いつのまにバージョンアップしてたんですね

>>772氏
eTilTranで画像全体モード・トリミング有りで補正する際に、
テクスト領域が実際より小さく切り出される為
画像の一部（右・下）が欠けてしまいます。
前にβ0.8使っていた画像では特に問題無い様だったので、
β0.8で試してみたり設定ファイル消してみても変わらず．．．

>>772氏
ttp://www.dotup.org/uploda/www.dotup.org1304.jpg.html
このよう用紙サイズの認識を失敗したものを
eTilTranで画像全体モード・トリミングありで補正する際に
トリム枠を大体用紙の位置に持ってきても
画像が欠けてしまいます。
P：jisui

>>197
この用紙サイズの認識ってのは、ScanSnapの用紙サイズ認識のことでしょうか？
あと、eTilにはトリム枠を移動する機能がありませんので、(画像の中心に設定されます)
ちょっと意味がわかりません。

すべてのページがサイズ認識失敗してるのでしょうか？
それとも一部だけでしょうか？　一部だけなら、そのページだけ手動でやるべきです。

トリムサイズは設定されているものとします。
次に、有効領域(コミックなのでテクスト領域のみ)が認識されているものとします。

まず、テクスト領域を補正したいので、有効領域モードにします。
(有効領域モードにしないとオンにならない機能があります)
自動領域補正ダイアログを開いて、以下のように設定します。
・基準領域をセンタリングする
(基準領域は有効領域の平均です。この領域をトリム領域の中心に移動)
・基準テクスト領域に、テクスト領域のみに合わせる
(テクスト領域をトリム枠に直接移動することはできません。
基準領域がセンタリング、すなわちトリム枠に移動している前提で、
テクスト領域を基準領域に移動します)

これで多分、このサンプルのページについては問題ないと思います。
ただ、他のページのテクスト領域の認識によっては問題出るかも知れません。

>>196
確認しました。調査して修正します。
ただ、個人的な話で申し訳ないですが、夏期休暇中につき、
手元にソースがありませんので、修正は来週くらいになります。

>>198
了解です。お手間かけます。
こういう時、プロジェクトファイルに補正データ残しておけるのは
目視補正だけ進めておいて後でバッチ処理かけられるので助かります。

>>198
用紙サイズの認識は、ScanSnapの用紙サイズ認識のことです。
認識失敗は一部のページだけなので、
トリムサイズを他のページに合わせ
画面右側のX座標に数値を入力したり矢印で調整してます。
全体モード＝傾け済み画像全体をテクスト領域画像として切り出しなら
それでOKだと思ったのですが、
>>196と関係あるのか？
そういえば右側が欠けたのしかみてない
下側については気付いていないかも

右や下が欠ける
>>196を見ると
全体モード＝傾け済み画像全体をテクスト領域画像として切り出しが
傾け済み画像の左上のX=0、Y=0の位置からトリムサイズの大きさで切り出に
なっている気がします。

すみません、
下のほうは忘れてください
勘で書いたやつを消し忘れました。

>>196-197
eTilTran β8-4
http://no722.cocolog-nifty.com/blog/files/eTilTran08b4.zip

遅くなってすみません。右側が欠けるバグを修正しました。
これで確認していただけますか。
良さそうでしたら公開バージョンにしたいと思います。

eTilTranの領域設定で幅を奇数にすると、出力したとき右端に黒枠ができませんか？

>>202
乙です。

欠けは大丈夫なようです。

MeTilTranでPDF出力できますが、
携帯のビューワーで見てる人いますか？
10M程度のファイルを閲覧できて
ここまでよんだみたいなしおりをはさめたり
するんでしょうか？

>202
722氏乙です。
エチルで現在表示(選択)されている画像だけを一発変換出力する機能が欲しいです。
実際に変換して他のツールで画像を確認するのが、設定を詰めるには一番簡単です。
ページ指定でもできないわけではないですが、１枚だけ試験的に変換するような
使い方には不向きだと思います。

>>202
対応ありがとうございます。修正確認しました。

>>205
2M程度のPDFでも開けないこともある。
開けても1分くらい待つ。
>ここまでよんだみたいなしおりをはさめたり
そもそも閲覧中のPDFにしおりを挟むなんてできるのか？

>>206

eTilTran V0.9β
http://no722.cocolog-nifty.com/blog/2007/08/etiltran_v09_521d.html

選択ページを変換出力する機能を追加して、公開バージョンとしました。
こんな感じで良いですか？
画像形式は前回出力した形式を覚えているので、その形式で出力します。

>209
>722氏、いただきました。
1ページ変換ありがとうございます。
やっぱり現物で確認できるのがいちばん分かりやすいです。

V0.9β手動の角度調整がおかしいような

同じく。
小説の最後のほうにある広告ページなんかを
手動修正しても元に（？）戻ってしまう。

MeTilTran V0.5β-1を使わせていただいております。
挿絵、カラーページをJPG、C24bit。本文をPNG、C4Bitで
出力設定にしているのですが、
出力画像形式を複合で再配置すると表紙などのカラーページが
PNGの白黒になってしまいます。
カラーページ検出サンプルを多く取ってみたり少なく取ってみたりしたのですが
変化ありません。
カラーページ11P、白黒挿絵2P、以降本文です。
V0.5ではJPGで普通にカラー出力できていましたし、
カラーページだけ別なツールを使えばいいのでしょうが･･･。
私の設定に問題あるのかもしれませんので、
お気づきになったことがありましたら、お教えください。

すばらしいソフトを作ってくださってとても感謝しております。

>>213
確認しました。
複合のときカラー出力するにはカラーページであることを認識する必要があり、
スキャン時にはカラー情報を保持しているのですが、
再配置のときには、そのカラー情報が消えてしまうようです。
修正しますので、少し時間を下さい。

>>212
もう少し詳しい情報をお願いできますか？
こちらでは、その現象を確認できませんので、
おそらく特定の状況で出る現象のようです。
現象を再現できないと、原因の特定は難しいです。

>>214
>>211-212とは別の者ですが、当方でも類似の現象起きました。
一旦ホイール回転にて目視補正し補正角度と計測角度が違う状態で、
一旦別のページに移ってから再表示したりそのページのみ変換した後などに、
元の状態とずれてプレビューされる感じです。0.8β4でも同様の現象確認しました。
100％再現されるかまでは確認してませんが、ご参考になれば.．．．

>>215
情報ありがとうございます。
確認してみますね。

>>213
MeTilTran V0.6β
http://no722.cocolog-nifty.com/blog/2007/08/metiltran_v06_326e.html

カラーページが出力されない問題を修正しました。
再配置のとき挿絵がカラーかどうか判定するようになっています。
お試しください。

>211-212,215
確認しました。
画像全体モードのときの角度計算が間違っているようです。
修正しますので、しばしお待ちください。

eTilTranでトリミング幅を奇数にすると出力した物の右側が1ピクセル黒くなる

>>217
複合時にカラーで出力されるようになりました。
ありがとうございました。

>>211-212,215

eTilTran V0.10β
http://no722.cocolog-nifty.com/blog/2007/09/etiltran_v010_27a5.html

遅くなってすみません。
角度補正の件、修正してみました。
ご確認ください。

>>218
残念ながら、現象を確認できませんでした。

>>220
ありがとうございます。
さっそく試させてもらいます。

>>218
俺もこの現象でたわ

>>220
角度補正いまのところ正常です。
とりあえずご報告まで。

>>223
報告ありがとうございます。うまくいって何よりです。

>>222
うちでは、どうしても再現できないので、再現方法を教えて欲しいです。
単純にトリミング幅を奇数にするだけでは発生できませんでした。

今ためしに、940×1400のファイルを939×1400にトリミングして出力したら黒線でた

>>220
乙です。
1冊処理してみて特に不具合は無い様です。感謝です。

右端線の件、当方では、切りの良い値でトリミングかけてる為か
今の所特に支障はありませんが、
少し確認した分では、500×500の画像を画像全体モード、補正0°で
処理した際に、幅499→線有り、幅497→線無しでした。
奇数の時全て、という訳では無さそうですね。

>>225
eTilTranの設定ファイルと元画像と変換後画像をどこかのアップローダーに
アップすれば、722氏の方で確認しやすいんじゃないかな。
できれば、よろしくお願い。

設定はノーマルだし元画像は真っ白

色々試してみました
確実に簡単に黒線を再現する方法
・Ver：eTilTran V0.10β
・デフォルト設定
・用意するデータ：999 x 1400の画像（BITMAPでもPNGで可で真っ白でOK）
->変換時に出力設定 >色深度を「8bit」に変更して変換実行すれば確実に現象再現します
（右端に黒ラインなので一枚で見ると判りにくいかも）

その他注意点
・同データでも24bitなら現象出ず
・画像サイズ 1000ｘ1400、1000ｘ1399の場合には現象出ず

>>225-229
黒線の再現テスト感謝します。
8bit出力で横サイズが奇数のときに黒線が出るんですね。
これだけ条件が判れば修正できます。

調べたところ、8bit時のピクセル転送に計算バグがありました。
修正版を作成しましたので、確認していただけますか。

eTilTran V0.10-1β
http://no722.cocolog-nifty.com/blog/files/eTilTran10b1.zip

おつかれさま
当方では問題なく出力できるようです

こちらでも同条件での現象発生はありませんでした。
早速の修正、お疲れさまですー

>>230
早速の対応乙です。
皆さん同様、修正確認しました。

64bit版がほしい

T-Time パブリッシャーズ・キットって持ってる人いますか？
販売終了してるみたいですけど。
ttzを自分でつくるって無理なんでしょうか。

>>235
ttp://pbc.cool.ne.jp/necom/index.html
ここに頼んでみれば？

>>235
ttz(他にも拡張子あったきがするけど)は基本的にHTMLの独自拡張みたいなものだから、仕様さえ分かってればかけるよ。

>235
T-Time2.3までは作成できた。5.0以後は作成できない。
今でも落とせるけど、今更レジストするのは無理だろう。レジストしないと作成できない。
あと、作成するのにタグのヘルプがないと難しいと思う。

>>236
>>237
>>238
回答どうもありがとうございます。

Internet Archiveで T-Time：タグ入門　とか
楽しい電子ルリユール教室　とかよんで
青空文庫のテキストに挿絵や背景いれたりしてみたんですけど、
(挿絵っていってもそれっぽい画像をよそからもってきただけなんですが)
テキストと画像をひとまとめにできればすっきりするなと思って。
ttzの形式にするのは
人にたのむ以外ないということでしょうか？

http://www.voyager.co.jp/d_order/d_order_ttime.html
一応、5.5でもアップデータ登録?(パブリッシャーキットのシリアルが必要)すればttzは作成できます。
もう販売はしてないみたいなので、正規の方法では自分みたいにパブリッシャーキットをもってる人しか使えなさそうです。
新たなシステムを作成中とかいてありますが、それを待つか、シリアルをどっかで手に入れるしか方法はなさそうです。

>>240
回答ありがとうございます。そうですか。
青空文庫形式 をZIPに圧縮すればArisuViewerで読めるんですけど、
それだと T-TIME形式 が読めないんですよね。
T-TIMEは文字サイズとか色とかいじれておもしろいんですけど
T-TIMEのタグに対応しててZIP書庫の中も読めるビューワ作れないですかね？
それが携帯電話にいれられるとすごいいいんだけど…
SOFTBANKのシャープ機使ってるんですが、
.zbf .zbk .zbs しか読まなくて使いづらいんですよね。
Javaの勉強しなきゃいけないのかな。
長いみちのりだ…

>241
すまん重大なミス。5.5でもレジストすればttz書き出し可能だわ。
管理者でインストールして、レジストしたんだが、ユーザ単位でしかレジストが有効にならない
仕様だった。実際に使うユーザでも再度レジストキー入れれば書き出せる。

>242
そうですか。でも、
.ttzってあまり使われていないんですね。
.ttzから他形式に変換するソフトがないですし、
.pdbと.bookを変換するならT-Breakでできるのに、
どうしてこれで.ttzと.pdbが変換できないんでしょう？
.ttzと.bookって中身そんなに違いないんですよね？

>243
中を見てみたけど、メモリ上ではT-Time用のhtmlそのまんま。
指定範囲のテキストを保存して、余計な部分を削除するとhtmlが手に入る。

>244
いろいろありがとうございます。
とりあえずhtmlの勉強をしてみようと思います。

通勤時にPDAで小説を読む目的でeTilTran V0.10βを小説の傾き補正とトリミングとリサイズに使わせて頂いています。

すいませんがトリミングの使い方でよくわからない処があります。
トリミングを文書ページだけ、もしくはあるページ範囲だけに掛けたいのですが、どうすればよいのでしょう？　
本の表紙や押し絵（カラー漫画や漫画ページ）はトリミングしたくないのです。

トリミングはツール→自動領域補正でトリミング範囲自動設定にCHECKを入れて補正ボタンで実行している
のですが、適用範囲を種別で選んだりページ範囲で設定してみたんですが、ページ全体がトリミングされて
出力されてしまいます。

もしかしてトリミングの設定方法を根本的に勘違いしていたらすいません。

>>246
ご利用ありがとうございます。
トリミングについてですが、
この機能は特定のページだけのオン／オフは設定できません。
ファイル全体にかかります。

ツールの自動設定は、指定範囲からトリミングサイズを計算して、
ファイル全体に適用します。
指定しない範囲については、単純に領域計算の元としないだけなのです。

よって、出力時にページの種類を設定できることを利用して、
トリミングをオンにして出力後、
トリミングをオフにしてから、挿絵だけを選択して出力してください。

リサイズせずに傾き補正、ノンブル位置合わせをして出力することは出来ないでしょうか？

MeTilTranを使わせていただいています。

最初に読み込ませてすぐプロジェクト保存した
プロジェクトファイルのサイズと
角度補正や改行、ノンプル範囲修正など
を繰り返して保存したときのサイズと比べると
後者が１００倍くらい大きくなってしまいます。

そしてそのプロジェクトファイルを開くと
メモリの使いすぎのためものすごくｐｃの
動作が遅くなってしまいます。

ちなみにwin2000でメモリ1G

>>722さん
ありがとうございます。バッチリできました！
全然的はずれの事を試していたので、的確なアドバイス大変助かりました。

すいませんが、もう一つトリミングで教えて欲しい事があります。

ノンブルを入れると文字が小さくなってしまう場合、ノンブルを無視して
基準テキスト領域だけが入るようにトリミング掛けたくなる事があります。
（PDAの画面サイズの都合で出来るだけ文字を大きく取りたい時）
こんな時は、どういう設定をすれば良いのでしょう？

領域設定→トリミング設定→トリミングありで幅と高さに適当な数値を入れて
試しているのですが、Y方向の位置がうまく合わなくて困っています。

自動領域補正で「基準テキスト領域に、テキスト領域のみを合わせる」を
選択すれば良いのかとも思いましたが、自分の環境ではグレーアウトしていて
選べないように見えます。

重いーMetil重いー。
うちのおんぼろPCじゃもうむりぽ（つД`）。
前の黄色のやつ使ってる。こっちのが設定ラク。

>250
トリミングで全体のサイズを決定。この状態だと本文位置はセンタリングされるので下のほうが
切れることもあります。
次に全体補正のYをマイナス値にして、本文全体を上にずらすことで、ノンブルを外に追い出して
しまうのではだめかなあ。
エチルでの話です。メチルはよう知らん。

>>250
「基準テキスト領域に、テキスト領域のみを合わせる」が出ないのは
画面全体モードになっているからです。でも、それはこの場合関係ありません。
トリミングを自動ではなく手動でサイズ設定して、
基準テキスト領域をトリミング内に手動移動してから、
(画面全体モードならクリックして移動できるはずです)
トリミングなしで自動補正すると良いです。
もしくは>>252さんの方法でも可です。
ちなみにトリミング領域は画像の中心に設定されるようになっています。

>>248
出力時にリサイズなしに設定ではダメでしょうか？

>>249
すみません。MeTilTranのファイル入出力が遅いのとか、
何か変なバグがあるのとか直そうと思ってるのですが、
なかなか難しくて困ってます。

>>251
重いのは重々承知してるのですが、
MeTilはこの方向からもう戻れませんので、旧バージョンをお使いください。

再配置せずに補正のみにできますか？
metilより前のタイプを使った方がいいですか？

>254
>121

>>255
すみませんでした
ありがとうございます

>>250
>基準テキスト領域だけが入るようにトリミング掛けたくなる事があります
私はWS004SHを使ってますが、文字だけを大きく取りたいときは
自動領域補正
トリミング範囲自動設定(余白0)
ページ全体にテクスト領域をズームして合わせる(余白0)

領域設定
トリミング設定→トリミングあり　（幅高さは自動で入る気がする）
領域処理モード→有効領域

ちなみに変換時にノンブル削除にチェックをいれても入れなくても変わらない気がする
他の設定も影響すると思いますが、私の環境ではテキストのみが入るようになっています
この設定だと上下左右の余白を少し多めに取られますが、
挿絵などもすべて表示はされてます

すばらしいツールを作ってくださった722さんに感謝

>>252　>>722さん　>>257さん
アドバイス感謝です。出張が急遽入ってネットに繋げませんでした。
今、ビジネスホテルにて古NotePCで色々試させてもらっています。

画面全体モードなるものに気づいてなかったでしたが、おかげさまで
領域設定で有効領域を設定すると、
「基準テキスト領域に、テキスト領域のみを合わせる」や「ノンブル削除」
が選べることがわかりました。
「ノンブル削除」にCHECKいれるとノンブルが削除できる事がわかりましたが
その分画面が大きくとれる訳では無かったのですね。

257さんのお勧めどおりに設定すると、表紙がちょっと小さくなってしまいますが
押し絵も本文も同時にトリミングでき、2回出力しなくて済むので非常に楽ちんで
助かります。

722さんとアドバイス頂いた方々に感謝

eTilTran0.1βを使わせていただいております。
こちらのソフトで画像の一部だけを切り抜いて保存する方法は無いでしょうか？
ADFスキャナで取り込んだ書類の傾き補正はこちらのソフトで出来るのですが、
周辺部分の不要領域を削除するには拡大、縮小して領域を移動して取り込まないように
しなければならず、例えば拡大縮小せずに上が５０ピクセル、左が２０ピクセル、
右が３０ピクセルだけいらない、などということができません。

このようなことができるのでしたらどなた様か教えてください。

すいません。ちょっと上の過去ログ読んだらトリミング設定でできました。

MeTilTran初めて使ってみたけど、良くできてるねー。
WM機で画面ちっちゃいのを使ってる人には福音ですな。
2.8型画面で小説読めるのは感動モノです。

使ってみて最初は誤認識とかあったけど、補正角あたりをグリグリ弄ると大概何とかなりますね

ＷＭの単語が出てきたところで便乗したいんですが、Viewer何使われてますか？

ページ送りが使いやすい物がなかなか見つからなくって…

マンガミーヤ

ﾐｰﾔの一択

ミーヤってWM6のどのバージョンでも使えるの？

MeTilTran V0.7β
http://no722.cocolog-nifty.com/blog/2007/10/metiltran_v07_3489.html

縦書テキスト画像化実験β2
http://no722.cocolog-nifty.com/blog/2007/10/2_fbd3.html

iPod touchを買ったのでビューアとして使ってみたところ、
右綴じの送り方向が逆になって違和感あるので、
「連番反転」でファイル名を逆にする機能を追加しました。
最終ファイルから読み進めれば、送り方向が合います。
お試しください。

ちなみに、touchの小説ビューアとしての使いごこちは結構よいです。
手でめくる感じが紙っぽくて感動的でした。
ただ、画像転送のときに、何か妙な変換しているらしく
転送が低速なのがネックですね。あと電池の持ちが・・・。

>>249
MeTilTranで保存されたプロジェクトを読み込むと、
内容が内部的に２倍になっていたバグを修正しました。
他にもバグが残っていたり、読み込み速度に問題あるので、
もうちょっと時間掛かりそうですが、ひとまずどうぞ。
(編集を繰り返したときの肥大はまだチェックしてなくて、すみません)

いつもありがとうございます。

思ったのですが、マニュアルというか使い方とか初心者向けのところってないですか？
いろいろと便利そうですが、何をどうつかっていいのかがわからず・・orz

縦書テキスト画像化実験！
これってスキャンしたのをテキスト化させてそれを画像化させれば読みやすい画像になって
それをノートパソコンで読める時代が来るのかな？（期待

部屋にある参考書から小説まで全部電子書籍化して部屋のスペースを広くしたいですし・・

>>268
ここの>>43あたりの場所は？
スレの方は流れてるけど、wikiのトップに現行スレへのリンクがあるぞ

>>268
>スキャンしたのをテキスト化
この工程でかなりの誤字が出る。
それを画像化してもかえって読みづらい画像になる。
誤字を直すには置換マクロを駆使し、底本と見比べて
一字一字打ち直す地道な作業が必須。
慣れないうちは文庫一冊10時間かけても終わらんでしょ。

>>268
その時代では、普通に電子書籍が売られていると思います。

電子書籍ってそんなに普及するかな？
普通の人はマンガとか雑誌は本で読みたいんじゃない？
パソコン立ち上げないと読めないなんて不便すぎる。
小説なら携帯とかPDAで読めるけどねぇ。

雑誌や、マンガは電子書籍向けに書かれるようになると思うよ。
4コママンガみたいに、コマ割が均一なマンガが流行るかもしれないね。
それよりも心配なのは、書籍のような有料のメディアのシェアが小さくなって、レベルが下がるかもね。
あるいは値段が上がって、非常に限られた人しか買わなくなって、書籍全体が専門書のようになる。
結果世界的に、知的水準が下がる。特にIT先進国。更に知的エリートと一般の人との格差が拡大、一般人は野蛮人化する。
迷信がはびこり、金儲け主義の宗教が蔓延する。

>>272
zero3くらいの液晶なら、漫画も楽に読めるよ
データ化された書籍の何が便利って、何十冊持っていってもminiSDに入れるだけだからかさばらない
いまや、長時間移動とか長期間出張の時には欠かせない

>>272
調べてみると判るんだけど
以外にかなり読まれているよ
本は売れてないんだが電子書籍は驚くほど伸びている
主に漫画らしいけどｗ
でも携帯電話が主なプレーヤーになってるから
読み辛いったら仕方が無いし画面も小さい

まあそんな状況だから
携帯電子書籍専用の漫画が出てきてもおかしくないね
同人誌とかそう言う形態で売れば
かなり売れるんじゃないだろうかｗｗｗ

>>266
722さん、いつもMeTilTranを便利に使わして貰ってます。
何十冊か使ってみてあれば良いなーと思った機能なのですが、

�@行編集等を行った時に、編集を元に戻す機能

　例えば行の幅調整をして思ったように調整出来なかった場合、
再認識でページごと読み直さなければいけない時がよくあります。

それと同じ関連なのですが、行の幅調整をマウスで細かく調整出来ればすごく便利だと思います。

�A画像（挿絵）の縦横回転

　これはまあ、見開きなど通常ページと違う縦横比の挿絵なんかがある場合にあると便利かなと。

素人の思いつきで希望を述べてしまって恐縮ですが、今後とも応援しております。

eTilTran V0.11β
http://no722.cocolog-nifty.com/blog/2007/10/etiltran_v011_8997.html

携帯端末で読めるように余白を削るのに使うニーズが結構あるみたいなので、
ノンブルを自動トリムから除外する機能と、連番ファイル出力を追加してみました。

あと間違って最新ソースを消してしまって内容が一旦β9時点まで戻り、
なんとか思い出してβ10-1相当に復旧したのは秘密です。

>>276
(1)の機能はちょっと難しいので検討させてください。
(2)の機能はChainPDFにもある機能なので、次の機会に実装したいと思います。

いただきました。
多謝。

>eTilTran V0.11β
いただきました。
前バージョンより余白が減って少し大きめに本文や挿絵を表示できるようになりました。
大感謝です。

MeTilTran07bを使わせてもらってます。

で、「暫定一文字行グループ削除」が上手く働かない様なのですが。
設定で「あり」を選択して、メイン画面では「無効」になっていますが、
再配置プレビュー画面、再配置出力で縦書きで出力されてしまいます。

無効領域を選択して、ノンブルなり挿絵なりを選択して、再び無効を選択すると
無効状態で出力されてくれます。

暫定とあるので、まだ上手く機能しないのでしょうか？

他のファイルで試してみました。
2段組の小説は無効領域が機能してました。

上記の小説はノンブルが中央下、章タイトルが奇数ページ左上。

しかし、考えたら今やってるのは携帯に取り込む用を作ってた。
だったら画面が小さいんだから、ノンブル無しの方が良いのか？って思った。

>>280
「暫定一文字行グループ削除」のロジックは以下のようになってます。

(a)ノンブル左右下または中央下の場合

対象グループの領域の下部座標をAとします。
画像全体の高さをHとし、そのHの上から10%の座標をBとします。
このとき、AがBより小さい、つまり上にあるとき、削除対象と考え、
さらにグループ内の行のあたりの最大文字数が1以下のとき、
章タイトルとして削除します。

(b)ノンブル左右上の場合

対象グループの領域の上部座標をAとします。
画像全体の高さをHとし、そのHの上から90%の座標をBとします。
このとき、AがBより大きい、つまり下にあるとき、削除対象と考え、
さらにグループ内の行のあたりの最大文字数が1以下のとき、
章タイトルとして削除します。

このことから、章タイトルの位置がぎりぎり10%もしく90%の位置から
外れている、または章タイトルが縦２文字あった、といった場合に
削除対象となりません。
あとは問題となるページの元データがないと詳しいことは分かりません。

ちなみに、この10%や90%が決めうちになっている＆他に良いロジックが思いつかない、
ということから「暫定」となっています。

頭がぴーまん〜。

取り敢えず、サンプル上げてみますね。

斧　he 39540
パス　sage

ttp://www11.axfc.net/uploader/20/so/He_39540.zip.html

722さん、いMeTilTranを便利に使わして貰ってます。
T-timeが更新されて思い出したんですが、再配置した連番画像のページ数に応じた位置にマークを付加するようになれば、一目でどのへんまで読んだかが分かるし、ページ数を付加するのと違って
あまり気にならず、目立たないから便利かなと思います。
分かりづらいので、T-timeの画像をおいときます。
DLkey :text
ttp://gonzo.dip.jp/~gonzo/cgi-bin/uploader2/upload.cgi?mode=dl&file=4846

MeTilTranで
一画面の行数、一行の文字数
を指定できるようになればいいなぁ。

722さんいつもありがとうございます。
PSPの小説用に愛用しております。

質問です。
MeTilTranで挿絵を指定した場合、絵では無い頁、横書きのタイトル頁とか
目次の頁とかで、頁全体を範囲指定していても、文字の最小範囲でトリミング
されて出力さるのを回避する方法はあるでしょうか？

携帯で読むにも体裁を整えたく思うこともあります。

表紙カバー等は選択範囲で任意のサイズに出来ますが、文字ベースの頁が
上手くトリミング出来ないです。
なんぞ設定で回避出来ないのかな？

MeTilTran V0.8β
http://no722.cocolog-nifty.com/blog/2007/10/metiltran_v08_fc76.html

>>280
サンプルありがとうございます。
特定の条件で誤って再配置されることがあるようです。
修正しましたので試してみてください。

>>284
面白い機能なので追加してみました。
ただ、それだけだとパクリぽいので、ちょっとアレンジしてみました。

>>285
再配置プレビューで字数計算をする機能を追加してみました。
ただ、ページ毎に微妙に文字サイズが変化するため、
完全に行列が維持されるわけではありません。

>>286
設定の[再配置時領域最小化]を[なし]で余白削除しなくなります。

頂きました。ありがとう御座います。

ここ最近、MeTilTranで携帯に取り込み始めたので、自分にとっての最適値が
まだまだつかめてません。
新機能と合わせて使わせて試行錯誤させてもらいます。

各自手持ち端末の最適値が決まったら、一覧化したいね。
集合知(Web2.0)って凄いよな。

>289
T-Timeの画像書き出し機能は機種別になってるから、それで青空文庫のを
書き出してみるかな。それを見れば余白なんかはある程度わかると思うけど。

>>287
いつも乙です。

>>287
採用ありがとうございます。

>>290
機種別っても、本当に携帯の機種別ではないからな。
各機種にデフォ値が用意されてるわけでもないから、
基本的に好みな値な感じ。
ttp://www.voyager.co.jp/T-Time/devlist.shtml

再配置するときできるだけミスが減るように設定する方法の
方が興味あるかも。(ものによって違うから難しい)

ソニー PRS-505 デジタルブックリーダー レビュー＆ギャラリー
ttp://japanese.engadget.com/2007/10/15/prs-505/

800x600のeInk良さげだな〜。

日本語周りがどうなってるか気になる

Eee PC 4G

【199ドル〜】ASUS Eee PC Part2【701/1001】
ttp://pc11.2ch.net/test/read.cgi/notepc/1191927537/126

>>293
http://journal.mycom.co.jp/news/2007/10/03/001/index.html
こっちの記事だとjpgもいけるみたいだけど、
やっぱりカラーはだめなのかな？
それでも$300で6インチ800x600なら買ってもいいかなぁと思う。

友達がアメリカ旅行に行ったので、PRS-505買ってきてもらいました。凄くタイムリーですねw
正直な感想を言うと「もし日本語版が出るなら買い」、現状は非常に惜しいです。

■画像ファイル
SDやMS、内部メモリに画像ファイルを転送すると自動的に認識されて、Picture項目に登録されます。
但し、フォルダを認識せず、すべて同一階層に表示されます。
階層はページ表示されますが、ページ送りがかなり遅いです。

画像はグレースケールに変換され、自動的にリサイズされます。
自動回転はしませんので、縦横比を切り替えておく必要があります。
残像が出にくい表示方法のため、一旦変なモザイクが表示されますが、速度は4秒くらいで、かなり綺麗です。

■添付の電子ブックデータ
英語に少し挿絵がついたeBookが内蔵メモリに入っています。
表示は快適でフォントも綺麗です。ページ送りは2秒かからないくらいです。
少し残像がありますが、気にならない程度です。

■フォント埋め込みPDF
日本語フォントが入っていないため、テキストやファイル名が化けますが、フォント埋め込みPDFが表示されることを確認しました。
ページ切り替えは2秒くらい。綴じ方向は無視されます。

■画像埋め込みPDF
2MBくらいのPDFなら、ページ切り替えは2秒程度と問題ありませんが、20MBくらいのPDFになると、ページ切り替えに6秒くらいかかりました。
また、ときどきハングアップするくらいの時間がかかったり、実際にハングアップしたりしました。
ページ数の問題というより、単純にファイルサイズが大きくなると問題が出るようでした。
なお、PDF作成には私の縦書きテキスト変換を使用しました。これが問題の可能性もあります。

表示されるページの見た目は、画像ファイルの表示と違って、少し残像があり、リサイズのジャギが出ます。
電子ペーパーは600x800ということですが、実際の表示可能サイズは上下左右とも少し小さいようです。下部に情報エリアありますし。
正確な表示サイズが判れば、ジャギらないPDFが作れるのではないかと思います。
あと文書名はPDFのTitleタグから抽出しているらしいけど、UTFエンコードは認識しないようです。
なので私のツールで変換したPDFでは文書名が化けてしまいます。

正直小説だけなら、よっぽど革新的な機能でもないかぎり、
[es]+MeTilTran+マンガミーヤで十分だなあ。

>>298
そうなんだよねぇ。

しかしやっぱMetilとetilのWikiみたいの
ちょっとほしいなー。

>>299
そっかなぁ。
素材も出力も使用者によってまちまちだし
設定は試行錯誤するしかないんじゃない？

翻訳物なんかによくある訳者の注釈（訳注：〜2行〜）のところの設定が難しいな。
ここでよく行がくずれる。　＞MeTil

>297(722氏)
いつもエチルにお世話になってます。

エチル／メチルに関して、
ノンブルの手動設定ってのは無理でしょうか。
範囲指定して、この範囲にあるのはノンブルであると決めて、本文領域からは
強制的に除外してしまう。
ノンブルは実質使い道ほとんどないし、それと同じ並びにある柱部分は無効と
して無視されてます。それならノンブル領域を手動設定してしまうほうが簡単で
確実な気がします。
（ところで、メチルよりもエチルのほうがノンブル認識率かなり高いのでは？）

メチル／縦書テキスト画像化実験に関して
出力画像サイズから決めるのではなくて、1行文字数と1ページ行数と余白を
現在の文字サイズで配置して、その結果を必要な画像サイズに縮小するという
方法はできないでしょうか。
（微妙に縦横比変わったりする可能性はありますが）
これだと元画像の大きさに(ほぼ)関係なく配置できるので、ユーザ側でも
設定情報を出しやすいし、設定ファイル化して取り込めるような方式にして
もらえば、ユーザ側でも協力できる余地が大きくなると思います。
各機種での文字数とか行数に関しては、最初のうちはT-Timeの画像書き出し
機能で具体例を出せば大体わかるでしょう。蓄積が進めば比較的容易に
設定可能になると思います。

>>297
ぉぉ。希少なレポ乙。

フォント埋込PDFがいけるのか。
綴じ方向を無視って……日本語縦書きを見開きにすると
ページ順が横書き相当になるということかな。

自前でシステムに日本語フォントが突っ込めたりすると面白いのに。

サイズの大きな画像PDFで問題が出るってのはちと辛いね。
スキャン資料をPCからそのまま持ってきて使うのは苦しそう。

透明テキスト付PDFとかどうなるんだろう。
システムが日本語対応してないんじゃ、日本語の検索文字列指定自体が困難かな。

>>297
レポ乙です。
フォルダを認識しないのは使いづらいかな。
作者名-作品名-巻数みたいなフォルダ分けをしていると。

http://select.itmedia.co.jp/shop/goods/goods.aspx?goods=13792
Linux搭載4.3インチ、30GBのPMP
履歴やしおりがついてるビューワーがあればほしいかも

>>301
訳注は無理です。はなから諦めています。
私の蔵書は海外SFが主なので、自分でも困って、
MeTilで手修正可能にしたんです。

>>302
ノンブルの範囲指定により変換精度をあげる手法は、検討したいと思います。
MeTilとeTilのエンジンは基本同じですが、
後から双方違う要望が出て、少しずつ変わってしまっています。
いつか統合しなければと思いつつ、そのままです。

ページの行数字数を指定するのは、かなり難しいです。
再配置のエンジンを作り直しになるし、
そもそも一文字ずつのサイズが微妙に異なるため、
行数字数を固定するのは無理があると思います。
現状、初心者にはとっつき悪いかも知れませんが、
そもそも元となる画像ページのサイズがまちまち、
スキャンする本もまちまちなので、これといった設定を呈示するのは
少し無理があるのではないかと思うのですが。

>>303-304
えと、綴じ方向についてですが、少し語弊があったかも知れません。
SonyReaderの右側と左下に、ページ移動用のボタンがあって、
右矢印が書いてあるけど、機能としては「次ページ」固定になります。
もう一つ、右下に上下左右のカーソルキーがあるのですが、
この左右キーでは、綴じ方向にあったページ移動が再現されています。

ReaderをUSBで接続すると内蔵メモリとMS、SDがドライブとしてマウントされます。
その中にシステム関係のフォルダは全くないので、
残念ながら改造して日本語フォント入れるということは無理っぽいようです。

透明テキストPDFの表示は問題ないというか、
そもそもSonyReaderに検索機能がないっぽい。

ちなみにPDFは、画像埋め込みとして、Jpeg以外に
無圧縮ビットマップ、ZIP圧縮ビットマップ(注：ZIPファイルではなく圧縮方式としてのZIP)
ランレングス、CCITT FAXの方式が選べます。
私のツールはJpeg埋め込みですが、ScanSnapなどはCCITT FAXです。

で、とりあえず、無圧縮ビットマップ、ZIP圧縮ビットマップを試してみたところ、
残念ながらサポートしていないようでページが表示されませんでした。
ただし、ScanSnapでスキャンしたPDFは問題なく表示できました。

そこで縦書きテキスト変換のPDF出力に、テキスト部のみZIP圧縮出力を対応させたところ
前述のように表示がされず、代わってCCITT FAXで出力するようにしようとしたのですが、
CCITT FAXのフォーマットに関する解説が見つからず、そこで挫折しているところです。
ランレングスもフォーマットがわかっていません。が、多分、サポートしてない気がします。
しかたないので、数10ページ毎にPDFを分割出力しようかな、と思っています。

CCITTはITU-Tに名称変更されたみたい。

日本ITU協会
http://www.ituaj.jp/

G3、G4FAXの規格はITU-T T.4 及び T.6に記載されているようなんだけど
仕様はどこにあるだよ〜って感じだ。

本家ITUの勧告フリーダウンロード案内
http://www.itu.int/newsroom/press_releases/2007/21.html

このあたりで面倒臭くなりますたｗ

☆

非常に惜しい

もうこの言葉をこの手の商品に対して何年も聞き続けてる気がするわ

縦書テキスト画像化実験β3
http://no722.cocolog-nifty.com/blog/2007/10/3_3890.html

>>307で、ZIP圧縮ビットマップがダメだと書きましたが、
あれから色々やってみたところ、単に変換に失敗していただけで、
実際にはZIP圧縮ビットマップが表示できることがわかりました。
ごめんなさい。

AdobeReaderでは少し壊れていても問題なく表示できるのですが、
SonyReaderでは少しでも欠損があるとダメみたいです。

というわけで、PDF出力にZIP圧縮ビットマップを追加してみました。
可逆圧縮なのでブロックノイズが乗らず綺麗ですね。
まだ、2bit,4bitのディザの実装がまだですが、
あまり暇がないので、今回はこんなところで。

>>308
資料ありがとうございます。
調べたところ、以下のところでG4 FAXのフォーマットを見つけました。
まあZIPが可能だったので、今回は見送りですけども。
http://netghost.narod.ru/gff/graphics/book/ch09_05.htm

>>311
乙です。

昨日PRS-505が届いたので使わせていただきました。


300KB程の文庫一冊分の青空文庫TEXTを600x800の300ページ程のPDFに変換しました。

データの形式は

1.DrawTate03bでPDF出力したもの(ZLIB 8bit) 17.5MB

2.DrawTate03bでBMP出力したもの(1bit)をG3Fax形式のPDFに変換したもの 3.5MB

3.DrawTate03bでBMP出力したもの(24bit)をprinter for librie(グレイスケール)でlrfに変換したもの 10MB

で試しました。


このデータをPRS-505に表示させたところすべての形式で表示されました。

ただし1と2のPDFの場合、ページ送りのボタンを押してから描画が始まるまで25秒かかっています。

722さんのお話ですともう少し早いようなのですが
変換の設定やページ送りにかかる時間を教えていただけないでしょうか？


参考までに3で試したlrf形式のデータだと2秒でした。

画像変換のツールには印刷出力を経由したものもかなりありますので
722さんの一連のツールの出力形式に印刷を追加していただけないでしょうか？
Printer for LIBRIeの場合はプリンタに送るドキュメント名がタイトルになります。

よろしくお願いします。

TTVブックリーダーって2.00から画像が使えるようになっているらし。
青空準拠じゃないけど、定型のヘッダ入れてタグ書き換えれば挿絵表示もできるそうな。
表示も速いし、ラノベとか読むには良さそう。

>>313
縦書テキスト画像化実験β4
http://no722.cocolog-nifty.com/blog/2007/10/4_567a.html

PDFを分割出力する機能を追加しました。
これでPDFも実用的に読めると思いますのでお試しください。

印刷出力については、縦書テキストのプログラムに実装するのは、
現在のところ難しいです。詳しいことは省きますが、
中身の構造が、印刷の構造とは逆になってるので合わないんです。
MeTilTranもちょっと難しいです。

ただし、eTilTranとChainPDFに印刷機能を実装するのは楽なので、
まずはそちらで実装したいと思います。


ページ送りの速度については、ちょっと詳しく調べる時間がとれません。
DrawTateで584x750のPDF、ZLIB 4bit ディザなし、という環境です。
ただ、SonyReader側で若干先読みをしているようなので、
ページを送るタイミングによっても違っていそうです。

printer for librieで作ったLRFの表示が早いのはいいですね。
私はLibRieを持っていなくてダウンロードできないのでうやらましいです。

ところで、一つお願いしたいのですが、
printer for librieで変換したデータをサンプルとしてアップロードして頂けませんか。
可能かどうか判りませんが、LRF変換出力が作れるか試してみたいです。

ちなみにSonyReader付属のLRFは少しフォーマットが違うぽいので、
海外サイトのLRF解説のものとは少し違うようでした。
また画像埋め込みの実装が知りたいので、テキスト主体なのは
ちょっと参考にしずらいというのもあります。

722氏、毎度乙です。

>>315
Printer for LIBRIe で作成したデータについてですが、検証には大きめのデーターでないと意味がないので
以下のツールで自作していただけないでしょうか。

【LBRIe】電子書籍専用端末総合4【ワーズギア】
5 名前：名無しさん＠３周年[sage] 投稿日：2007/01/17(水) 21:14:14 ID:qI9ajL3b
Printer for LIBRIe
ttp://www.aii.co.jp/contents/smojsdmk/LIBRIE/software_0001/Setup.exe
Q. Printer for LIBRIeを単体(LIBRIe for Windowsなし)でインストールするにはどうすれば良いですか?
A. MobileRead Forumの下記ポストを参考にされてください。
ttp://www.mobileread.com/forums/showpost.php?p=40191&postcount=13

Printer for LIBRIeは２年前にSONYでダウンロードしたものと同じものでした。

通常の方法でインストールするとlrfファイルはPCに接続されたLIBRIeかメモリースティックにしか保存できませんが
上記の方法でインストールすると印刷ごとにファイル名を尋ねてくるようになります。
このままでは不便ですので仮想プリンタポートRedMon - Redirection Port Monitor
を作成してファイルを保存しています。

Printer for LIBRIeで出力されるデータにはlrfファイルが持つ
bookid author author-reading title title-reading description date publisher thumbnailfileの情報のうち
title :印刷時のドキュメント名
description :作成日時
date :作成日時
しか設定されていません。
このままだと著者別一覧が使えませんが
EditLRFMeta というツールで情報の表示・変更ができるので
title・author・ファイル名をドキュメント名の形で渡してtitleに設定し出力させ
titleとauthorを更新してファイル名で保存させようと思っています。

Printer for LIBRIe以外の

MyClip for LIBRIe ttp://www.aii.co.jp/contents/smojsdmk/LIBRIE/software_0001/MyClipForLIBRIeInst.msi
NewsPaper for LIBRIe ttp://www.aii.co.jp/contents/smojsdmk/LIBRIE/software_0001/NewsPaperForLIBRIeInst.msi
Toolbar for LIBRIe ttp://www.aii.co.jp/contents/smojsdmk/LIBRIE/software_0001/ToobarForLIBRIeInst.msi

で作成したデータはフォントが内包されていないため日本語部分が表示されません。

>>317-318
丁寧な紹介ありがとうございます。
さっそくインストールして試してみました。
http://www.sven.de/librie/Librie/BBeB の情報を参考にしてバイナリ覗いてみましたが、
Printer for LIBRIeは600x800の4bit画像埋め込みになっているようですね。
ちょっと情報の説明が抜けていて、ヘッダとサムネイルの部分だけしか判りませんでしたが、
もうちょっと調べてみたいと思います。
まだ、文書情報の部分の構造と、文書データのタグ構造が今ひとつわかってません。
というか重要な部分全部ですけども。

722氏へ

PDFをLRFにするツールがあります。
RasterFarian 2.5.1 ttp://www.mobileread.com/forums/showthread.php?t=10402

PDFをラスタライズ、ImageMagickで加工、LRSを作ってLRF、というもので
インストールしてバッチを追いかけていただけば色々わかるかも。

LRF形式のヘッダ情報をダンプするツールを作ってみました。
ダンプするだけなので特に何かに使えるツールではないですけども。

LRF Dump v0.01
http://no722.cocolog-nifty.com/blog/files/LrfDump01b.zip

これによると、文書情報はXMLをZLIBで埋め込んでいるだったので、
文書情報の書き換えツールくらいなら簡単に作れそうな感じですね。
サムネイルの差し替えもできそうです。

あとは実際の本文のタグ情報ですが、
>>320さんに紹介していただいたツールを調査してみたいと思います。

LrfDump v0.02
http://no722.cocolog-nifty.com/blog/2007/11/lrfdump_v002.html

LRFファイルの内容をダンプするツールの続きです。
オブジェクトのタグ情報もダンプできるようになりました。
また埋め込み画像を抽出したりすることも可能です。

ついでに文書情報を書き換えて出力する機能もつけてみました。
ただ、ちょっと不安定で読めないファイルになるかも知れません。
(本ツールでは読めないけど、LIBRIe LE for Windowsでは表示できる
といった謎な場合もあるようです)
お試して頂けるとありがたいです。

テキストやフォントなど、よくわからないタグが色々あるのですが、
とりあえず画像だけのLRFを作れる材料は揃った感じです。

それにしてもLIBRIeもSonyReaderも埋め込み画像は全て600x800だけど、
実際に表示可能なエリアは600x766程度なので、
これって必ずリサイズジャギが発生しますよね。
変なの。

パソでフロッピーに移してワープロで読めるように出来ますか？

>>323
それは単にいうと商用の専用ソフトが必要
でもPC初心者がほいほい手を出せる物では無くて、
PCとワープロのハード・OS＆ソフト面両方をかなり熟知してる知識と経験が必要

2chのこんな所で環境も晒さず、ｽﾚﾁ気味なage質問してるおまえは一つ一つ手作業で入力してなさいってこった

<参考>
リッチテキスト・コンバータ - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%83%E3%83%81%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%83%BB%E3%82%B3%E3%83%B3%E3%83%90%E3%83%BC%E3%82%BF
リッチテキスト・コンバータ19
http://www.antenna.co.jp/rtc/
IBM形式フロッピーディスク - Wikipedia
http://ja.wikipedia.org/wiki/IBM%E5%BD%A2%E5%BC%8F%E3%83%95%E3%83%AD%E3%83%83%E3%83%94%E3%83%BC%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF#.E5.A4.96.E9.83.A8.E3.83.AA.E3.83.B3.E3.82.AF
コンバートスター１７　製品の概要
http://www.systemport.co.jp/product/cs17/gaiyo.html
この他にもあるから自分で調べな

>>324どれも「ワープロのフロッピをパソで読む」タイプじゃないか
パソからワープロならもっと簡単にできないの？

プレステ1専用ゲームをプレステ2で読む
たったこれだけでもこんなに手間と金がかかるのに
プレステ2専用ゲームをプレステ1で読み込むのは簡単にできそう(ﾟ∀ﾟ)なんて考えてるわけ？ﾔﾊﾞｸﾈ？

>>325
氏ね。

DS用マジコンを買ったついでに、勝手アプリのDS用漫画ビューワを試してみました。
思ったよりも秀逸な出来だったので、紹介。
使ったソフトはフリーで配布されている「Comic Book DS 3.0」です。

以下のような特徴があります。
・二画面をつかったデュアルディスプレイ表示に対応
・縦横回転可能（二画面表示状態でもできる）
・左ボタンを押すだけでページ右上>>左上>>右下>>左下>>次ページと言った、
　漫画向けの順送りスクロール機能が搭載
・結構高速
・日本語ファイル名が使えないが、zip圧縮ファイルを放り込むだけで独自パック形式に
　変換するコンバーター付属。リサイズも同時に行える

例えばDSを横見開きに持って、左ボタンを押してるだけで本を一冊読めたりもします。
PDAでもミーヤCEくらいでしか搭載されてない順送り機能ですが、やっぱあると快適ですね。
二画面見開きも新鮮。
コンバートもzip放り込むだけなので簡単です。

以下続く

弱点としては、DSそのものの解像度がかなり低いため、縦1400ドットの画像などを
持ってくるとかなり巨大に見えてしまう点。幾らスクロールしてもページの端にたどり着きませんｗ
コンバート段階でリサイズは可能ですが、どうしても細かい文字は読みにくいですね。
二画面でかかっても、4インチVGAのPDAにも勝てません。
また画面間の隙間が大きいのも、漫画を読む際にはちょっとつらい・・・

ソフト的には、かなり完成されています。
動作もかなり軽快で、サムネイル表示も高速。速度面でのストレスはありません。
DSの「二画面に分かれている低解像度液晶」に我慢できるなら、実用的に漫画を読むことも
不可能ではないです。

ちなみおまけ機能として、DSから直接ネット上の漫画データを拾いにいける機能も搭載されています。
多分作者さんのサーバーだと思うんですが、アメコミのサンプルデータのようなものが、
60冊ほどあって微妙に楽しいｗ
ただ、データが重いのか、すげー転送に時間かかりますけど。

DSとマジコンを持っている方は、試してみると面白いです。
ネタっぽいですが、それでもQVGAクラスのPDAで読むよりかは見やすいかと。
電子書籍の雰囲気を手軽に味わうにはちょうどいいと思いますよ。
以上。長文失礼。

>>315

　縦書テキスト画像化実験β4でZLIB4bitで100ページで分割したデータを作成したPDFを
PRS-505で試してみました。

　ページ送りの速度がlrfファイルとほとんど同じでした。

　300ページのPDFは相変わらずの遅さでしたが、この違いはページ数かデータサイズか
のどららなんでしょうかね。分割するページ数の最大値が100ページなのはページ数が
関係しているためでしょうか？

　１冊のデータを分割して出力するのはあまり好ましくないのですが
データの汎用性で言えばPDFの方が圧倒的に上なので選択に悩みます。


　あと変換していて気がついたのですが、データ中に
※［＃挿絵画像 08_179］
という行があると落ちます。

>>322
LrfDump v0.02での書き換えですが数件行いましたが今のところエラーは出でいません。

>>330
テストさんくすです。

PDFの速度低下ですが、
野口雨情の詩集をPDF化したところ、
116ページ、1.2MBのデータになったのですが、
PRS-505で問題なく読めたことから、
データサイズが起因だと思っています。

ちなみにページ分割の最大が100なのは、とくに意味は無いです。
何か最大値に要望ありましたら、後で直しておきますよ？

※［＃挿絵画像 08_179］が落ちる件ですが、
このツールは青空に準拠してるので、
［＃挿絵(xxxx.jpg)入る］といった場合の「＃挿絵」を見つけ
続いて括弧からファイル名を抽出するのですが、
この場合は括弧が無いので落ちてしまいます。

しかし、その形式の方言は初めて見ますね。
拡張子も無いようですし、この形式は普及しているものなのでしょうか？

LrfDump v0.03
http://no722.cocolog-nifty.com/blog/2007/11/lrfdump_v003.html

縦書テキスト画像化実験β5
http://no722.cocolog-nifty.com/blog/2007/11/5_b54c.html

待望のLRF出力機能が付きました。
これで300Pで45MBとかのファイルでも、ブックを開くとき少し待たされるようですが、ページめくりは快適です。

>>332

　縦書テキスト画像化実験β5で300ページ程度のlrfを試してみました。

　まったく問題なく表示できました。ページ送りも快適です。

　今まで複数のプログラムで処理を重ねて作成していたlrfファイルが
一つのプログラムでできるようになりずいぶん楽になりました。

　表示サイズも584x750が指定できるためルビなどの小さく細い文字もきれいに表示されます。

　sony readerは文章をファイル名ではなくタイトルと著者名で管理しているので作成時に
指定できるのも便利です。

　テキストからlrfを作成できるこのプログラムのほかに、画像からデータを作成するChainPDFを
lrfに対応していただければ、日本語フォントを持たないsony readerを日本で使用する敷居が
ずいぶん下がると思います。

　後、PRS-505での確認は取れましたがLibrieだとどうなるのでしょうか？
　以前は所持していたのですが現在手元になく確認できません。

>>331

　PDFでのページ送りについてですがデータのサイズよりはページ数に依存するようです。

　１ページにピリオド一つというデータを作成して試してみました。
　400ページで350k Byteほどのサイズです。
　ページ送りのキーを押してから再描画が始まるまでの時間を計りました。

　100ページ：1秒
　120ページ：2秒
　140ページ：3秒
　200ページ：4秒
　220ページ：6秒
　240ページ：8秒
　260ページ：9秒
　300ページ：10秒

　個人的には２秒が限度だと思います。


　※［＃挿絵画像 08_179］については校正ミスのデータでした。

ChainLRF v0.01
http://no722.cocolog-nifty.com/blog/2007/11/chainlrf_v001.html

連番画像ファイルからLRFを作成するツールです。
良かったらお試しください。

>>333
うまく動作しているようで何よりです。
自分でも、ようやくSonyReaderが使い物になって安堵しているところです。

LIBRIeについては私も実機をもってないので何とも言えませんが、
LIBRIe LE for Windowsで確認したところで問題ないようでした。
目次機能も動作しています。

>>334
なるほど、その結果からいうとページ数に依存していそうですね。
いったい中で何がおこっているのかかなり謎です。

＃挿絵画像の件、了解しました。

>>335
はじめまして。一世代前のPRS-500持ちですが、偶然こちらにたどり着き
ChainLRF試用してみましたところ、問題なく表示可能なLRFが生成されました。

当方のPRS-500はUniversal Flasher(ttp://www.mobileread.com/forums/showthread.php?t=10900)
を使って内臓フォントとして日本語フォントを適用させているのですが、
その環境でも日本語で設定したタイトル・著者共に問題なく表示されています。

これまでMobileReadなどで開発されているソフトウェアも一通り試しましたが、
大抵日本語に弱く、結局comiclrf.pl(ttp://www.mobileread.com/forums/showthread.php?t=11123)
を日本語の書名を通せるようにしたり、画像分割や余白除去、ディザリングなどできるよう
色々アドホックに改造して小説用に使ってました。

そんな中、日本語はおろか、画像サイズ、色深度やディザリング法まで設定できて
実質LIBRIeからPRS-505までの全機種対応されているものを
こんなにも短期間で作成されたというのには驚きました。
(もし気が向いたらページ分割と余白除去を実装してください。絶対使わせていただきます。)

以上長文失礼しました。


P.S.
一つバグを発見したようなので報告させていただきます。
出力ファイルをドライブのルート(C:\など)に設定して出力すると一度目は成功するのですが
二度目からはこんな感じで例外エラーが発生します:

************** 例外テキスト **************
System.InvalidOperationException: ファイル C:\\a.lrf は有効なファイル名ではありません。

あとChainLRF.txtと出力完了時ダイアログの中で「LRF」となるべき所が
何箇所か「PDF」となっているようです。

>>335

ChainLRF v0.01　試してみました。
PRS-505での動作も問題ありませんでした。

PRS-505はモノクロ１６階調なので
試しに200ページほどのコミックを4bit階調で変換したところ

GIF 14M Byte
PNG 20M Byte
JPEH 25M Byte

となりました。
PNGやJPEGよりもGIFのほうがサイズが小さくなるのは意外でした。

>>336

PRS-500がUniversal Flasherによって内蔵フォントを日本語フォントに入れ替えられる
話はどこかで聞いたことがありましたが具体的にどのような手順で行うのでしょうか？

現在のUniversal FlasherがPRS-505に対応していないのは存じていますが
差しさわりがなければ教えていただけないでしょうか。

ChainLRF v0.02
http://no722.cocolog-nifty.com/blog/2007/11/chainlrf_v002.html

見開き分割と余白除去を追加してみました。
勢い任せに実装したので、変な動作をするかも知れませんが、人柱よろ。

>>336
その情報はとても興味深いですね。
書き換えツールを覗いてみましたが、
どうやら内部はLinuxで、メモカに記入したスクリプトで
フォント入れ替えや、メニュースタイルの変更ができるみたいですね。
これはPRS-505対応が待ち遠しいところです。
もしその情報を見にされましたら、ぜひ教えてください。

今のところフォーマットが不明ですが、
日本語が通るようであれば、テキスト情報の埋め込みを試したいところです。
(フォント埋め込みも可能なようですが、さすがに資料がありません)

>>335
PNGは8bit諧調と24bit諧調に特化して、内部的にはZIP圧縮なんですね。
あまりピクセル情報にこだわった圧縮ではないので、
それほど圧縮率は良くないのです。
とくに1bit〜4bitについてはGIFのほうがピクセル並びにこだわっているので、
こういう場合は圧縮率がよくなるんですね。

>>338
さっそくリクエストに応えていただきありがとうございます。
(開発速度速いですね〜)
ページ分割と余白除去機能を試さしていただきました。
今まではcomiclrf.pl内のImageMagickに与えるパラメーターをいろいろ
いじって試行錯誤してたんですが、GUIで設定できると結果がすぐにわかって
非常に便利ですね。感激しました。

あえて気になる所と言えばページ半分個と余白除去を組み合わせて設定した際
画面に表示される画像と出力される結果が違うことです。

(たとえば見開きの場合、画面に表示される画像は横長の画像をそのまま
余白除去したものになりますが、LRFに出力されるのは
ページを分割してから余白除去をしたものになりますよね)

一ユーザーの視点からすると画面表示と出力結果は
ある程度一致してくれた方がうれしいので、
縦横比チェック→半分個を選択した時点で
横長な画像は分割して表示されるようになれば
さらに便利かな、と思いました。

あとこれは好みによって激しく意見が分かれるところなんですが
Sony Readerのような狭い画面上でスキャンした文字画像を読む場合
アスペクト比を無視して拡大できた方が視認性が良くなります。

たとえばページの左右に20%ほどの余白が残っているとすると、
アスペクト比を無視して画像を引き伸ばし
文字を20%の横倍角フォントの様な状態で読むわけです。

ただこれにはデメリットも多くて、挿絵などまで引き延ばされたり
行数の少ないページですと文字が必要以上に引き伸ばされて
読めなくなります。
(自分のスクリプトの中では余白除去の発生しないページは
挿絵とみなしてアスペクト比の無視を行わないようにしていました。
また後者はスペクト比率の変更を200%まで、
などといった形で制限することで回避できます)

それからPRS-500やLIBRIeを見る限り、E-Inkは淡い表現が苦手なので
(新型のVisplexを搭載したPRS-505はどうですか?)
コントラストの正規化・強調もできた方が視認性が上がると思います。

以上要望というわけではありませんが、ご参考まで。

(C:\などに出力した際のバグは再現されませんでした。)

Universal FlasherのPRS-505対応については作者のIgorsk氏が作業中
ファームウェアの上書きに失敗して本体が起動不能が陥ってしまったようです。
(いわゆるBrickedってやつです)

PRS-500なら純正のファームウェア・アップデーターが配布されているため、
それを使って簡単に復旧できるのですが、何分新製品な505は
現在のところファームウェア・アップデートもされていないため
そこでしばらく開発がストップした状態になっています。

もしなにか続報があればこちらのスレッド
ttp://www.mobileread.com/forums/showthread.php?t=15834
で公開されると思います。

あとテキスト情報の埋め込みに関しては、
これは参考になるかどうかわかりませんが
次の三つは日本語を通せることを確認しています
(ソースコードも公開されています):

makelrf (C)
ttp://www.sven.de/librie_files/

flatLrf (Java)
ttp://monalipse.sourceforge.jp/tmp/lrf/

pylrs (Python)
ttp://www.mobileread.com/forums/showthread.php?t=9768

以上、長々とスレ汚し失礼しました。

>>337
一応自分なりにPRS-500への日本語フォント導入手順を一通りまとめてみたんですが、
上のレスよりもさらに長くなってしまいました(160行くらい)。
このスレに投下してもいいもんでしょうか?

(もしだめならデジモノ板の電子書籍端末総合スレの方にでも投下しようかと思います)

>>342
ちょうど電子書籍端末総合スレの方でもSony Readerの話題になっているのでそちらのほうがいいのではないでしょうか。
よろしくお願いします。

>>343
デジタルモノ板の電子書籍端末総合スレに投下しました。
(いろいろ推敲を重ねていたら結局倍くらいに膨れ上がっちゃいました)

コピペミスで順番を間違えて貼ってしまったので
分かりにくいですが次の順番でお読みください。

http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/332-334
http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/336
http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/335
http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/337-346

将来Universal Flasherが対応した暁にはPRS-505ユーザーの
参考にもなればうれしいです。

>>336

GJ

ChainLRF v0.03
http://no722.cocolog-nifty.com/blog/2007/11/chainlrf_v003.html

レベル調整などを追加してみました。

>>336
日本語化手順、いいですね。
BBeBへのテキスト埋め込みはmakelrfで理解できましたので、
日本語化できるようになったら、ぜひ対応したいと思います。

BBeBへのフォント埋め込み方法がわかれば、なお良かったんですが、
さすがにこれは詳しく公開されてませんね。

>>346
使わせていただきました。
素晴らしすぎです。
ゴミ除去の追加のおかげで余白除去の精度は上がりましたし、
しかも完成画像がプレビューできることで直観的に
それらのパラメーターをいじることができて実に便利です。

またリサイズ緩衝を入れていただいたおかげで
狭い画面をフル活用できるようになりましたし、
私もこつこつと自分のスクリプトを改良してきたつもりでしたが
これまで使ってきたものはすべて、
機能的にも完全に追い抜いて実装されてしまいました。

海外でもいろいろなツールが開発されていますが
こと画像のLRF形式への変換ということに関して言えば、
多分このソフトは現時点で一番高機能で使いやすいソフトだと思います。
(恥ずかしながらグレースケールの心理的物量なんて存在すら知りませんでした)

あえてこれ以上アイデア出しをさせてもらうとするなら、
日本の新書版書籍などに特有の二段組みをより視認性高く、
画面を活用して表示できるよう、
縦長の画像を横分割してから90度回転
(あるいは90度回転してから縦分割)
ということができればより便利になるんじゃないかと思います。

Readerには既にHorizontalモードというUI全体を右90度倒して使用し
縦幅を横幅として有効活用できるモードがありますが、
電子書籍端末総合スレでもちらっと書いたように
画像表示に関して言えばこのモードは所詮Verticalモードの画面を
2分割して拡大表示しているだけなんで、かなり汚い表示になります。
(その上、上画面と下画面のつなぎ目に重複があると
その部分をかすれたように表示する機能まで付いているので
あまり見目がよろしくありません)

二段組みだけじゃなくスキャンされた欧文文書や横組み文書なんかでも
実用性があると思います。
(JIS規格なんかはスキャン版が無料公開されてるんで
Reader上で見れたらうれしいかもと思ったり)

もちろんあくまで「アイデア」ですので、
なんかこんな提案あったな、とでも心の隅にでも留めておいていただけたらそれで十分です。
(結果的にこれまで提案したことはすべて実装されているんでちょっと心苦しいです)

makelrfについては情報が役立ったようでなによりです。

お礼というわけではありませんが、
PC-Sony Reader間でファイルをやりとりするにあたって
非常に便利なスクリプトを一つ紹介させていただきます。
(もうすでにご存じだったらすみません)

MobileRead WikiのSony Reader hackというページで配布されている
ttp://wiki.mobileread.com/wiki/Sony_Reader_hack

Ebook.pyというPythonスクリプトです。
ttp://wiki.mobileread.com/wiki/Image:Ebook_py_041.zip

これはUniversal Flasherの作者Igorsk氏の書かれたもので
eBook LibraryのDLLを利用しUSBを介してSony Reader内部にある
ファイル関連の操作をできるようになるというものです。
(ですので、たぶん同じeBook Libraryを使用しているPRS-505でも使用可能だと思います)

インストールは実に簡単でebook.pyをeBook Libraryのbinディレクトリ
(デフォルトではC:\Program Files\Sony\Reader\Data\bin)
におくだけです(使用する際はそこから実行します)。

詳しい操作方法は上のSony Reader hackに書いてありますが、
たとえば本体の内蔵メモリ上にあるLRFファイルにアクセスしたければ、

ebook.py ls /Data/media/books

とすれば

Sony Reader utility 0.41 (c) 2006 Igor Skochinsky
/Data/media/books/:
-rw-rw-r-- 2398193 Sep 01 2006 00:01 PRS500_OG.pdf

のような結果が返ってきます。

getすればファイルをPC上にコピーできますし、
catすれば標準出力に出力されます。

デフォルトでは安全のため読み込みしかできませんが
ebook.pyを修正してenableWriting = 1とすればReader側への
書き込みもできるようになります。

putでPC上のファイルをReader側に書き込め、
delでReader上のファイルを消去できます。

なおどちらのコマンドも注意が必要です。
不用意に閲覧中のファイルやシステムファイルなどを
消してしまうとReaderが落ちてしまいます。

なお、Readerに挿入されているメモリーカードへアクセスするためには
メモリースティックがa:、SDカードがb:というドライブレターを使う必要があります。
たとえばa.lrfというファイルをReaderのメモリースティック上にアップロードするには

ebook.py put a.lrf "a:/Sony Reader/books/a.lrf"

という風に指定する必要があります。

私はこんなかんじのバッチスクリプトを使って横着してます:

setlocal
set arg=%~f1%
pushd "C:\Program Files\Sony\Reader\Data\bin"
ebook.py put %arg% "a:/Sony Reader/books/%~nx1"
popd

eBook Libraryを使って転送するのとの違いは、

・起動が軽い
・コマンドライン上で操作できる
・通信中しか接続を占有しないため
　わざわざアプリケーションを終了しなくてもすぐにReaderを取り外せる
・同様に通信中しか「ケーブルの取り外し禁止」マークが出ないので
　転送の終了したことがReaderを見るだけでわかる

といったところでしょうか。便利です。

他にもum pinfo pwriteといった
リカバリーモードで使うコマンドが用意されていますが
残念ながらこれらは使ったことがありません。
以上、ご参考になれば幸いです。

再々度の長文レス失礼しました。

>>346
連続ですみません、先ほど久しぶりにlibprs500に付属する
html2lrfというコマンドを使ってみたら、
今まで見逃していたのですが、出力するLRFにフォントを埋め込む
コマンドラインオプションがありました。

--serif-family=SERIF_FAMILY
--sans-family=SANS_FAMILY
--mono-family=MONO_FAMILY

というのがそれで、たとえば

html2lrf --serif-family="C:\Windows\Fonts, Comic Sans MS" a.html

などという風にするとeBook Reader上でも実機上でも
英字をComic Sans MSで表示してくれるようになります。
ただ、いろいろ試しましたが日本語は通らないようです。

html2lrf --serif-family="C:\Windows\Fonts, IPAPGothic" a.html
html2lrf --serif-family="C:\Windows\Fonts, SimHei" a.html

などとしてみてもフォントデータ自体は埋め込まれているようなのですが
(出力されたLRFファイルのサイズが大幅に大きくなるので)
表示はされません(html2lrf自体は入力がUTF-8であれば問題なく日本語を取り扱えます)。

MSゴシック、MS明朝などに関しては"C:\Windows\Fonts, MS PGothic"などと指定しても
埋め込まれませんでしたので(ファイルサイズに変化なし)
TTFファイルに分割したもので試してみましたが、
やはりデータとしては埋め込まれているようでも表示はされませんでした。

また他にも制限があって、埋め込むフォントの指定がFont Family単位になっているため
たとえば前の例で言うと"C:\Windows\Fonts, Comic Sans MS"と指定するのはOKですが
そのボールド体を期待して"C:\Windows\Fonts, Comic Sans MS Bold"としても
埋め込んではくれません。
(Comic Sans MS BoldはFont FamilyではなくFont Nameであるためだと思います)

html2lrf自体はpylrsライブラリを利用しているんですが、

ttp://www.mobileread.com/forums/showthread.php?t=9768
ttp://www.mobileread.com/forums/showthread.php?t=10582

libprs500の方で既に取り込んでフォークしているとのことなので
そちらを参照された方が早いかもしれません。

ttps://libprs500.kovidgoyal.net/

以上、ご参考になれば幸いです。

>>336
情報ありがとうございます。
ツールはまだ使ってないのですが、
ttp://www.mobileread.com/forums/showthread.php?t=10582
に添付されているhtml2lrf.lrfのサンプルの中身を覗いてみたところ、
フォントは単純にTTFを圧縮して埋め込むだけで良いみたいですね。

このサンプルだとFontオブジェクトに以下のフォントが埋め込まれているようです。
lrfDumpで解凍して抜き出してみましたが、普通にTTFファイルでした。

F559:フォントファイル名:/usr/share/fonts/corefonts/andalemo.ttf
F55D:フォントフェイス名:Andale Mono

F559:フォントファイル名:/usr/share/fonts/corefonts/times.ttf
F55D:フォントフェイス名:Times New Roman

F559:フォントファイル名:/usr/share/fonts/corefonts/timesbd.ttf
F55D:フォントフェイス名:Times New Roman Bold

F559:フォントファイル名:/usr/share/fonts/corefonts/timesi.ttf
F55D:フォントフェイス名:Times New Roman Italic

F559:フォントファイル名:/usr/share/fonts/corefonts/timesbi.ttf
F55D:フォントフェイス名:Times New Roman Bold Italic

一つのファイルに対して付けられるフォントフェイスは一つだけみたいです。
あと、ファイル名に何やらunix系のディレクトリ名が付けられていますが、
これは必要なのか省略可能なのかは、ちょっと不明ですね。

一度埋め込めばTextAtrオブジェクトから、
F516:フォント名:Times New Roman
などとフォントフェイス名を指定するだけで良いようです。

>>355
なるほど、どうりでMSゴシックなどのTTCフォントが使えなかったわけです。

772さんがLrfDumpというツールを作られていたことは見逃しておりました。
(過去ログはいいかげんに流し読みしていたもので……すみません)
本体を入手されて間もないのようなのに次々とツールを作られている
その生産性の高さには毎度の事ながら驚かされます。

少し使わせていただきましたが変換ツールによっては生成されるLRFに
癖があるのがわかっておもしろいです。

スクリーンの幅や高さもツール毎にまちまちに設定されてますが、
Sony Readerにとってはどの数値が最適なんでしょうね。

せっかくの600x800スクリーンを画面下を占めるステータスバーなどのせいで
フルに使えないのはSony Readerの不満点の一つです。
(LIBRIeではフルに使えたのに!)

ステータスバーやLRF表示時の余白については百歩譲って認めたとしても
画面右端の黒枠が何のためにあるのかがわかりません。
(これらの画面構成についてはPRS-505もPRS-500と同じだと思います、たぶん)

722さん、いつもメチルたんを酷使させて頂いてます。

現在、読み込んで設定した情報をプロファイルで保存出来ますよね。
動画の変換ソフトとかのように、複数のプロファイルを連続で読み込んで一括変換とか出来ないでしょうか。
設定だけ何冊も済ませておいて、寝てる間に変換とか出来るとすごく便利だと思います。
出来ればで構いませんので、対応して頂ければ嬉しいです。

Amazonの電子ブックリーダーKindle公開、399ドル
ttp://japanese.engadget.com/2007/11/18/amazon-kindle-399/

SONYのヤツの対抗馬かな。
日本には入ってくるかねぇ。

>>358
ビズ速にスレが立ってたから「どっかなあ」と思ってやってきたらこの過疎ぶり。
絶望した！！

>>359
http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/

すごい、いつの間にかLRFまで変換できるようになっていたなんて。

ChainLRF 0.04
http://no722.cocolog-nifty.com/blog/2007/11/chainlrf_v004.html

自動カラーチェックと、タイトルの自動ローマ字変換を追加しました。

ローマ字変換はMS-IMEの逆変換を利用しているので、
他のIMEが入っていると動作しないかも知れません。

>>357
かなり簡易版で、MeTil本体をバッチモードで動作するみたいなので良ければ、
合間を見つけてやってみたいと思います。
あまり時間なくて、いつになるか分かりませんけども、
そんなに期待せずに待っていてください。
(あとMeTilにLRF出力つけたい)

>>362

　いつもご苦労様です。ChainLRF04b試してみました。

　リサイズ緩衝や余白除去のおかげで画面が有効に使えるようになり
見やすくなっています。

　私の環境はXP標準のIMEとNatural Inputがありますがローマ字変換も動作しています。

　ただ圧縮ファイルを入力ボタンで開いたときは問題ありませんが、Drag＆dropで開くと
ローマ字変換が動作せずヒストグラムボタンと詳細設定ボタンも無効状態のままで使用できません。

　作成したデータを読んでいて思ったのは、　PRS-5058の画面では細い字では見ずらいので
フォントでいうボールドにする方法がないでしょうか？

ChainLRF v0.05
http://no722.cocolog-nifty.com/blog/2007/11/chainlrf_v005.html

>>363
ドラッグ＆ドロップの件、修正しました。
今度は大丈夫だと思います。

ボールド化の機能を追加してみました。
同じページ画像を重ね合わせて減算合成して、黒の部分を強調します。
詳細設定のボールドレベルを増やすと、
指定した数だけ右にずらして重ねるので、線が太くなります。
お試しください。

ＷＢＳ

722さんへ、
MeTilTran08βで、
ツール→設定→読み込みをした場合と、
ツール→再配置プレビュー→ウイザード（ウィザードが正しい？）で、
出力幅や出力高さを変更した場合に、再配置プレビューが更新されなくなるようです。

暇な時にでも確認お願いします。

＞タイトルから括弧を除去する機能を追加しました。

えーと・・・

>>366
途中で設定データを読み込んだことなかったので気づきませんでしたが、
何か変なことになっているようですね。
ちょっと間が空いて、内容忘れかかってるので少し時間掛かるかも知れませんが、
修正したいと思います。

>>367
ご利用は自己責任でお願いしますね。
まあ、著者名をあらかじめ括弧付きでファイル名に併記しておけば、
自動抽出できるので便利だと思いますのでお使いください。
SonyReaderは著者別ソートが出来るので便利ですね。

ところで今気づいたんですが、「本のタイトル(1)」のように
括弧で本の巻番号を記入した場合は、一緒に消えてしまいますね。
これは次の機会に直しておきたいと思います。
(次にはChainPDFと統合したいと思っています)

ファイル名の付け方の規則に付いて、
何かありましたら教えていただけるとありがたいです。
他にスペース区切りや、アンダーバーもありそうですが、
これはさすがに、どっちがタイトルか著者か区別できそうにないですね。

722様いつもありがとうございます。

Librieユーザーですので、ChainLRF、縦書テキスト画像化
ともに使わせていただいております。
　特に、Printer for LibrieだとLibrie内で順番がバラバラに
なるところ、ファイル名から生成しているのか、順番がキチン
とそろってくれて重宝しております。
以上、お礼だけ失礼しました。

＃バッチモードの事ですが、ふとコンソールアプリケーションのように、ファイル指定、
＃確認ダイアログなしで動作するモードがあれば簡単便利ではと思いました。
＃ ChainLrf -b -i input.zip -o output.lrf -inf default.inf みたいな感じで。
＃もちろん、どのように実装する、しないは722様の事ですので、何かの参考になれば

ああなるほど。zipなどを管理するときに、ファイル名に
[夏目漱石]吾輩は猫である.zip
みたいにすればいいのか

ScanSnapでスキャンしてますが、Librieなどで読む時に
ファイル名が長くなりすぎるから、いつも作者名は消してました。
これで便利になるといいな。

本のタイトル(1) のパターンもあるけど、(上)(下)とかも考慮して頂けると嬉しいな

　本バラしてScanSnapにかけてスキャンしなくても、分厚い本を何冊も高速でスキャンできるいい方法って
ないかしらん？

>>371 ほいよ
ttp://www.kirtas-tech.com/

>>371
もいっちょ
ttp://japanese.engadget.com/2007/11/14/atiz-booksnap/

ハンディスキャナーってのが昔売ってたんだけど、
最近見ないね。
実用に耐えないのかな？

>>371
ビデオカメラで録画
ページ送りを一定の時間でできれば
あとはその時間ごとにサムネイルを保存するような感じで
静止画保存


早いぞ
文字が読めるほど綺麗に録画できるビデオカメラあるなら実用可能だろ
一定時間静止画切り出しは自動でできるソフトたくさんあるし

ビデオカメラ固定して、リモコンで静止画記録のカキコは見たことあるけど、
動画切り出ししても読めないだろ。
ハイビジョンカメラで、小説くらいの大きさなら可かも。

高解像度のデジカメを三脚に下向けて固定、下でペラペラめくりながらリモコンでシャッター。
くらいが安価で手軽かなあ・・・。
ガラス板とかでページ押さえたほうが綺麗なんだろうけどね。気にしだしたらキリないし・・・

普通にフラットベッドスキャナー使った方が良くね？

大きめの本だと、
「伏せて置いてスキャン→表にかえす→ページめくる→場所合わせながら伏せる」
みたいなのがちと面倒だったりする。特に本を伏せたり表にかえしたりするとこ。

>>377
　実はその用途で使うデジカメ明日買いに行く予定！キャノンのIXYか、パナソニックの
LUMIXにしようか迷ってる。
　
　両方とも広角は28mm〜で接写は申し分なさそう。IXYは液晶部分が大きいのと
画質がやや良さそうな点で勝るが、LUMIXの方はISOが6400と桁違いに高いから、
暗めの場所の撮影に有利な点で勝る。

　あと、画像の補正機能までついてる機種がカシオあたりから出てるけど、確か富士ゼロックスから
だったか補正専用のソフトが出てたんで、その機能にはこだわらんでもえーやろ。

　どっちがえーやろ、迷ってまう。

その用途ならデジ１だろ

コンデジは論外なんじゃねぇの

　いやいや、あんまり高くなっても困るし、本だけじゃなく、常に携帯して出先で書類とかの
パソコンへの取り込みも手軽にできるのんがええっちゅーことですわ。

論外だけど夢を見てる人には何言っても無駄だろう。
そもそもここビューアのスレでスキャンスレじゃないって。

>>380
接写より、なるべく遠くからズームで、みたいな感じのほうが歪まなくていいかも。

ChainLP V0.01
http://no722.cocolog-nifty.com/blog/2007/12/chainlp_v001.html

ChainLRFに、PDFと縦書きテキスト画像化の機能を取り込みました。

LIBLIeの場合、タイトルのローマ字変換よりも
タイトルの読みを平仮名にしたほうが良いので、そのオプションもつけました。
「タイトル(1)」の場合の巻数を保護する機能もつけました。(上中下も対応)

あと、コマンドラインからのバッチ起動に対応したつもりです。
お試しください。

>>385
リブリエの場合、ソートはカタカナではなかったでしょうか？
まえひらがなにして、「その他」に分類されてしまったので。

a

722様
うは、話題になった事ほとんど実装されてしまってる。
さっそくありがたく使わせていただきます。

ScanSnapで作った文庫のスキャンデータが800冊分くらいあるので、
これでサクサクLibrie化できますー。
昔の文庫は余白が多いので助かります。

>>386
LIBRIe LE for windowsで確認したところ
平仮名順で認識してるんですが、違うんですかね？
まあカタカナに変換するのは簡単なんですが

>>389
LIBRIe for windowsでは平仮名でもソートされるんですが、
リブリエ側ではカタカナでないとその他になってしまいます。
そういう仕様のようです。
できれば変えて頂きたく。

LRFDumpは作者命などを後から訂正できるので便利ですね。
ToolBar for リブリエのページの犬が動かないバグ直せないもんでしょうか？

>>390
了解しました。
ルビ処理に結構バグがあるので、そのついでに直しておきます。

>>391
すいません、LIBRIeユーザではないので意味がちょっとわかりません。
LRFDumpはどちらかというと自己の学習と、
他にLRF出力するツールを作る人の助けにと思って作っただけなので、
これ以上、とくに何か実装する予定はないです。
といいますかバグなら、SONYが直すのが筋だと思うのですが？

SONYのｻﾎﾟｰﾄはｱﾚ

日本のリブリエチームは事実上解散したしな。

>>394
ソニーの人？

ChainLP V0.02
http://no722.cocolog-nifty.com/blog/2007/12/chainlp_v002.html

連番ファイルの出力に対応しました。
また、青空形式テキストから、タイトルや著者、章タイトルなどを抽出します。
章タイトルは字下げされた文から抽出して目次化するので誤認識も多いですが、
目安程度には使えると思います。
お試しください。

MeTilTranの出力画像拡大率を変更しても変換時に100%に戻されるのは何故？

うぉー、バッチモードめちゃくちゃ便利っす。ありがたや

とりあえずバッチのフロントエンド用に、携帯動画変換君の Transcoding.ini を下みたいに書いて使ってます。
[Item1]
Title=コミック用
TitleE=COMIC
Command0=""<%AppPath%>\ChainLP" -b -i "<%InputFile%>" -o "<%OutputFile%>.lrf" -ini comic.ini"

ChanLP 0.02つかわせていただいてます。便利です
気づいた点などを

詳細設定、挿絵をGIFに、色深度４ビットに変更、設定
→詳細設定で、色深度24ビットに戻っててエラーメッセージ

です。たぶん、色深度が保存されていないだけと思います。

あと、著者抽出ができたため、BookID 生成に本のタイトルだけ
が使用されるようになったでしょうか。
出来たら、もとのファイル名そのままか、著者名-タイトルだと
Librieに取り込んだとき綺麗に並んで便利かと。ご一考いただければ

>>395
出版社。

>>397
出力拡大率等のパラメタは記憶していませんので、手入力してください。
そのうち記憶するようにします。

>>398
なるほど、他のバッチツール使うのはいいアイディアですね。
ちなみにeTilにバッチ機能搭載にチャレンジしてんですが、
どうもバグが取れなくて、結局バッチ機能を封印していました。
同様の方法でバッチを実装してみたいと思います。

>>399
GIFの色深度の件は調べて直したいと思います。
ところでBookIDの件ですが、LIBLIe for printerのBookIDに合わせて、
FBLPyymmddhhmmssの形式で自動生成しているだけです。

SonyReaderの場合、タイトル読み順と著者読み順に並ぶんですが、
LIBLIeの場合、違うんでしょうか？実機持ってないのでサッパリ分かりません。
とりあえず、読み変換やタイトル抽出などのチェックを外せば、
元の通りだと思うんですが？

ｵｰﾃﾞｵスレって無いんだねｗﾌﾟ

>>722さま

ChanLP 0.02私も重宝して使わせていただいています。
2点ほど、希望など。

１．文書詳細でメモに入れたものが、RLF変換後に反映されていないようなのですが。
今は、再度RlfDumpで書き込んでいます。

２．連番画像取り込みでRLFに変換する際に、
目次を手入力でいいので、任意の言葉にできないでしょうか？
ページ数だけではちょっとわかりにくいものもあるので。
青空文庫変換では、パスのところに章タイトルが抽出されますが、
そこを手入力するようなイメージです。

７２２様

>ところでBookIDの件ですが、LIBLIe for printerのBookIDに合わせて、
>FBLPyymmddhhmmssの形式で自動生成しているだけです。

そうだったんですか、完全に私の勘違いです。
たまたま、連続してデータを変換していたので、名前順になっているのだと
思い込んでいました。

ChainLP v0.03
http://no722.cocolog-nifty.com/blog/2007/12/chainlp_v003.html

目次を編集する機能をつけてみました。
メモが反映されないバグやGIFの24bitなども修正しています。

722さま、ChainLP大変重宝しております。
あまり需要という意味ではないと思われますが、
PDF入力にも対応していただければ嬉しいです。

pdfからいったん画像を書き出せばすむことではあるのですが…。
ご検討の程、お願い致します。

ＰＤＦ入力はつらそうじゃね？
フォントのレンダリングとかいろいろあるから。
AcrobatReaderを、ＣＯＭ経由で呼び出すとかすれば出来るのかね

画像や表を入れてまとめた勉強内容を、辞書的な検索機能(目次)を付けて電子書籍化し、
電子書籍ビューアで持ち歩きながら閲覧するということをしたいのですが、
自分で電子ブックを作る(元ファイルはワードやパワーポイント、OneNoteなどで作るとして)方法はありますでしょうか？
単純にPDFファイルにするのが一番適切ですか？PDFのレンダリング速度は問題ないでしょうか？

>>408
>PDFのレンダリング速度
どんな電子書籍ビューアを使うのかにもよるんじゃない？
ワードとかパワーポイントで作ったデータを電子ブック化するなんてできないと思うけど

ChainLP v0.04
http://no722.cocolog-nifty.com/blog/2007/12/chainlp_v004.html

連番画像の圧縮ファイル出力と、青空文庫の外字タグに一部対応しました。
お試しください。

>>406
さすがにPDF入力対応は無茶です。
すごく難しいです。

AcrobatReaderの利用は、Adobeがそういう使い方を許可していないと、
何処かで読んだ記憶があります。(確かアンテナハウスのblog)

仮想プリンタでBMPやTIFF出力するツールがあるので、
それらを組み合わせて何とかしてみてください。
http://gigazine.net/index.php?/news/comments/20071107_virtual_image_printer_driver/

>>410

722殿

いつもChainLPを使わせて頂いております。
今までEditLRFMetaGUIを使っていたのですがうまくいかなかったので、
722殿がBBeBに参戦して下さってLRF環境が格段に良くなり
感謝の言葉もございません。

さて、ChainLP04bですが、zipファイルからLRFを作成しようと対象のファイルを開くと
「アプリケーションのコンポーネントで、ハンドルされていない例外が発生いたしました。」
と出て処理が停止してしまいます。
念のため03ｂに戻してやってみた所問題はありませんでした。
ご確認頂ければ幸いです。

あと、以前から気になっていた所がひとつございまして、
何巻か出ている漫画をひとつのzipファイルにまとめている場合、
ファイル名が巻によってまちまちなので巻の順番がおかしくなることが多々ございます。
例えば、
[作者名] 作品名.zip
　[作者名] 作品名 第01巻
　　作品名01_000.jpg
　　作品名01_001.jpg
　[作者名] 作品名 第02巻
　　000.jpg
　　001.jpg
この場合、ChainLPでは第02巻が先に表示されてしまいます。
一度解凍してファイル名を付け直すのも巻数が少なければよいのですが、
10何巻もありますと結構大変なのです。

もし可能でしたらご対応頂ければと存じます。

それは自分で名前付け直したほうがいいと思うけど


解答はするようだけどその後は
リネームソフトで一括でできるでしょ

まぁ順番を任意で変えたいって要望はありだけどね

だよねー。
一回展開した後、FlexibleRenamer とかで *\*.jpg → \1_\2.jpg
ってやれば良いんじゃないかな。

ChainLPの青空文庫形式txt入力がいまいちな件。

・禁則処理で余分な空行が生まれる
　例）…あいうえお。＜改行＞かきくけこ…
　→ ちょうど読点が禁則処理された場合、
　　「あいうえお。」と「かきくけこ」の行の間に余分な空行ができてしまう。
　　v0.02とv0.04で同じ現象が起こるけど、v0.01では起きないみたい。
　　禁則処理はDrawTateから結構かわってる？　処理対象も違うみたいだし……。

・ルビ対象が空白文字(全角&半角)や長音符「ー」で切れる
　例）あいうえお｜亜　伊　宇≪あ・い・う≫かきく…
　→ 「宇」からルビをふりはじめてしまう
　例）あいうえお｜カーキー≪かぁきぃ≫くけこ
　→ ルビが表示すらされない

・ルビが改行後の行頭にある時で、対象が漢字以外だと、前の行に表示される
　例）あああ。＜改行＞　いいい≪イイイ≫ううう

・縦中横(疑似)有効時、半角文字を全角空白で結ぶと縦中横対象と認識しない
　例）「!?　!!」

722氏、もしよかったら対応してください。

>>412
つーか、そもそもスキャンしたとき自分がそういうファイル名にしたんじゃないの？
誰かがつけてくれたわけじゃないよね？

ChainLP v0.05
http://no722.cocolog-nifty.com/blog/2007/12/chainlp_v005.html

>>411
すみません。自動カラーチェックで落ちるバグがありました。
今回ので修正していますので確認してみてください。

ファイルの順番についてですが、
作るのがかなり面倒な上に、圧縮時に注意すれば済むことなので、
対応は勘弁してください。

>>415
ルビの親字に空白を入れるのは、
青空文庫の作法から外れるような気はしないでもないですが、
「｜」を優先するよう修正したら対応できたみたいです。
縦中横(疑似)も修正しています。

ちなみにChainLPのテキスト配置はDrawTateとは全く違っていて、
一から作り直しているため、別物と思ってください。

他に変な配置になるようなのがあったら教えて頂けるとありがたいです。

Amazonの電子ブックリーダ「Kindle」ファーストインプレッション
ttp://pc.watch.impress.co.jp/docs/2007/1219/pda70.htm

面白そうだなぁ。Kindle。
ローカルファイルの表示は（純正では）できないようだけど
自前のテキストをhtmlに編集してAmazonに登録することで
専用書籍ファイルにしてくれるっぽい。

ハードはデザインにちとクセがありそうだけど
良さげに見える。

Kindleだけど、
＞自前のテキストをhtmlに編集してAmazonに登録することで専用書籍ファイルにしてくれるっぽい。
これ、日本語の文章でも変換可能なのか気になるね。（もちろんKindleで表示可能になるのかも）

あと、その記事に書かれているこれが気になる。
＞PDFなどの汎用のドキュメントの利用は制限があり

その前に日本から購入できないのがなぁ。

よく読んだらローカルファイルも単純な英文テキストは行けるようだ。ｽﾏﾝ

PDFの制限があるっぽいのがなんかやっかいそうだね。>>419

kindleで書籍化して全然読まなかったらtundleになるのか

だれがうまいこと伊江と（ｗ
>>421
> kindleで書籍化して全然読まなかったらtundleになるのか

kin襴dle子の帯締め乍ら〜

722様

いつもChainLPをありがたく使わせてもらっています。
青空文庫形式txtなんですが、以下のような不具合？が生じました。

入力がtxtで、出力をdirにした場合

・設定で余白の幅を指定しても反映されない
　例）デフォで余白が0.50になっているが、これを上が2.50にしても0.50のまま変わらない

ためしにDrawTateでやってみたら、きちんと余白が反映されました。
ですので一応報告までに

ChainLP + 変換君で年末休みを使って５００冊以上 Librie形式に変換できた。
もうこれ無しにはいられんわ。ありがとー

ChainLP v0.06
http://no722.cocolog-nifty.com/blog/2008/01/chainlp_v006.html

あけましておめでとうございます。
今年は使い勝手のいい携帯電子ブックリーダーが出るといいですね。

リリースに書き忘れましたが、余白が効かないバグを修正しました。
あと、フォルダ構成やファイル名の都合で読めないzipを
がんばって読めるようにしてみました。

テキストの横書きモードを試しに搭載してみたんですが、
縦書きでの調整値と共用するのは難しそうです。
妙に字間が開くのが良く分かりません。

>>426
作者様乙です。
旧年中はお世話になりました。
文庫や単行本を何十冊でも持ち歩けるようになりました。
とても感謝しております。
> 今年は使い勝手のいい携帯電子ブックリーダーが出るといいですね。
いまはWS004SHを使ってますが、ちょっと重いですね。
マンガミーヤが使えるので機能は満点をつけてもいいくらいですが。

722様乙です
対応してくださってありがとうございます
さっそく使わせてもらいます

青空文庫用に携帯端末が欲しいんだけど、何がいいかな。
電子書籍専用のでもPDAでも何でもいいです。

見易さとコストパフォーマンス重視で宜しくお願いします。

ソフトバンク９２０SHは？

書籍は買うのですか？それとも自作でしょうか

自作する場合で
もしそれだけのためにPDA買うのならば
文字ではなくjpeg画像を読むことになりますが
ゲーム機のPSPが液晶も大きくてよいかもしれませんね

最近PDAが売ってないですよね
電子辞書ってPDAと同じかとおもったら辞書は辞書なんですね＾＾；

個人的にはSig3かな。安いし。
縦にして本を開く様な感じにして持ち、画面を90°回転させて表示させると
読みやすい。俺は主にMangaMeeyaでJpeg画像を見る方だけど、スペースキーで
ページ送り、前変換キーでページ戻しにして使ってる。
LIBRIeも使ってたけど、画面がモノクロで階調が少なく切り替えが遅すぎる。
なによりいちいち変換しないといけないのが死ぬほど手間で手放した。

PSPは解像度が長辺480ドットしかねーぞ。
4ｲﾝﾁあっても文章読むのにはｲﾏｲﾁ。

ZaurusとかW-Zero3(のおっきい方）とかEM・ONEとか。
純PDAは稀少になったね。Zaurus以外は電話だもんな。

俺は電子書籍は購入と自スキャン双方。読むのはZaurusで。
でも小説みたいに読んだきりが多い物はスキャンは面倒で
最近はあんまりやらなくなった。ScanSnapあってもめげる。
一時間半で読み終わる本を時間と手間かけて電子化ってどーよ、みたいなｗ

最初からデジタルデータで売ってくれと思う。

ん〜　それだけのためにPDA買うならPSPは？って書いたつもりなんだけど

>ZaurusとかW-Zero3(のおっきい方）とかEM・ONEとか。
>純PDAは稀少になったね。Zaurus以外は電話だもんな。
 
電子手帳代わりにPDA探してたらほんとにないんですよね
携帯でいいかなとほんとに思った。10年前には
子供用の電子手帳買って使っていたんだけど、壊れてねもう使えない
１０年まえだとテプラも子供用があってね３千円で今の５千円同等の性能はあったよなぁ

PSPで十分読めるよ
QVGAのPDAでも問題ない
画像処理をちゃんとやればいいだけの話

金をかけたくないならPSPか中古PDAをオススメする

お前らPSPって何てもん勧めてんねん！
解像度足りないし重たいし、まだiPod touchならわかるが・・・。

>>429
お約束としては、infoCarryがｵﾇﾇﾒ
単4一本で数日〜数週間持つ、バッテリ切れても中身消えないし。
片手で操作、JOGで簡単!!モノクロ液晶は見やすくてキレイ
パソコンの使用が前提だがXPやVistaでも動くみたいだしﾈ
屋で中古しかないけど500〜4000円位だし。ｵﾇﾇﾒはVNW-V5。安いし縦書きで読めるyo

でもまずは自分の携帯の取説を読め！話はそれからだ
最近の機種にはテキストリーダやブックリーダが搭載されているはず。
Text中心の青空文庫ならそれで十分なんだぜっ！

リナザウで快適
ブンコビューアが改ページに対応してくれたらもっといいのに

>>436
iPod touchとPSPって解像度ほぼ同じなんだけど頭大丈夫？
画面はPSPの方がでかいし、画像1枚に500文字以上入れても普通に読めるよ
むしろどういう使い方をしてれば足りないんだか理解できない

青空文庫でしょ。
携帯のテキストリーダーで十分じゃない？
ソフトバンクのならアプリもある
http://appget.com/vf/pc/apview_028628.htm

携帯でいいんじゃね？
今時の携帯なら、3インチWVGAでPDFビューア標準装備。
青空文庫なんかアプリで普通に読めるし、自炊のJPG小説だって
722さんのツールを使えばどうにでも加工できる。
それに携帯なら、あとで邪魔になったり無駄になったりって事もまあないからな。
コミック読みにはお勧めしないけど。

P905iTV
135g
フルワイドVGA　TFT 3.5インチ
480×854

はやくでないかね

沢山のレス有難う御座います。レスが2日で止まってたからこんなに早く且つ多くのレス貰えて驚いた。

携帯はP506iCとかいう2.4インチのQVGAなんだよね。
画面小さくて見辛いから携帯で読書なんて考えもしなかったけど、今時の携帯って凄いんだな。
今調べてみたらEM・ONEっていうのも電話なんだね一応。
あの大きさは魅力だけど消費電力高めな上、悪評が目立つから手は出したくないな…。
それにやっぱ携帯は有事に使えなくなったりすると困るので別にしておきたいと思ってる。

リブリエは書籍専用だけあっていい機能備わってるのね。
解像度もサイズも申し分無いから売ってたら間違い無く買ってるんだけど…。

PDAではsig3よりzaurusのが発色いいらしいので、買うならそっちかな。

PSPは持ってる。通勤PSPとかいう便利そうなツールがあるみたいだから使ってみて具合が良かったらこれでいきます。
でも出先でPSP取り出すのはちと恥ずかしいよな…ゲーム機だし。（主に自宅だからまあいいけど）

長ったらしく書いて申し訳ない。まだ結論出てないけど、大変参考になる意見を御教示頂き有難う御座いました。
zaurusSL-C1000が何気に気になるので実機見て良さげだったら買うかもしれない。
それとinfocarryは解像度は今一だがサイズでかいので使い勝手良いと思った。見たら買う。

>>440
確かに722さんツールはリナックスザウルスで読む時非常に重宝してるが
携帯用に再構成はちょっと厳しくないか？
300ページのjpeg形式小説を携帯用240×320に再構成すると800枚くらいになってしまう。
800枚の画像を携帯に転送して読むなんて・・・・・・・・

>>429
青空文庫専用ならinfoCarryが便利だが、jpeg形式も読むならザウルスがいいかも。
青空文庫用のビューアーソフトがあるよ。
少々使い方にクセがあるが慣れるとリナザウはいいよ。
ゲームもするならPSPかな。

自分はau携帯だから、722さんのツールで100ページごとにPDFにして読んでるな
重くないし電池のもちも悪くない

ChainLP v0.07
http://no722.cocolog-nifty.com/blog/2008/01/chainlp_v007.html

>>444さんのレスでページ分割機能を思い出したので、分割機能を追加しました。
以前のChainPDFと同じ機能ですが、圧縮ファイルとLRFも分割できます。

MetilTran v0.09
http://no722.cocolog-nifty.com/blog/files/MeTilTran09b.zip

まだ作りかけですが、MeTilTranにLRF出力機能を追加しました。
但し、中身の画像はJpeg形式のみとなります。
色々足りてませんがお試し版ということで。

あと、再配置プレビューで設定ダイアログをいじると
ウイザードが機能しなくなるバグを修正してみました。
ご確認ください。

>>445
いつも乙です。

>>445
乙です。使わせていただきます。

>>443
PSP使いの俺は、目への負担を減らすために文字サイズ大きめに設定しているから、
一冊で1600枚くらいになることあるよ
途中のページまで辿り着くのに時間かかるから、100枚ずつフォルダ分けしないといけないけどな
PSPの画像ビューアにはしおり機能がないから小分けにしないとどこまで読んだか思い出せない
という理由もある

便利なのか不便なのか、解らないねｗ

PSPでjpegの本を読むなら動画にしてしまえば？
駒送りでいいんだし、レジュームが使える

>>445
722様乙です
携帯で読む自分としては、ページ分割はとてもありがたいです

ところでMetilTranにも同様の機能をつけることは可能でしょうか

ChainLP v0.07ありがたく使わせていただきます

>PSPの画像ビューアにはしおり機能がないから
自作アプリでしおり機能付のなかったけ？

>>452
クラック前提で語られても……

公式で対応してくれたらいいよね

http://japanese.engadget.com/2008/01/17/v9-10-e-ink-ebook/

>10型は825 x 1200と高解像度になっています。本体サイズは255 x 173 x 14.3mm、重さは320g。
>ハードウェア仕様は64MB内蔵フラッシュメモリ、SD / MMCスロット、CPUにARM 9系200MHz、RAM 32MB。LinuxベースのOSで
>PDF / DOC / TXT / HTML / JPG / CHMあるいは圧縮ファイルに対応します(「RAR, ZIP」と明示してある)。

もうこれ日本で発売してくれ。
というかzip圧縮jpgに対応してるなら本気で欲しい。

Meeyaが使えるやつなら見開きっぽく
横長の画像にして数半分に出来るよ。

MeTilTran V0.10β
http://no722.cocolog-nifty.com/blog/2008/01/metiltran_v010_f6fc.html

>>451
ページ分割機能を追加しましたのでお試しください。
ChainLPと同じように圧縮ファイルも分割できます。

ザウルスとPSPだと、一画面に表示できる情報量どっちが多いの？

例えばA4の文書を取り込んで、出来るだけ広い範囲を表示させようとした場合、それぞれ
上下または左右の何分の一くらいは画面上から削られてしまうかとか。

更新乙です。

>>457
更新お疲れ様です。
前からだけど、zipとかの圧縮ファイルをD&Dしても読み込まないのは、
仕様と考えていいのかな。
>>458
ザウルスの方が上だと思う。
PSP 480×272
ザウルス 640×480
PSPはワイドサイズだから横が余る。

解像度って大事だよ
PSP使ってるけど、画面大きくても文字が読みづらい

>>457
乙です。ページ分割対応してくださって本当にありがとうございます
ありがたく使わせてもらいます

うん、それゆえいまだにザウルスは手放せない。
もう完全に書籍ビューアにしか使ってないけど。
Advanced／W-ZERO3（800*640）に惹かれるが液晶が小さいからなぁ・・・・・・
使ってる人いる？

そりゃいるでしょｗ

>Advanced／W-ZERO3（800*640）
ってアドエスのことか。
あれって800*480だろ。

>>457
722様いつも乙です。

さっそくMeTilTran V0.10βのページ分割機能を試してみたのですが、
以下の不具合？があったので報告を

約400ページの画像を読み込み、ＰＤＦで100ページずつ分割して再配置したのですが、
なぜか最後のＰＤＦは話の途中でとぎれ、画像の最後まで再配置されませんでした。
特に出力中にエラーなど起きず、完了の表示もされました。

ちなみに、ページ分割をせずにＰＤＦで出力した場合においても、画像の5ページ分が出力されていませんでした。
携帯サイズに合わせているため、画像400ページは、1600ページほどになっています。

これは前のバージョンでも起きたことがあったのですが、全部出力される場合とされない場合とがあり、
もしかしたら、出力する際にページ数が多いのが原因かもしれません。

MeTilTran V0.11
http://no722.cocolog-nifty.com/blog/2008/01/metiltran_v011_b150.html

ChainLP V0.08
http://no722.cocolog-nifty.com/blog/2008/01/chainlp_v008.html

MeTilTranでPDFを出力するときに挿絵があると、
挿絵の分だけページがズレて実際のページ数より少なくなる
といったバグがありましたので修正しました。
また圧縮ファイルのDrag&Dropに対応してみました。

ChainLPは画像を横倒しにする機能を追加しました。
ビュアー端末を横持ちで使う際にお使いください。
(もしくはスキャンデータが元から横倒しになっている場合の補正)

>>467
722様、更新乙です。
早速使わせていただきます。
ほんとにいつもありがとうございます。

eTilTran使っているんだけど、圧縮ファイルの読み込みでzipファイルでもうまくいかない場合があるんだが、どうしてこういうことが起こるんだろう？同じようなひといない？

eTilTranの圧縮ファイルの名前処理が少し間違っているところあって、
階層が深いと読み取れないとか、
ファイル名に"[" "]" ","が使われていると読めないとかあります。
括弧が付いていると読めないのはdllが悪いんですが。
とりあえず単純なファイル名つけで回避して頂きたく。

>>470
おー、確かに"[" "]" "ついてました。合点がいきました。返答ありがとうございました。

偽UnZip32.DLL

>>472
今試してみたけど、うまく騙せなかった。ショボーン。

ChainLP V0.09
http://no722.cocolog-nifty.com/blog/2008/02/chainlp_v009.html

ChainLPが2000で動作しないとは全く気づきませんでした。
バッチ対応したとき、XPスタイルを内部から適用したのがまずかったようです。
今度のは起動テストしたので大丈夫だと思います。

あと、形態素解析エンジンMeCabでタイトルを分かち書きできるようにしました。
SonyReader用にローマ字化したとき、間にスペースが入って読み易くなるかなと。
ただ、なぜか家のマシンの一台ではMeCabが正常に動作しませんでした。
そのマシンはスパム対策にPOPFileが入っているのですが、そいつがMecabを使用していて
何かコンフリクトしているのかも知れませんが、原因はつかめませんでしたorz

いつも使ってます。
かなり機能も充実されているのですし、とっくに Version 1.0 を謳ってもいい出来になっているのではないでしょうか。

なにに使えるソフトなのかまったく分からんね

携帯端末で、青空文庫形式のテキストやスキャン画像を読むためのソフトだろ？
まぁ過去ログ読んでないと、分かりづらいけどな
722氏いつもお世話になってます

使える人は、ほんと、このソフトにはお世話になってるよな
今まで埃かぶってた Librie がこのソフトのおかげで使い物になるようになった。

http://japanese.engadget.com/2008/02/18/mylo-com-2-3-1-3-5000/
ビューアとしてはどうなのか

これだね。
http://www.sony.jp/products/Consumer/Mylo/
ソニーはビューアー作るの好きだよな。
まあこれはPSPのノウハウで作ったかんじだけど

ｍｙぉは、ﾋﾞｭｱ機じゃないよｗ

FLEPiaのビジネスモデル
2009年度　本格量産販売　年間10〜50万台
http://www.frontech.fujitsu.com/downloads/services/products/paper/flepia/downloads/paper-approach.pdf

日立は、A4サイズのモノクロ電子ペーパーを業務用に実用化する。コンテンツさえ用意すれば、設置工事など不要で導入できるのが売り。
2010年には年間100億円を売り上げるとしている。
http://www.itmedia.co.jp/news/articles/0605/11/news078.html

世界最大・A3フルカラー電子ペーパーをブリヂストンが開発　世界最薄フレキシブルも。
商品化は09〜10年ごろを見込んでいる。
http://www.itmedia.co.jp/news/articles/0710/19/news102.html

イタリアのTelecom Italia Mobile(TIM)はPolymer Visionと開発したモバイルデバイス"Librofonino"の展示を行った。
5インチQVGA、16階調モノクロ表示の電子ペーパー。
現在の画面サイズは5インチで書籍を表示するのに適したサイズだが、2009年ころには一回り大きい7インチサイズを投入予定という。
カラー化は2010年ころの予定。
http://journal.mycom.co.jp/articles/2007/11/20/gsma/index.html

14.1インチ型カラー電子ペーパーを
LGフィリップス社が開発 (2007/05/15)
ディスプレイを専門とする市場調査会社である韓国のDisplaybank社は、フレキシブル・ディスプレイの市場規模が2010年に59億米ドル、
2015年に120億米ドルに達するという予測を発表している。
http://www.eetimes.jp/contents/200705/18565_1_20070515153125.cfm

上記の情報から電子ペーパーが、本格的に普及するのは、2009年以降になりそうです。
今年は、e inkの9.7インチのディスプレイが6月ころに量産されるようです。
そしてFREPiaも1万台のみ一般販売があるみたいですが、2008年の末でしょうね。

2009年（たぶん終わり頃）から、いっせいに各社電子ペーパーを発売しそうですね。
ハードの立ち上がりとともに、ソフト（電子書籍）も更に活性化するのは、間違いないでしょう。

>>480
ゲームができないPSPだな

>>480
zero3からPHS抜いて、アプリ色々最初から入れて素人でも使いやすくしたような感じかな

ChainLP V0.10
http://no722.cocolog-nifty.com/blog/2008/02/chainlp_v010.html

自動的に小説画像の傾き補正とノンブル、章タイトルの除去ができるようになりました。

>>475
そろそろフリーウェアにしても良いかも知れませんね。
となると、ヘルプファイルとかドキュメントを準備しないといけませんね。

>485
手抜きでも許されるのがフリーソフト。
oooなんてのは、

【ソフト紹介】
ﾊﾞｲﾅﾘｴｼﾞﾀ

【免責事項】
本ソフトウェアの使用で生じた損害に作者は絶対責任を負いません。知りません。

だしw

まぁ、スレ立てて別でやった方がいいかもしれんね
バージョンアップも頻繁だし、後から追いかける人も楽だろう

722様はじめまして
昨日ChainLP V0.10を知り、大変便利に使わせていただいております。
リブリエの自炊がとても楽になり感謝しております。

一点だけ質問というか要望なのですが、
青空文庫形式のテキストから縦書のLRFファイルに変換の際に
�T�U�V等のローマ数字が横書きに変換されてしまいます。
できるようでしたら対応お願いします。

Metilでルビの削除したいんですけど、幾つかのページでルビが本文に巻き込まれてしまって、色々といじってみてはいるのですが
うまくいきません。こいうのは上手く設定すれば直るもんですか？それともある程度はしかたないことなのでしょうか？

ページの角度を調整して、再認識するといいかも
自分はいつもそうしてる

そうそう。たいがいは角度の調整で何とかなる

COWON-A3って、ビューアとしてどうなん？

http://tenant.depart.livedoor.com/t/kaeruzo/item4060673.html

>>492
どーだろね。
小説を読むならしおりが入れられるやつじゃないと使いづらいけど、
そんなふうには見えないし。

722様
ChainLP大変重宝しています。ありがとうございます。
要望なのですが、自動的に目次をつけられないでしょうか？
入力ファイル名を特定の書式、例えば、〜〜[目次名].jpg
のようにすると自動的に目次名が入るようなイメージなのですが

それだったら、目次用のテキストファイルフォーマットとかがあったほうがいいんじゃね？

目次名 [ファイル名/番号]

みたいな感じで。

出た〜〜っ！

http://japanese.engadget.com/2008/03/11/netronix-9-7-and-lan-e-link

はいはい。予定は未定ね

どうやらPRS505の日本語化はまだ試してないみたいですね。まー日本でリブリエが買えるからだと思います。
北米で発売されているソニーのPRS505はとても便利で、今は日本語のフオントも入れることが可能です。
もし、５０５を使っている方で興味ある方。。。。。レスください。

505様

リブリエを中古で購入しようか悩んでいるのですが、PRS-505の日本語化が可能なのであれば、海外から購入しようかとも思っていたところです。

ネット上でも情報を漁りましたが、今のとことPRS-500の日本語化は可能だということがわかったのですが、505はまだ無理との認識でおります。

もし、505で可能であれば、情報をいただけると幸いです。

尚、こういうことに関する知識は浅いので、できれば分かりやすくご教授いただければ、ありがたいです。

>>499
ここのちょい前の書き込み見れば、なんとかなるっしょ？
http://hobby10.2ch.net/test/read.cgi/dgoods/1185003956/

ありがとうございます。
非常に丁寧に解説されてました。

ところで、この方法で、日本語化した場合、やはり横書きオンリーで、リブリエの様に縦書き表示にはならないんでしょうか？

それと、実際にこの方法で、日本語化したPRS-505の画像なんかはないのでしょうか？

素人な質問で申し訳ありません。

mobileread.comのフォントレマッパというツールを利用し、内部メモリに日本語のフォントを入れて、システムのフォント代わりに使う方法です。
ただ、日本語のフォントの属性をシステムのフォントと同じくするのが面度です。
詳しくはこちらへ。。。

http://www.mobileread.com/forums/showthread.php?t=20644

505 ﾒｪﾙ 様

ありがとうございます。
大変参考になりまいした。

リブリエでChainLP使ってみた。
出力解像度600x800・高品質双三次補間でlrf作ったが、ミーヤ+Printer for Liblie
と比べて、ファイルサイズ大きく(リブでのページ送り動作もより遅く)、漢字の横線が
かすれたり、細かい部分が潰れたりして見づらい。
今後に期待します。

Printer for Liblieはモノクロ２値だからファイルサイズ小さいのは当たり前じゃない？

> Printer for Liblieはモノクロ２値
んなこたーない

髪切った？

722さん、いつもMeTilTran愛用させてもらってます。
最新版に以下のバグがあるようなので報告します。

「グループ編集」→「追加」→「本文(縦書)」とします。

この場合、縦書きの文章は右行から左行に読み進むので、右にあるグループから
順に(1)(2)(3)と認識されなければなりません。
ところが最新版では左にあるグループが手前の文章として認識されてしまうようです。

ちなみにV0.10では正常に動きました。

ただいま、ChainLPのHELPファイルを作成中です。
そのときにファイル名からの自動目次と、ローマ数字の回転をつけますので、
今しばらくお待ちください。

>>508
とくに何か変更した記憶はないのですが
今ちょっと確認してみましたが、とくに問題はなさそうです。

上下の位置関係はどうなっていますか？
二段組の本文に対応するため、左側でも、上下関係にある場合は、
順序的に優先されることがありますが、それとは違うんですよね？
その画面をどこかにアップしてくれれば話は早いんですが。

>>504
ファイルサイズが大きいのは、採用している圧縮方式によります。
Printer for LiblieはBMPのZLIB圧縮ですので、
ほぼPNGぽい圧縮になると思われます。
色深度や圧縮方式を変えて試してみてください。
なお、リサイズ方式の改善や、リサイズ時の補完フィルタ追加などの予定はないです。

>ローマ数字の回転をつけますので

722様、要望を対応予定にいれていただきありがとうございます
ローマ字で章分けしている書籍が沢山ありますので、助かります

>>722さん
バグを確認したのはおっしゃるとおり二段組の文章です。
しかし上下関係とは別に不具合が確認できました。
今日は忙しいので明日以降に画像をキャプチャしてみます。

携帯のVGA液晶が意外と馬鹿に出来ないとおもった。
905シリーズとかで見るとすごいね。
http://gifbunko.com
青空をのアプリでよめるとこです。

>>722様

一昨日からMeTilTran11bを大変便利に使わせてもらってます。

.png画像を取り込んで、1ページごとに認識具合を確認しつつ、適宜角度を微調整して再配置を
しているのですが、角度を調整するボタンが大きいととても助かるのですが・・・

>>513
Shiftキーを押しながらホイール回すと幸せになれるよ

>>514
まじか

どなたか教えてください
MeTilTranで取り込んだスキャンを縦書き・横書き・挿絵に分類する作業というのは
1ページづつ行うしかないですか？
例えば001.jpg 006.jpg 018.jpg 065.jpgをまとめて一括挿絵登録したいとか無理ですかね？

やべー７２２さんのツールに今頃出会った。
俺がこれまでやっていたことは何だったんだ。
神ツール。マジ感謝してます。

>>722さん申し訳ありません
508の件ですが私の勘違いでした。
手動で傾き補正した二段組の文章を認識させようとしていたのですが、
最初から読み込みを自動でやり直したら正常に動きました。
その後バグは確認されません。
誤報を流して申し訳ありません。
また報告が遅れてすいませんでした。

MeTilTranでフォルダから入力した画像を補正角やページの種類など何も変更しないで
再認識のボタンを押すと認識の結果が変わるのは仕様なのかな。(それとも補正角が0で計算されなおされてるのかな。)
この再認識で上手く認識される場合が結構あるから全体を再認識できるといいな。
(再スキャンだと再認識したものと結果が違う)

ChainLP V0.11
http://no722.cocolog-nifty.com/blog/2008/04/chainlp_v011.html

PCがHDDごと飛んだり、年度末を越えても忙しかったりで、
Helpファイル作成が遅々として進んでませんので、途中経過として、
ローマ数字や、ページ名の自動抽出などを追加したバージョンを公開しておきます。
あと外人さんが使ってるみたいなので英語モードも追加してみました。
直訳なのと、ぜんぜんテストしてないのがあれですが。
まだまだ忙しいので、しばらく沈黙することになりそうです。

>>516
現状、一枚ずつ設定するしか方法はありません。

>>519
再認識はスキャンの時と同じルーチンを通っています。
違うのは、設定された角度を前提で、組版チェックを行うことです。
ただスキャンのときも、まず角度を決定して、回転してから組版チェックしてるので、
結果が同じになるはずなんですが、自分でも結果が変わる理由が良く分かってません。
構造が複雑になりすぎて、一度整理しないといけませんね、これは。

>520

722様
バージョンアップお疲れ様です

>青空テキストで、ローマ数字が横倒しになる現象を修正しました。

ChainLP11b3をダウンロードさせていただきましたが、
ローマ数字に関しては以前と同様横倒しになっております。
なにか回転させる特別な設定項目等がございますのでしょうか？

722様 、

待ちかねの0.11が出ましたね。どうもありがとうございます。しかも、英語のメニューは最高です。
早速使わせていただきましたが、英語ウインドウズでは英語モードにしてもどうやら出力モードが
活性化されませんね。漫画のLRFへの変換は問題ありませんが、LRF以外での変換メニューは出来ません。
やっぱり日本語のウインドウズ以外じゃだめでしょうか。

Unhandled exception has occured...... This system does not
contain support for the Japanese locale. というメッセージが相変わらず
出て来ます。

TXT formatだったら、青空でなくても（韓国語のｔｘｔも読み込みます)
受け入れてすべての設定をかぶせることができますが、今度はOUTPUT
ボタンが活性化されません。

どういう風にしたら解決出来ますでしょうか。

前もってお礼を申し上げます。

>>521
あれっ？こちらで確認したところでは、何も設定しなくても縦になるんですが、
ひょっとしたら青空タグの方言か、フォントの違いによるかも知れません。
※［＃ローマ数字1、1-13-21］
といったタグで、フォントはMS明朝でテストしているんですが、
>>488さんは、どういった環境でしょうか？

>>522
英語OSの体験版をインストールしてテストしてみますので、
しばらくお待ちくださいね。
データを入力してからOutputボタンを活性化してるんですが、
途中でエラーが発生して、活性化のステップが無視されるのかも知れません。

あ、へんなトリがつきましたけど、>>523は私です。

７２２様、
ウインドウズの国設定のSTANDARD and FORMATをUSAから日本に変える事によって
すべての問題が解決されました。手数おかけしました。どうもありがとうございます。
韓国の何百ものソニ　リーダ　ユーザはあなたのCｈaiｎLPを大切に使わせていただいております。
皆を代表して感謝いたします。　

>523

>※［＃ローマ数字1、1-13-21］
>といったタグで

722様
すみません、タグを使ったらあっさりローマ字縦表示できました。

恥ずかしながらローマ数字表記の為のタグの存在を、いままで知らず、
普通に�Tと入力していました。
自己流青空文庫形式で入力してきたため勉強不足でお騒がせしてすみませんでした。

素人同然な私相手に、いろいろ対応ありがとうございました。
ChainLPを今後も末永く使わせていただきます。

722様、
英語のメニューにして使ったら両面スキャンを単面に分ける機能がなくなるバグが
ありますね。まず、報告だけで。。。。。

722様ってのが
（お）なにーにいさま

(オ）ナニ−兄様ってよめるんだけど

>>505
このスレはsageで書いてください。

>>529
誤爆？ｗｗ

584x750
584x754

どっち？

>>530　(名前の)505、つまり>>527に対してだろ

ChainLP v0.12
http://no722.cocolog-nifty.com/blog/2008/04/chainlp_v012.html

英語OSで落ちやすかったり、一部機能が使えない問題を修正しました。
テキスト文字としてのローマ数字やロシア文字が横倒しにようにしてみました。
あと、ルビのときの禁則処理を改善しています。お試しください。

http://k-tai.impress.co.jp/cda/parts/image_for_link/181613-39550-4-1.html

>>533
おっ、いつもありがとうございます！

>>534
結局kindleって日本版発売されるのかね？

ChainLPと比べてpdflrfの方が、デフォのままで薄すぎず濃すぎず丁度いい案配になるな

>>537
pdflrf良いの？

ChainLP、なんかJPEGをPDFにすると、画質に
不満があるんだよな
ボーッとしてるというか…

４インチVGAのPocketPC + マンガミーヤ で最強だろ

>>539
４インチVGAってどんなんがあるの？

今ならiPAQ212かな。hx4700の中古なら安い。

>>541
とん。

へーpdaの新作でたんだぁ
どっちかつーと112のほうが軽そうでいいなぁ
いまWS004SHつかってるんだけど、220gはなにげに重い
240×320の3.5インチだとやっぱみづらいかな

3.5インチ/QVGAと4インチ/VGAでは、漫画の見え方は天地ほども違う

自分も２１２使ってるけど漫画読む分は全く問題無い。
文字だけの本も見てるけどＢ５サイズ横書き１ページ３０行
ぐらいの本を取り込んだものが普通に読める。

私はX50vで見ているけど、3.7インチでもVGAだとQVGAとは全然見え方が
違うから、やはりVGA液晶を搭載したPocketPCがビュワーとしては一番
使い勝手が良いと思える。
多少、値は張るけど、閲覧環境の快適さを考えると手放せない。

WS004SHってVGA化出来ないっけ？
出来たら欲しいなー

>>547
VGA化できるよ
しないと640X480の画像でも汚い。
マンガミーヤの拡縮設定でなんとかなるんかも知れんけど。

リナザウ（SL-C700）で見てるんだけど、これってVGAなの？

EM ONEでマンガミーヤ縦画面はかなり良い。
片手で長時間持ってもなんとか平気な軽さ。
本体も片手でサクサクページ捲れる丁度良い大きさ。
WVGAの4.1インチ画面だから目を凝らさなくても文字が読める。
ファイルサイズもあまり気にするす必要がないみたい。
今まで見た中では1.8GB 全28巻っていうのが最大だけど特に問題無し。
ただし、PC版と違って1巻ずつZIPにしたものを纏めてZIPで1ファイルにしたものは
再生できなかった。それと、栞が機能しない。

EMONEよりは212のほうが良いよ。
SDHC対応だし、駆動時間長いし。
携帯とPDA兼ねると肝心なときに電池切れで電話使えなくなるし。

>>549
うん、VGA。
俺もSL-C750使ってる。
青空text形式も縦持ち・横持ちでいけるし、abookReader使えば画像形式の小説もいけるから
重宝してる。
4インチVGAで中古1万以内で買えるのも嬉しい。
通信関係は弱いのでほとんど電子書籍リーダーとしか使ってないけどｗ
あとリナックスの勉強が少し出来るかな。

>>551　電池の予備買えよ！ｗ

iPAQ212いいなぁ
SL-C700潰れたら、買おうかな？
ページだいぶめくったので、横のジョグダイヤル
みたいなのが、ちょっとゆるくなってきた…

マンガミーヤの話はうんざり

そんな糞なことに頭使うなよ

他人の楽しみを腐す君の様な人は、江戸の昔から（もっと昔から）今に至るまで、無粋者と呼ばれておりましてな。

>>556
使うぶんには自由だが、どこいってもPDAなんかのネタに
マンガミーヤ、マンガミーヤうるさいし、そんな腐心するネタでもないだろ。
専用のスレで勝手にやってくれって思う。

ビューアのスレでビューアの話題をうるさいって、君ちょっと頭おかしいんぢゃない？

>>557
まあ、思えば何年前に開発停止したのかも定かでない、在野の素人が
片手間で作ったソフトの代わりすら登場しないのがWMなんだよねｗ

そんなにウザいなら、画像ビューワーの決定版を作って公開してくれ。

でもマンガミーヤを使うにあたって、メチルは最高のツールです。
このスレと>>722氏に感謝。

Hanlin V9　まだかなぁ…

WmじゃないPCでも、ミーヤ使ってますが。
PC用としても、他にいいのがない現状ではないかと思います。

キーコンフィグ自由さや栞機能ならLeeyesのほうが使いやすいと思う。

青空分形式のテキストが表示できない。

このスレをみると、なぜ電子書籍ビューアがでないか分かる。
キモヲタ相手じゃマーケット小さいもんなあ。
金は出さないくせに言うことはいっちょうまえだし。

マンガミーヤ以上の物を作れそうもないからって、ヲタの悪口言うのは筋違いだと思いますが。

そんなのいらんし。

そもそも、普通に有料の電子書籍はすでに結構な存在になっているのではないですが？

有料の電子書籍なんてつまらんのしかないし。

基本的に、今の時点で電子書籍ビューワを欲しがる奴は本好きばっかだからな。
今のamazonくらいの品揃えがあってようやく一人前（amazonも、実はそんなに品揃えよくないけど）。
現状の電子書籍の品揃えは、精々キオスクに毛が生えた程度だから話にならん。

>>569
電子書籍でどんな本が読みたいの？

E-Inkのディスプレイじゃないと認めん

画面のプロパティで120DPIに設定してるんだが、MeTilTranの
ウィンドウやダイアログの表示の端の部分が切れてしまう。
722さん、気が向いたら修正頼みます。

Kindleでも青空文庫をChainLPで連番画像化->公式ソフトMobi Pocket Creatorで高密度圧縮しprc化
で、綺麗かつ高速に表示されましたぜ。722さんに国際的な賞賛を。

上の方にでてるリナザウやアイパックでは
250MBくらいのPDFをサクッと読めますかね？

それなら買いなんだけど…。

>>575
絶対にサクッとはいかない。
25MBがせいぜいだろ。

>>575
それページ数の違いとかモノによって変わってくるから
評価用のPDFが無いと答えられん。

画像ならわりと問題なく見れるからJPEGに変換してZIP
に固めたやつ作って見れば？マンガミーヤで。

250MBだと文字ベースの可能性はほとんどなくて
スキャナから取り込んだ画像ベースのPDFだろうなー。

Zaurusは一応はPDFを表示するツールもあるけど
　・重い
　・1ページのサイズの大きな物はメモリ不足で開けない
　・透明テキストの検索ができない
とほぼ実用にならない。
WinCE(WinMobile)機の方が多少マシだけど
最近のスマートフォンでも800x480程度の画面しかなくて
文字だらけのA4スキャンなんかは読んでられねー。

結論：やめとけ

４インチ機なら文庫本サイズぐらいの文字は読める。

>>575
今使っているPDFリーダーのウィンドウを480x640の大きさにリサイズして、読
みたいPDFを開いてみよう。多分狭すぎて嫌になる。それがVGAクオリティ。

あと、ザウルスにはAdobe製のリーダーソフトはないから、フリーのPDFリーダー
を使うことになる。ファイルによっては体裁が崩れて読めなかったりする。

>>575
250MBのPDFなんてリナザウではまず厳しいよ
というかたぶん開けない。
ザウルスでフリーのPDFリーダー入れてるけど重くてほとんど使えない。
PDF→JPEG→無圧縮zip化をabookReaderで読むのがいいと思う＞リナザウ
JPEGの段階でリサイズしたらもっと快適になる。

＞画像ならわりと問題なく見れるから
OCR処理されたデータは逆に重いとか？

画像データに透明テキストが埋め込まれてるやつって意味あるん？
テキストか画像かどちらかに統一しろよと思うね
pdfは基本的に重いな、djvu対応だと画像データでもスイスイいきそうなんだけど

検索できるじゃん

だいたいPDFって、なんかピントがボケてるでしょ
JPEGで見る方が好き

>>584
それならばAcrobatのアンチエイリアス処理を外せばいいんでない？
ADFが作成するPDFの画像は基本的にjpgをアーカイブしただけですよ。
OCR結果の透明テキストば別として。

ttp://japanese.engadget.com/2008/05/07/irex-iliad-book-edition-8-1/

ChainLPの縦横比チェックの設定、時計回りと反時計回りって
回転方向が逆じゃね？

本当だ。気づかんかった。

吹いた

通勤中に自炊したマンガ/小説を読みたいんだけど、機種選定で困ってる。

新品入手可,VGA,150g未満,2G以上記憶可能の条件が希望だけど。
> a:iPAQ 212(192g) b:ipod touch(480*320) c:W-ZERO3(220g),es(175g)
> d:docomo 905i,sb9**SH(ソフト?)
携帯以外(a〜c)は微妙に条件に合わず(d)の携帯が現実的かと思ってる。

携帯乗換は諸事情にて無理で、マンガ読みだけに利用できるのか不明なのと
スレ内で携帯使用報告はあってもイマイチ使用感が分からなかった。

で悩み始めると際限なくて。
150gは胸ポケに入れて着崩れない重さとして設定したけど妥当か微妙だし、
スレ内でtouchの報告もあってWQVGAで平気かもとか、悩み無限ループ中。
是非助言を下さいませ。

905iくらいの画面サイズでいいならアドエスでもいいじゃん
W-SIM抜いたら一応150g切るし、無保証なドライバ入れればmicroSDHC可だ

zero3かiPaqしかないと思うけど。
テキスト小説オンリーなら携帯でもいいけど、漫画だとかなりつらい。

↓こっちのスレにレポートとか書いてあったよ。
http://pc11.2ch.net/test/read.cgi/mobile/1165780562/114-

WQVGAじゃ字が満足に読めんわな。
VGAでも漫画のフキダシ以外の手書きの小さな細い字はよく見えん。
4インチ以下の画面は正直凄く疲れるぞ。まして通勤の揺れる環境では
更にキツイ。おそらく携帯サイズだとすぐに後悔することになる。

>>590
iPod Touchは無理。
ファイルサイズが巨大になる。

バイオタイプ-Uでかばんに入れて持ち歩き最強説

正直、X50vの3.7インチ液晶ですら漫画は読みづらいことがあるので、
軽さよりも液晶サイズを基準に考えた方が良いと思う。
それを考えると、自然に携帯は候補から外れるので、やはりiPaq
＋好みのビューアとかになるんじゃないかな。

>>590
参考までに
SH903iＴＶを使って１ページ丸ごとスキャンしたPDFの
マンガを見たりしましたが解像度云々以前に
画面のサイズの問題で吹き出しの文字が読むのが
かったるいです。（携帯の画面で見るなら
携帯で出回って居る１コマづつ見るタイプ以外は
キツイと思います）

手持ちのＨＴＣ　Ｚやザウルスでもやって見ましたが
こっちなら辛うじて見れる感じでした
（但し、SL-CザウルスのABookReaderみたいに、
その目的に特化したビューアーは欲しいです）

１ページ丸ごとスキャンしたマンガを紙の本と
同じイメージで見たいならVAIO Uくらいのサイズは
欲しいですね（重いけど）

漫画もコマごとに再配置とかできればいいんだけどね
普通の漫画は4コマみたくコマ割りが単純じゃないから無理かなぁ
そう思うと電子コミックって手間かかってるんだな

根本的に、あんな手間かけてる時点で携帯コミックの出版点数には限界があるよな

リナザウ使ってるんだけど、リナザウも携帯電話も
漫画読んでる分には手間変わらんよ
問題は重さと電池の保ちだな

電池の保ちは、電子ペーパーが良くなれば、なんとか
なりそう

漫画読むんだったら４インチVGA機しか選択肢無いだろ。
これより小さいとキツいぞ。

zaurusはそこそこいけるんだが、液晶の質が今ひとつなんだよねえ・・・・・・

>>601
４インチ以上のデバイスって具体的には何があるの（普通のモバイルノートは除く）？

>>603
4インチ以上のVGA解像度で軽くて薄型で片手で持ってタッチパネルで簡単に頁捲り可能
という漫画読みに適した条件で現実的な機種としてはiPAQ212かEM ONEあたりがお薦め。

ってか、4インチっていうのも恣意的すぎるな。
大きければ大きいほどよくて、でも液晶が大きくなると重くなって使いにくいから、
あとは視認性という観点で下限がどこだって話になる。

その下限が4インチかどうかって言うと微妙。
俺は5インチだから。

>>591-605 ありがとう凄く参考になった。
特に液晶の大きさの重要性は心に留めておきます。

電車通勤の関係で片手で持てて(=一方は吊り革)
ワイシャツ胸ポケに入るサイズ(=乗換&夏は背広着ない)を
考えると10*13辺り、6インチだと超薄型でないと無理で、
3インチは小さいと皆口を揃える辺りから4〜5インチが妥当なラインか
| 3inch = 4.6*6.1
| 4inch = 6.1*8.1
| 5inch = 7.6*10.2
| 6inch = 9.1*12.2
| 7inch = 10.7*14.2
再度探したら HTC Advantage X7501,EM ONEとかも
引っかかったので、これから詳細見てくる。
あと、>>592のスレはノーチェックだったので全部読んでくる。
ちなみに>>594 iPodTouchは操作性よさそうなのと
iComicという有望そうな開発中アプリが圧縮状態で読めるので、悩みつつ残した。

少し悩んでみる。よかったら、また相談乗ってくれ。ﾉｼ

マンガ読み用はPSPくらいの大きさが必要。
だから本命はatom搭載のUMPC。
とにかくしばらく待て。

ＰＳＰ+漫画PSPで変換

これがファイナルアンサー
でもcfw入れないと快適にみれるソフトがないけどね

>>607
PSPサイズでいいなら、EM-ONEがほとんど同じ画面サイズでWVGAなんだが

EMONEはなんとなくイヤなんだよ。
なんとなくなんだけど。

EMONE買ったけど、画面がつるてかで文字が読みにくくてがっかりだ

>>611
ノングレアの保護シート張ったらいいのに

男性が片手で持って操作できる範囲でできるだけ大きい液晶というと
4-5インチとなるが、手の小さい人だと5インチでも大きすぎるかも。

EMONEは800x480のWVGAとスペック的にはVGAよりいいが
漫画を読む場合は漫画の縦横比の関係で縦表示時に上下に
黒帯ができる。よって、漫画を読む時はVGAと変わらない。
EMONEの液晶は>>611はがっかりとのことだが、まがりなりにも
SHARPで個人的には結構綺麗だと思う。

PSPの解像度は480x272。画面が大きくてもWQVGAの携帯と解像度的に
同類でページ内を拡大してスクロールして見なければ満足に文字も
読めないため全然論外では?
ましてリーマンがPSPだと仕事に対する姿勢も疑問視されるだろうし。

できれば4-5インチで1024x768以上の機械が出て欲しいところ。
UMPCも暫くは片手で楽々持てるという軽さと大きさは無理だろうけど今後に期待。

ここ最近、携帯（あうw54sa）で小説をpdfにしてで読んでるけど（めちる使用）

画面の大きさとかも重要だけど、読み勝手？も大事だよ。
所謂、「しおり」が出来ない。

携帯のpdfビューワはレジューム機能が無い。だから途中まで読んで後でまた読むって時、
自分でページ数を覚えるなり、メモ記入しとかないといけない。

iPodTouchが４インチになって、VGAになったら
いいのにね
使いやすそう

そうでもないよ。
漫画用ビューワーがないだろ。

開発中って書いてなかったっけ？

どれ？

これ、作者ページが消えちゃってるけど･･
http://www.oshiete-kun.net/archives/2007/12/ipod_touchicomic_1.html

iPodTouchのビューアは、たぶんiPhone2.0 SDKの一般公開待ちだろうね。

この人が引き継いで開発してるよ
http://cfuncname.seesaa.net/
別の漫画ビューワーも

動画
http://www.t-time.jp/Movies/demo_16ya.html

>>614
似たようなことやってるがP905iだとレジュームできるよ
どうやらi-mode PDFの仕様みたいだから他キャリアだと
どうなってるのかわからないけど

端末搭載ビューワによって変わるんだろうね

atom搭載はバッテリー持たないだろ

>>621
みんな安易にcomicvewerって名前にしすぎ
これで何個目だよ

正直コミックは4インチや5インチじゃ疲れて仕方ないので
最低7〜8インチは必要

まぁ、いで口開けてまってりゃ、そのうちなんか入るだろ。

>>626
４インチ以上だと携帯性に難がある。
あんんまり持ち歩かないんだったらいいけど。

４インチ以下だと読み辛い。
４インチ以上だと持ち運び辛い。
だから選択肢は４インチしかない。

≦4 読みづらい
≧4 持ち運びづらい

＝4 読みづらく持ち運びづらい

つまり折りたためて、折りたたんだ状態で4インチ未満ならおｋってことか？

大き目のDSがいいってことだな
そんなのでるといいな

１画面で折りたたみ可能がいいな

技術的にむずかしいこと言うなよw

折りたたみ二画面デュアルディスプレイ端末でおｋ

電子ペーパーは折り曲げれるからできそうな希ガス

>>628
すげぇ馬鹿だな
以上と以下と未満って小学生で習うんじゃなかったっけ？

ttp://japanese.engadget.com/2008/05/14/astak-mentor-150/
QTベースってのがいいかも。

>>634
軽く曲げるだけでいいならともかく二つ折りは厳しいです＞＜

>>636

WinCEって書いてあるけど、どの辺のレイヤでQt関係あんの?

でもこれいいね。6インチモデル200ドル代ならほしい。

5インチ版はinux 2.6 / Qtってなってる。
手持ちのビューアーとして使うなら5インチ版が一番いいな。

白黒みたいだけど、しおり機能はついてるんかな。

5インチでも6インチでも200g以下でハイスペ携帯電話なみの軽さですね
どちらも薄型大画面なので壊れないように持ち運ぶためのケースが重要かな
都会の電車通勤者は満員電車に耐えるハードケース必須

安いから壊れたら新しいの買えばok

ブックマークありで8000ページ(文庫30冊くらいか？)読めるのはすばらしいけど、
いちばんちっこくて19ｘ12cmってでかいな。

小さいのが欲しいんだったらPDAでいいじゃんよ
大きくて軽いのが欲しい人は電子ブック

その電子ブックが売ってないんだよな
今の技術で新製品だしてほしい

なんだったら携帯電話の画面を大きくするだけでいいよ
（そうすれば開発とかないので値段も安いだろう）

専用リーダーは出てきてもハードカバーサイズか
良くて新書サイズ＋αだし、どうも製作サイド
（主に出版側か？）との意識のギャップを感じる。

ワイシャツのポクットにねじ込める
この条件で電子ブックを読もうとすると
PDAしか無いしなー

電子ブック出しても需要が無いのかすぐ生産終了＆サポート打ち切りに
なっちゃうじゃん。汎用性無いマシンでそうなるとマジ終了。

現実的には画面でかいPDA買ったほうがいい。ＰＤＡで一番画面でかい
のが４インチ。それよりちょっと大きくなると一気に価格１０万超えとか
になるし持ち運び辛い。

>>636
こういうのを待ってました
いつも出遅れの日本

>>648
Σブックみたいにまた消えるんじゃね？
白黒だったり高価だったりとイマイチ流行らんんだよ。専用機は。
携帯機が安くて軽くなるのを待ったほうが早い。

俺は、電子インクだとクイックショナリー２を使える可能性があるから期待している。
PDAやモバイルノートの液晶じゃスキャンできない。

買ってすぐお蔵入りしたクイックショナリー２が表舞台に出るのをずっと待っている。

自炊の漫画読みたいだけなんだけど、４スケールグレーって
普通に綺麗に表示される？

漫画自体は白と黒の線画だけなんだけど、それをJPEGに
した画像はどうなんだろう？

自炊している人なら4階調に自分で変換して試すのも簡単だと思うんだ。

>>636
いいねこれ。でもえらい先だな。

>>651
アンチエイリアスかからないから普通に汚いよ。
ガビガビだよ。

>>654

ちゃんと時間かけて、減色すれば4色PNGでもテキストものならいけんだけどね。

>>636
6インチと9.7インチはこれと同じ？
ttp://japanese.engadget.com/2008/03/11/netronix-9-7-and-lan-e-ink/
ttp://www.netronixinc.com/product_e-book.htm

flashのサイズとか、どっちかの表記が怪しい気がする。

階調足りなくてデイザ処理入るからザラザラした画像になる。
こんなの日本じゃ売れん。

>>649
消えたってどこぞの独自仕様フォーマットしか読み込まないウンコと違って汎用規格を読み込めれば使いようがあるわけですよ。

えー
じゃあ、自炊派は、今のところPDAしか選択肢が
無いってこと？

今のところはそうだな。

ttp://www.astak.com/e-book.html

>>659
ザウルスも消えるみたいだからもうPDA自体が絶滅だな。

画質良ければe-bookみたいなのもアリだけどな〜。
しかし画面的には昔の８ビットパソコン以下だし。
職人がそれ用に描いた絵ならそれなりに綺麗かもしれんが
取り込み画像なんかザラザラブツブツになるだけだし。
イメージ的には大昔のワープロ専門機の画面？
汚くても読めりゃいいって人向けだな。

画面の上からトレーシングペーパー貼り付けたら綺麗に見える気がするかもよ。

幻燈かよｗ

>>664
バカだなあ・・・　度の合わない眼鏡をかけた方が画面に傷を付けなくて済むだろうに

>>666　ぉぃぉぃ、ﾄﾚﾍﾟを知らないの？ｗ

画面の上からトイレットペーパー貼り付けたら汚物に見える気がするかもよ。

このスレほんと低脳しかいないのな。
トレペとサンペがごっちゃになってるとか。

ずいぶん４スケールに粘着しているバカが居るな
本を読む分には全く問題ないよ。

>>669
まあ、ﾄﾚﾍﾟを知らない奴は多いと思うｗ　和紙や特殊紙には、もっと薄いのが存在するがねｗｗ

>>656
これをみるとかなりきれいに出てるみたいだけど、はめ込みなんかな。

>>672
大きい奴は解像度高いからデイザでも遠目で見ると綺麗に見える。
画面一杯の犬のアップとか素材選びで綺麗に見せてる部分もある。
まあ広告だから当然だが。
小さい機種の画面は出てないっしょ？
つまりそういうこと。

新聞写真と同じ原理で、色数少なくても解像度高ければ綺麗に見えるのだ。
ガビガビの画面写真でも縮小すれば見掛け上の解像度上がって綺麗に見える罠。
広告会社の匠の技。

>>674　網点だろ！ｗｗ

広告会社の技じゃないっつーのｗ

リブリエに使えるカバーを探してます
↓を売ってるトコありましたら教えてクダサイ
http://www.sanwa.co.jp/product/syohin.asp?code=PDA-SLLB

amazonで中古うってるじゃん？

俺は重くなりそうだからいらねーけど

>>677
カバー持っているけどお勧めしないよ。使っていないし。
元のカバーをきつい革のサンワサプライカバーの中に入れて使うので
重くなるし元のカバーが必要だから二重で意味ないし。

eTilTranに、ChainLPの縦横比チェック機能とバッチ機能
つけて欲しい。

もしくはChainLPに、eTilTranのコミック用傾き補正と、
傾き補正時にノンブル削除しない設定つけて欲しい。

バッチ機能は、コマンドライン・オプションがあるので
>>398 みたいにすると、便利だよ

eTilはコマンドライン・オプション無い

>>656
1200x825で4階調あるならソコソコ見れそうだな。

どの記事にも重さが書いてないのが気になるが…

722さん、MeTiltranで「行編集」→編集したい行をマウスで選ぶと、
「幅調整」の項目が出てくる行と出てこない行がありますよね？

「幅調整」可能な行が含まれる場合、「ノンブルありなし」のように「幅調整あ
り」と表示させることは出来ませんか？

目視による校正の効率が上がると思います。

また、同様にページ内の「挿絵ありなし」を表示させることは出来ませんか？

傾き補整に失敗したページや画像内にゴミが含まれる場合、挿絵として認識され
ることが多いようです。

その場合の目視による確認の手間が減ると思います。

722さん、みなさん初めまして。
今日、初めてMeTilTranを知り、試してみました。これはすごいソフトですね!

MeTilTranを使って読みたいものがあります。論文です。

論文 pdfで検索すると出てくるように、
http://www.google.com/search?hl=ja&ie=Shift_JIS&q=%98_%95%B6+pdf&btnG=Google+%8C%9F%8D%F5&lr=
論文は、たいていA4かB5の縦置き横書き、リードのみ一段組、本文は二段組。ページの上部に図が入ることがあり、その場合一段組になることがある、という構造です。
たとえば、この検索結果の四番目にある
http://securit.gtrc.aist.go.jp/research/ paper/css2002-takagi-dist.pdf
は二段組の構造です。
(上の四つは、一段組でした)。

こういう論文をMeTilTranで再レイアウトして読めたらと思います。
PDFを入力できるとベストです。
ご検討いただけるとうれしいです。
また、MeTilTranの開発項目にあげていらっしゃったバッチ実行にも期待します。

ところでMeTilTranは、雑誌記事での掲載は不可ということですが、Webマガジンでの記事ではどういう扱いですか?

↑
こういう質問は、作業工程に関する質問の前に、どんな使い方をしたいのかを
書かないと、適切な回答は期待できない。

http://securit.gtrc.aist.go.jp/research/paper/css2002-takagi-dist.pdf

のような論文を、MeTilTranで再レイアウトしたいです。

pdfは透明テキストが大抵入ってるから、MeTilTranでやる必要性がよく分からないし、
PDFならモバイル機でもビューアーが付いてるのが多いから、無理して再配置する必要がない気がする。
(重いなら分割すればいい)

たしかにテキストはおっしゃるとおりです。ただ、論文の場合、図や表が重要な意味をもつことがあり、テキストだけでは意味がないこともあります。
PDFのビューアーは、単に拡大するだけで、スクロールが発生し、単にめくるだけと較べて、オペレーションが増えます。
二段組の場合、いらない箇所が目に入って、理解を妨げがちだということもあります。

というか、別にPDFに限らず、JPEGなどの単に横書き二段組に対応してほしいということです。それならOK?

そもそも横書きって再配置できんだっけ？
以前のバージョンだと実用レベルで動かなかったような

あ、今まさにそれを質問しようかと思ってたのだ。

ご無沙汰しています。
いま、とても忙しくて余り手を入れていられない状況ですが、
>>680
検討させてください。eTilTranにバッチは難しいので、ChainLPのほうで。
>>684
了解です。
>>685
PDF入力はフリーウェアである以上、不可能なのです。
個人でPDFの全データ構造をPDFリーダーなしで再現するのは、かなり難しいので、
Adbeとのライセンスか、もしくはアンテナハウス等サードパテー製ツールが必要です。
なので、PDFを仮想プリンタを使用してJPEGなりBMPなりに変換して利用してください。

あと、それ以前に横書きは、機能的には一応ありますが、サポートしていないに等しいです。
MeTilTranでは縦書きエリアを認識しますが、再配置まではしていません。
こういっては何ですが、元々が縦書き小説を読む助けとして開発したため、
個人的に関心が非常に薄く、対応のためのモチベーションを持つことができそうにありません。
あいすいません。

>>692
乙。

バージョンアップ、期待してます。

乙です。バージョンアップ待ってます。

>>692
いつもありがとうございます。

横書きに興味を抱かせるためには・・・フランス書院に横書きｹﾞﾌﾝｹﾞﾌﾝ

>>692
いつも乙です。
eTilTran使わせて貰っています。
以前からちょっと気になってたので既出だったらすいません。
・縦6000くらいの解像度だと読み込み時にエラーで落ちる。
・回転アルゴリズムの問題か、背景白で端に黒い部分があったりすると四辺の境界部分がギザギザになる。HQBicubic, High共に。
(これは以前自分も自動回転処理プログラム作ってた時に発生してその後補間式を弄ったら解決した憶えがあります。)

ChainLP V0.13
http://no722.cocolog-nifty.com/blog/2008/06/chainlp_v013.html
・暫定的ですが、コミックの傾き補正に対応しました。但し、小説優先の設定に固定されています。
・小説画像に余白除去を行った後、消えてしまったノンブルを転送して復活させる機能を追加しました。
・設定画面を整理して、項目グループ毎にタブで分類しました。

お待たせしました。
忙しくてあまり手を入れていられないのでデバッグや、細かいパラメタなどが足りていませんが、
一応コミック画像の傾き補正やノンブル転送に対応してみました。使ってみてください。

>>696
このツールはVS.NETで開発していて、グラフィックライブラリは.NETを使用していますので、
グラフィックス性能が結構それなりなんです。
縦6000pixelの画像を食わせてみたことは無かったんで気づきませんでしたが、
そういう制限は結構ありそうです。PNG保存も圧縮率がかなりそれなりですし。
とはいえ、グラフィック部分まで自前で用意するのは、私の能力的にちょっと無理っぽいですね。
どうすればいいでしょうね。

>>697
お疲れさまです(・∀・)

>>697
おつっす

>>697
毎度乙です。
そうでしたか、グラフィック処理はコンポーネント使ってらっしゃるんですね。
それならば今更回転処理部分を弄るわけには行かないですね。＾＾；
自分はSDKのみでやるので全部自前で、、逆に面倒で途中で死にました。。ソース途中消去というのもあり。orz

文字検出による補正は届かないとだろうと見て、
やはり漫画用の線検出と斜め補正はハフ変換なのかな。
分割して閾値で剪定して平均値を取るというのは、ちょっと思いつかなかったので参考になったツールです。

>>697
細かい事なんですが当方ATOKを使っているので、MeCabの
設定の「MS-IMEも併用」の項目を設定ファイルに追加して
いただけないでしょうか？
また、同様に「変換時プレビュー」の項目も追加していただけると
助かります。

ChainLP V0.14
http://no722.cocolog-nifty.com/blog/2008/07/chainlp_v014.html
・青空テキストのとき、誤ってレベル調整が効いてしまうバグを修正しました。
・表示プレビュー設定などのチェック状態を保存するようにしました。
・OS画面解像度の120dpi設定でのレイアウトを考慮しました。

>>701
保存するようにしてみました。
最近、VS.NET2008を入れたら、強制的にOffice IME 2007になってしまったんですが、
このIMEでもAPIが変わってしまったらしく、読み変換ができないみたいですね。

>>696
ハフ変換は検討しましたが、速度が遅い、論理的なラインしか得られない、
細線化しないと正確なラインが得られない(しかも細線化は遅い)。
ということで、やめました。

あるピクセルから下方向に探索して、黒ピクセルが見つかったら記録、
さらに数ピクセル横に移動して、また下方向に探索、といった風にして、
点群データを得て、直線性を評価してから、直線なら平均二乗法で角度を計算しています。
これを下方向だけでなく、上方向や左、右など行って、垂直線と水平線を得ています。
このあたりはコミック傾き補正ビューアのプレビューを見ると大体分かると思います。

ただ、分割しているのは、コミック中ほどのコマのラインを得る配慮ですが、
見開きビューアで表示する人たちの用途では、のどの垂直線しか見ないらしいので、
分割する意味はあまり無かったようですね。
ご参考まで。

>>702
お忙しいところ、有難うございましたm(_ _)m
より一層使いやすくなりました。

>>702
乙です。
エチル、メチルにはお世話になってる。

電子書籍端末売れず──ソニーと松下が事実上撤退 - ITmedia News
http://www.itmedia.co.jp/news/articles/0807/01/news122.html