各種フォーマットの作成方法についてや、編集ソフトウェア、
自作図書配布サイトについて語りましょう。
本命のXmdfは無理でしょうが…できるのは青空形式かepub2ですかね？
俺が使ってるのはWinのO's Editor2だけど、
今メインOSがUbuntuなんで気軽にかけないと言うｗ
wine使っても日本語入力がばけるし、
Linux系で青空文庫形式対応したエディタないかなー。
こんなのとか↓
ttp://www.geocities.jp/tamiyagi2/emacs.html おおおお、こんなの有ったんだ、知らなかった、サンクス！
って俺Emacsは使ったこと無い件。
オライリーの本は持ってるんだけど積んである。読むか。
とりあえず青空形式にしておけば、後で他形式へ変換するのもスムーズで安心。
やっぱり縦書きとルビは最低必要ですね。
日本語は縦書きでないとシックリ来ない。
小説しかり、コミックしかり
個人で電子書籍作ろうとしたら
一番障壁になるのは取材面だと思う。
自作の小説・漫画・画集・写真集あたりなら問題ないけど。
ttp://calibre-ebook.com/ ver.0.7.46で（自分的に）最大の変更点
＞When converting non english texts to english for filenames,
＞use the users currect calibre interface language.
＞This allows Japanese/Korean/Vietnamese characters to be
＞correctly converted. Previously they were assumed to be Chinese.
今まで書籍名やcalibreが自動生成する著者名フォルダ名を中国語読み
アルファベット表記にしてくれて使う気が起きなかったのだが、今ver.からは
ちゃんと日本語ローマ字読みになってる。
勉強するソフト変わってくるよね。
とりあえず何でも作れるようにInDesign勉強してるけど
ムズい。
この辺も見てみて
ttp://hpcgi1.nifty.com/hongming/komorebi/wforum.cgi?no=4121&reno=no&oya=4121&mode=msgview&page=20 漢字仮名混じりルビあり文化が日本の成長を妨げてる現況な気ガス
もう公用語を英語にするしかないよ
あるいはローマ字か
現在、日本語縦書きで一番いいのは青空文庫形式だよね
オーサリングはともかくビューアが揃ってる
ePub3.0が正式にリリースされたら、誰かが青空形式→ePub3.0形式の
コンバーター作るだろ。その時点で青空形式は終了(-人-)
ヘッダを少し書き換えて、関連ファイル足してzip圧縮するだけで対応できるだろうね。
それで終了はしないと思うが。
青空形式はePub3への変換用の軽量マークアップ言語として残るだろ。
htmlって書くの結構めんどいし。
いちいち青空形式で入力してから変換みたいな手間はかけないって
青空文庫サイトとしては、参加者が世代交代しない限り、青空文庫形式は無くならないだろうね。
「とりあえずテキスト形式で読めないこともない」ってのも強味だし。
もう簡単にコンバートできるとこあるぞ
ttp://www.byard.jp/book/aozora_epub_convertor.html というかePub2.0対応コンバーターなら、それ以外にも結構あるぞ。
つか3.0なんてまだ紙の上だろ
誰がうまいこと（ｒｙ
コンクールに落ちたというけれど、タダでこんな物が読めるなら高いお金出して単行本を買うのが馬鹿らしくなりますよ。特に女性にお勧めです。
ttp://p.booklog.jp/book/8242 ttp://epubs.jp/watch_video.php?v=52NMA6S73U47 ttp://www.ipad-zine.com/b/545/ ちょっと前に落としてまだ読んでないが消すことにしたわ
ttp://denshi.o-oi.net/ 形式はなにで書くのが良いんだろ。
お気に入りブログをepub化
・シャープ、XMDF形式の電子コンテンツ制作ソフト「XMDFビルダー」を無償提供
ttp://internet.watch.impress.co.jp/docs/news/20110422_441701.html ttp://internet.watch.impress.co.jp/docs/column/yoake/20110428_442981.html >記者A：コンテンツを制作している企業に対して提供するということですが、どういう
>要件なのでしょうか。例えば小規模な、1人でやっている会社でもダウンロード可能
>なのでしょうか。
>中村宏之：一応企業名とか、メールアドレスなどを登録していただきますが、
>事前にチェックすることは難しいので、登録していただいたらダウンロードできる
>ようになっています。
>記者B：企業なのか個人なのか、どうやって判別するのでしょう。さっき、あまり
>チェックしないということでしたが、だとしたら例えば同人誌のサークル名などを
>入力すれば落とせちゃいますよね。
>中村：まあ、ダウンロードできてしまいますね（笑い）。
>記者B：ですよね（笑い）。
やはりDRMについては渡さんというところがミソかな。
> DRMをかける、かけないというのは、販売サイトのビジネスがコントロール
> する問題
とあるけれども、XMDFの配信サーバやビューアの実装が囲い込まれている
現状では例えば販売サイドが独自にDRMを運用する、というのはあり得ない。
結局DRM付きで売りたいなら現状はガラパゴスへお越しを、という事になる。
記事にも出ているけれども同人誌などの小規模出版に関してはシャープが
自ら動いてチャンネルを設けない限りXMDFの出番は無いだろうね。
審査とかあったら、大爆笑だけど。
EPUBだとAdobe Content Serverは個人はともかくある程度の事業者なら
導入出来るものだから、同人誌をDRM付きで販売するストアが出てきても
おかしくはないと思う。
こいつらの会話がどことなく上から目線でキモイのはなぁ～ぜ？
ttp://idpf.org/epub/30 もっとスクリプトとかで自動化できるものかと思ってたらしこしこ指定していくしかないんだな。
一体どんな高機能を期待してたんだよ
印税が高めで、人がまあまあ多いところがいいです。
amazon
アメリカのアマゾン？
日本のアマゾンは自分で電子出版できないようですが？？
何人かの日本の人が出版しているみたいだし。
ttp://www.geekpage.jp/blog/?id=2011/1/14/1 印税→高め
人→いっぱい
両方満たしてるだろ？
いまなら日本語の本はかなり少なく、物珍しさで買う人もいるかもよ？
アメリカのキンドルで日本語表示できないんだが。。。
一般スレならともかく、電子書籍スレなのに。
ttp://www.kotono8.com/2010/07/31newkindle.html 89648 Book Results for "Japanese edition"
縦書きもルビも3.0でバッチシだったぞ。
今日ニュースで出てたけど、どう？
ttp://iphone-lab.net/archives/139102 サイズが大きくて困っています。
ttp://d.hatena.ne.jp/sasaki54te/20110829 snapscanの白黒でスキャン
jpegに一度変換してpdfに再結合
通常のOCRかけた後最適化
clearscanは太い字がつぶれたり
字と字の間に変な縦線が入ったりしたので却下。
松永さん、無理に自分のサイトにリンク貼らないでもｗｗｗ
ほぼ絶版になっていて、図書館でもなかなか見当たらないある本を
テキスト化したんだけど、著作権が切れてるかどうかが確定しなくて、
ネット上にＵＰできずにいるんだ。
海外文学で原作者はとうに亡くなってるんだが。
翻訳者の宇多五郎という人が亡くなっているのかどうか。
亡くなってるなら没年がいつか、知ってる人いないかな。
ちなみに生年は１９０１年らしい。
本当に公開したいんだったら、「相当な努力」を払うことが必要でしょう。
ttp://rnavi.ndl.go.jp/research_guide/entry/theme-honbun-100009.php ttp://www.bunka.go.jp/1tyosaku/c-l/index.html どもです。
とりあえず、没後五十年経過してるんなら、
公開してみようかなあと言うぐらいの気持ちでいるので。
ネットでは没年調べまくったんだけど、出てこなかった。
著作権台帳とか文藝年鑑の存在は知らなかった。
図書館にあるみたいなんで、今度調べに行ってくる。
青空文庫は、著作権切れてるかどうか確定してないと
渡すのもどうかなと思って。
それにあそこは底本がないと、かなり作業滞るみたいだし。
現に欲しくて待ってる某作品なんか、2002年から校正待ちの
ままだし。
それならいっそ、少しぐらい誤字脱字残ってても、自分で公開した方が
早いなあと。
富士通S-1500AかキャノンDR-C125。
どっちがお勧め？
ラーメンか牛丼。
どっちがお勧め？
あなた感じ悪いですよ。
何を主体的にスキャン(食い物の好み)するのかすら示さないで返事求めるなよ
しらないなら黙っていて。
違いなんぞ、その2機種がライバル競売して半年経ってるんだしWEBにいくらでも比較記事・Blog有るだろｗ
その上で何か聞きたいなら、テメエの特殊事情を書かない限り、お前の糞質問には誰も答えねぇよカス
Acrobatが7.0でした。これって9にバージョンアップしても
ちゃんと動くんでしょうか？
ＯＳはＸＰです。
手軽さならDR-C125。
最高解像度で少しでも画質をとか言うならS-1500…というより、フラベを勧める。
カバーの取り込みはどうしてますか？
一枚で長くスキャンしてます？
それとも分割してますか？
どっちが取り扱いが良いでしょうか？
本文と合成してる。
１ページ目→表紙
２ページ目→表見返し
間→本文
最後から１ページ目→裏見返し
最終ページ→裏表紙
って感じ。
Ｎ＠Ｋの内部も社長もすっかりと韓国に蝕されたが
テレビ業界のお偉いさんは、みなさん
金富子の女相場師にお世話になってお金増やしてるらしい。
やっぱりお金を増やす情報を流してくれる金富子さんの韓国を
めちゃくちゃ奉るわけだよね。
周りから聞くと、金さんは相当日本ひいきらしく寄付とか援助も凄いらしいね。
ネットで探すなら、
「 億様の株れしぴ 」 「金富子 株れしぴ」。。
ttp://www.topics.or.jp/localNews/news/2011/12/2011_132339430727.html wktk
いじめをする方は、死ぬ覚悟を決めて、家族と水杯を交わしてお別れをすまし、身辺を整理し、遺書を書いてから、心置きなくいじめましょう。火災保険もお忘れなく。
人間は追い詰めるとなにをするか判りません。
ttp://www45.atwiki.jp/pt2awiki/ Zipにしてまた解凍してxhtmlとcssで作るなら最初からDreamweaverで
サイト作成してブラウザで見れば良いじゃんと思うんだが。
電子書籍専用ビューアでないといかんっていうわけでもないし
ローカルのフォルダにサイトのファイル入れたもの置いておけばそれで
済むよな、ネットに繋いでいればリンクも作動するし
ネイティブアプリでブラウザ自分で実装して配布した方がいい予感
どうせePub市場なんてずっと先だろうし永遠に来ないかも
「ヨミーバ」
ttp://www.yomiba.com/ 手元にすでに絶版になった600ページほどのハードカバー学術書があって
非破壊で自炊したいと考えているんだが、ハンディスキャナでの
自炊って非現実的？
普通のコピー機みたいなスキャナは本が分厚すぎてきれいに取り込めなかった。
何かいい方法があれば教えて欲しい
自炊技術総合6 @電子書籍板
ttp://uni.2ch.net/test/read.cgi/ebooks/1331045534/
ちょっと前に非破壊できれいに自炊する方法はないって話をしてたけど
情報ありがとう
教えてくれたスレの過去ログ読んだけど、非破壊できれいに取り込むのは難しいか…
ttp://rakupla.cocolog-nifty.com/blog/ ttp://www.nikkei.com/article/DGXNASFS1500R_V10C12A6EB1000/ AozoraEpub3 (青空文庫txt→ePub3変換)
ttp://www18.atwiki.jp/hmdev/pages/21.html に関連した報告とか端末仕様の解析で使わせてもらえればと思います
> 注記スタイルの間違いが気になる
青空注記→ePubスタイルの調整し切れていません。
青空文庫のxhtml参考にしてみます。
xhtmlの編集とvertical.css修正で調整効くので、
修正方法指摘してもらえると助かります。
> kepubとepubは別処理の方がいいのでは？
kepub栞対応は容量増えるし、拡張子.kepub.epub選択時のみ有効にします。
> 画像が入ってると強制的にサムネールに使われてしまうんでしょうかね？
表紙設定に [表紙無し] と追加します。
乙であります！
惚れてまう
→1.0.5u1→1.0.6b3と、こちらの指摘通りに修正いただいたのですが、なぜかうまくありません。
具体的には、見開きの挿絵を１枚ずつ全画面表示するために、
［＃改ページ]
＜右画像リンク＞
［＃改ページ］
＜左画像リンク＞
［＃改ページ］
という風に書いて変換をしていましたが、
1.0.5 からは画像との間に空白のページが表示されるようになりました。
そこで該当のxhtmlのソースを調べたところ、
画像表示の直前に改行タグを見つけたため、報告して現在に至るわけですが、
最新の1.0.6b3 でまたもと通り、画像の間に空白ページが表示されてしまいます。
そこで、4→5→6 と、データを比較してみてようやく問題点を特定できました。
物置wikiでいただいた回答
＞文中の［＃改ページ］で前後に分割するように修正した影響で後ろの改行が次ページに出てました。
にある通り、本来ページの最後に入るべき＜br/＞が次のページの頭に移動しているのが問題の本質で、
今回の対策では、移動先のページ先頭の＜br/＞を削除したのみで、
本来あるべき、ページ最後の＜br/＞が消えたままになっている、というのが不具合の原因だと推測します。
とりあえず、これで 1.0.4a 時点の［＃改ページ］処理の状態に戻ると思われます。
1.0.5u1、1.0.6b3のどちらでもエラー
ttp://www.aozora.gr.jp/cards/000230/card1154.html 0002.xhtml を Firefoxでみたときにでるエラーの内容
XML パースエラー: タグの対応が間違っています。終了タグが必要です: </section>
URL: file:///OPS/xhtml/0002.xhtml
行番号: 16, 列番号: 3:
</div><br/>
--^
改行は1.0.4と同じ状態に戻しておきます
画像の場合って余白は0.5文字分付いてますか？
画像のみのページは余白0のスタイルにするとかは対応できそうです。
最終戦争論・戦争史大観は ［＃ここから１６字下げ、２０字詰め］ を認識してなかった
青空注記この複合パターンもあるのか…
スレ借りたはいいけど早速バグ報告スレになってしまた。
お疲れ様です。
ttp://www.aozora.gr.jp/annotation/etc.html ここの「字下げ」を見ると、現在アップされている最終戦争論は、青空文庫の正式な書き方にそっていないような気がしてきました。
［＃ここから１６字下げ、２０字詰め］
↑
このキーワードでググると、結構情報がでてきますね。
とりあえず何となく分かったので、自分で直せそうです。
618 名無しさん＠お腹いっぱい。2012/07/25(水) 21:34:06.67 ID:1rjn6nO8
DRMフリーのEPUB作品の「Growing Up Hummingbird」を
ttp://rakuten.kobobooks.comで直接買ったら そのままダウンロードできて、FirefoxのEPUBReaderアドオンで普通にカラーで中身を見れたよ
ttp://www.epubread.com/ ライブラリを同期するとC:\Users\ユーザー名\AppData\Local\Kobo\Kobo Desktop Edition\kepubに
拡張子なしで保存されるから、それをコピーして「.epub」って拡張子をつければOK （Windows7）
英数字の羅列でぱっと見はなんだか分からないけど、更新時間でソートすればライブラリに登録した順になる
C:\Users\ユーザー名\AppDataは隠しファイルだからフォルダオプションで見えるように設定の変更が必要
接続したKoboも同期すれば本体のメモリの\.kobo\kepubに同じファイルがある
Koboストアから取った青空文庫のやつも、.zipにしたら解凍できて中身が見れたんだが、ここの参考にはならない？
これって既出？
本スレでも技術スレでも既出かと
また、AozoraePub3作者さんはKoboもっていないので
ストアからDRMフリーコンテンツを得ることはできないし
他の人も再配布はできない
参考にできるのはCSSだけになります
（類推はつくけど、本文見れないので、参考になるけど微妙感あり？）
あ、Koboいらないのか…すいません
作品名分かりますか？
それが参考になるかもしれないです
青空文庫だと思ったら全く関係ない本のプレビューを展開してったぽい。
ttp://www18.atwiki.jp/hmdev/pages/21.html - ［＃ここから○字下げ、○字詰め］対応
- ［＃ここから○字下げ、罫囲み］対応
- 改ページ処理の改行を調整
- kepubしおり対応 (栞用span出力チェック時)
- 表紙ファイル指定 (ファイル選択,URL,先頭の挿絵,表紙無し)
試してもらって問題なさそうなら表題周りの処理修正後1.0.6にする予定
gitHubに登録したので、ソースのゴミ消したらコミットします。
優先度の高めの
・青空注記スタイルの対応
・ePub3の解析
・見出しと空行での自動改ページ
・見出しまたは改ページからの目次生成
は少し時間かかりそう。
ついでで一太郎のePub出力のKobo利用も誰か検証してもらえるとものすごく助かります。
.kepub.epubではなくて、.epubの方が快適なら、epub用にスタイル調整した方が良いかも。
楽天の青空文庫はDLして参考にしてみます。
開発ありがとうございます。
取り急ぎ1.0.4から1.0.6b4にしてみたらおかしくなりました。
目次のあと、本文は章のタイトルしか見えず、そして吹っ飛ぶ？
真っ白になったり、次の章まですっ飛んだり（やっぱり本文見えず章だけ見える）
結局最後までは進めませんでした。
時間があったらほかのデータも試してみますが、今日はもう寝ます・・・
理由不明です・・・Chapterも動作してなかったみたいです。
空白ページの発生については、全くの別件だった疑惑が浮上しました。
おおむね結論は出ているのですが、確認してからまた報告します。
そもそも、ページ最後の＜br/＞については、本当に必要なのかどうか疑問が残るし
もしかしたら1.0.6b3の状態が正解なのかもしれません。
（だったらごめんなさい…）
すでにご覧いただいているのでしたら失礼
ttp://uni.2ch.net/test/read.cgi/ebooks/1342916042/61
こちらに、作者氏提供のテストファイルを、拡
張子.epubにした結果が載っています
>.epubの方が快適なら…
この点について、個人的には.epubが理想です
が、現実解にならないのかな？と思っています
そのため、Koboの.epubへの適化は先送りし
有志による情報集約後にするのも一案かと思います
以下、その理由です
類推するに、.kepubの栞機能有効化の労力に
比べて、.epubの問題点の克服はそれなりの手間が
かかります（もしくは難度が異なる）
一つにはKoboに適化したCSSの作成
最大公約数として.kepub体裁を模倣するとし
ても、その手間。また約物体裁をどうするのか
（spanで囲んで半取り？ となると本文に手を
入れる必要がある？）
もう一つはどのようにすれば目次機能を有効化
出来るのか、はたまた.epubでは目次機能は利用
不可なのかの検証
本スレで「.epubと.kepubではエンジンが違う」
といった趣旨の書き込みがありましたが、それが
事実であれば、実質的にKobo Touchは二つの
ePubリーダーが乗っていることになります
利用する側の理論としては、ひとまず大過なく
読める状態にしてほしい、というのがあるでしょう
id振って栞が有効になるのであれば、比較そちら
の方がしやすいのでは？と愚考します
※（おそらく）レンダリング処理に際して、点滅
してしまう.kepubは正直イヤw 1MB弱で10回程度
点滅され、その処理を待たなければならないのはな
あ…
.epubもさらに長文になったら同じようなことが
起きる可能性もあるけど
.kepubはなにもせずに、そこそこの体裁を提供し
てくれるのはありがたい。一方でCSSの指定がより
上位のようなので、CSSでかなり「組める」点も
いいんだけどねー
野良青空文庫を拾ったら目次に
<a href="#chap1">ほにゃらら1</a>
<a href="#chap2">ほにゃらら2</a>
とあって各章の頭に
<a name="chap1">ほにゃらら1</a>
とあります、
しかし青空文庫の工作員マニュアル等見てもこの表記は見当たらず、
目次はXHTMLで各章の見出しから自動的に挿入されるとなっています。
この以下のタグの使い方を説明しているサイトがあれば教えて下さい、
<a name="chap1">ほにゃらら1</a>
手元の野良青空文庫を修正して以降と思いますので・・・
知りたいのって、こういうこと？
ttp://www.tagindex.com/html_tag/link/a_name.html HTMLではそのタグがあるのはわかっていますが、
青空文庫でそのタグが使えることになっているのか？とか
青空文庫でのそのタグの使い方は特殊なのか？とか
もしかするとその野良青空文庫を作った人がわざと</a>を省いたんじゃないか？と思うほど忘れてるし
正規のXHTML版はJavaScriptで目次が自動生成されるようになってる。
ttp://kumihan.aozora.gr.jp/heading.html の説明文中では、変換後の見出しにa nameが使われてる。
ただ実際のXHTML版のソースではa idのような。意味はほぼ同じだけど。
まあその野良は、単にJavaScript無しで目次が機能するように、
自分で直接目次を書いておいたというだけなんじゃ？
要はそういうこと（ページ内リンク）だし。
閉じてないのは記入ミスなのか上記ビューアではエラーにならないとかかな。
ePubの場合はxhtmlエラーになるので除外するしかなさそうだけど、
<a name>の方は見出し代わりに目次生成につかえるかもね。
＞＞124
理解できました
そういうことがあるって思考にありませんでした(^_^;)
基本的に自分用に作った物でしたら作られた方のリーダーに適合するもので当然ですね
公式じゃなくて好意の野良青空文庫なので上手に使わせていただきたいと思います
120から124を見て、何でバグったか判明。
<a name="chap1">ほにゃらら1</a>
の</a>が抜けてた！orz
お騒がせしました。よく見たらWikiに解決方法書いてあるし・・・
で、href/nameタグではChapter動作はしてないようです。
あと、表紙を有効にしたら途中の挿絵が全滅しました。(先頭の挿絵を選択)
無効にすると従来どおりの動作です。
しおりは動いてるようですね。
>107です
試したら、koboからバッチリ0002.xhtmlが見ることができました。
ただ副作用として、字下げした部分の下の表示が少し切れるんですよね。
青空epubが出力したkepubを見ても、なんで自動に改行されないのか、わかりませんでしたが。
ttp://cdn.uploda.cc/img/img5011374d0a7a4.jpg なにやら文書中に、対応する見出しを埋め込んで、それを引用しよう
という流れに見受けられるのですが、（違っていたらスマ）
現行で、おおむね［＃改ページ］ごとに区切られ、xhtmlに小分けされているわけで
目次は、それぞれのxhtmlの先頭へリンクされているのだから、
各xhtmlファイル中の頭から、空行・制御コード・タグ・青空注記等を除いた
先頭の有効な文字列を、頭から改行コードまで引用すればいいんでないのかな？
文章が長すぎれば、上限を決めて後ろはカットすればいいし、
有効な文字列が存在しなければ、空白もしくは（no title)なんかでもいい。
画像しか存在しないと判別できれば、「挿絵」とするとか。
特殊または例外的な使用例があるかもしれませんが、
原則、［＃改ページ］［＃改丁］した次には、
章番号であったり、それを含む章タイトルである確率は非常に高いはず。
これなら、ユーザーはソースファイルを下手にいじる必要もなく
トラブルも起こりにくいと思うんですが、いかがでしょうか？
［＃ここから１６字下げ、２０字詰め］で 上余白16+高さ20のdivになって
36文字のところまで下がはみ出してますね…
全体的な余白とかがおかしくなるかもしれないけど、以下の対策ではみ出し
無くなるかもなので試してしてみてもらえないでしょうか？
vertical.css の 「html {」内に 「height: 100%;」 駄目なら 「body {」 にも 「height: 100%;」 指定
直らなければ字詰め無くても困らなさそうだしとりあえず非対応にします。
ついでに body{ の line-height: 1.75; を変えたら行間変わるかも試してみてください。
kepubだとあまり制御はできなさそうですが。
目次は改ページ文字自動取得で0001とかよりはましになるかもなので、
目次（仮）状態での早めの対応検討してみます。
129のスタイル訂正です。
height:100%は無しで、
vertical.cssの内のjizumeのheightを以下のようにmax-heightに変更で、
div.jizume20 { max-height: 20em; }
div.jizume20 { max-height: 20em; }
↑
これで字下げしたまま、計４行改行してバッチリ表示されるようになりました。
ありがとうございます。
ttp://www18.atwiki.jp/hmdev/pages/21.html - 目次(仮) (本文先頭行＋改ページ後の先頭行(Max32文字)で設定)
- 折り返し字下げ注記で2行目以降のインデントずれを修正 (各行を<p></p>で括る ブロック注記の行は括らない)
- <a .*></a>タグ削除
- ［＃ここから○字下げ、○字詰め］対応 (max-height指定)
目次は仮で、空行を飛ばした先頭行max32文字が出るはずだけどテストは不十分。
他の修正は報告と検証のおかげでだいぶ調整できました。 今日は早めに寝れそうです
お疲れ様です！
ttp://www.dotup.org/uploda/www.dotup.org3241520.zip.html aozoraepub3とaozoraXMDF用のアイコン置いとく
目次の対応乙です。……が
koboの目次って、実はxhtmlのファイルネームだった？
あと、［＃中見出し］で囲ったタイトルが無かったことになっている？
もしくは先頭に入っている空行のキャンセルが実施されていないのかも？
体裁を整えるため、［＃改ページ］のあと、
１行（もしくはそれ以上）あけて章タイトルを入れるパターンも考慮してください。
……画像のみを［＃改ページ］で囲むと悲惨なことになりますね・・・
画像だけのページはその数字のままです。
Readiumで目次見ると画像以外はちゃんと改ページ後の空行下の中見出しの中の文字で
出てるんですが、nav.xhtml自体もうまく作れてない？
画像の方はdivにしてみたけど単ページの場合は100%指定になってないと駄目なのかも。
画像サイズの影響もありそうですが、cssとかのclassも修正しつつうまく出るxhtmlを確認して
みてもらえると助かります。
AozoraEpub3-1.0.6b6 で一応修正
アイコンどうもです。 パッケージに入れておきました。
AozoraXMDFの方は需要無いので放置ですが。
ReaderだとXMDFが快適なんだけどね。
いえ、koboの目次の表示が、nav.xhtmlの表記を反映していないようで、
以前と全く同じ連番表示になっています。（少なくともうちでは）
あと、自動取得で、青空のルビ開始位置を示す「｜」が残っています。
その他……また明日にします。
<a .*></a>タグ削除機能搭載ありがとうございます、
このような機能が搭載できるとは思っていませんでした、
kobo用のepubファイルならば確かに要らないタグなのでepubファイルにしちゃった時点で要らないんですよね、
さっそく試してみます。
いつも読む野良青空文庫変換完了、
<a .*></a>タグ削除が効いてちゃんと表示されます(^_^;)
目次が表示されるようになってますね、
電子書籍の場合実本と違ってパラパラめくって該当の章を見つけるというわけには行かないので目次がとても便利です。
ところで、
目次の行の後ろに[+]という表示が出て
ほにゃらら[+]
その[+]をタップすると
ほにゃらら
戻る 開く
ttp://imepic.jp/20120727/409710 という表示が出るようになりましたがこれはなんだろ・・・
ファイルを解答してnav.xhtmlを見ても[+]の出る行と出ない行の違いがわからない
気持ちを切り替えて、新規で別の文書を変換してkoboに突っ込んだところ、
無事に目次が表示されている……ということで、
既に入っているデータは、PCで上書きせずに一度PCで削除したのち
一度切り離してkoboに消えたことを認識させてからもう一度接続して
PCから転送してやると、目次が表示されるようになりました。
目次のデータって、上書きされないんだろうか？
もし途中で構成を変えたデータを作って反映されなかったとしても
上記の方法でリセットすればいいようです。
本当はもっとスマートな方法があればいいんだけど…。
なんかkoboで削除すると同じファイルネームの文書を認識しない…
みたいなことをどこかでみたのでちょっとビビっている。
目次の[+]は、単に表題が長すぎて表示しきれなくて、
続きがありますよ、という意味だと思います。
だから、[+]だけタップすると、全文が表示されるみたいな。
ちなみに、目次には全角２３文字まで表示できるようですね。
ttp://www18.atwiki.jp/hmdev/pages/21.html - 目次(仮)の置換漏れ修正
- ファイル名からタイトル作者設定
表題取得周り(副題に対応、確認画面)ができて、他も問題なさそうならβとれるかな。
- 青空文庫のファイルで <メールアドレス> の記載がのエラーに対応 ("<"→"<" ">"→">" にすべて置換)
<と>はすべて置換したので、xhtmlエラーは減ったと思う。
青空文庫収録の作品は例外結構あるのでKoboストアからの方が確実かな。
- β6あたりからimgタグの画像が出なくなっていたので修正
他に乗り換えるのに、何か良いソフトは無いですか？
ePub3出力は結構シンプルだったけど、スタイルもそこそこしっかり対応してるっぽい。
でも無料じゃないんだよねぇ。
手持ちの野良青空文庫変換して読んでいますがもう問題はないといっても過言ではありません^^;
挿絵もきちんと入るし突発的に白ページが挟まることもなくなりました、
koboで見れないんでしょうか？
ttp://www.aozora.gr.jp/cards/000912/card4673.html これなるテキストファイルを適当に選んで変換してkoboに放り込みましたがライブラリに現れてくれません。
何が原因なんでしょう？
本体を初期化しました 失礼しました
別フォルダ内に格納されている挿絵（JPG）は，反映されていますか?
当方では，
画像ファイルなし: <IMG SRC="img/01_001.jpg">
といったエラーがでてしまいます。
青空文庫のテキストファイルと同じディレクトリにあるイメージフォルダの中に入っている画像のことですよね？
AozoraEpub3で変換後はきちんとEpub内に格納されていてkoboで文中で挿絵として表示されます。
20作品くらい変換しましたが、今までこれに失敗したことはありません、
koboの方はカスタムファームウェアを入れてるけど関係あるかな？
ttp://www49.atwiki.jp/kobotouch/pages/24.html 文章込みのブロックと、画像のみのブロックで
表示スタイルを変えているようなのですが、
どの部分でそれらを決めているのか教えてください。
何となく、画像のみを［＃改ページ］で囲ったときに発生する
空白ページの正体が見えてきたような気がするので確かめてみたい。
後から変更できる部分でないと検証できないかもですが。
それから、文章ページの上下のスペースを大まかにでも変更できるような
設定メニューがほしい。
個人的には上部スペースをもう少し詰めたいわけですが。
まさかタグを大文字にしている青空テキストがあるのかと(ry
…
IMGタグのSRCの値を取り出す処理が小文字しか認識してなかた。
連絡助かります。次のバグFixで直しておきます。
ジワジワきたw
いつもありがとう。
がんばってください！
現状は画像だけのページも本文内の画像と同じ処理しかしていません。
前後改行の画像のみのページはvertilcal.cssではなく画像用の余白のない
image.cssを作っておいてそちらをページに設定はできそうです。
余白設定については、kepubでその辺の調整がどこまできくかがちょっと不明ですが、
設定画面で余白等スタイル調整機能は検討してます。
＞現状は画像だけのページも本文内の画像と同じ処理しかしていません。
これは、ある意味納得なのですが、
文字が混在すると、単体に比べて画像が縮小されて表示されるのが
いったいどの部分の影響なのかとても気になります。
余白はvertical.cssのbodyのpaddingのみ影響しています。
画像ページのxhtmlで<body class="cover">にすると vertical.cssのbody.cover
(paddingとmarginが0で縦横100%のスタイル)が優先で適用されるので、
xhtmlのbodyのみ修正してみたら余白は無くなるかも。
画像のサイズによって100%指定で縦横比がおかしくなる場合はdivの方にも
スタイル設定が必要そうです。
ChainLPのePubはimgの方に幅高さがあるんですが、汎用的にするなら
100%指定でうまくいくように調整するのがよさそうです。
更新ありがとう。
プロパティで変更すりゃいいの？
画像のみで空白ページができるのは、ページ開始時に自動で入る余白があり
全体から余白を除いた空きスペースに画像が入りきらないときに
自動的に次のページに押し出していたため、見た目が空白になるようです。
うちの環境では、デフォルトでは縦横780x582の比率より横が長ければ
押し出されて空白ページとなっているようでした。
で、vertical.cssのbodyのpaddingを三つ0にしたところ、
空白ページは解消されましたが、上下と右に微妙な隙間があきます。
次に、<body>を<body class="cover">に置き換えた場合は、
縦横800x600の画像はびっちり100%隙間無く表示されました。
ちなみに、800x600より小さい画像は右上詰めで表示され、
大きい画像は、縦横比の長い方が100%になるように右上詰めで表示されます。
いずれもアスペクト比の狂いはありません。
というわけで、個人的には、<body class="cover">がデフォルト、
もしくは、どこか設定で選択できるようになっていてほしいです。
よろしくお願いします。
画像はみ出しの調査たすかりました。
何となく挙動が分かってきました。
vertical.cssのbodyの方で margin: 0; padding: 0; の両方指定でも800x600の画像のみを全画面表示
できそうですが、横が長めの画像だとはみ出しそうなのと、文字が入ると文字の方の余白に問題でそうですね。
まずは画像単ページの場合のみ<body class="cover">にするようにしてみます。
前処理でページが画像単ページか判断する部分にもう少し時間がかかりそうです。
jarなので、ショートカットのアイコンはプロパティの「アイコンの変更」から設定してください。
jar起動用のexeを作れば設定できそうだけど、セキュリティとか面倒そうなので対応予定なしです。
目次の作り方がどうしてもわからない
例をあげると
［＃改ページ］第一章
あっちゃんあっちゃんあっちゃんあっちゃんあっちゃん
あっちゃんあっちゃんあっちゃんあっちゃんあっちゃん
あっちゃんあっちゃんあっちゃんあっちゃんあっちゃん
［＃改ページ］第二章
とうちゃんとうちゃんとうちゃんとうちゃんとうちゃん
とうちゃんとうちゃんとうちゃんとうちゃんとうちゃん
とうちゃんとうちゃんとうちゃんとうちゃんとうちゃん
［＃改ページ］第三章
かあちゃんかあちゃんかあちゃんかあちゃん
かあちゃんかあちゃんかあちゃんかあちゃん
かあちゃんかあちゃんかあちゃんかあちゃん
この第何章とかの部分だけを目次にしたいんだけども
置換機能で一括で置き換えるとして
何のタグをどこにどうつけたらいいのか教えてください
目次はまだ(仮)状態で使いにくいですが、
［＃改ページ］の後ろまたは次の行(空行空白除く)の本文を利用しています。
先頭の章のみ表題行設定されてるとタイトルと著作者の次の本文が使われます。
第一章の前に［＃改ページ］があると、0001とかタイトルの目次が作られます。
以下のような書き方で第一章～第四章の目次ができます。
(第二章～第四章の記述はお好みで)
--------ここから
タイトル (←表題設定でこの行は目次に使われない)
著者名 (←表題設定でこの行は目次に使われない)
第一章
あっちゃんあっちゃんあっちゃんあっちゃんあっちゃん
…
［＃改ページ］第二章
とうちゃんとうちゃんとうちゃんとうちゃんとうちゃん
…
［＃改ページ］
第三章
かあちゃんかあちゃんかあちゃんかあちゃん
…
［＃改ページ］
第四章
じいちゃんじいちゃんじいちゃんじいちゃん
…
--------ここまで
目次の確認はepubをzipとして解凍して OPS/xhtml/nav.xhtml で。
大見出し中見出し小見出し注記で改ページ関係なく階層目次作るとか、
章っぽい行を自動判別とかはやりたいけど対応はまだ先っぽい。
-----------
TOC
1.第一章
2.第二章
3.第三章
4.第四章
・
・
・
-----------
となってました、koboのほうでは目次がグレースケールになっていて選択できません。
自分よくわかってないのでどこか基本的なところでミスしてるのかもしれません。
とりあえずもう少し色々やってみます。ありがとう。
の対処法は試してみた？
アドバイスありがとう。
koboを工場出荷状態に戻してからやってみましたが、目次グレースケールでした。
章分け自体はされてるんですよね。
firefoxのアドオンのEPUBReaderを使って、
そちらで読むと、章タイトルは出ないんですが1,2,3,4,…て感じで章分けされてるのがわかります。
ていうか全く自分の側のミスでした。
koboへのファイル移動にcalibreを使っているんですが、
あのソフトが.kepub.epubを勝手に.epubに直してました。
一旦calibreの専用のフォルダに入ってそれからkoboに転送されるんですが、
元ファイルばかり見ていて、そっちを確認してなかった自分のうっかりミスです。
なので再び工場出荷状態に戻して、
calibreを使わずkoboに直接入れて同期させました。
今度は目次も完璧に動作してます。
自分のkoboはkoboデスクトップの同期を数回も使うと
挙動がおかしくなるので
アクチ時以外はcalibreが良かったんですが、自作の.kepub.epubの場合
今はまだ使わないほうがいいようです。
お手間と時間をとらせてしまい、申し訳ありませんでした。
不具合報告をするときに
操作手順を漏らさず記載することがいかに重要かがよく分かる
経過だな。
端折って「うまくいきません」って結果だけ書く輩が多くて、
ソフトウェア作者やサポートの中の人って大変だなって思うわ。
半分ぐらいは駄目KDが原因ぽいし。
あとはスレ的に内容が電書作成に役立つといいんだけどね。
＞(上下の行が［＃改ページ］で挟まれている画像注記、先頭行の画像は下が［＃改ページ］のみ)
以上において、koboにてb10までと挙動の変化がみられないのですが、
どこをみれば、変更後のデータとして正常なのかそうでないのか、わかるか場所を教えてください。
○わかる
<imgの方のみで［＃（画像.jpg）］注記の方がマッチしてなかったです(ノ∀`)
ttps://github.com/hmdev/AozoraEpub3/downloads の1.0.6b13で修正したので試してみてください。
vertical_image.cssが読まれていて <body class="fit">になっていれば適用されています。
実質改ページが入っていない場合が多いので、画像サイズで自動単ページ化する処理も
入れたいけど、ブロック注記内か判断できるようにならないとページ分割できないので、
対応はまだ先っぽい。
Koboの拡張子.epub時はAdobeRMSDKっぽいので、目次が使えるようになったかも。
こっちの方が軽いなら、余白と傍線が逆なのを設定できるようにすれば実用可能かも。
詳細は随時以下にまとめていく予定です。
ttps://github.com/hmdev/AozoraEpub3/wiki/%E5%8B%95%E4%BD%9C%E7%A2%BA%E8%AA%8D%E7%8A%B6%E6%B3%81 有料でも構いません。
縦書きEPUB3の生成もできるソフトは。
情報どうもです。
一太郎、早速調べてみたら、epubファイル読み込み非対応らしいですね。
ttp://support.justsystems.com/faq/1032/app/servlet/qadoc?QID=051715 読み込み対応してくれないかな？
前にも出てたけど
ttp://code.google.com/p/sigil/ Sigilはepub2までの対応だよね
epub3だとFuseってのがあるけど、どうだろう
情報どうもです。
Sigilは無料なのはありがたいですが、
とか見ると、バグが多くて、使いにくい感じみたいですね。
バージョンアップされたら解決するのでしょうか。
情報どうもです。
FUSEe、これ↓ですね。
ttp://www.amazon.co.jp/dp/B0046XJB6Q/ 値段が35000円辺りで、ちょっと高めですね。
使い勝手はどうなのでしょうか。
まだβ版ってことで無料で使えるバージョンもある
HPから落とせたはずだよ
これで正常なのでしょうか？
FUSEe βは、製品版と違い、WYSIWYGでの文字等の入力が出来ないと思います。
タグ入力必須で、編集とか相当面倒くさいのではないかと思います。
製品版が、もう少し安くて、使用感のレビューとかあれば、検討するのですが。
(URL略)
右も左もない、ただ「日本」のみが主題となる言論誌。それが「言志」。
戦後保守と訣別した、新しい潮流が今ここに！
◆「言志」公式HP
ttp://www.genshi-net.com/ 他に、手になじんだHTMLエディタとかあるとかなり使えるようになる。
もちろん、本人にHTML(XHTML)とCSSの知識も必要だけど。
Koboが無いので暇な人誰か以下のePubの動作確認してみてもらえると助かります。
↓にある dogura_magura_*.epub の4ファイル
ttps://github.com/hmdev/AozoraEpub3/downloads 確かに大分早くなりますね。
今までページめくりした時、一拍置いてページ表示
されていたのが瞬時に表示される様になったように感じます。
とその前に、
dogura_maguraってどうやらファイル全部読み込むまで点滅終わらないけどこれって何とかならないのかなぁ？
.epubの場合
<BR>の方はページめくりが2秒くらい、
<P>の方はページめくりが1秒くらい
ちょうど半分になった
.kepub.epubの方は
どっちも指をこすった瞬間にページめくりが完了するので差がわからなかった
拡張子を.kepub.epubにするとファイルを全部キャッシュに読み込んでるような感じ、
試しに*..kepub.epubのファイルの拡張子を*..epubに変更してみると
やっぱりメージめくりにそれぞれ2秒と1秒というのんびりしたページめくりに
Readerで<br>だと固まって使い物にならなかったけどkepubだと速度関係ないのか。
あの点滅は伊達じゃない？
Kobo再キャンペーンでポチったのでスタイル周りとかはもう少し最適化はできそうです。
ドグラ・マグラも10個くらいの章にわかれていたら点滅しなくなるんだろうな・・・
青空文庫からDLしたテキストに適当に
［＃改ページ］
を入れて分割して、AozoraEpub3でEPUB化してみたら？
って言うけど文章中に謎の空白が出来るってことでしょ？
容量決まってるでしょ？
改ページ処理される訳だから
文章中に謎の空白なんて出来ないが？
本文中に改行だけの行が頻出するから
500行毎に改行だけの行を検索して［＃改ページ］を入れてみた
AozoraEpub3で変換して
koboからもくじを見ると10章くらいに分割されて
キャッシュに読み込むため点滅もしなくなった
ファイル名からとか確認画面ができたのでちょっと使い道が微妙。
表題と著者名の行のスタイル調整はこの指定でやってますが、
確認画面とは連動していないのでよく分からん状態になってます。
ただのテキスト変換とかはファイル名からにするぐらいで、基本は「表題+著者名」で。
どのへんを確認すればいい？
全部の挿絵というわけでなく、
ライトノベルによくある本文前に何ページかあるイラストその一番最初の絵の前に真っ白の空白ページが差し込まれる
仕様かな？
本スレネタだと思うけど
紙本と電書では、挿絵が違うそうな
違うというより、電書版は挿絵抜いてある
某社のラノベはそんな感じらしい
世界で唯一の出版元を除いてすべてがつぶれていくんだろうと思う
googleが本気出せば全てがひとたまりもないけど
今のところ新人相手の無料書籍を儲け度外視でやってくれるのは
アマゾンだけ。それゆえ今度の日本語対応は期待しているが
パブリッシュプログラムももちろん日本語対応で出るんだよね
UTF-16以下の異体字の代替文字の一覧があれば置換できそうなんだが
そのへんの情報とかってどこかにない？
外字フォント埋め込みができるのが一番良いいんだろうけど
外字の世界は深いのでなかなか手がだせんです
koboで表紙が表示されないのですが
何が問題なのでしょうか？
詳細情報等あればwikiのコメント欄にでもお願いします
画像は現状リサイズなし出力して、拡張子でフォーマット指定しているだけなのでその辺かも
今後のReaderのはみ出し対策や余白無し単ページ化の実装するときに画像周りは調整予定
電子書籍端末が画像に強くないのでいろいろと最適化は必要になりそう
事前に600×800にリサイズしたPNGでも表示されないです
表紙の指定方法とか同じで以前旧バージョン(1.0.6b14～23辺りのどれか)で変換してあったものはkoboで表紙は表示されます
PCではESPERで確認してるのですがESPER上ではAozoraEpub3-1.0.6b29で変換したファイルでも表紙は表示されます
［＃ここから表組
［＃ここから表罫囲み］
とかいうタグがあるけど、これせめて区切りコード指定してくれないとどうしようもないよね
寺田寅彦 比較言語学における とかはタブコードを入れてるみたいだけど
マルサス 人口論 は 全角／ で
夢野久作 暗黒公使 なんかどうしろと
半角の特殊文字の置換をお願いします
＆ ＆ａｍｐ；
” ＆ｑｕｏｔ；
＜ ＆ｌｔ；
＞ ＆ｇｔ；
c ＆ｃｏｐｙ；
うちのKoboだと特に問題ないんだけど、DB壊れてる？
表示できないファイルアップしてもらえればこっちでも試してみます
1.0.6b35で直しておきました。
< と > の変換はしてたけど & は忘れてた…
" と ' と ` は問題なさそうなのでそのままで。
駄目なら replace.txt に書けばとりあえず置換はできます
ｋｏｂｏスレで上がってた
(一般小説)[岡本綺堂] 岡本綺堂の怪談奇談・青空百話.kepub.epub
(一般小説)[田中貢太郎] 田中貢太郎の怪談・奇談青空百話.kepub.epub
ttp://kie.nu/kqH これら入れても表紙出ません
今までの事はファイル選択時の表紙です
読書時は画像表示されます
うちのKoboはホームでもライブラリでも表紙出てるのでKoboをリセットした方がいいかも
あと、© は該当する青空注記は以下で定義されていてこれで書けば変換されます
※［＃著作権表示記号、1-9-6］
表組は工作員マニュアルにスペースと罫線使うように書いてあるけど
勝手に注記定義されてるともう無理…
その他のやっかいな注記
窓見出し、割り注、横書き、２段組もePubのcssで汎用的に対応するのはちょっと厳しそう
［＃当時は食べない］
的な説明注記が全カットされるんですが
自分は説明注記いらないのでそこはあまり対応する気はないです
素早い対応ありがとうございます。
確認しました。
そういうのは入力編集用のタグだから出力に出なくても仕方ないんじゃないの？
コメントアウトして HTML に埋め込んでもしょうがないでしょ？
で認識出来ないタグを画面に出したら場合によっては読辛くてしょうがいないでしょ？
たとえば
〔＃「△△△」はゴシック体］
とか大量にあるファイルがあるけど、こんなのそのまま出たら読み辛い。
〔＃「△△△」は太字］
に置換したけどね。
でもなかには
〔＃「「△△△」」は太字］
となってるのもあって、これは変換出来ないみたい ここから ～ ここまで式に置換した
というわけで、出したいタグは＃を消すか そのまえに空白でも入れるように編集したらどうだろ？
ありがとうございました
出したいタグは事前に編集しようと思います
半角の"|"は変換できない…
小説を読もう！ではどちらでもいい、みたいなんですねぇ
青空関係ないですけど
ttp://www.aozora.gr.jp/cards/000291/card24370.html とか ------------ の -が１個足りないだけで全文コメントアウトされちゃう。
・・・・でも 仕方ないか
replace.txtに追記して共有するか、
同拡張して、ファイル名で絞って適用するreplace_??.txtを選ぶとかしないとね
作者に対応求めるばかりではあまりにあれなので、せめて問題のある.kepub.epubをどこかにあげましょう
著作権的にまずければ、問題箇所数行でも
そうすれば他の人も問題点を調べられます
IVSではなくて？
コメント行はさすがに54文字守られてると思ったけどこんなところに罠が…
48文字以上とか緩くしつつ、閉じてなかったらエラー出すようにはしておきます
IVSいまいち理解が足りないけど
UTF32出せない時点で、異体字セレクタにもKoboとか対応できなさそう
電子書籍端末やビューアの縦書きでのIVSへの対応状況ってどんな感じなんだろう？
でもって、Koboの外字を画像に置き換えとか面倒なので、4バイト文字を似たような
2バイト文字で置き換えて表示できれば出ないよりはいいかなぐらいで考えてます
例: 「歯＋句」、U+2B81A → 齣
あ、いや もし対応してくれるなら 48文字以上54未満の行で警告を表示してくれるだけの方がいいかも
たまに 長い----が章区切りで入ってたりするから
だからコメントアウト後に10行以上コメントアウトしたら、コメントアウトしてるけどいいの？ てな警告が欲しい
底本：ｘｘｘｘ
の行を自動的にファイルにしてくれるのは１冊だけなら便利でいいのだけど
100ファイルとか連結してると 目次が肥大してちょっと不便。
とりあえずエディタの置換で底本：ｘｘｘｘの前と後にコメントアウトいれて対応してるけど・・・・
前者は未対応でも元文字表示はするんじゃないかな？
まあ、それじゃ葛飾区も正しく表記できないので、対応しているのかもしれない
UTF-32は単に固定長でDB都合がいいから、とかくらいにしか使われてないと思われ
UTF-16BE/LEでIVSは扱えたと思う。たぶん、おそらくw
後者はサロゲートペアのことかな？
どちらも検証環境は会社にしかないので当分わからんw
これ、対応している生成側は、DTPアプリくらいじゃないかなあ？
とにかく、EPUB3をKoboでなら、NetFront BookReaderの仕様に依存すると思うので、そこから判断つくかもしれない
半ばの他リーダー対応で言えば、最近Kinoppyが上記二点に対応した
紀伊國屋書店Kinoppy 1.2.2 (iPhone/iPad) EPUB3 Fixed LayoutやOMF(Open Manga Format)などに対応
ttp://cotoha.jp/2012/08/kinoppy-for-ios-122.html すまんこ、他はわからない
b32で「底本：」で改ページして目次に「奥付」と出すよフラグONのままだったけど
b33以降は改ページしても目次には出さない仕様にしてるけど直ってない？
Koboだと異体字セレクタの方が空欄か豆腐で出そうな気もするけど
ePubの仕様的にはUTF32で出さずにIVSで出すべき？
UTF32→IVSの対応表があれば前の2バイト文字だけ使えばKoboでも
表示ができるようになりそうだけど、そのへんの変換でググってみます
情報いろいろthx
底本で文字なしの目次出てた('A`)…
b36で更新しておきます。
未対応なら、豆腐ですね
参考→Unicode対応範囲確認サイト-日本語環境
ttp://www.est.co.jp/fe/fonttest/japanese-list.html これをうまく変換すれば、Koboで検証できると思います
出先でずっとスマホなので、豆腐しか見られないw
EPUBもいわゆるブラウザでの表示があたりまえのあたり、IVSでは？
あと、32と16は固定長か否かという認識ですが（当方プログラムは門外漢）、IVSと排他ではないような…
対応表というのは見たことないなあ
というか、上記の認識なので対応表というものがあり得るとは思いもよらない
備考
kobobooks.comの青空に関しては、DRMがかかっているため確定事項でないけど、外字が画像化されている模様
（我が輩は猫であるとか、それらしきファイルがある）
実際に読んだわけではないし（軽小説しかw）、画像化されているからといって可不可も断言できないので、ちょっとこれは検証するまでなんとも
早速対応ありがとう。 定本： ＝＞ 文字なしの目次が消えたの確認しました。
それから
[WARN] コメントが 16 行以上
というのが変換前に出るようになりました。 もしかしてコメントアウトした総数を数えていませんか？
コメントアウトから コメントアウト終了までの行数で出して頂けるとありがたいです。
前後に半角文字があると自動縦中横してないのでそれかも
!と?は優先的に処理した方が良いかもしれない
WARNはコメント毎のコメント内行数になっててb37で行番号も出すようにしました
コメント内行数でエラーありがとうございます。 これでほぼ確実に検出出来そうです。
外字は画像ってあたりまえじゃないの？
元
「嘘を吐《つ》け。羊羹［＃「羊羹」は底本では「羊※［＃「羹」の「大」に代えて「人」、268-下-20］」］なんて
出力
「嘘を<ruby>吐<rt>つ</rt></ruby>け。羊羹（「羹」の「大」に代えて「人」）</span>」］なんて
と余分な </span> が入ります。
報告まで
DDF ※［＃中に点のある右に傾いた平行四辺形（fig46187_02.png）、96-15］
19F＋44※［＃中に点のある△を右に90度傾けた三角形（fig46187_03.png）、96-15］
357※［＃中に点のある△を左に90度傾けた三角形（fig46187_04.png）、96-15］
って文字の埋め込み 難しい？
芥川龍之介 邪宗門に 返り点 ［＃四］があります
未［＃四］曾有［＃三］一事不［＃レ］被［＃二］無常呑［＃一］
一応外字注記で画像指定があった場合は※をとって画像注記に変更し
文中の画像注記を中寄せで表示するようにしたけどKoboのみ位置が右寄せになってる模様で調査中
画像サイズで文字画像と判断して幅を文字幅と同じにするとかは未実装
外字画像用のスタイルは↑で調整できそうだけど、外字を画像にするか代替文字にするか
埋め込みフォント使うかはもう少し検討してみる
10第
章
って感じになるんですが？
以前(b35とか)は
第
10
章
って表示されますが旧バージョンでの変換では同ファイルは目次削らないとファイル開けないんです
も含め全てはPC上(espur)でのチェック段階での話です
b38で縦中横下の外字画像がずれないようにしたときの、
縦中横のpタグ内のdivのinline-blockを処理できていなかった模様
spanのinline-blockにしたらなおったぽいので他への影響確認後に更新しておきます
PC用のビューアは以下がおすすめで、基本上2つと実機で確認してます
・Adobe Digital Editions 1.8.3 (RMSDK : Sony Reader ※1.7系は駄目)
ttp://labs.adobe.com/technologies/digitaleditions1-8/ ・Readium (Chrome アプリケーション) (NetFront : Kobo)
ttp://readium.org/ ・Kindle Previewer (WebKit? : Kindle)
ttp://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000765261 ・FUSEe β (調査中 ※xhtmlエラーが確認できる？)
ttp://beta.fusee.jp/ 一応kobo用に変換してるので個人的にはkoboで問題無いなら取り敢えずOKですが
今後も改良お願いします
>ゴシック体注記対応 (Koboはデフォルトフォント時のみ有効 太字にはならない)
これってエラーにならなくなっただけですか？
それともKoboデフォルトフォント時のみでゴシック体表示されるって事でしょうか？
どちらにしてもKoboデフォルトフォントのみ有効ならば
結局、編集すると思うのでエラーログは出して欲しいです
Koboで別のフォント選択時はfont-famlyの指定が効かないのと、
スタイルでフォント指定時は太字スタイルが無視されます。
（Koboのフォント変更時は外字も小さい明朝表示になるので無理してるのかも）
ゴシック体はePub的には正しい状態でエラーログは出なくなってるけど
例外的にログが出るようにしておきます。
置換については、chuki_tag.txtの <span class="gtc"> → <span class="b">
に変更でゴシック体が太字扱いになるけど、アップデートで上書きされてしまうため
別ファイルで設定できるようにするとか検討します。
Koboリセットした影響か、太字が表示されるようになった
<span class="gtc"> → <span class="gtc b">で
Koboデフォルトフォント → 太字ゴシック
Koboフォント指定 → 太字
Reader → ゴシック
になるので、次の更新の時にとりあえずこの状態にして、ログは特に出さないままにします。
確認後KoboのファームアップしたけどePubのスタイルで変わったところはなさそうな感じ。
与謝野晶子 註釈與謝野寛全集 にて
［＃ここから２字下げ、２０字詰め］
・・・・
［＃ここで字下げ終わり］
というのが多数あるのですが、このタグ毎に字下げと地上げが大きくなり 最後には横書きになります。
”、２０字詰め”とかを全部削除して対応したのですが
報告まで
わたしは、２０字詰めにならず、２０字オーバーしてしまいますけど…
後で直して夜にでも更新しておきます。
太字とゴシック体注記はcssの方を修正してどちらもゴシック太字指定にして
KoboとReaderの両方でそれなりの表示になるようにする予定。
文字コードがANSIだと問題なく使えるのですが
ANSIで表示できない文字がある場合
UnicordやUTF-8で保存してドロップすると
文字化けしたり本が開けなかったりします
なにか対応策ってありますか？
レスありがとうございます
恥ずかしながらUTF-8の設定があることを見落としていました
さんのおかげでできました！ありがとうございます
機能を若干削った廉価版で、1万円台に値下げしてくれないかな？
機能限定版なら無料で落とせるんじゃないの？
無料のは削られすぎてるのかな？
それでいい人もいるだろうけど
タイトル、副題、著者名の順で3行連続で書いてるのですがまともに反映されません
設定を表題+著者名だと[副題] タイトル.kepub
設定を著者名+表題だと[タイトル] 副題+著者名.kepubになります
AozoraEpub3-1.0.6b44では
設定を表題+著者名でちゃんと[著者名] タイトル+副題.kepubで反映されるのですが…
2行目が「―」でなく3行目が「訳」「編纂」「校訂」で終わっていたら
2行目を著者にするようにb45以降調整してます。
3行目の著者名に「訳」とかついています？
「表題→著者(副題優先)」を追加してb44と同様の処理になるように
b51で修正しましたが、タイトル周りの自動判別は難しい。。。
バッチリでした
>3行目の著者名に「訳」とかついています？
試した物は
著者名／翻訳者名 訳
って感じです
統一させたくて自分でこの形態に書き換えてるので青空文庫と整合性取れなくても仕方ないのです(こちらの所為ですので)
1.0.6b44まではOKだったので今までのを全部再変換用に書き換えるのは辛くて
お手数掛けてすみませんでした
あと、目次から特定のIDの画像までのリンクを張れれば、わたし好みの画像kebubができるんだけど、
そもそもそんなことできるの？ 教えて中の人。
OPS/xhtml/nav.xml (Kobo用) と OPS/toc.ncx (Reader,Kindle用)
に設定されてます
ページ内に複数の画像を入れてxhtmlファイルの先頭以外に飛びたい場合は
飛ぶ先のタグが<div id="id1">なら href="0001.xhtml#id1" のように
ファイル名の後ろに#とIDつければいけるはず
画像ePub作成時のスタイルの参考にしたいので、タグの変更点とか
画像のサイズとまとめ方等フィードバックしてもらえると助かります
マジで宜しくお願いします。
乞食ですみますん。
ご察しの通り、１つのxhtmlの中に複数枚の画像を詰め込んだだけです。
具体的には、画像単ページの
<span class="img"><img src="../images/0001.jpg"/></span>
↓を
<span class="img">
<img src="../images/0001.jpg" id="kobo.1"/>
<img src="../images/0002.jpg" id="kobo.2"/>
<img src="../images/0003.jpg" id="kobo.3"/>
<img src="../images/0004.jpg" id="kobo.4"/>
<img src="../images/0005.jpg" id="kobo.5"/>
<img src="../images/0006.jpg" id="kobo.6"/>
<img src="../images/0007.jpg" id="kobo.7"/>
<img src="../images/0008.jpg" id="kobo.8"/>
<img src="../images/0009.jpg" id="kobo.9"/>
<img src="../images/0010.jpg" id="kobo.10"/>
</span>
という感じにしただけですね。
ちなみに、IDは、"kobo."がついていれば、数字は１個あればしおりが効きます。
ついでに言えば、１つのxhtmlの中でかぶっていなければ、
別のxhtmlで同じIDがあってもきちんとしおりは効くようです。
<div id="kobo.1">でもしおりは効きますが、
いずれにしても目次からのリンクを張ることがかないません。
今のところ、目的の画像への目次を作るには、
そこが先頭になるようにxhtmlを小分けにするしかない状態です。
最後に残念なお知らせとして、
わたしはその都度画像を800x600や1200x900など、4:3に成形してから突っ込んでいるのですが
よくある縦長の画像だと右に寄ってしまいますね。てへ
（改善の余地があるなら、お願いしたいです）
<body class="fit_w">
にしておくと、自動的に横幅が画面いっぱいまで拡大されて隙間がなくなり、
厳密には縦横比が変わってしまうけど、元画像によってはこれでもアリかも。
全て同じ比率で4:3に近くないとマズそうですが。
xhtmlにまとめたら読み込み時にページ切り替えがもたついたんだけど
もしかして全画像を一つのxhtmlに書いてる？
xhtmlにまとめるとDBが肥大化しないのと反転しなくなるという利点が
あるので、初回の読み込み時間とか問題ないならそれもありかも。
画像の中央寄せは、縦書きの場合はtableタグかcssのdisplayと同様に
して、vertical-align:middle にするとできます。
画像だけならページ自体を横書きにして divで括ってのtext-aling:center
指定にした方が動作は軽くなるかもしれない。
画像はサイズが取得できるようになったのでスタイルはそこそこ調整できそう。
xhtml途中への目次での移動は、文字の場合もまだこちらで検証して
いないので、目次関連の実装時にいろいろ試してみます
直接、特定のIDの画像へのリンクが可能なことがわかった。
いかにも小説ファイル向けの目次ページのような気がするが、
うまく利用できないか研究してみよう。
横書きだが、ルビが表示されている。
どうやって作っているのだろう。
青空文庫形式のテキストを、このように変換することはできないものか。
青空文庫の作者別まとめとか作っても、ファイル連結して１回通すだけで殆どＯＫになった
ダメなのも ----- の数の違いとかチャンとコメント出るし場所も判る。
しかもいちいち nav.xhtml->0000.xhtmlして package.opf弄ってたのさえやってくれるようになった。
nav.xhtml から要らないリンク消すだけでいい
作者さんありがとう。
いっそ、画像のサムネイル表示などはどうだろうか？
最新のAozoraEpub3(1.0.7a4以降)は目次が出力されるようになっている。
青空テキストを変換したEpub3を、KindlePreviewer(もしくはkindlegen)
でmobiにすると、kindle 4で、横書きだが、ルビと目次つきで読むことが
できる。
大助かりです。有難う。
・画像は縦横4:3にする。
・画像ページは、<body class="fit_w"> にする。
・不要なxhtmlは削除する。
・nav.xhtml内の不要リンクは削除する。
だいたいこれだけやっとけば、きちんと動作する。
あとは好みでpackage.opfも整理するくらいかな。
一応、画像選択ページも作って一つの雛形はできた。
これだけなら全自動で作れそうだが… あるなぁ、大きな問題が…
サンプル動画。
ttp://youtu.be/Zv2DMKJnFls 画像kepubとしてはかなりページめくりが高速ですね
動画から推測するに、全ページが目次化されていないからのようなのかな
サムネイルビューページはおもしろいですね
いかんせん重いようですが、これは性能的に如何ともしがたいのだろうなー
リフレッシュは設定上どうされています？
例：
坂本龍馬 海援隊約規
>｜運‐輸《ウンユ》 ｜射‐利《シヤリ》 ｜開‐柘《カイセキ》［＃「開‐柘」の左に「ヒラキ」のルビ］
また
［＃注記付き］ＡＡ［＃「BB」の注記付き終わり］
も
対応要望じゃなく報告まで
イイねー！乙です。
これが自動で作れるようになったら、大量のcbzとpdfを全て移行させるわ。
ときに、大きな問題ってなに？
速さに目次は関係ないです。
サムネイルのページでタップからの動作はkoboの仕様かな？
ページの表示自体は私のソースが稚拙なせいでしょう。
リフレッシュは１ページになっていました。
もっと長く設定すれば、引っかかりも少なくなるかも。
ちなみに、ページめくりは真ん中の設定。
大した改造ではないので作るのは難しくないと思いますが
おそらく出来上がったファイルに大きな問題が…
１つのxhtmlの中に画像をたくさん詰め込んでいる都合上その枚数に比例して
アクセスしてから１枚目の画像が表示されるまでの時間が長くなります。
経験では、50枚で6～7秒・100枚で15秒前後・200枚で25～30秒かかります。
いったん表示されれば、ページめくりは快適なのですが
わかっていても、一瞬フリーズを疑うこの待ち時間、我慢できるかな？
ちょっとキツイかもしれませんね。
cbzの早さに慣れるとそのラグタイムはストレスかも。惜しい！！
kobo storeで売ってる漫画はどう処理してるんでしょうね。
漫画は買ったことないから、レスポンスがいいのかどうかも知りませんが...汗
＞
ttp://android-smart.com/2012/09/aozora.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Androidsmart+%28AndroidSmart%29 には画像ファイルが入ってない
青空2009DVD >
ttp://d.hatena.ne.jp/Koumei_S/20090307/1236419281 のは古くて１冊ボッチだとけっこう抜けてしまう
という事で、まずは青空全作品ダウンロードスクリプトを作るぞ
といっても
ttp://hpcgi1.nifty.com/hongming/komorebi/wforum.cgi?mode=allread&pastlog=0002&no=1352&page=10&act=past のperlスクリプトを変更すれば簡単そうだ。
でもperlは初めて
ActivePerl-5.14.2.1402-MSWin32-x86-295342.msi
というのをインストール asakkald.exe ではなく >c:\perl\bin\perl.exe asakkald.pl で動作するのを確認
変更は、スクリプトの後半を sub にして 前半のリストを作ってる部分をループにして呼び出せばいけそうだ
###### zipダウンロード
の mkdir/chdirをコメントアウトして
##### 作品毎のループ
mkdir("$sakka",0755);
chdir("$sakka");
の$sakka を $sname と変更
use Cwd; #入れて
# for( $lcnt = 1;$lcnt<$scnt;$lcnt=$lcnt+3 ) {
からif(&httpreq()){ の前まえ コメントアウト
my $CDIR= Cwd::getcwd();
for( $lcnt = 1;$lcnt<$scnt;$lcnt=$lcnt+1 ) {
$sname = $nlist[$lcnt];
$line = $lcnt;
$uri = $slist[$line];
$target = "text";
printf "\n---------------%4d:%-20.20s-----------",$lcnt ,$nlist[$lcnt] ;
chdir($CDIR);
LoadFile();
}
sub LoadFile{
if(&httpreq()){
とやって 後ろに } を追加
でも、 &？上漁史 とかのフォルダ名が出来た
ぼくじょうぎょし か、もうひらがなに変えてしまえ
けっこうダウンロードはかかってる。
781作者名あるはずでまだ１00程度みたい けっこう txt形式を置いてないのがあるけど
一つの作者さんの場合は 解凍ツールで一発だが 全部のフォルダにかけないとね
問題は、解凍後の名前がかぶる事。
同じ作者で同じ作品名で別のものだったり、かな使いが違う場合だったりする。
zipファイル名をフォルダ名にしてフォルダを掘ってやれば解決するけど、それだと後の処理が面倒
ALZIPならbatから呼び出せるけど、ALZIPはGUI版なら同名が重なった時に別名にするってオプションが出るのだけど
コンソール版は上書きするか日付を見て上書きするかくらいの選択しか出来ない。
以前 WSH-vbscriptで zip解凍した時は、同名ファイルは別名にするフラグを付けても上手くゆかなかった。
一度別のフォルダに解凍して同名があればzipファイル名を後ろに付けるスクリプトを書く必要があるな
<job id="ZipOpen"> <?job error="True" debug="True" ?>
<object id="objFs" progid="Scripting.FileSystemObject" />
<script language="VBScript">
<![CDATA[
dim logFtp
Sub logOut(s)
logFtp.WriteLine s & Err.Number
Err.Clear
End Sub
Sub ZipOpen1(zpath,fname)
ZipFile = fname
ExtractTo = zpath & "\tmp\"
If Not objFs.FolderExists(ExtractTo) Then objFs.CreateFolder(ExtractTo)
Set objShell = CreateObject("Shell.Application") 'ZIPファイルを解凍して、解凍先フォルダにコピーする。
Set FilesInZip = objShell.NameSpace(ZipFile).items
Set objFolder = objShell.NameSpace(ExtractTo)
If (Not objFolder Is Nothing) Then
objFolder.CopyHere FilesInZip
End If
Set objFld = objFs.GetFolder(ExtractTo)
For Each objFl In objFld.Files
spath=objFl.Path
sname=objFs.GetFileName(spath)
On Error Resume Next
if objFs.FileExists(zpath &"\"& sname) then
outname = objFs.GetBaseName(sname) & objFs.GetBaseName(ZipFile)& "." & objFs.GetExtensionName(sname)
objFs.MoveFile spath , zpath &"\"& outname
else
objFs.MoveFile spath , zpath &"\"
end if
If Err.Number <> 0 Then logOut zpath & " がなぜか移動できない。"
On Error Goto 0
Next
ExtractTo = objFs.GetAbsolutePathName(ExtractTo)
On Error Resume Next
objFs.DeleteFolder ExtractTo ,true
If Err.Number <> 0 Then logOut ExtractTo & " がなぜか消せませんでした。"
On Error Goto 0
End Sub
Sub ZipOpen(srcPath)
Set objFld = objFs.GetFolder(srcPath)
For Each objFl In objFld.Files
srcTmp=objFl.Path
ext = objFs.GetExtensionName(srcTmp)
if ext = "zip" then ZipOpen1 srcPath,srcTmp
Next
For Each objSub In objFld.SubFolders
ZipOpen objSub.Path
Next
End Sub
mpath = objFS.GetParentFolderName (WScript.ScriptFullName)
if MsgBox (" フォルダの全ZIPを階層的に展開するよ？", 1) = 1 then
Set logFtp = objFS. CreateTextFile(mpath & "\errlog.txt")
ZipOpen WScript.Arguments.Item(0)
logFtp.close
end if
]]>
</script> </job> </package>
エラーの場合があるから On Err 使う必要があるけど WSH のは訳が判らなくなる
仕方ない。
perlの実行が終わったみたい
でも html の数が 780 １枚足りない！ まあいいや。
42225_ruby_13289.zipがカレントフォルダに出来てる・・・なんかミスったのかな まあいいや
＞del /s *.html
で一気に html を消す
そして
ぼく上漁史
かく見 鈍太郎
若林かん蔵
大倉 てる子
の名前を修正
zipファイルの無いフォルダが結構あるので
これを捜すためにフォルダ名にzipのファイル数を表示させたい。これは朝作った
<package>
<job id="FileNameConvet">
<?job error="True" debug="True" ?>
<object id="objFs" progid="Scripting.FileSystemObject" />
<script language="VBScript">
<![CDATA[
'配列に一旦名前リストを作ってから
'だから1万を超えたら知らない
dim n,sn(10000),fn(10000)
Sub FolderNameList(srcName)
dim fp,nm,filnm
n=n+1
sn(n)=srcName
set fld = objFs.GetFolder(srcName)
nm= fld.Files.count
Do While (Len(nm) < 4) : nm = "0" & nm: Loop '4桁の0埋数字
filnm = objFs.GetBaseName(srcName)
fn(n)= nm & filnm '<---新しい名前
End Sub
Sub FolderConvert(srcPath)
Set objFld = objFs.GetFolder(srcPath).SubFolders
n=0
For Each objFl In objFld
srcTmp=objFl.Path
FolderNameList srcTmp
Next
dim i
for i=1 to n
Set fp = objFs.getFolder(sn(i))
fp.name = fn(i)'<---ここでリネーム
next
End Sub
if MsgBox (" フォルダ名の頭にファイル数を4桁で付けますよ？", 1) = 1 then FolderConvert WScript.Arguments.Item(0)
]]>
</script>
</job>
</package>
作者数 780人からは 130人以上減った
ヘタにエクスプローラを表示させたら固まりそう
WSHはコンソールも出ないし 窓も持ってないから 実行してるかどうかは windowsタスクマネージャ上にあるかどうかだけだ
regsvr32 /u zipfldr.dll をしてる人は zipを解凍できないから regsvr32 zipfldr.dll を実行しておく事
やっと解凍終わったので で0001のフォルダだけcopyしてる所。
単なるcopyがえらく遅い
for /R %a in (*.png) do copy "%a" .\
を実行
＞copy "wk\1\0001手塚 寿郎\fig45210_001.png" .\
＞.\fig45210_001.png を上書きしますか? (Yes/No/All):
と聞いてきた。 手塚 寿郎さんは訳者さんで Leon Walras 純粋経済学要論 一冊 って事で
手塚 寿郎さんのフォルダを消去
----- textMergeFolder.bat -----------------
cd /d %~dp0
cd
if %1 == /f goto :fileSUB
if %1 == /d goto :dirSUB
pause このBATファイルと同じフォルダに text.txtとtitle.txtを作ります
:BASE
del text.txt
del title.txt
for /D %%I in (%1\*.) do textMergeFolder.bat /d "%%I" "%%~nI"
for %%I in (%1\*.txt) do textMergeFolder.bat /f "%%I" "%%~nI"
goto :EXIT
:dirSUB
for %%I in (%2\*.txt) do textMergeFolder.bat /f "%%I" "%~3-%%~nI"
goto :EXIT
for %%I in (%1\*.txt) do textMergeFolder.bat /f "%%I" "%%~nI"
:fileSUB
echo;［＃改ページ］>>text.txt
echo;■%~3%~4%~5%~6 >>text.txt
echo;■%~3%~4%~5%~6>>title.txt
type %2 >>text.txt
echo;>>text.txt
:EXIT
----- ここまで -----
目次を 作者＋タイトルにしたいので
ファイル名にファイル先頭行をくっつける事にした
ttp://www49.atwiki.jp/kobotouch/pages/49.html の ファイル先頭文字をファイル名に(ファイル名が２重にならない版).wsf
を少し改造して実行したら 途中でエラーで止まる
辻潤 変なあたま
というファイルだ。 改行コードが 0x0D のみ unix系改行コードをVBは行区切りにしてくれないみたい
k=InStr(1,nm , chr(13),0):if k>0 then nm=Left(nm,k-1)
と入れて対応した
orokanaru_hahano_sanbunshi.txt
愚なる（?!）母の散文詩
ファイル名に使えない文字だ。このファイルだけなので手作業で対応
青空文庫.2012年全text(png含).zip
ttp://kie.nu/oQ_ 青空１冊ボッチだけの作家さんは269話分ありました。
ペンネームのせいで１冊だけの扱いの人も多いです
タグが変なのが多くて時間かかりました。
[入力はボランティアの皆さん] 青空１冊ボッチ作家群の269話.kepub.epub
ttp://www1.axfc.net/uploader/N/so/159605.dat ２冊だけの人のもそのうちに
[入力はボランティアの皆さん] 青空１冊ボッチ作家群の270話.kepub.epub
ttp://www1.axfc.net/uploader/C/so/173731 これは ［＃「a」に「b」の注記］ スタイルの注記だけ変換してあります。
変換前のテキストで
検索文字列 ［＃(「[^「」]*」に「[^「」]*」の注記］)
置換文字列 ［#\1
と置換しておいて、xhtmlに対して
ttp://toro.2ch.net/test/read.cgi/tech/1340383120/224
とやっています。
AozoraEpub3で スルータグ（ < とか &の変換もしない区間指定） を用意してくれれば 元ファイルだけで対応出来るのですが
吹喋［＃「喋」に「ママ」の注記］ とかで「ママ」は出したくなかったのであえて無視してます。
青空［＃「青空」に「あおぞら」のルビ］ とかは独自仕様？で使ってる人がいるけど
そっちは対応しても問題なさげなので対応できると思う。
仕様的には「ママ」以外のルビは《》で書くみたいだけど青空の仕様はよく分からんです。
外字を含むときの［＃注記付き］には対応したけど、これも｜と《》で困らないので気づかなかったし。
あと左ルビはePubだと無理っぽいので行左小書きで後ろに表示しておけばいいんだろうか。
青空文庫のhtml 版でも
ttp://www.aozora.gr.jp/cards/000908/files/51377_39744.html のように表示できていない
また窓見出しも難しそう
ttp://www.aozora.gr.jp/cards/001404/card49966.html とかで多用してるけど htmlの方は単なる強調になってる
左ルビもテーブルで固定出来ればソレっぽく出来るだろうけどやっぱりrubyの拡張を期待するしかない
ルビのネストが出来て
<ruby class="LeftRuby"> とかで
ruby.LeftRuby {
ruby-position:below; とか right/leftが指定出来るとか
}
span.hiraganaA { text-emphasis-position:under; text-emphasis-style: "あ"; }
span.hiraganaI { text-emphasis-position:under; text-emphasis-style: "い"; }
span.hiraganaU { text-emphasis-position:under; text-emphasis-style: "う"; }
とか作って 対応出来るかもしれないけど・・・・現実的じゃないな
サイズはたぶん元テキストで500Mbyte程度
重くなる可能性については
ためしにepubを非圧縮zipにすると体感的には開くのが早いようなので
圧縮しないepubならいけるんじゃないかと思う
問題は索引が無いと厳しい事
実験的に、作者名のリンクから作品名のリンクに飛ぶように作ってみた
[入力はボランティアの皆さん] 青空文庫10～19冊の作家作品.kepub.epub
ttp://www1.axfc.net/uploader/P/so/114033 cd /d %~dp0
cd
if %1 == /f goto :fileSUB
if %1 == /d goto :dirSUB
pause このBATファイルと同じフォルダに text.txtとtitle.txtを作ります
:BASE
del text.txt
del title.txt
for /D %%I in (%1\*.) do textMergeFolder.bat /d "%%I" "%%~nI"
for %%I in (%1\*.txt) do textMergeFolder.bat /f "%%I" "" "%%~nI"
goto :EXIT
:dirSUB
echo;［＃改ページ］>>text.txt
echo;:%~3:>>text.txt
echo;:%~3:>>title.txt
echo;>>text.txt
for %%I in (%2\*.txt) do textMergeFolder.bat /f "%%I" "%~3" "%%~nI"
goto :EXIT
:fileSUB
echo;［＃改ページ］>>text.txt
echo;■%~4%~5%~6 >>text.txt
echo;■%~4%~5%~6>>title.txt
type %2 >>text.txt
echo;>>text.txt
goto :EXIT
:EXIT
［＃改ページ］
:作者名:
［＃改ページ］
を入れて :作者名: が目次になり、これだけのxhtmlファイルが作られるように仕掛けておき
nav.xhtmlに:作者名:目次の前後に </ol>:作者名:目次 <ol>と正規置換で入れて最初の</ol>を一番後ろに回し
EmEditorは改行を含めた正規検索が出来るので <ol>.*?</ol>を検索キーワードにしておいて
キーボードマクロで検索してカットし カーソルをファイル名に合わせてファイルを開いてはペーストさせて作った
asakkald.pl では最初にアイウエオ順の作者名で出ているので
の mkdirで$lcntを頭に付けてやればアイウエオ順に出来るだろう
<link rel="stylesheet" type="text/css" href="../css/vertical_font.css"/>
<link rel="stylesheet" type="text/css" href="../css/vertical_text.css"/>
<link rel="stylesheet" type="text/css" href="../css/vertical.css"/>
を消さないといけないかな
行頭の空白（字下げ）を除いてありますが、
空白を残すことはできないでしょうか。
そのほうが見出しの階層がわかりやすいと思うのですが。
［＃改ページ］ 〔＃目次抜き〕
とかのタグが欲しい。
あと連番で出してる htmlや画像ファイルだけど
アルファベット１文字でもいいから頭に追加出来ると嬉しい。
例えば
［＃改ページ］ 〔＃CHAR-A〕 なら A0004.xhtmlでそのページの画像ファイルには A0011.pngという感じで
この追加文字は次の改ページでもリセットされないと嬉しい
一度 EPUB に作った後のマージが楽になると思う
さらに欲張ると
縦書き横書き用のcssは常に両方吐き出して
［＃改ページ］ 〔＃縦書き〕
［＃改ページ］ 〔＃横書き〕
というタグでそのページだけ切り替えられると便利かも
画像縦横比による自動幅調整 (画像が横にはみ出る対策)
指定サイズ(現状400x600固定)以上の画像は単ページ化
を組み込んで貰えませんか
1.0.7b5だとカラー画像で画像縮小ログ出ているページが変な色になりますし
1.0.6u1だと画像が単一ページ扱いされず文章中や右上に表示されてしまいます
以前の1.0.6では400x600以上のサイズなら1.0.7系の様に画面いっぱいに表示されずとも
単一ページ扱いされてたのですが
1.0.6だと改ページ周りの処理と画像周りのクラスとか無いので自動単ページ化の組み込みは厳しいです。
1.0.7b6でJAI利用にしたのでjpeg読み込みは直ってると思います。
もし↑で直ってない場合は画像縮小のチェックを外して縮小しないようにすれば
画像はそのまま出力して単ページ化のみ有効になります。
>1.0.6だと改ページ周りの処理と画像周りのクラスとか無いので自動単ページ化の組み込みは厳しいです。
1.0.6u1以前の1.0.6では何故単一ページ扱いされてたのでしょうか？
画像幅が大きいとmax-width:100%で単ページのように表示されるかと思いますが、
小さい画像は前後に改ページがなければ本文内に表示されるはずです。
Koboの場合はリセットでスタイが変わったりするけど、謎ですねぇ。
400x600よりほんの少し大きいサイズの画像なんですが
・ 1.0.7系だと拡大され画像は汚くなりますが画面いっぱいに単一ページ扱いされ表示されます
・ 1.0.6u1だと画面いっぱいに表示されず単一ページ扱いもされず画像が文章中や右上に表示されてしまいます
・ 1.0.6(無印)だと画面いっぱいに表示されず単一ページ扱いされ左右中央表示されます
幾つか1.0.6系で試しましたが1.0.6(無印)以前は1.0.6u1と同様の結果でした
何故か1.0.6(無印)だけ画像周りの挙動が違うんですよね…
上記は全てPCで確認した内容です
Reader対応のため現在の仕様に落ち着いたようですが、
koboに限って言えば、
上端にきた半角スペースを自動的に削除するような仕様のため
向こうに書いた、半角スペースを用いた禁則処理が理想的な結果を得られるような気がします。
たとえば、「～…～？ ～…～」という文章があった場合
普段は「？」の後ろに全角スペースがあるように見え、
「？」が画面一番下にきた時に、後ろのスペースが消えて、
その後ろの文章が次の行が表示される、と。
これは紙の書籍の表現にきわめて近いものと思われます。
あと、全角スペースしかいじらないので、縦中横の「!!」の後ろにも適用できますし。
もちろん、こういった文章の折り返しで途中の全角スペースが次行の先頭に来るケースは
ごくまれに起こるものなので鼻息荒く力説するものでもありませんが
一度あれを体験してしまうと、今の仕様がなんだか違和感を感じてしまって…。
願わくば、kepub出力時のみとかkobo専用の出力も検討していただきたいです。
（向こうにも書いたけど、なぜか消えたようなのでもう一度書いてみました）
Readerでも表示が変にならずにKoboでは行末で消えるようになったっぽい。
↑だとReaderでは禁則されないので追い出しも選べるようにして1.0.7b8に更新しておきました。
ePubの設定で禁則が正しく処理されるとかePubエンジンが対応すれば何もしなくて
よくなりそうだけど、現状できないこと多いしePub4とかになるまで無理かなぁ
ttp://genemapper.info/blank-after-mark/ 検索でちらっと見たけどスルーしてた。。。
全角スペースの代わりに(char)(0x2001)や(char)(0x2003)でReaderでは行末で消える
全角スペースになったけど、Koboだと0ｘ2002とかでも微妙に高さが低いっぽい。
こっちの方がタグエラーとかなさそうなので高さ調整して適用してみるけど
ePub関連の裏技は実機検証が面倒過ぎる('A`)
・行末で非表示 と、・禁則処理（追いだし）
の双方を比較しましたが、
ウチのkoboで見る限り、行末で非表示されることなく、
禁則処理（追いだし）と同様の表示になります。
07b8でうまくいっていただけに、残念です。
再調整をお願いします。
で、色々調べてみた
・0x2000を2文字
Kobo → 全角の高さで追い出し
Kindle → 全角の高さで追い出し
Reader → 全角の高さで行末消える
・0x2003を1文字
Kobo → 半角の高さで追い出し
Kindle → 全角の高さで追い出し
Reader → 全角の高さで行末消える
・半角スペースにしてpadding-top:0.5em
Kobo → 行末消える
Kindle → 行末消える
Reader → 行頭に出る(何もしないのと同じ)
・前の文字にpadding-bottom:0.5em (前にタグがあると無理)
Kobo → 追い出し
Kindle → 追い出し
Reader → 追い出し
ということで、
・Kobo・Kindle用行末非表示 (Readerは禁則無し)
・Reader用行末非表示 (他は追い出し)
・何もしない
の3つから選ぶようにするしかないかな
(強制追い出しは前の文字にタグだと無理があるので廃止)
心から、乙であります。いろいろ面倒かけてすんません。
自前のテストパターンで今頃気づいたのですが、
一番下に１文字分のスペースがあっても半角スペースは消えるのね…
ところで、
AozoraEpub3純正の画像KEPUBの画像切り替え時間を
半分くらいに縮める超簡単な方法を見つけた気がする。
速度はcbzにはかなわんのだが…
今回は総画像枚数が関係する変な待ち時間はない。
まだもう少し研究するけどｗ
あんまり青空タグに特化されると、普通のTEXTをepub3化する時にかえって使いにくくなりそうな気がします。
ぶっちゃけ私の用途では
文頭のタイトル、著者名、［＃改ページ］での章立て、これだけで充分なわけです。
例えば非表示コメントタグとかは、下手すりゃ本文がごっそり消えてしまったりするので、逆に面倒臭くなる。
なので古いバージョンもダウンロードできるように残しておいて欲しいです。
ttp://ebook.itmedia.co.jp/ebook/articles/1209/27/news060.html 古いバージョンも十数バージョン分はダウンロード出来ると思うけど
全バージョン無いと不満って事？
コメントそのままとかルビ付きでhtmlから抽出とか
要望あげておいてくれれば対応検討します。
Web小説も挿し絵付きのサイトもあるみたいだし
ChainLPあたり参考にしながら調べてみます。
うおお、対応してくださるのですか！
私は330じゃないですが、私もそういうのがあるとありがたいと思ってたので嬉しいです
ありがとうございます！
一般に紙の書籍は見開きページの初出漢字にルビを打ち、その後はルビなしで
次の見開きに同じ漢字が出てきたらまた最初のものにだけルビ打ち…と続きますが
epubのようにリフローする電子書籍は見開きの概念がないと思います
電子書籍のルビの打ち方は、以下のどれが正しいのでしょうか？
１ 底本どおりにルビを打つ（電子書籍になると同じ漢字に打たれるルビの出現が
ちぐはぐになります）
２ 各章ごとに初出の漢字にだけルビを打つ
３ 書籍を通じて初出の漢字にだけルビを打つ
４ 好きにする
1巻に1箇所だけ振っとけやと
ページめくるたびに振りなおしてあるのはなんなのかと
ホントなら「リフロー」のルールとして、プログラム側で制御すべき問題ですよね。
「基本、データ側では全てルビを振り、一画面中に同じルビがある場合は、最初に現れる一つだけ表示して、後は表示しない」というのが普通で、
場合によっては「章/節単位で最初に現れたものだけ表示」とか「全部(データ通りに)表示」とか。
そうなんです、しかも出版社ごとにまちまちで…
なるほど、とりあえず全部ルビを打って後で制御する方式ですね
そこらへんも規格で統一してくれれば電子書籍も作り易いんですが…
ありがとうございました、参考にさせていただきます
青空タグで必要性を感じるのは［＃改ページ］と［＃挿絵入る］くらいなのですが
基本形の［＃ ］以外の細かな青空タグをオフにできるチェックボックスがあったら嬉しいです。
特に厄介なのが--------で囲まれた部分が消えてしまう点で、これだけはぜひ何とか対応して欲しいです。
自分の今のやり方は、WEB小説のHTMLを一旦手元にダウンロードしておいて、
HTMLからのTEXT抽出はこちらのソフトを使用
H2Tconv
ttp://nekomimi.la.coocan.jp/freesoft/h2tconv.htm それでできたTEXTから、余計な部分を削除して、青空タグに誤認識されそうな部分は下のソフトで編集
複数行置換
ttp://www.vector.co.jp/soft/dl/win95/util/se407023.html （早いし複数行にかかる置換ができるので便利）
そのあとでAozoraEpub3にかけてます。
ChainLPのURL→epub変換は、長編小説には不向きでした。
画像epubのせいなのか、ファイルが大きくなってしまいkoboではフリーズしがちです。
ルビの表示非表示は、リーダープログラム側で制御可能なので、ニーズが出てくればリーダーが対応するかもしれません
も、 の指摘通りすべてにルビが振ってあれば、リーダーがその選択肢のすべてを実現は不可能ではありません
EPUB3のjavascript周りを把握していないのですが、ブラウザ並に動くのであれば、全体表示非表示程度は容易です（処理速度などは無視）
※KTは時計webアプリ動いてたけど…htmlなのでNetfrontではなくnickelなので縦書きが…
一方いま現実として、ストアによってリーダーは決められているので上記を待つのは悪手でしょうね…
外に出すでもなし、自分に親しくないものだけルビを一括で振っておしまいですね、今は
青空形式でもないんだったらHtmlEpub3とかWebEpub3とか言う名前にして別アプリに追い出せない？
１つのアプリであんまり複雑化すると、
現状のAozoraEpub3の良さが損なわれてしまう気がする
私は今のバージョンでほぼ満足してますありがとう作者さんまじで感謝してる
うわー！私のやりたいことそのままだ。ソフトの紹介ありがとうございます。
どちらも、レジストリいじらない所がまたありがたい。
今までちまちまコピペして、一行ずつ置換してたので、お陰でめっちゃ捗る。
そしてAozoraEpub3作者様、本当にお世話になってます。
firefoxのアドオンなので書かなかったんですが、
もしfirefox使いならScrapbookとEPUBReaderを入れとくとすごく便利ですよ。
前者は目当てのサイトのダウンロードに、
後者は作ったEPUBの確認作業に便利です。
ありがとうございます！
自宅は狐なので、帰ったら試してみます。
ただurlによっては使えないけど。
誰かこれできてる人いますか？
色々試してみたんですけどfirefoxのEPUBReaderだと「XMLパースエラー：整形式になっていません。」でエラーがでてるのがわかるし、
koboではエラー箇所以降は全部消えちゃうんですよ。
AozoraEpub3でもText2ePub（ChainLPの作者製作で横書きONLYで軽い）でも、どっちも同じく。
「＆、<、>、"、'」などの記号が原因なのはわかるけど、変換するには複雑すぎて置換では追いつかないんです。
これがなんとかなったら掲示板ログ遺産を変換して読めるようになるわけで、需要はすごくあると思うんですよね。
技術的にすごく難しいことだったりするんでしょうか。
コンバートの過程で1レス事に画像ファイルに変換すればいい。
・・・手順は浮かぶんだが、時間的な問題で作るのが中々難しい。
wikipedia→ePubなんぞより、よっぽど需要ありそうだな。
有料でもいいから、どっかやらんかねえ。
幅広のAAだと行の折り返しで崩れちゃうのがあるんだよね。
calibreでEPUBにしたことはあるけど文字が小さくて読むのにつらい。
Reader上でページ回転すれば読める程度の大きさにはなるが、ページめくりが重くなる。
結局、用紙サイズをReader1画面分の大きさ（用紙方向は横）に設定したwordにテキストを
貼り付けてPDFで出力（もちろんフォントは埋め込み）したあとPDFをページ回転したファイルだと
ページめくりも軽くて結構読める。
Reader側で拡大縮小とかページ回転させたりしないで表示させるだけにすればOK。
>351
dattohtml→calibre→ePubとかは？
1レスごとじゃなくなるけど。
AozoraEpub3で作ったやつなら、css変更してみれば？
自分はvertical_text.cssのfont-sizeを115%に変更してる。
本当は正しい指定の仕方じゃないかもしれないけど、
ちょうどいいくらいの大きさだから妥協してる。
自分用画像KePubにおいて、>273 のように画像につけたIDに関して
残念ながら、2.1.1以降、特定画像に対するハイパーリンクおよび
任意の画像で閉じた時のホームからの復帰が無効になった模様。
手動でのしおりはきっちり効くのでID自体は生きているようだが
ちなみに、しおりをつけた位置で閉じると、復帰した時に
一瞬しおり位置を表示した後、強制的に先頭画像に戻される。
仕様なのか、バグなのか、なんか悪意すら感じるわ…。
全画像一括表示は待ち時間があれなので、区切りのいいところで小分けし固めて
そこそこ満足して運用しているけど、この変更は残念。2.1.4でも同じだった。
画像表示とか、文章表示とか、内部処理が色々変更されているようだが
まあ、基本の画像送りが高速なので別にいいか。
画像送りの体感はAozoraEpub3の画像epubと大差はないような感じ。
表示はxhtmlでなく直接表示のようだけど、
どこでモード変更しているのか、細かいことはわかんねーや。
やっぱ一枚ずつの表示だと、どうしても間に白ベタが入って目に優しくないね。
何とかうまくページ内で２枚目以降の画像を読み込む仕掛けを作れないもんですかねぇ。
元のファイルがwordでは無理なのかな。
wordの文書を開いて[名前をつけて保存]する、その時に[書式なし*txt]を選択。
これでtextで保存されるので、それをAozoraEpub3にかければいいです。
罫線やオートシェイプの図なんかは消えるでしょうから
その部分は画像に変換して［＃挿絵入る］タグなんかを使えばいいんじゃないかな。
Excel・Wordの文字列を画像に変換する方法→コピーして「ペイント」に貼り付けるだけ
ttp://bora2.jugem.jp/?eid=74 どうも、参考にさせてもらいます。
AozoraEpub3を使った電子書籍制作についてblogを書いてみました
それをご報告します
EPUB3 形式による電子書籍の作成と Android版 電子書籍Reader による表示
ttp://nako1941.blog87.fc2.com/blog-entry-115.html Epub3をmobi形式に変換できるKindlePreviewerが2.7にバージョンアップしてる。
挙動をみると(当然だが)次のような製品体系になっている模様
+Kindle eInk
-Kindle Paperwhite
-Kindle
-Kindle DX
+Kindle Fire
-Kindle Fire
-Kindle Fire HD
+Kindle iOS
-Kindle for iPad
-Kindle for iPhone
AozoraEpub3で作ったepub3を変換表示させると、Kindle Paperwhiteモード
ではOKだが、他では不可のようだ。
自炊もいつかは、prc,mobi,azw3とかでフルスクリーンになるよね？
明らかな自炊対策だからなあ
逆に厳しくなってくるかもしれないし
第一章［＃「第一章」は大見出し］
とかって、ePubに反映されないんですね。
まあ、本家の青空文庫でも「見出しタグ」をちゃんと使ってるやつは少数派なんだけど、
ちゃんとした見出し階層構造を持ったHTMLファイル(H1～H6)を青空形式に変換する際にはやっぱり、
見出し構造は目次に反映させたいですねぇ。
わずかにスクロールバーが出ますけど。
<meta name="fixed-layout" content="true"/>
<meta name="book-type" content="comic"/>
参考 (p)(p)
ttp://wiki.mobileread.com/wiki/Fixed_layout_ePub#Kindle_KF8 txtファイル＋imageファイル=ePubファイル
みたいな感じを考えてるんですが・・・
Sigilとか使えば良いのでは？
中身開いてxhtmlファイル直接弄ればいいんでない？
画像のみをePubにするなら、画像のみ入ったzipファイルをAozoraEpub3に突っ込めばいいし、
小説の挿絵みたいのを考えているなら、青空文庫の書式を参考にテキストを作り
そのテキストと画像の入ったzipファイルを突っ込めばいい。
画像へのパスが通っていれば、そのままtxtファイルを突っ込んでもいいよ。
それとも、既存のePubファイルを改造したいという話なのかな？
なぜかうまく動かなくなってしまった。
画面UI周りの互換性でエラーが出ていたので該当部分削除でなおったと思う。
目次対応を始めたけど、改ページと見出し注記以外は、
「第～章」、「第～話」、「その～」と数字のみの行で抽出してます。
他の見出しや章区切りぽい行を自動抽出して変換前にリストで編集するとかは、
ChainLPみたいにページ見ながらじゃないと意味なさそうだし、
再変換でまた設定は面倒だしでちょっと悩み中。
元テキスト編集で<a name="目次名称">～</a>の場所を目次にする
とかの方が使い勝手はいいかも。
目次編集機能として、項目のオン／オフとテキスト編集あたりが早くほしい。
適当な思いつきだが、
編集時の補助として、項目前後の数行くらいポップアップ表示とかできるといいかも。
>357の画像IDへのハイパーリンクの件は直っていた。
でも閉じた時の画像への復帰はだめなままだった。
さらに、内部目次一覧のチェックマークが１回ずつ遅れて付く気持ちの悪い症状が…
修正する方法ないかな？
いちいち縦中横の設定置換する必要がなくなったよ。
それで、できればハートマークも正立にしてもらえるとありがたい。
急がないので、いずれ更新の折に追加してもらえればでの話ですが。
text-orientationってちゃんと効いてる人います？
どうもちゃんと効かないんだよね。
レンダリングエンジンに対応したベンダープレフィクスとか、ちゃんと付けてる？
もしかして自分宛？
font-sizeにベンダープレフィックスが不要なように、line-heightと
letter-spacingにはプレフィックスはいらないんじゃ？
text-orientationは必要かもしれないけど。
Sigilでもブラウザ(IE＆webkit）でもちゃんと表示されてるんだけど、
readerは効かなかった。
いろいろ試してみたらcssとhtmlを同じ階層に置いたらline-heightは
ちゃんと効いた。
※［＃（image/**.png）］
で画像指定した場合，フォントサイズに関わらず原寸で表示されるから表示が酷いことになる
Koboで買った本はフォントサイズ変えるとそれに合わせて大きさ変わった気がするんだがこれはサイズ別の画像が用意されてるのかな？
画像じゃないんじゃね？
外字画像は画像注記化だけして幅1文字のスタイル適用してなかった。
直したので後で更新しておきます
あと、目次が一段落したら気分転換にWeb小説対応検討中。
ブラウザからのDnDで各話HTMLキャッシュしてルビと改行を青空化して
つなげてから変換すればいけるかな。
ルビ以外に画像とかその他スタイルが使われてる作品ってある？
これで快適な電書生活が出来るわ
それと入力文字コードのプルダウン項目を横に広げてください。今は選択しているのが、どちらでも表示されません。おそらく…表示になっていると思われます。
細かい注文ですが、お願いします。
と思ったら『EPUB3における日本語電子書籍ベーシック基準』に
>独立した扉ページで、ページの中央に配置するための方法は現時点では規定されていない。
って書いてあってびっくりだわ
洋書ってそういうの無いんだね
なるべくお手軽な開発環境がよいのですが、どういうのがあるんでしょう？
やりたいことは、とりあえず、テキスト入力やら各種設定ができて
それを反映したテキストファイル(xhtml等)を出力できればよいです。
EPUBの編集ならFUSEe βやSigilがあるけど、それではできないことがあるのかな?
そのくらいなら、
①ePubファイルの拡張子をZIPにする
②Windowsの圧縮フォルダ機能でZIPファイルにアクセスする
③Notepadで編集する
④ePubファイルの拡張子を戻す
だけで済むんじゃないか?
実は文書の内容を変更するのではなく、特定のxhtmlファイルに特定のタグを埋め込みたいのです。
埋め込むタグは毎度同じなのですが、ファイル毎に微妙に変更する箇所があるので作り置きができず、
条件に合わせて必要なタグをエクセルで生成し、テキストエディタで貼り付ける、という作業をずっとしてきたのですが
１セット10～20のファイルを１つ１つ修正するのは正直面倒になってきたので、
一括変換ツールのようなものを作ってみようと思ったわけです。
sed と awk でいいんじゃね？
先日、ePubファイルからOPFファイル抜き出して書誌情報を一覧表示してCSVかTSVで書き出すプログラムを作った。
イーブックストアで買ったePubファイルの名前から書名/作者名が得られれば良しって感じだ。
最初はDelphiXE2で始めたんだけど、標準ライブラリでのZIP解凍に無理があったのと、
やっぱり手馴れてる方がいいので、Delphi7にオープンソースのアーカイバライブラリ「Abbrevia」を入れて、とりあえず自分の必要とする機能は実装できた。
>399 でも言ってるけど、ePubをどうこうするなら、ZIPとテキストファイル(XMLやHTMLやXHTML)が触れる機能さえあれば、大概の開発環境でどうとでもできるだろう。
Javaでも、Perlとかのスクリプト系言語でも大丈夫だろうし、商売っ気ナシならVisualStudioのExpressエディションとかでもイイんじゃね？
Kindle Previewerにepub突っ込むとmobi開こうとしたところでクラッシュするようになったぜー
こっちのWin7のKindlePreviewerではPWしか選べないけど表示は問題ないです
他のePubでも試してみてください
あとKindlePreviewerのバージョンあげたら左右中央が効かなくなってどうやっても直せない…
実端末だと表示どうなんだろ
<div class="c27">
<div class="c28">
<p class="c29">中央寄せ本文１</p>
</div>
</div>
</body>
.c27 {
display: block;
}
.c28 {
text-align: justify;
display: inline-block;
vertical-align: middle;
height: 100%;
}
.c29 {
text-align: left;
}
mobiを見るとこんな感じになってる
calibreを使って
blogに乗ってある小説をキンドルで読もうと色々と試したのだけども
最新の記事５件しか取得できません。
一応キンドル実機に転送したらこの５件に関してだけは上手く見れたのですが
最終話近辺だけの話だけって言うイジメを見た
ニュースソースをカスタマイズして追加にて
一番古い記事の日数を 小説の第一話の日数から逆計算して
138日に
ニュースの取得スケジュールの
delete download news older than の箇所を削除しない
にして
フィードのURLの登録のRSSも
ttp://http://kuzumotinonizi.blog.fc2.com/?xml">ttp://kuzumotinonizi.blog.fc2.com/?xml このソフトにこだわる訳では無いので、もっと良いソフトや方法があれば
もうずっとこれで悩んでて、キンドルに触れてないｗ
fc2blogの仕様か登録するフィードが悪いのかどっちでせうか
一応このスレ内を見て
： 名無しさん＠お腹いっぱい。 [sage] 2012/11/23(金) 03:50:03.54 :fbQlnEU0
実家に置いてあるiPad2にKindleアプリ入れて、同じ本を読もうとしたら、
目次が表示されるが、目次のリンクをタッチしても、そのリンクの項目に
飛ぼうとしない。リンクの表示は一瞬反転するが、それっきり。
あと、全文検索もiPad2のKindleアプリでは、当方の出版本では
なぜか機能しませんでした。
ちなみに今は、実家から戻ってきたので、iPad2は手元にはありません。
本はSigilで書いて、toc.ncxを目次のhtml文に変換するrubyのスクリプトを
ネットから拝借して、それを使って目次ファイルを作成し、
epub2ファイル本体に取り込んでいます。
困ったな。何か対策は無いのかな？
よろしくお願いいたします。
ttp://makoto-watanabe.main.jp/ebook.html 外してるかもしれんけど
RSSをいろいろ加工するならYahoo! pipesを使ってみるのはいかが
挿絵にできるのでしょうか。
例えば、AozoraEpub3-1.0.7u1で、対象画像を単ページ化しない様
サイズを設定し、生成したepubのvertical.cssに
span.img {
display: inline-block;
vertical-align: middle;
float: left;
}
のようにfloat属性を書き足しただけでは、小さな画像は回り込み
表示されますが、大きな画像はimgの行の手前で改ページされて
しまいます。
もし可能であれば、具体的な方法か参考となるリンクをご紹介
いただけると幸いです。
くなりますね。
例① : AB漢字《かんじ》 →<ruby>AB漢字<rt>かんじ</rt></ruby>
例② : AB｜漢字《かんじ》 →AB<ruby>漢字<rt>かんじ</rt></ruby>
例③ : ＡＢ漢字《かんじ》 →ＡＢ<ruby>漢字<rt>かんじ</rt></ruby>
例④ : ＡＢ｜漢字《かんじ》 →ＡＢ<ruby>漢字<rt>かんじ</rt></ruby>
青空文庫では英文字は前後に半角スペース入れる事になってるから、それがない場合
はひとつながりでルビベース扱いするのもあながち間違いではないですけど、そうすると
例③の動作との整合が取れてないですね。
どちらかに統一したほうが良いと思うんですがどうでしょうか。
私の個人的意見としては、例③の方に統一したほうがすっきりするような気がします。
ルビの｜省略対応の連続の判別で漢字と半角区別されてなかった('A`)
③になるのが正しいので修正しておきます
逆の場合で
逆③ : 漢字ＡＢ《ａｂ》 だけルビがつかなかったけど｜なしは仕様外で無視でおｋ？
画像回り込みは単ページ化されてないxhtmlで次ページになるなら端末がやってる？
画像回り込み設定は画像サイズ指定でできるように検討してみます
いつも便利に使わせていただいています。
416は現行のEPUB3で実現できるのかも知らずに質問させていただきました。
レンダラとしては(もちろんAozoraEpub3のほうも)正常動作のような気も
しています。
質問の件とは別に、画像によっては周りこみして欲しい場合があります
ので、回りこみ指定の実装をご検討いただけるのは嬉しいです。
ありがとうございます。
逆③には気づいていませんでした。
確かに仕様外なので、無視でいいんじゃないでしょうか。
可能なら、「n行m桁：漢字ＡＢ《ａｂ》……」てな感じでログでも吐いてもらえるとカンペキかもです。
web小説を取り込む際に
H2Tconvを使って、青空形式の目次を付けたいのですが
$LINE1
$FNAME［＃「$FNAME」は小見出し］
$TITLE
$FTIME
$LINE1
ヘッダの部分を上記のようにしてるんですが
どうも上手くいきません、
他に変換設定とかいじるところはありますか？
それとも、AozoraEpub3の方の設定を変えた方がいいのでしょうか？
それと、もう１つ聞きたいのですが
小説を読もうのサイトの一番綺麗な取り込みについては
「小説を読もう！」「小説家になろう！」一括ダウンローダ ver 2.27
で、ダウンロードした後に
AozoraEpub3でEpubに変換
kindlegenでmobi
この工程が一番手っ取り早いです？
ttp://denshi.o-oi.net/ と、いうかこのサイト.mobiの項目すらねぇじゃねぇかｗ
もっと、こうこの設定をいじればいけるとか
ヘッダタグをこう、改変したら、Kindleでの目次移動をとか
具体的な事で
422はマルチ
$LINE1はコメント扱いになるのと$FNAMEはURLなので
↓で行けない？
$LINE2
［＃ここから小見出し］$TITLE［＃ここで小見出し終わり］
$FNAME
$FTIME
$LINE2
thxありりー
ばっちりいけた
ただ、
［＃ここから小見出し］$TITLE［＃ここで小見出し終わり］
これだと目次がKindleで見ると、すべて一緒の名前になって目次が目次の役目を果たしてなかったｗ
だから
$LINE2
［＃ここから小見出し］$FNAME［＃ここで小見出し終わり］
$TITLE
$FTIME
$LINE2
にして
よっぽどサイト管理が下手とか偏屈な管理人じゃなければファイル連番になってるから
txtの時点で置換でURLの部分をweb小説のタイトル名にし
最後の .html の部分を 置換後を指定しないで置き換えれば消えるから
予想以上に上手く目次でけたわ
これ、$LINE3でも、だめだったんだ
１と３を試してから２もどうせダメなんだろうなぁとか勝手に思ってた
最後に複数置換でサイトの広告消して 青空ヘッダを入れて
AozoraEpub3でEpubに変換
kindlegenでmobi
ばっちりとKindleで読めました
試験verなのでまだまだ調整が必要ですが暇な人試してみてください
一覧ページ以外はキャッシュしてるから読もうサイトに負荷はそれほど
かからないと思うけど取得時の規約とか制約とか作法とかあるんだろうか
不具合や変換できない作品があれば配布ページの方で
便利な機能をありがとう。今のところ正常に動いてますー
IEからNコードをまとめて持って来るNovelDLの機能が便利すぎるので、
相変わらずそちらの使い方がメインになるとは思いますが、単発で落としたい作品が
あったときなんかはこの機能を利用させてもらおうと思います
まずは最低限の機能が実装できたので公開してみます。で、
何ができるかというと、>270から始まった自分用画像kepubの自動作成です。
ただし、ペースになる画像kepubはAozoraEpub3で作成する必要があります。
>282で動画を公開した時、実際に試した人がどれだけ居たのかわかりませんが
お手軽に作れるので、cbzよりkepubが好みな人は一度試して欲しい。
置き場。www51.atwiki.jp/kb86/
でﾜﾛﾀ
おまえすげーな
見つけたのは先々週だしｗ
いつか動作報告が来るのを期待しつつ、今日も変換作業する。
どのソフトを使うと良いでしょうか、できればフリーソフトがいいのですが
絵本を取り込み、その画像を元に他のソフトでフラッシュ化、そしてそのファイルを書籍ソフトに貼り付けですかね？
わかり難くて申し訳ないですが、動く絵本を作る為にどのようなソフトが必要か教えてもらえないでしょうか。
宜しくお願いします。
イメージとしては河合楽器の親子でわくわくえほんスタジオというソフトの機能が良い感じですが
本格的に商用利用(絵本を書籍化)する場合においては向いてなさそうでした。
上記の機能を使いたいのですが、オススメのソフト等ありましたら是非参考にさせてください。
成立しないお遊びソフトなので、電子書籍作成ソフトとは到底言えないかと
電子書籍のフォーマットはEpubにして、そこにGIFかMP4を埋め込むって感じでいいとは思うのだけれど、
今のところコンシューマ向けの電子書籍作成ソフトと呼べるものはないような気が…
コード丸出しの開発者向けか企業向けの高価なものばかり
メディアブックパブリッシャーを使って、GIFやFLASHを埋め込む感じですかねぇ。
ナレーション吹き込んだりするのも、一苦労しそうです。
ttps://www.justmyshop.com/products/ichitaro/ リリース後 .mobi にも対応するようだし
個人でも手に入る価格帯ではこれが鉄板かもね
epubファイルの書き出しオンリーなのかな？
読み込みは出来るのだろうか？
書き出し専用のようだ。再編集は無理っぽい。
閲覧には専用リーダー使えって書いてある。
あとmobi対応は開発中で後から提供っっぽい。
ttp://ebook.itmedia.co.jp/ebook/articles/1212/04/news112.html いままで//ncode.syosetu.com/txtdownload/dlstart/ncode/*****/?no=
に行って連番を作ってイリアで落としていた手間が大幅に省けてる＞＜
確かにあれは、便利だけどそれ以前の方法が
あほすぎるだろｗ
ttp://w033.seesaa.net/ このツール使えば良かったのに
と、いうか、電子書籍板にきてまだ一ヶ月だが
初日にこのソフトまで行き着いたぞ
便利なんだけど、なんだか行頭空白がずれるんだよなあ
それうちの環境じゃ動かなかったんよ。
ＩＥをつかってないからだと思うけど。
これの他にムーンライトノベルズと携帯小説系の
ダウンロードはなんとなくマスターしてしまった。
iriaさん大活躍。
それ自分も試行錯誤中。
どうしてもダメとなったら統合済みファイルもってきて
別のソフトでやればいいやーと思ってます。
replace.txtにて半角スペースを全角スペースに
変換とかしてるんだけど、話によってなぜだか２文字空白スペースあいたり
してしまってますが、別の条件でやってみる。
ルビと画像取得のためにHTMLの方から直接抽出しているんだけど
半角スペースと違う文字コードのスペースが行頭につくっぽい。
行頭半角スペースつかないように調整しておきます。
自分では使ってない機能なので不具合とか要望あれば書いといてください。
いつも便利なソフトをありがとう
自動DLだけでも凄く便利になったので
ありがとうございます。
負担になったら悪いと思いつつ、お時間があきましたら
よろしくお願いします。
- 行頭字下げ調整 (例外文字に
ありがとうございます＞＜
むっちゃ助かってます いやまじで、ほんとにありがとう！
・画像閲覧中、途中でいったん抜けてホーム・ライブラリから復帰した時に元の画像に戻れない。
・ページ（xhtmlファイル）をまたいで画像１枚戻った時、前のページの最後の画像に戻れない。
上記の２点の問題について、AozoraEpub3-1.1.0b9で突然解消されました。
調べてみると、cssのepub-writing-mode:horizontal-tb;の一行がその答えでした。
なぜ、横書き設定だとうまくいくのかイマイチ分かりませんが、その組み合わせが必須と言うことでしょうか。
ちなみに、今まで作った、手作りデータおよびReconstructionKepubで作ったデータいずれも
この１カ所のみ書き換えただけで期待通りの動作をすることを確認しました。
現状、最新のAozoraEpub3を使う限り問題は自動的に解消されますが、
変更があってもいいように、追って、ツール側で固定するようにしようと思います。
ありがとう、AozoraEpub3、そして中の人。
改ページ後に表示されるにはビューワに期待するしかないが
今は挿し絵に対応する文章直後に指定するのがベストかなあ
あるポイントが表示されたら、そのページは続きを表示しておき、
次ページ全体にさし絵が表示される感じで
フォントサイズを変えたりしてもうまく処理されないといけない
epubはファイルの構造からして別になってる
本文.xhtml/挿絵.xhtml/本文続き.xhtml
みたいな
小手先の技術じゃ対応できない
先読みしようと読み込みまくるとドグラ・マグラみたいになるだろうし
これはもうepubの宿命だわ
ttps://github.com/masaki85/narou2epub ttps://github.com/SaitoAtsushi/yomou-publisher ttps://github.com/kazuki/epub3-converter AozoraEpub3 で「小説家になろう」から変換してみた。
表題ページの html に誤りを発見。
span 要素は div 要素を含んではいけません。
ランキングや小説情報のページから小説タイトルをＤ＆Ｄ
これで失敗したこと無いがなあ
生成自体に問題はないよ。 生成された ePub の一部が規格違反ってだけ。
大抵のビューアでは少々の問題は吸収してくれるから普通に読む分には気付かないかも。
それと目次データ (toc.ncx) が変なとこ指してることがあるっぽい。
Unpackすると、epub入ってるよ。
ttp://www.mobileread.com/forums/showthread.php?t=61986 ステータスが入力をHTMLに変換中・・・が進行1％で止まってます。
ソースは500ページくらいの文庫本、scansnapで読み取りPDF化
品質はスーパーファイン白黒です。
困ってます。よろしくお願いします。
自己解決しました・・・すごく時間がかかるんですね・・・
チェッカーを使って検証したら「epub/OEBPS/toc.ncx:
外部DTD実体は許可されません。DOCTYPEを削除してください。」
というエラーが出ました。ググってみたのですが該当する項目が見当たらず、
とても困っています。いったい、どうしたらよいのでしょう。
まずtoc.ncxの内容を晒してみたらどーかな?
ファイルを開いて見ました。こんな感じなのですが……。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN" "
ttp://www.daisy.org/z3986/2005/ncx-2005-1.dtd"> <ncx xmlns="
ttp://www.daisy.org/z3986/200 その <!DOCTYPE ncx (中略)ncx-2005-1.dtd"> の行を削れば？
アドバイスありがとうございます。
<!DOCTYPE ncx (中略)ncx-2005-1.dtd"> の行を削除しましたが
やはりエラーが出てしまいました。
上記の行が問題だとは思うのですが……。
青空epub3でepubに変換して比べてみるとか
<?xml version="1.0" encoding="UTF-8"?>
<ncx xmlns="
ttp://www.daisy.org/z3986/2005/ncx/" version="2005-1"> <head>
<meta ～>
↑複数行
</head>
<docTitle><text>タイトル</text></docTitle>
<navMap>
<navPoint ～><navLabel><text>～</text></navLabel><content src="～"/></navPoint>
↑複数行
</navMap>
</ncx>
件の行を削除しても、エラーメッセージは同じ?
存在しない行についてエラーを出してるとなると、チェッカーそのものの動作を疑うか、削除したつもりでできてないかのどっちかじゃないか?
お返事が遅くなってすみません。
削除した後は、こんな感じです↓
<?xml version="1.0"?>
<html xmlns="
ttp://http://www.w3.org/1999/xhtml"">ttp://www.w3.org/1999/xhtml"ttp://www.idpf.org/2007/ops" xmlns:xml="ttp://www.w3.org/ XML/1998/namespace" xml:lang="ja">
<head>
<title>13_01_20 - 目次</title>
</head>
<body>
<ol>
<li>
<a href="../Text/document2.xhtml#TOC_C1D721EC-2F40-426A-A500-B215DCE163340">一</a></li>
<li><a href="../Text/document3.xhtml#TOC_2E25D9B8-3E00-4415-AF83-D58E5D17BBCA0"> 二</a></li>
<li><a href="../Text/document4.xhtml#TOC_9840C83A-DFE2-40EB-913F-7EE8C309A2970"> 三</a></li>
<li><a href="../Text/document5.xhtml#TOC_97190164-64DF-49D5-B16A-44A209EEE9760"> 四</a></li>
<li><a href="../Text/document6.xhtml#TOC_01121247-4E56-4FD4-8746-BD3AB56C0B8C0"> 五</a></li>
<li><a href="../Text/document7.xhtml#TOC_B6D85D70-2CD4-4733-9C4E-36469A33296D0"> 七</a></li>
</ol>
</body>
</html>
ttp://code.google.com/p/epubcheck/) ERROR: 13_01_20-2.epub/OEBPS/Text/document2.xhtml(131,106):
element "ruby" not allowed anywhere; expected the element end-tag,
text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big",
"br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins",
"kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small",
"span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="
ttp://www.w3.org/2000/svg") このあと上記のようなエラーの指摘が1ダースほど続いています。
そのエラーを見ると、!DOCTYPEを丸ごと削除しちゃったから中身がなんだかわからなくなってるんだな。
>469の内容を見ると、<!DOCTYPE...じゃなくて、一行目が手元にあるePubとはちょいと違ってるね。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
を
<?xml version="1.0" encoding="utf-8"?>
に変更( standalone="no" を削除 )してみたらどうなる?
EPUB 2 ではrubyタグは使っちゃ駄目だろ。
> element "ruby" not allowed anywhere;
って書いてあるんじゃん。
エラー内容自体全然読んでないとかアホすぎるわ。
ありがとうございます。
自力で解決いたしました。
「紙のレイアウトを忠実に再現するための形式」だししかたないか
入力ファイル名(zip/txt共に)に日本語が使われてると読み込みすら出来ない
「ファイル選択」でのファイル一覧にすら出てこない始末
出力時も日本語が含まれてると?????で化ける
結構致命的なんだがほかに報告が無いし俺の環境だから？
OSXのバージョンは10.8.2
AozoraEpub3のバージョンは1.1.0b25
Javaのバージョンは1.7.0_13-b20
なにか設定が必要なの？
スノレパ＋1.0.7だけど、問題なく使えてるよ
もしかして「入力文字コード」を正しく指定してないんじゃないか？
どっち指定しても変わらんかったよ
スノレパではちゃんと動いてるんか…マウンテンライオンで動かしてる人は居ない？
ttps://dl.dropbox.com/u/3831825/KindleCenter.zip テンプレ作成どうもです。
こちらで試したら表示がずれる場合があったので他の端末と
cssが共用できるように調整して1.1.0b26に適用しました。
縦書きの中に横書きと縦書きのdivを入れて高さ90%とかちょっと
無理してますがPerviewerでは大丈夫っぽい。
Kindleユーザが意外に多そうなので他に要望があれば対応検討
するので書いておいてください。
横書きになっちまった…
デフォルトのkindle_pw.iniが
DispW=658
DispH=905
CoverW=625
CoverH=1000
になってるせいか表紙の横幅がおかしなことになってるわ…
DispW=629
DispH=984
CoverW=758
CoverH=1024
が正常値かな？
ttps://kdp.amazon.co.jp/self-publishing/help?topicId=A2J0TRG6OPX0VM を見ると表紙が最低1000pxで理想的な縦横比は1.6とか書いてあるけどこれはKindleアプリ向け？
1.0.7の表紙→表題→目次ページのほうがよかったな
まあ自分で修正すればいいんだけどさ
途中から変換できてないんだけどなんでだろ？
変換できないtxtファイル上げたほうがいい？
本文の中に------------------------------------------------------------------- が混じってた
HAHAHA
端末やアプリ側は読みのソートや検索に対応してるんかな？
HTML5タグをそのまま使って、
<video id="aiueo.mp4" src="../Video/aiueo.mp4" controls="true" width="216" height="216" autoplay="true" loop="true" />
とか書いてみたが、
Sigil上で記述すると、ビデオが表示されないので、不具合あるんだろうなと思うが、
正しくはどう書けばいいんだろう？
そもそもマトモに再生できないないんじゃ...
GIFアニメすら怪しいというのに
もっと空いてるとこ使ってくれないかな(´・ω・｀)
ttp://openend.co.jp/wordpress/smart-epub/20120628-memo/ 情報３９！
参考になりました。
山ライオン使ってて同じ症状が発生してる。
作者に質問投げたけどmacはわからん言われた(´・ω・｀)
ソースは関係ないっぽいんでmacのJava周りを調べた結果、原因はJar Launcher.appにあるっぽい。
Finderからjarをダブルクリックするとこいつが起動してjarを実行するんだけど、これを経由すると文字化けが発生する。
んで、対処法としてはターミナルから直に java -jar AozoraEpub3.jar なコマンドを打って起動すれば化けなくなる。
毎回ターミナルから起動するのは面倒だからcommandファイル書いてFinderからダブルクリックで起動できるようにしてる。
fit_h/fit_wって画像のフルサイズ表示のためのタグだよね？
ここらへんCSSで自動で調整出来ないもんか…
テンプレ弄ってfit出さないようにしてる
階層表示されるnav.xhtmlの書き方があれば対応するんだけど、
この部分のepubの仕様と端末の対応状況よくわからんです。
Readerは階層化すると展開しないと選択できないとかで使いにくいし
目次周りは癖があって調整難しいですね。
手持ちの汎用htmlを変換したいと思うのですが、html→青空文庫形式のナイスツールが見つからない。orz
html5 形式にさえすればあとはメタデータをつけて zip で固めれば ePub の出来上がり。
それから必要なら Kindlegen 等で変換かける。
ttp://tsubute.cocolog-nifty.com/blog/2010/01/post-2157.html ↑ここにコメントしたけど反映されないのでここに書いとく↓
＞本は紙で読むからいいいんだよ。とか、わけのわからない既成概念に囚われている
＞人も少なくないだろう
これは既成概念ではなくて、実際に紙の本に利点があるからなんだ。
それは、紙以上に直感的なページめくりがありえないということ。
何故なら直感的なページ捲りとはまさに紙の媒体で行われることを指しているから。
電子書籍業界ではその紙の利点は常識で、どうにかしてそれに近づけようとしているんだけど、
どんなに頑張っても板の上に画面を表示させている段階の現在では、なかなか追いつけない。
つまり、私が言いたいのは、上で述べたことと、
自分の考えに合わない考えを「わけのわからない」と簡単に切り捨てるのではなく、
もう少し広い心を持ちなさいということです。以上。
心が狭いですか？
紙の洗脳からとけてない昔人間にも電子書籍を読ませてやろうというサービス精神だろ。
紙にできて電子書籍にできないことはない。
その反対は、あまりに多すぎて書けないけどな。
電子書籍はパーフェクト。電子ペーパーの存在が大きいな。
２０世紀までが紙の時代。
２１世紀から電子書籍の時代だよ。
いつの時代も時代についてこれない奴はいる。
そういう奴は恥を晒さないようおとなしくしておけ。みっともないわｗ
そういうのはゴミ溜めの雑談スレでやれよクソが
亀だけど
ttps://github.com/jgoguen/calibre-kobo-driver のプラグインで幸せになれるかも
あれどうにかできないもんかね？
float入れたりしてみたけどかわんねーわ
全部の文字に全角空白でルビふってみたらどうだい？
また、その前後にルビ付きがあると開きが顕著に…。
後ろにルビなしの文字が隣接している時は、ルビのみそちらにはみ出すようになればいいのに。
漢字の上揃えでルビの表示ってできないのかな？
出来るようにならないかな？
ビデオタグはiPhone、iPadでしか働かないみたいに、Kindleのドキュメント
には書かれているみたいなんだが、困る。
即効で消えた、まるちめでぃあ本になるだけ
変換してくれるアプリかサービスは無いかな？
逆はあるみたいなんだが。
例えばあるページのどの日付のブログ記事にするかとか。
ePub の構造は簡単なので、そのへんに一貫したルールを付けられさえすれば技術的にはそんなに難しくない。
遅レスだがepubのやる夫スレまとめができてた
Firefoxでは見られなかったけど
ttp://aa-yaruobunko.x0.com/ ttp://freecomic.biz/ 今Sigil使っているけど、epub2までしか対応してないようなので。
一太郎、FUSEe
無料
でんでんコンバータ、かんたん電子書籍作成、AozoraEpub3
10.8.3だが俺もMacで使えん。
症状は全く同じ。
ttp://support.apple.com/kb/HT5559?viewlocale=ja_JP テキストファイルからepubを自作したいのですが、
任意の数行を指定して、可能な限り改ページしてはいけません的な設定をできる作成ソフトはありますか？
端末の解像度に関わらず、１ページ内に可能な限り表示したいのですが、
数行ごとの固まりの途中で改ページしてほしくはないので。
途中で改ページしたくない要素を p なり span なりでまとめて、
スタイルシートの page-break-inside を適用すりゃいいんだが、
そんなピンポイントな要求を満たすソフトなんてちょっと思い付かない。
細かいコントロールが必要な場合は直接に html を編集するしかないよ。
そこまでやってもビューアが対応してなきゃそれまでだし。
ありがとうございます。
やっぱり難しそうですね。
おとなしくPDFで作ります。
Macのアプリで言えば、有料アプリは買うに値しないと思う。
AozoraEpub3で十分だと思う。
「十分だと思う」じゃねーよ…
O's Editor２があるじゃない。
専用端末はタブレットに食われたし
フォーマットもepubで安定したし
そのepub作成支援も大体出終わったし
話題の電子図書館系か？
楽だろ。
または、GoogleDocで書き出して整形でもいい。
GoogleDocで作って販売停止にされてる人がいっぱいいたような。
AozoraEpub3(
ttp://www18.atwiki.jp/hmdev/pages/21.html)で「小説を読もう」からePubに変換後、iBooksに取り込んでいます。 変換はほぼ正常なのですが、一点だけ、iBooksの目次で飛びたい項目をタップしても小説の一番最初にしか飛びません。
設定で直せますか？
ちなみに目次をページ出力することで、そのページからのハイパーリンクで項目に飛ぶことは可能です。
ttp://www.hamashun.me/archives/4301651.html 縦書は完璧です。の問題だけがあります。
ttp://t2aki.doncha.net/?id=1363270197 これ見て修正してみたら？
toc.ncx修正すればいけるんでないの？
最低限の機能しか付いてないけど。
単にheight100%の指定では画面端で切れ、ページをめくると次の文章に行ってしまいます。
意味的には CSS で overflow を指定すべきところだと思うんだけど、
たぶん対応してる ePub ビューアなんてないだろ。
ttps://bugs.launchpad.net/calibre/+bug/1253965 /usr/lib/calibre/calibre/ebooks/txt/processor.pyの100行目
from markdown import markdown
を下記のとおり書き換える
import markdown
これで変換できるようになった
ちなみにvimは使い慣れてないのでsuでguiからやった
gksu gedit /usr/lib/calibre/calibre/ebooks/txt/processor.py
launchpadはちゃんと探してみるもんだね
Ubuntu13.04
Calibre1.0
とりあえずなんとか見つけたVerticalEditorってソフトでなんとかなった
AozoraEpub3作成のepub文書を画面一杯に表示するための変換ツールを作ってみた。
画像はもちろん、テキストページも全画面表示されるので
既読％表示を邪魔に感じている人にはすっきりしていいと思う。
一応、FW3.0.x向けだが、たぶんFW2.10.0でもいけると思う。
当方glo＋FW3.0.1で運用しているが、その他の機種／FWは各自で試してほしい。
ttp://www51.atwiki.jp/kb86/16.html koboglo+fw2.10.0+b2でテキスト表示は正常に動いてる
フォントパッチで左右マージン、ラインマージンを設定しているとはみ出すｗ
複数DDするとエラーが出る、ボックスが小さくて放り込みにくい。
デフォKBMにチェックしてもデフォルトフォントのままで変更されてない。
上下余白以外に左右余白も設定できませんかね？
あと、デフォルトフォントをKBminchoM以外も出来たらいいな
デフォルトフォントについては、
デフォルトのフォントが「KBMinchoM」になるという意味なので、
表示は「デフォルト」のままで問題ないと思うんですが。
それとも、画面に表示される文章のフォントもKBMinchoMではない？
他のフォントは、CSSに記述すべきフォント名がわかれば選択式も可能です。
内蔵のフォントはどう指定すべきか悩んだので、今回見送りました。
フォントパッチについては導入方法すらわからないので
その影響についての検証はできないし、対応する技術も無いと思う。
画面の左右マージン、実はワタシも答えを探している…。
表示だけじゃなくて、画面でもデフォのままです
2.10.0だからかな？フォントパッチでシステムフォント削除してるからかな？
表示もデフォルトフォントの変更も問題ないけれど
右端の行にルビがあるとベゼルの段差ギリになっちゃうので
左右のマージン調節効かないときびしい
進捗表示を消せるのは非常にありがたいので
アップデートに期待してます
当方はCWFでKBMinchoをシステムに刷り込んでいるので
もしかしたらフォントだけインストールしてもダメなのかもしれない。
ファクトリーリセットも面倒なので、今は確認・検証しないけど。
それはそうと、いろいろ試していてなんかすごいのができた。
画像のみのkepubなのだが、読書設定のリフレッシュ設定準拠で
設定ファイルをいじれば最大99ページおきのリフレッシュ。
加えて、ワンタッチでいつでも手動リフレッシュOK、てな感じ。
これもFW3.0/2.10専用なので、まずは国内正規版がリリースされないと
仕様変更があるかもしれず、安心して移行していいのかどうか悩ましい所。
まずはauraの発売時にアップデートがあることを期待しよう。
古い文庫なんかの表裏で文字のボヤけ黄ばみを消し去りたいんだけれどどんなソフトと手順がいいでしょうか？
今はひたすら断裁して取り込み→付属のAcrobat10でテキスト化してる段階です
あと、同じような新しさの本でもサイズが倍以上違うのもなんとかできればと思います
追記でファイルはpdfです
ところがgloでは全画面表示出来ていた自炊epubがAuraでは、余白ができちゃう。
calibreで転送してます。
転送時に.kepub.epubしてます。
端末での解釈が違うのかなぁ
多分君のgloのファームは2.6.0あたりだろう
自己レスです。
epubに直接固定レイアウトの設定を追加したら、うまくいった。
calibreでこの設定が出来ないものか？
端末の解像度指定はできるけど、そういうことじゃくて？
解像度はAuraにあわせてるけど、
なぜか、余白ができる。
Calibleでepubに変換後、ファイルの中を直接編集して初めて全画面表示出来るようになる。
gloだと変換するだけで、全画面表示できるのになぁ
まぁつど一回だけやればいいのでいいんですけどね。
自動化できる方法があればベスト何ですけどね
ttp://www51.atwiki.jp/kb86/pages/16.html 全画面化ツールがダウンロードできなくなってる
もし、電子書籍の販売の仕方がわからない方はこちらまで！！！
ttp://home.v03.itscom.net/pmkey30/ld/cocologToPubooToAmazon.html coboって誤字は指摘されて直したんかい？
>基本的には無料でOKです。(ｷﾘｯ
→楽天koboで出版する場合は月額525円となります。
→Amazon Kindleに関しては申請しても発売されません。
えっそれ全然無料じゃないし、そもそもPuboo使う意味なくね？
ボーナスサイトタグついてるし広告用の記事なんだろうけど
逆にPubooのｺﾞﾐｸｽﾞさが出ててすっげー恥ずかしい記事だから削除した方がいいよマジで
あり合わせの材料を使っても、まる一日かかったわ。
ただ、auraは持ってないので、gloとの動作比較をしてもらえると助かる。
ttp://www51.atwiki.jp/kb86/pages/15.html Amazon Kindle向けのepubファイル作成とかに便利なのでは。
FUSEe、Windows7 64bit対応しているのかな？
メーカーのホームページには32bitは対応と書いてあるが、64bitは情報載っていない。
対応しています。
Windows 8 インストール時にちょっとコツはいるけど、手順の説明書が入っています。
64bit 自作を含む一部環境でエラーが出るけど、対処法も説明書に記載あり
知識があるならハンドコーディング一択。
サポートで選ぶなら、FUSEe。
なろうのweb定義ファイルを書き換えればなんとかなる
とりあえず、ざっと書き換えてみたのをアップしてみた
AozoraEpubのフォルダ内にある web/ncode.syosetu.com/extract.txt と差し替えればOK
うまくいかんかったら、適当にページのソースを見ながら書き換えてみて
（各話毎の日付の表示はうまくいかんかったから非表示にしてる）
ttp://www.dotup.org/uploda/www.dotup.org4887416.zip.html 情報３９！
FUSEeのエラー対処の説明書の中身って、ネットで公開されているのでしょうか？
読んでから、買うのを考えたいです。
ttps://romancer.binb.jp ありがてぇ、ありがてぇ
早速頂きました
一部の小説がなんか、変換がおかしい
ttp://ncode.syosetu.com/n6332bx/ これとか、目次が集中してたり
さっき作ってみたのでどうぞ
ただ、あらすじの中の改行は、作者が入れたやつとなろうが自動で入れているやつの区別が出来ないので
改行位置がおかしくなります
begin-base64 664 syosetu.com_extract.lzh
UAAtbGg1Lf0CAAAwBQAAIoAFUyACkqNNBwBGpAMAAA4AAWV4dHJhY3QudHh0GwBBWh9xNhfHzgHo
TZOl8S3PAYFbKdMbz84BBgAAN94HAAACkWubFaT0m5qSHfYhwAOlr/NxsdmCNy2RQJWmjJjJBWxS
RAIgL+ybgLauQVcro4FR4FmMoiArFmzlHPwP82leI7fetKgmk25tNpNxa+HXRppsmX7/MWAfA6XL
rKUKIEPepQpAQQAf7a1Q9bqyY0aJckk50ODDjkRc6HFOjRyMaHBJV7v4Nigx0p0pPWmpcn2U5t94
ZgAR2AIdoEagEecXe7b3xT4wq+KwxhiGxMJ7j2/qxHpPrbEs1gD+2B3dMhTg4QI7ghVDpAfTT0ux
LR6lJ9JKnuK0IBD6ARoK9/UI+QnARkgR42LDCKMLKwhiIp2XAOijv7m4ryHjCGlm4BQxEKHmHZT6
NAjZR1eGU2JikjQYsG7w2/dGLwOblwIx2XCfwThB/k/HLc3A3d2boZitU3BlgehRT2vcxYXpWE4M
LdmlunIzJaWO/9YrU359Xo26uz1pI6zFg4dekox8Xg3y5nAg5A4f8UX+U1WYjXz1OLmAeJIFUM5w
IcjFhfmFegN/R8VW1x34otXjfjPVWOe5rZ6SL2TZWw/jUn7SlSUA/4AQ1AH8AD88CGmuR005vQnL
5U5nyT20ArI8vHzx3etzQqJlQ4WQ+jxMd/GOWqpPdopy9EIiGN7uvaAfqVc/fCHJb3QlryR0tCj3
y9MEhDxEhEMvRSpTEpMwMylJ4quzPVvdw6cmlOTa5c+wC8I20ZjYjQi3u2rS6ixH8IdW8/M9tleN
7bENmt2zGZ/94Gkhn5f9kKysX3ax9sr2O4yX8QOAYR6T371IMVV494TGn9qU7hU4NMMsA8NocIfg
lpTRPMtZri/buzSg4wYywDayErjgguzlqP3dNL9CQWTtZrL4AhycaVqklPZ+tWf21ZUmtUlNfY0x
CG10TjwMzztRvvaSze2BZuYaW4CK18vcmHCxY8JfJWu9Qql5Up0sLcrZnhfMB6AsP1XzXwRppStU
Tu1658HbFnssIBgE5oc0NWxQDswpvg3ligYi+1Xx3VPnz2aoduynN6Xhrw6u/IAA
====
前書きがあると本文が取得できないみたい
URLぷりーず
ちなみにキャッシュが残ってると新旧混在してうまく動かないので、.cacheフォルダの下にあるncode.syosetu.comフォルダは
消すなり別の場所に移動するなりしておきましょう
キャッシュ消したら問題ありませんでした
お騒がせしました
キャッシュ消したけど本文取得できないみたい。
ttp://ncode.syosetu.com/n5306by/ Base64EnDecoでｇｇｒ
普通にできるけど？
最初はあるんだけど第一章の12話から本文ないんだよ～
どうしてなんだろ
ttp://fast-uploader.com/file/6948540239736/ やってみましたが正常に出来ているようです
まず、別のフォルダにAozoraEpub3を新しく展開してextract.txtを差し替えただけのもので
試してみてはどうでしょう?
ttp://ncode.syosetu.com/n4046bv/197/ 新しくAozoraEpub3を用意してextract.txtだけ差し替えてもダメだった
同じ小説でも前置きが無い話数は問題無く落とせてる
無職転生とかはちゃんとできてるが
異世界食堂だと
「以上のことに注意して、お楽しみいただけると幸いです。」のあとが無い……
問題ある人とない人が分かれるってことは、落ちてくるhtmlソースに違いがあるとしか思えないので
で、578を落として見てみたら、各話へのリンクの部分だけが修正されていて
各話の抽出設定の前書き･本文･補足の部分は修正されていないので
最初のセクションだけ本文として取り出されるので前書きだけになるようです
583は当然修正されています
キャッシュが残ってるか落ちてくるindex.htmlに違いがあるとしか思えませんので、そのindex.htmlを
見てみないと原因がわかりません
乙
異世界食堂もも出来ました。
さん有難うございました!
異世界食堂できたっすありがとうございます。
しかし「AozoraEpub3を新たに展開」がそんな重要なんですかね……
cacheだけ消していけるのかと横着してました
個別対応になるけど、新品の道具なら同じ手直しですむので楽なのです
そもそも原因や過程なんてどうでもよくて、求める結果さえ出ればそれでいいって人が大部分なので
調査なんてせずに古いものを捨てさせれば済むのです
をBase64EnDecoでデコードして、古いのを削除して新たに展開したAozoraEpub3のweb/ncode.syosetu.com/の中のextract.txtだけ入れ替え
すると、↓のメッセージが出てまったく落とせない、駄目な話数があるとかではなく、全ての話数が駄目だった
同じことをのでやると駄目な話数はあるけど、一応使えてます
ttp://ncode.syosetu.com/n9669bk/3/ : List Loaded. SERIES/TITLE : タイトルがありません
ttp://ncode.syosetu.com/n9669bk/3/ は変換できませんでした ネットには公開されてないが、問い合わせれば、教えてくれると思われ
個人的に、サポートはかなり手厚く感じた
こう言ってくれてるのにスルーとか
釣りなのか疑うレベル
タイトルがみつかりませんというとこから推測して
の「## タイトル」の部分だけをのものと入れ替えたら上手くいった
（ひょっとしてデコードをミスってるのかな、何回やっても同じファイルになるけど…）
一話だけなのに目次が表示されたりするけど、本文は問題ないのでよしとしよう
おさわがせしました
## タイトル
TITLE .novel_title:0
↓
## タイトル
TITLE .novel_title:0,.novel_subtitle:0 (^.*</div>)
> /3/ :
って第二話「ドン引きのメイドさん」だけやろうとしたら俺も
「SERIES/TITLE : タイトルがありません」
が出たよ。
トップの目次からやればいいんじゃね
それは確かに、自分ではまったくやらない処理だからテストしてなかったな
っていうか、連載ものの各話単独での処理ってどういうときに使うんだろうな?
自分も必要はない、トップに戻るのを忘れて変換しちゃいそうになってただけでｗ
ってことで、連載ものの各話単独処理が必要な人の場合、にはの修正が必要ということでひとつよろしく
できました。
本当にありがとうございました。
ありがとうです。
したものに説明文を付けてうｐしておきました
ttp://fast-uploader.com/file/6948643504509/ そのうち消えるんでどしどし転載希望
ところで細かいことで実用上はさほど問題ではないんですが
KindlePWにどんどん上書きしていって読んでるわけですが
以前だと最新話のはじめから読めていたのが
ここんとこ最後の「底本：～ 変換日時：～」にすっとぶような
##本文に日付が無い場合 公開。更新日時の文字列に利用
###CONTENT_UPDATE_LIST .long_update ^(.+?)(<span title=\"(.+?)\".*)?$ $1 公開 $3
定義ファイルの修正どうもです
公開日付の部分を修正して、配布サイトのほうに説明書いておきました
開発放置しすぎて色々忘れてる…
やっぱり日付もほしいと思っておりました
作者さん、対応ありがとぉ
サイト構成が、がらっと変わったせいで
予想はしてたけど、やっぱりキャッシュファイルは互換性がないのですかー
今まで溜めに溜めた小説５９６話分の約１．２GBのキャッシュさん、さようなら～
変換すれば使えるよ。
・各話のindex.htmlの加工
本文のtagのidを新形式のidに
前書き＆後書きはtagのネストをflatにして新形式idを付与
・update.txtの改稿がある部分の形式を調整
をすれば
変換済旧キャッシュ＋新着の最新話
とかで問題なく使えてる。
目次が関係するupdate.txtにも手を入れないといけなかったのは予想外だったが。
抜き出してる部分は同じ形式なのに最終的にテキスト化される文字列で
微妙にspaceの挟まり方が違ってしまうようだ。
#tableタグからdd,dl,dtタグに変わったのがjSoupの振る舞いに影響でもしてるのか、
#根本的な原因は究明してないけど…
python+lxmlとかで作っちゃったから使うにはちょい敷居が高いんだが…
つまり、個別の話の URL は
ttp://ncode.syosetu.com/XXXXXXXX/1/ ttp://ncode.syosetu.com/XXXXXXXX/2/ ttp://ncode.syosetu.com/XXXXXXXX/3/ ttp://ncode.syosetu.com/XXXXXXXX/4/ ttp://ncode.syosetu.com/XXXXXXXX/5/ みたいな感じだけど、このとき第3話を削除したらかつて第4話だったものに
ttp://ncode.syosetu.com/XXXXXXXX/3/ の URL が割り当てられる。
更新日とかの情報を全部総合しても一意に特定できない場合がある。
ほとんどのケースでは問題ないけど、キャッシュとの整合性が合わなくなる可能性がある。
クソなサイトデザインだと思うけど、途中で簡単に切り替えるのも難しいだろうな。
暁なんかはそこらへん上手くやってるんだけど。
削除挿入等によるURLズレがあってコンテンツの一意性がない設計なのは前からの話だけど、
コンテンツの蓄積が進んじゃうと運営的には今更設計変更の手出ししづらい部分なのかもなあ。
各コンテンツの中身の類似度を見ながらURL移動をトラッキングすることは
(完全な精度を求めないなら)やってできない話ではないけど重いし
AozuraEpub3よりは、なろうに特化したツールの守備範囲だろうなあ。
タイトル等も含めて調べて、繰り上がり、繰り下げ等が発生してそうな状態かを判定して
ありそうなら詳細移動追跡モードに入ってキャッシュ再構成するとか、
独立したキャッシュメンテツールとしては作れなくもないんだろうけど。
書籍出版に伴うダイジェスト化とか最近は頻発してるから
ダイジェスト化前のコンテンツ保護とかも機能的には近いものがあるか。
(ダイジェスト化に伴う大幅なコンテンツ構成変更を自動検知して保護モードに入るとか)
ああ、類似度調べるためには新コンテンツ側を拾ってこないといけないから
そんなことするなら素直に全部拾いなおすほうが話が早い。
(trackingする意味がない)
やっぱ目次ページだけから大幅変動をある程度判定して
キャッシュ全purgeするかどうかを決める程度でしか機能しないなあ。
俺は自作のスクリプトで ePub 化してるけど、キャッシュは一切しないというサイトに優しくない方針をとってる。
(少しアクセス間隔を置くようにはしてるけど。)
それで成果物のサイズが前回よりも小さくなったら一部が削除されたものと判断して、前回分をリネームして残しておき、
完結してから手作業で編集するという運用。
せめて各話の最終更新が秒まであればそれが実質的な ID として使えるんだけどなぁ。
目次ページに表示はしないけど、html自体には秒単位で情報埋め込んであるとか、
APIで各話の詳細タイムスタンプ一括取得できるとか、
そういう配慮があれば話が早いんだけどねえ。
検索は API あるけど、個別の小説の内容はあまり勝手に利用されては困るって感じなのかもな。
あのデザイン。
読みづらかったり重かったりする仕様変更は本末転倒だと思うけどなー
慣れってもんも有るんだし。
重いというのも、変更した後でアクセス集中しているせいじゃないかな
運営としては変更によって良くなると思ってやってるんだろうからあまり無碍にするのもちょっと気がひけている。
禁則処理が無くなくなったことだけはものすごく違和感がある
以前は出来てたことなんだから是非処理するようにしてほしいものだ
これを normal にしたら禁則処理されるよ。
青空文庫の注記の入力を補助するマクロがあるけれどあまり使われていない気がする。
ttp://www.haijin-boys.com/wiki/%E9%9D%92%E7%A9%BA%E6%96%87%E5%BA%AB%E7%94%A8%E6%95%B4%E5%BD%A2%E8%A3%9C%E5%8A%A9 Emacs 用や秀丸用のはそれなりに使われてるっぽいぞ。
青空文庫形式の注記全部使えるのがこれしかなかったので。
固定レイアウトのタグを入れると、テキスト画面も引きずられて拡大される仕様なのだが、
画像・テキスト混合kepubの画像だけ拡大することもできるようなので作ってみた。
単純にFW2.6.0のように戻したい人にはいいかもしれないね。
AozoraEpub3-1.1.0b32が立ち上がらないのですが、
なんとか使う方法はないでしょうか。
AozoraEpub3-1.0.7u1だと使えています。
自分の環境では動いてるよ
AozoraEpub3: 1.1.0b32
Java 8.u5 64bit
Windows 8.1 64bit
なので環境の問題かと
ありがとうございます。
Javaが7だったので8にアップデートしてみたんですが、やはり立ち上がりませんでした。
何かが邪魔してるのかもしれないですね。
Windowsのバージョンの問題でないことがわかってよかったです。
今頃だがふと思い出したので、デフォルトフォントを任意で設定できるようにしてみた。
内蔵フォントはもちろん、fontsフォルダに新規追加したフォントについても適用できる。
フォントパッチの導入もしてみたが、
システムフォントの削除はやり方がよくわからないのでやっぱり検証できない。
とりあえず、本体のフォントリストに表示されていれば、そのフォントは適用できると思う。
EPUB3 やHTML5 でおもろい話有りませんか？
関連スレ
電子書籍を出版するならどこがいいの？
ttp://ai.2ch.net/test/read.cgi/ebooks/1311724771/
何もかも汚いフォントだったが、本文だけは serif に設定できたが、表題や設定、ボタンの説明などは汚いフォントのままだった。
Media OverlayのEPUB3を読めるもので良さそうだったけど、インタラクティブのレスポンスが悪すぎてどうしようもなかった。
例えば、ピンチでの拡大縮小、タッチでのそこからの再生、等がとても使える物ではなかった。 作りが悪いだけだろうか？
それともPhoneGapの限界だろうか。
音声の速度変換だけは音質も変わらず良かったけど。
Menestrelloは贅沢を言わなければ、リフロータイプのMedia Overlay （音声同期）本がiOSで読めるからテスト用としてはそれなりに存在価値は有るが実用にはならない。
勿論日本語にも対応していない。
iBooksの場合は固定レイアウトで作らないといけない。
調べてたら、EPUBの中にリフローのMedia Overlayを再生するJavascrictも存在してるみたいだな。 これを入れればiBooksでリフローの音声同期が出来る。
ttp://www.epubtest.org/compare/ これで主なリーダについて何が出来て何が出来ないかかなりはっきりする。
EPUB出版するにしてもどのリーダを対象にするかで作り方も変わってくるだろう。
日本のサイトで日本のリーダをテストしているサイトも有った。
ttp://densyodamasii.com/?page_id=2066 
ttp://densyodamasii.com/wp-content/uploads/2013/09/column_37_01.png まだまだお粗末だな、教科書なんかではテキストと同期して読み上げたり、インタラクティブな需要は大きいと思うけどな。
幼児用の絵本なんかインタラクティブ必須になるだろ。
epubとか、
htmlとcss,js全部の機能はもちろん動くべきだし、epub用の追加タグも全部対応してね？あ、追加タグって言ったけど、Webkitが標準化したタグとRMSDKが標準化したタグの二種類あって中身ちょっと違うけど両方対応して！
みたいな無茶ぶりも良いとこ
今から新しくビューワ作る人なんて出てくるのかね
EPUB3仕様を全て満足するリーダはほとんど無い。
クラス分けされて無いと買うユーザも騙されたと思ってしまうよ。
ただ、青空注記はパーシングがすっげー面倒臭い。
青空→HTML+CSSのコンバーター造ろうとして挫折したオレが無能なだけかもしれんが。
ついでに言うと、本家の青空文庫で公開されてるデータでも、青空注記をかなり雑と言うか間違った使い方してる奴もあるしね。
わかる。
校正記号みたいに人が読み書きする前提ならそれなりに合理性がある表記法だと思うんだけど、
データフォーマットとして見るとグダグダで扱い難い。
漢字に関しては今となっては Unicode に移行してしまえばいいんじゃないかと思うし。
なんてあると複雑すぎないかな。
ソフトには何がありますか？（有料含む）
できれば、マルチメディア対応で、
ビデオファイルとか、epubファイル内に組み込みたいです。
FuseEとか、マルチメディア対応だけど、
Windows7 32bitまでで、64bitには対応してないみたいですね。
作っても読めなきゃ仕方ないぞ。
Android用のリーダも有るけどDRMがかかった物は読めないだろうし。
PC用でReadium と言うのがフリーソフトで使えるようになってるけど、まだ商用では使わないようにと言ってるからな。
これは全てJavascriptだからHTML5が動く物なら動くが、そもそもEPUB3がHTML5とほぼ同じと言ってもHTML5をまともに実行出来るのは、Webkitを採用しているリーダしか無いから、今はAppleとGoogle以外は無い。
商用と言ってもリーダーだけなら結構どうにでもなると思うが、リーダーのハードが絡むと難しい問題がある。
マルチメディアを実行するには高価なハードが必要になるから。
ACCESS が、多分これを使ってマルチメディアリーダを作ったな。 主に教科書用途だが。
ドットコムのサービスでしょうけど、自サイトに出版済みの作品のビューワを設置するには
どうすれば良いのでしょう？
これを参考にしたら？
ttp://t2aki.doncha.net/?id=1398242194 半年前の質問に答えてもらえるとは思いませんでした。
今さらですがありがとうございます。固定レイアウトを勉強してみます。
ありがとうございました
書籍の中でjQueryとかHTML5のCanvas使ったプログラム動かしたい。
ePub3の規格上は作れることになってるねぇ。
でもまあ、どこまで再現できるかはリーダー次第でしょう。
ePaper端末なんかだと、あんまりダイナミックなアニメーションなんか、再生できてもマトモに見えない可能性の方が高い。
対応してるのはiBooksだけじゃないかな。
どうせ今はiBooks以外のリーダはまともなマルチメディアを動かす能力なんかないから、やるならiBooksだけに絞ってやっておけば良い。
そのうち色んなリーダの性能も上がって来るだろう。
基本的にはHTML5のほぼフルセットが使えるんじゃ無いかな。
iBookだとWebKitを丸々信用して良いと思う。
ただ、iBooksと互換性が無いケースが所々有るから両方で読ませたければ注意が必要。
ttp://www.bluegriffon-epubedition.com/BGEE.html MFブックスの異世界弁護士1をkindleで、一気読みしようと
H2Tconvにて
一話の
ttp://mfbooks.jp/original-books/sakiyomi/archives/57 から
最終話の
ttp://mfbooks.jp/original-books/sakiyomi/archives/105 までの24話分読み込んで、開いたら文字化けを起こしてたんですが
何かいい方法ありませんか？
そう、思うだろ。俺もそう思ってた。だから落として連結されたの変えたり、h2tconvの設定見直したりしたんだが無理だたんで他の方法含めききにきた
んでそのあとAozoraEpub3+kindlegen
対応してないサイトとかからもコピペでやってたんだが
ほんとはそれも追加する方法とかあんのかな……
,424,425
俺のお勧めでの追記項目としては、フッタに
［＃改ページ］
そして個人blogや取得する個人サイト、その時の気分等で変えているが
俺が今現在使っている最新のヘッダは
［＃ここから中見出し］$TITLE［＃ここで中見出し終わり］
［＃ここから地から１字上げ］
［＃ここから１段階小さな文字］
$FTIME
［＃ここで小さな文字終わり］
［＃ここで字上げ終わり］
で、メモ帳じゃなくてフリーソフトのMKEditor for Windows
使って開いたら改行もキチンと表示されてるから編集しやすいよ
リンク抽出は、ぐぐって自分に合ったのを探したらいいよ
うちは、古い人間なんでunDonut+modに付いてる標準のリンク抽出使ってるから当てにしない方がいい
で、上に話題に上がっている異世界弁護士で実践してみよう
ググって、出てきた
ttp://t.mscl.jp/chk/ リンクゲッターに
ttp://mfbooks.jp/original-books/sakiyomi/lineup/isekai-bengoshi-1 目次のこのページを読み込ませます
次に抽出されたのをH2Tconvにて
ttp://mfbooks.jp/original-books/sakiyomi/archives/57 ttp://mfbooks.jp/original-books/sakiyomi/archives/60 ・
・
・
105
まで、貼り付けて余計な
----------------------------
が、あるからそれだけは消す
変換後 アプリで開くのチェック入ってるの確認してMKEditorを設定しておく[初回のみ]
開始ボタンをクリックします
そうして、文字化け問題が解決されていると仮定して
複数行置換にて似たような部分を抜き出し
置換前文文字列に貼り付け
置換後文字列のところは 空白でおっけー
広告やらいらない部分を消したらaozoraepub3に放り込んで終了
そうして、結局 異世界弁護士の文字化けはどうにもならんのかのぉ
kobospan入れられるとどうなるの？
kobospanについて仕様書みたいのがどこかに公開されてるのかね？
AozoraEpub3-1.1.0b32のフォルダを
Program FilesまたはProgram Files(x86)以外の場所に置いたら起動しました
亀レス、ゴメソ。
Win7 説明書に書いてある必要コンポーネントが揃ってないと起動しない
Win8.1 必要コンポーネントは自動インストールされるが、FUSEeのアップデートは全手動
サポートの担当者が変わったため、サポートの質が落ちた印象。
さんくす！とても参考になりました。
※ 要サイト名検索
☆ +ニュース板
・ 2NN
・ 2chTimes
☆ +ニュース板新着
・ 2NN新着
・ Headline BBY
・ nl/bbynews
☆ ニュース板他
・ NEWS100@2chATR
・ Desktop2ch
・ 記者別一覧
☆ 全板
・ 全板縦断勢いランキング
・ 2勢
・ READ2CH
それでも高い・・・買おうかどうしようかな？
ttp://viewporter.com/epub3-editor/ これはどうかな？無料みたいだけど。
ちなみに韓国のソフト会社の製品だが、日本語表示には対応している感じ。
XHTMLのタグ編集が出来ないようなのが気になった（出来るのかな？）。
FUSEeは、今の1.3.2は買わずに、2.0バージョンアップ待ったほうが良い。
今の1.3.2は、ソフトの中身が古すぎて、
ソフトが売りにしているデザイン画面とか使って編集すると、
出来たコードが、epubcheckerでエラー出まくりのひどいことになる。
タグ編集ソフトも、途中でカーソルの動きが変にもたついたりして、ちょっと実用にならない。
30000円もつぎ込む代物でないのは明らか。単に無料配布だったFuseβを強引に有料化しただけ。
今は、開発会社が潰れずに2.0を出すところまで漕ぎ着けるのを祈るのみ。
xhtmlファイルの編集は、外部のエディタ（秀丸とか）を使って行えた。
epubcheckもメニューから行えて、エラー箇所を表示してくれる。
Viewporter、韓国製というのが気にならないのであれば、結構、使える感じだね。
（「失敗しました」と出る。）
かなりがっかり。
ちょっと手間がかかるが。
青空EPUB3で変換したEPUB3（「反逆」の字間が調整されて広がっている）
ttp://i.imgur.com/4WdjAZL.jpg 目指したい形（販売物。親文字がきっちり並んでる）
ttp://i.imgur.com/Y68zDfg.jpg Indesignがルビを細かく調整できてEPUB出力できるということで体験版を入れてみたんですが、
↓グループルビ＋「親文字間の調整」を「調整しない」にすることで編集中はきっちりとすることが出来たのですが
ttp://i.imgur.com/JWQnUCG.jpg いざEPUB3形式で書き出すと、↓ように文字間が開いてしまいました。
ttp://i.imgur.com/pGwncaT.jpg 全部同じビュアーを使っています。
かれこれ2週間はこれで悩んでます。
そろそろハゲそうです。方法ご存知のかた教えてください。
全くの素人考えだけど
叛[はん]逆[ぎゃく]ではだめ？
字間が空くものと空かないものがあるなら
現時点では、諦めるしかないような、、、
特定のビュワーにだけ対応させればいいのなら
そのビュワーを示して引き続き頑張れ
そのclassのスタイルシートでの設定でinline-blockするとかはどうだろう
試してけど
でいいんじゃない？
解決案としては非常に素晴らしいのだが
構造化文書としては絶対にやってはいけない例であるな
こういうハックが蓄積されることで、みなさんのお使いになるアプリはバグ満載となるのです
byエンジニア
cssで困ったら、禁じ手「販売物を割って中のcssを見てみよう」って手もある。
kindleはごにょごにょしないとダメだが、
koboだと立ち読み版が暗号化されてないので、DLして拡張子変えれば普通にcss見れたりする
ログイン時にいちいちメルマガ希望させようとしてきてウザすぎﾜﾗﾀ
解除めんどくせ
そのうちまた間違えてメルマガ登録しちゃうから、解除するよりメアド側で着信拒否にしておく方が楽。
質問の答えにはなってないが、リフローがあるから気にしなくて良いと思う
手持ちの小説確認してみたけど、ちょうどいい位置に句読点なくて確認すらできなかった
禁則処理があるからちょうどいい位置に来てないと勘違いしてる。
句読点が行頭に来ないように前の行で1文字少ない場所で改行される。
行頭1文字＋句読点（改行）みたいになってたらそれ。
紙本が縦40字として電子版の同じ本で縦40字になるよう調整したら
本来ぶら下がりになるべき場所でそういう自体が度々発生する。
均等揃えすら自動で行ってくれない時点でお察し
毛唐はもちろんローカライズ担当者にも日本の組版知識なんてあるとは思えないし
レンダラを改良する技術も権限もないだろうね
一応CSS3にはhanging-punctuationってのがあるんだけど
現行のepubがCSS2+3の一部だから定義されてない
均等揃えもCSS3には定義されてるもののやはりepubでは……
RTCには日本語組版に必要なモノが全部揃ってるんだよ。WGは実によく勉強している
実装がおいついていない。それは市場の需要がソフトウェア情勢を動かすほど盛り上がってないことを表している
次が「破綻なく縦組み」。
「美しい縦組み」はさらにそのあとだ。
実際、ラノベなんかだと横組みの方がいいんじゃないかってぇのも多いけどね。
ルビの多いアレとか、英文字を多用するアレとか。
俺「えーと……」
ガキ「ワールドブレイクだよ」ﾆﾔｧ
シコシコソース修正するのもかったりいよ。
text-decoration:noneを指定してても
勝手にoverlineにされてしまう現象に悩まされてる
カギ括弧の時は字下げしなくていいというデタラメがネット界隈にも流れているがなんとかしてほしいわ。
p style="text-indent:0.5em"でもいいけど
文の途中に出てくる場所で自動改行されるものには対応できんから微妙だった
推薦して下さい。僕としましては、サクサクとページめくりができる事が
一番大事です。後は、大差はないでしょうから画質とかは普通程度有れば
いいと思います。宜しくご指導をお願い致します。
我が日本国では全角スペースを一つ打って下げることを字下げ（一字下げ）というんだよ。
で、文の途中で改行された場合において「行頭に来ているカギ括弧」とわかるように天ツキというものがある。
つまりここは段落の始まりではないという意味。
こういったことが、段落というもので文章をつくる知的文化。
キンドルも米国の段落（パラグラフ）で文章をつくる知的文化に則っているから天ツキというものがある。
ちなみに中国は二つ打って二字下げるらしいが、朝鮮には段落の概念がないんだろ？
段落のスタイルはスタイルシートで別に定義するべきだから空白インデントというクソな習慣やめろ
という話なのにそれが理解できてないお前がアホなんだよ。
>段落のスタイルはスタイルシートで別に定義するべき
なんだ、このキチガイは。
んなもんスタイルシートで定義すな！ 日本人じゃないのか？ 恥を知れ。
こういうバカ、とくにワードを使っているバカがコピペをすると無茶苦茶になる。
使いもんにならん。おまえと同じだ。
「印刷したときにきれいに見える」が目的なのか、
「どんなリーダーでもそこそこに見える」が目的なのかによっても、違うよな。
「行頭に空白を入れて段落」というのは、小学校の作文で、原稿用紙を使ったことによる方便だよ。
真っ白や、罫線だけの紙に書くときは、「ちょいと下げる」だけだからね。
ところで、「行頭に半角スペースふたつ」は、やっぱりアカンのかな？
横から。出版社辞めて長いので、今の状況に疎いんだが
なんで段落をスタイルシートで定義したらいかんの？
簡単にでも教えて欲しい
いまの出版社は糞だから関係ない。だいたい電子データのことに関しては無知蒙昧。
人類の知的財産をそのまま残すための方策だ。
ようは、純粋にテキストデータのみを将来世代に残したほうがいいんだよ。
媒体やブラウザーに依らない、純粋なテキスト。これこそが電子書籍のあるべき姿だ。
コピペしやすく違法コピーもしやすくなるが、それはまた別の問題。
また文章には二種類の書き方がある。
一文一文、つまり文（センテンス）を積み重ねていくタイプ。ブログやネットの書き込みがそうだ。ここに段落の概念はない。その縛りはない。
もともとアジアの文化はこちらであり、日本もじつはそうだった。だから教育を受けていない者、身についていない者は、しぜんとこういった書き方をする。
そして、段落（パラグラフ）を一つの単位として積み重ねていくタイプ。長い文章を書くとき欧米ではこれは当たり前の概念だ。どこぞの欧米人がゆーとったわ。
この両方の書き方を、いや文化を、ちゃんと区別し、書き手の意図したそのままの形で残していくためにも、スタイルシートによらない保存方法がよい。
いずれみな、それに気づく。
欧米人は段落の文化だからスタイルシートで一つの形に決めてしまっても問題ない。
しかし日本人は両方を使いこなす。ゆえに日本語は複雑で高度な言語だ。スタイルシートごときで型にはめんな！
ファイルの拡張子をxhtmlからhtmlに変えると、無事編集できた。
ホームページビルダーをベースにしたEpub3エディタが出たらいいのになと思う。
比較的長持ちするMOメディアとか今では絶滅しているし。
書籍は、中性紙の紙媒体で作成した方が後世に残りやすい気がする。
うーん・・・歴史的というか思想的な理由だったんですね
全面的に賛同というわけにはいかないけど
とにかく詳しく説明していただいて有難うございます
両方が混在するならその区別をデータ上で表現すべき。
適当なクラスを定義すればよい。
意図を残すなら意図を表現する手段を活用するのが筋というものだろ。
構造化文書もなにもあったもんじゃないな……
母国語しか知らない人間は、とりわけ母国語を特別視したがる傾向にある
複数の言語に親しめば、日本語も「よくある言語形態のひとつ」にすぎないことを理解できるだろうに
なぜか本文の検索ができない
今開いてるページにあるキーワードを検索しても結果0件って表示になる
なにか特別な作業が必要なんだろうか
Kindle端末が裏で検索用のインデックスを作ってるから、それが終わるのを待ってあげて
いつ作り始めていつ終わるのかはよくわからんが
もうこまめに消してるわ
その場合未インデックス化タイトルって出ますよね？
ttp://gyazo.com/5db8dd77e429dec87bb8c5f4b245ed9c.png 十分時間をおいて再度検索して
ttp://gyazo.com/c21134b72f08fe74998a3c35eb6e3d0e.png この状態です
一応環境
Kindle無印2014モデル(5.6.1.0.6)
なろうのほうはもう端末に頼るのはやめて
作品全文検索 - 俺Tueee.Net!ってので探してるな
1.下記サイトにて、EPUB 3ファイルに変換して、
ttp://books.doncha.net/epub/ ibooksに読み込むと、
以下のエラーが出て、最初の数ページしか表示されません。
“This page contains the following errors:
error on line 34 at column 90: PCDATA invalid Char value 8
Below is a rendering of the page up to the first error.”
2. そのEPUB 3ファイルをKindlePreviewerにてmobiファイルに変換して、
iphone用Kindle(縦書き設定済)に読み込むと、
エラーは出ず全文表示されますが、縦書きになりません。
3.他にも試行錯誤しており、
でんでんエディターで、テキストをEPUB 3ファイルに変換しようとすると以下のエラーが出ます。
Error!
ErrorException [ Error ]: Call to a member function find() on a non-object
そこで28万字を16万字に減らし、変換すると、変換時にエラーはでませんが、
ibooksに読み込むと、1.と同じエラーがでます。
iphone用Kindle(縦書き設定済)に読み込むと、
エラーは出ず全文表示されますが、縦書きになりません。
4.また、t2epubというツールで、
configで縦書き設定しても、本文が縦書きになりません。
また、ibooksで読み込むと、やはり同エラーが出て、最初の数ページしか表示されません。
5.ちなみに、以前、EPUB 3ファイルをSigilというツールで編集すると問題なくできた記憶があるのですが、
Sigilは今ダウンロードできないようです。
(SigilはEPUB 2までしか対応できてないという批判もあって今はダウンロードできないのでしょうか)
自作テキスト(28万字)を縦書きで全文を、ibooksとiphone用Kindleで表示する方法を教えてください。
(ibooks、iphone用Kindle、どちらかでも構いません)
それか変なメタ表記入ってるとか
あとは青空文庫形式テキストにしてJava上ツールのAozoraEpub3で変換するか
>error on line 34 at column 90: PCDATA invalid Char value 8
34行目の90桁に、バイナリ(キャラクタコード8 = バックスペース。気の利いたエディタなら"^H"とか表示されるはず)
があるって言ってるじゃないか。
申し訳ありません。
せっかくご教示くださっているのですが、バイナリの意味が分かりません。
ワード、サクラエディタを使用してますが、"^H"とは表示されません。
サクラエディタで、テキストファイルを文字コードutf8（BOMなし） 改行コードLFで設定しましたが、改善しません。
ワードのファイルの変換で「改行の挿入」にチェックを入れると、エラーは起こらず全文は表示されますが、文章途中で改行が入ってしまいます。
改行あたりにヒントがあるのかと思い、禁則処理を行わないや、句読点のぶら下げを行わないようにしても、改善されずです。
引き続き試行錯誤中です。
備忘録としてあとでログに残しておきます。
結局原因は分かりませんでしたが、この方法で取り除くことができました。
ワードにて作業
1.検索と置換にて
・「 (全角スペース)」→「●」
・(特殊文字ボタン押し、段落記号を選択)「^p」→「■^p」
これで文頭などの全角スペースが●に置き換わり、改行の手前に■が入力される。
2.ここで一旦名前を付けて保存すると、ファイルの変換画面が表示される。
UTF-8を選択するのは当然だが、
ここで「改行の挿入」にチェックを行う。つまり「^p」が挿入されます。
3.検索と置換にて
「^p」→「入力無し」
全文から改行が無くなります。
4.検索と置換にて
・「●」→「 (全角スペース)」
・「■^p」→「^p」
1の作業の逆にみえますが、
「■^p」の「^p」は3の作業で抜いているので、ここでは「■」の置き換えになります。
以上です。
これでエラー原因を取り除いたテキストを、下記を使ってEPUB3に変換し、無事ibooksで閲覧できました。
ttp://t2aki.doncha.net/(ひまつぶし雑記帖 かんたんEPUB3作成ローカル版) 私だけかもしれませんが、残しておきます。
皆様、お騒がせしました。レスくれた方、ありがとうございました。
Kindle Paperwhiteでmobiファイルを作りましたが、(念のため縦・横両方)
iphoneのKindleアプリでは横書きで表示さてれてしまいます。
ちなみにPCのKindlePreviewer上では問題ないです。
(ibooksでも問題ないです)
実際KDPに販売すれば、縦書きで表示されるのでしょうか。
下記のサイトだと、そのような事が書かれてありましたが、今もまだ改善されてないのでしょうか。
ttp://blog.sixapart.jp/2013-05/KDP-troubles.html#3 ツールが何かは知らないが、たぶん大丈夫。
ストアで購入した本は長押しドラッグでドラッグした範囲だけ選択できるけど
AozoraEpub3で作ったのだと長押しした時点で文節を丸ごと選択して確定になるみたいだ
みんなはドラッグで選択できてる？
何とかならないものか・・・
自分はkindle端末を使っていないから詳しくないけど、似たような報告を最近Narou.rbで見た覚えがある
＞Kindle端末で単語の選択を出来るようにするために、小説別変換設定に
＞enable_insert_word_separator オプションが追加されました
変更履歴に上記があったけど、これが756の言っている不具合対応にならないかな
面倒じゃなければ、Narou.rbを試してみるといいかも
まさにそれでした
ありがとうございます
H2Tconvの文字化けは
できたtextファイルの拡張子をhtmlに変えて、いったんブラウザで読み込む。
ブラウザの文字エンコーディングを何種類か試すとたいてい読める。
それを新しいtextファイルにコピペする。
これでいけるよ。
なろう小説からお気に入りの小説をAozoraEpub3でDLしてるんだが
――― これの前後に前書き・後書きが入ってると小説の世界観が台無しになるから
削除した状態でDL・連結したいんだが、できないのかな?
前書き・後書きを含めないもの、あるいはオプションで含めないようにするものもある。
でも、大抵はドキュメントがないので使い勝手悪いんだよな。
そっか、使い勝手が悪いのか。
取り敢えず物は試し、実際に使ってみてダメっぽかったら
1話1話、前書き・後書きを削除・連結するよ、ありがと
ファイル生成にAndroidのアプリ使ってみるとかは？
PCで環境作るの面倒かもだけど
ttp://i.imgur.com/2Fp2Mro.png Androidにそんなソフトがあるのか、環境整えて試しに使ってみるよ ありがと
narou.rb
これを左綴じにするにはどうしたら良いの？
mobiのままじゃない？azkにしてる？
タイトルリンクも自動でやってくれるし、直感的に電子書籍に書き込んでる感じがいい
あと脚注機能さえついてくれれば文句ないわ
どうにも紙の本とルビの振り方が微妙に違うのが気になっていたので、
紙本のルビ表示をなるべく再現するべく変換機能を追加してみた。
補正できるのは、単漢字に対する１文字・３文字・４文字ルビの表示のみです。
熟語を分解して補正するわけではないので、青空ソースの時点で単漢字ルビ振りをする必要があります。
AmxPlus v1.09
補正前
ttp://cdn51.atwikiimg.com/kb86/pub/ruby00.png 補正後
ttp://cdn51.atwikiimg.com/kb86/pub/ruby01.png ３文字・４文字ルビの場合、前後の文字の状況によって、個別に表示が変化します。
こんなマニアックなモノに需要があるのかどうか分からないが、同志がいたらいいな…
aozoraepub3で、出力先を今までずっとデフォルトで使ってて
今まで手動でKindleのフォルダに移動してたんだけど
これ出力先を
F:\documents\narou
に変えたら、すっげぇ楽になった今のバージョンだとepub削除してくれるし・・・
本当に何で今の今までこんな簡単な事に気づかなかったのか
いままで手動コピペでやってたわ……
aozoraアップデートもぜんぜんしてなかった
小説家になろうの仕様変更以来
情報ｔｈｘ
前からのクセで端末つなぎわすれてたｗ
本好きの下剋上で
一時著作権切れの本を再現しようとした時にルビのせいで本文がずれるのが気持ち悪かったから補正したくなる気持ちは分かる
Ruby 2.1.0以上がどうのこうのと
コマンドプロンプト？でギブった
基本コマンド操作だし、WebUIもD＆D対応してないから複数の新規小説一括変換出来ない。日本語フォルダ対応してない。
ランキング見ながらの変換作業も一手間だし、あえて言うなら既読小説の管理は楽かもしれないが
urlのファイル保存しててドロップboxと共用してスマートフォンからも見ている俺からしたら導入するメリットが見当たらず変換作業も手間掛かるだけに成り下がって2日で削除。
せめて、右クリックメニューの中に narou.rbで変換する。
とかあったら便利だろうなぁと思ったぐらい
やればいいじゃないか。
ブラウザの拡張機能でコンテキストメニューを追加するやつあるだろ。
いや、一つの事にしか食いこんできて、そんなアホな事をドヤ顔で言われても
それに自分が試してもいない事を言うても。
お、おぅとしか
コンソールアプリの方が組合わせはやりやすいってことの例として挙げたつもり。
トレードオフや優先順位のあることだから、これはこれでこういうデザインなんよ。
文句を言うなら「このツールが使い難い」じゃなくて、「他の選択肢がない」ことについてだと思う。
DLしたい小説のページを開いてる状態で、1クリックで完了(DL/変換/転送まで一括)
右クリックもD＆Dも必要ないし、連続して複数作品もいける
ブックマークレット使用ってNarou.rbである必要性あるのか？
そしてランキング見ながらタイトル掴んでのD＆Dだからページ開かない
もちろん必要性はないけど、Narou.rbに用意されてる標準機能で、便利で使いやすいから使ってるだけだ
なるほど。直接ページ開かないのは想定外だったｗ
こっちは大体いつも軽く読んでみてからDLしてるから、自分にとってはこれが一番楽なんだよ
Downloadボタン押して出てくる窓にリンク掴んで放り込めばいいだけだな
1つずつ改行する必要はあるけど、まとめて複数もいける
日本語フォルダ対応してないってのも最初だけで使い勝手にはほぼ無関係
まあ、変換すること自体が手間とか言ってるあたり釣りっぽいが
明示的にサムネなしのmobiって作れないのかな
narou.rbでenable_double_dash_to_imageをオンにすると縦棒のサムネだらけになったｗ
kindle端末側の問題かねぇ
全然マニアックじゃないわ
各電子書籍ストアのアプリ担当に
君の爪の垢を煎じて飲ませたいぐらいだわ
「感想を書き込む前に」のひとことだけとか
アチラがわの問題だろうか？
他の作品でもそうなる
ありがとうございました
>AozoraEpub3でハーメルンの最新話が保存されない
ttp://blog.livedoor.jp/zask5178/archives/457398.html 外部のツールを使う必要あるの？
細かなオプションで調整したいこととかはあるかもしんないけどさー
試してみたけど、細かいこだわりはないからそれで十分だわ
まあ、強いて言うなら外部ツールを使った方が鯖の負荷軽減になるのかな
保存フォルダが隠し属性でファイラで拾いにくいんだよなぁ
負荷についてはサーバの構成によると思う。
ePub 版で落とすなら各話にアクセスするための転送量と接続回数は抑制できるが、
そのかわりに ePub に変換する処理が走ることになるわけでどちらの負担が軽いとは一概に言えない。
(負荷がかかる場所が違うので。)
使いたいように使えばいいんじゃないの。
ユーザが普通に利用してもサーバの方で負担が大きいのなら、
サーバの増強なりサービスの見直しなりになるだけだろ。
もちろん、ツールを使ってウェイト無しに一気に何千作品も落とすような「普通でない」使い方はダメだと思うが、
普通のユーザがそんなみみっちい負荷のこと気にする必要ないよ。
ttp://sigil-ebook.com/ こんどは>792のいうようなファイル出力ためしてみるわ
設定項目がよくわからんが
AozoraEpub3のは問題なく開ける
なんか違いがあるんだろうね
ttp://www1.axfc.net/u/3615719 validator をパスしたから完全に仕様通りになってるはず。
俺は Kobo もってないので試してみて。
ちなみに元のやつはこれね。
ttps://novel.syosetu.org/57301/ kobo glo で開くことはできたよ
(ハーメルンで作った縦書kepubは開くこともできない)
でも文字が消えてて読めない
これはハーメルンで作った縦書PDFでもそうなるね
それはダメなの？
EPUB／PDF／JPEG／GIF／PNG／BMP／TIFF／HTML／CBZ／CBR／MOBI
でしょ
一般のほうはいけるが
更新来たと思ったらカクヨム対応で泣くかとｗ
無ければ自分で作るけど
Narou.rbが人柱版公開中
koboだと地雷
mobiで作ってもだめ 読み込めない
今更 Kobo を選ばないでしょ
Narou.rb使ったらkoboでも開けたぞ
ノーマルのままでも自炊本や自作ePubが簡単に取り込めるとか、
ファームウェア書き換えたらAndroidが動くとかって聞いたけど？
なおした
kepubは普通に読めて、epubはページめくりが逆に、mobiは横書きになってたが…
テキストと同じ階層に画像ファイル置いてるし何が原因なんでしょうか…
スレ汚しスミマセン
読めるようになってる
中の人ありがとう！
動的な表示がしたい
リーダーが対応しなきゃ仕様だけ定めてもどうにもならんからな。
E-Ink のクソ遅い描画とか、変則的で小さい画面とかいったデバイスの制約もあるから、
そういう環境では実行できてもまともに使えないし、現実を考えればオプショナルになるのは仕方がないわな。
JavaScript を使う場合でも、使えなくても最低限度読むことは出来るように構成することが求められているが、
色々と配慮しなきゃならん出版業者でもあるまいし、リーダーを限定して実行できればいいという選択もありじゃない？
PC やタブレット上でウェブブラウザ拡張として実装されたタイプのリーダーなら JavaScript も動くことが多いよ。 (結局はウェブブラウザなので)
ときどきサイトを見に行く
>ノクタは、novel18.syosetu.comの中にあるextract.txtをこちょこちょしたらいけた -- 名無しさん (2016-06-11 22:19:35)
あぁぁ教えてほしい 👀
Rock54: Caution(BBR-MD5:0be20a4887bc3d3353f527d3636c44e3)
サイトに作者さんの書き込みがあったよ。早めに対応するようにします、だってさ
自分もうれしい！
narou.rbはダメだったんだよね
まあ進展あったのは良いことだ
対応されてるのは知ってるし、
Aozora作者コメントでも「急ぐならnarou.rbのほうを」つってんのよ
しかし個人的にはちょっと使えん
そんな意味だろうなと思ったから「何がダメだったのかは知らんが」と前置きした
お前の発言だけだと他の人が誤解しそうだから補足しただけだ
助かりました！
ありがとう！ありがとうございます！
Pandocで変換
ttp://gazo.shitao.info/r/i/20160914070816_000.png ADE の以前のバージョンではちゃんと表示できてた (具体的なバージョンナンバーは覚えてない) んだけど、
これって ADE のバグなの？ それとも ePub の仕様のほうが変わったりした？
少なくても 4.0.3 では同じようなおタコな表示してる。
ttp://i.imgur.com/WoFjP3p.png 「でんでんコンバーター」で作ったやつだけど、それがダメだったのかな。
Narou.rbも同じAozoraEpub3を使ってるからEpubを作る時の設定によるんだと思う
css かな？ opf の方かな？
<nav epub:type="toc" id="toc">
↓
<nav id="toc">
としたら正常になった
AozoraEpub3だとKindlePWの設定にして拡張子を「.mobi+.epub」にするとうまくいくっぽい
もしくは template\OPS\xhtml\xhtml_nav.vm を書き換え
yomou-publisher (
ttps://github.com/SaitoAtsushi/yomou-publisher) で作った ePub ではその箇所だけ変更しても ADE での表示は変わらなかった。 他の指定とのコンボで効いてくるのかもしれない。
Narou.rbで作ったファイルと比較しようとしても構成結構違うからしんどい
……ADE使わないかNarou.rbとかを使うのが良いのではなかろうか
Yomou publisherはこれ毎回全話DLするのかな
だとすると連載を追うのに使うのは厳しそう
なろうのサイトは URL が常に連番で維持される (話を削除すればその箇所が詰められるし、間に差し込めば後が全部ずれる) のと、
更新日が日までで時刻がないという問題があって厳密にキャッシュの整合性をとれない可能性がある。
そういった問題を一切無視して簡易キャッシュを付けたバージョンは作ってあるんだが、
細かな管理の機能やドキュメントを用意するのがわずらわしいのでいっそキャッシュしないと割り切ることにした。
どうしても必要ならキャッシュ付きのプロキシ使うとかいう方法もあるし。
narou.rb は WEB UI まで用意したりしてたいしたもんだ。
でも、 narou.rb の、複数のツールを下請けで使ってる構成があんまり好きじゃない。
自分でカスタマイズしたいときに Ruby ようわからんというのもあって使いたくない。
どうしてもYomou+ADEでやりたいなら、とりあえずADEで正常に読めるファイルを作って参考にするしか
ちなみにNarou.rb、自分もRubyとか知らないけど例えばアルファポリスに対応するのは結構簡単だったよ
なんか、海外のepubビューアで時々見る感じだ
ADE以外だとどうなるかね？
まぁどうしてもADE使いたいなら作る方調整しないとか
AozoraEpub3で作ったePub3縦書きファイル表示してみた
Google Chrome上のReadiumだと問題なく表示できるけど
Adobe Digital Editions 4.5だと表示がおかしくなってる
普段は Sony Reader で読んでるから実害はないんだけど、生成スクリプトの大幅な改変を考えてて、
結果の確認にいちいち転送するのが面倒くさいから ADE で久々に開いてみたらこんなだったという経緯。
ADE は縦書き対応してるはずなのにおかしくなるのは指定の方に何か間違いがあるのかもしれないと思って訊いてみた次第。
無視しちゃってもいい話ではあるんだけど、マイナーなリーダじゃなくて ADE での話だからなぁ。
主要な ePub リーダのひとつといえる ADE できちんと表示されないのは気持ち悪い感じ。
html タグに対して writing-mode での縦書き指定を入れると狂う。
body タグに対する指定にすると OK だった。
つまり css で
html {
writing-mode: vertical-rl;
}
とか書いたらあかん。
body {
writing-mode: vertical-rl;
}
ならきちんと表示された。
うお、原因わかってよかった
週末試そうと思ってたよ
俺はハードはreader、ソフトはKinoppyだな
Kinoppyのepub表示がreaderに近い感じなんで
ページ数カウントがむちゃくちゃになるのと、本文を読めない。
ttp://www.rupan.net/uploader/download/1474482819.epub (ダウンロードパスワードは epub です。)
コンテンツの各ファイルは opf ファイルを置いたディレクトリかその下のディレクトリにおかないと狂うっぽい。
バリデータはエラー無しと報告するんだけどなぁ。
ttp://i.imgur.com/OHxvw1B.png 
ttp://i.imgur.com/oYTSd6t.png いつもこの部分で発生するわけではなく同じ文字サイズでも発生する場合としない場合があるようで困っています
mobi自体の行間隔設定とか余白設定でも変わってくる
表示がたまに1行減ったところで一体何が困るのか
全く同じ設定で全く同じ操作をしてなお同じ場所で差異があるならKindleアプリの不具合
ページを戻ったりしてるならただの仕様の可能性もある
ちなみにKindle PW～Oasisとかだとたまに豪快にページの半分とかが空白になって次のページに行くとそこが飛ばされてて元のページに戻ると復活したりする不具合がある
ただ一旦サイズ変更してその後元のサイズに戻すと別の場所で発生することがあります
空白行と見間違うことがあったのでどうにかできないかと思ったのですが仕様としてあきらめるしかないでしょうか
ルビがちゃんとでるかわかんないけど
AozoraEpub3の初期設定で作っただけのものです
普段最後の行が79.8くらいまで使って表示されてるのが傍点（ルビ）等諸々の影響で80.1とかに溢れるとその行の前に改ページされる
恐らくはそんな感じの仕様だから行間隔/余白/フォント辺りを調整すれば安定させられるかもねって話
自炊小説用に使ってる
コミックはiPad用に見開きで自炊しちゃったのでいまさら分割すんの面倒だ
Kindle Paperwhite(第7世代,マンガモデル)ってひとまとめですしな……
速くなってたぞ。
動画アップされてたわ。
ストレージ容量が増えただけでメインメモリやらCPUやらは多分変わってないよね（PW2015と比較して）
変わってたら第8世代か第9世代に分類されそう
PW2013とかと比較したら速いかもだけどそれだと話がズレてくる
新ファームでも古いデータだと速くめくれないらしい
ハードは関係ない
ふと思い出したから の件を HAMELN に報告しといた。
HAMELN から落とした ePub 形式のデータで、
ページ送りが著しく遅くなったり、
そのまま戻ってこなくてフリーズってことがあった。
色々と検証した結果、
ブロック要素の直下にインライン要素が大量にあるときに計算量が爆発してしまうってことっぽい。
HAMELN の ePub は body タグのすぐ直下に本文が全て入る構造になってるから、
一話あたりの文章量がある程度多くなるとそうなる。
他のリーダではならないのかな。
こういうことがあるので、小説の場合は br タグで改行するよりも各行 (または適当な段落のまとまり)
を p タグで囲ってもらうのが望ましいなぁと思ったので、
ePub を作るソフトを作ってる人は配慮してくれるとありがたい。
br で改行して？データ見たこと無いな。
何でつくったんだろう？
あれのepub3が腐ってるのは有名だろ
HAMELN は公式で ePub 形式を提供してる。
程度次第では ADE ですらページめくりが遅くなる。
HTML レンダリングの本質的な問題なのかもしれない。
ためしにちょっと長めの文書 (元データは青空文庫から) で
問題のある ePub を作ってみた。
ttp://www.rupan.net/uploader/download/1481690480.epub (ダウンロードパスワードは epub)
手元の泥タブでKinoppyとPerfectViewerに放り込んで見たけど
ファイルを開くときに若干遅いような気がするだけで
ページめくりとか普通にサクサクだったよ
Google Play Books@Android7.1
この件、修正されたー。 ありがたや。
