実際に作ったツールを使って電子出版をしてみて問題点を抽出する。改造版AozoraEpub3ではepubによる電子出版を前提にソフトウェア作っているのでkindle出版に使える。ただ、エディターがなかったので初心者にとっつきにくかった。そこで青空文庫エディターでを使えば簡単になるのではと思った。もともと青空文庫の注記を使ったepub作成を行っているので、テキスト入力でも作れてしまうが。元の原稿がブログ記事の場合はhtmlやマークダウンなこともあり注記を変換する必要がある。htmlは問題なく読めるがogpやアフリエイトタグを読み込むと、電子出版では権利がある画像を使うことができないので修正する必要が出てくる。 ブログでは記事のリンクをOGPで行うが電子出版ではaタグを利用したリンクを規制されていることが多い。aタグをurlテキストに変換したほうが楽だと感じた。
画像の挿入 画像を挿入時にsourceと書かれているがどのように入れるのかがよくわからなかった。フルパスで入れたら取り込まれたが、相対パスの取得が難しかった。青空文庫注記では相対パスではないとファイルを移動したときに見失うはず。
自動サイズ調整時には気にならなかったが、裁断時にどうしても傾く。簡単にまっすぐ切る方法はないだろうかと治具を作ることを考えた。
カッターマットに定規を接着して直角な面を作っている。 www.youtube.com
直角定規を当てることで直角に切りやすいだろう。
曲尺（３０ｃｍ×１５ｃｍ、ブラック）jp.daisonet.com
問題点はまっすぐなのかどうかが判別がつかない。切るところ以外のスペースが少なすぎて斜めになりやすい。３００円のでも無理するとA4サイズは切れるがちょっと曲がりそう。本二冊目ですでに切れ味が落ちている気がする。
ルーズリーフの穴は切り取った方がいいと思ったが問題なく読み込めた。穴があった方が向きがわかりやすい。
板型スキャナで読み込んでもいいが、scansnapの場合はもろくなっている端を切ってから読み取った。
薄い紙の場合にscansnapの構造的に傾きやすいようで、最後の一枚のページの読み込み結果を捨てて、次に読み込む紙に加えることで対処した。たぶん掃除するとましになると思うがめんどくさい。
切る必要がないと便利だが、本と違って表面裏面という方向に読み取ってほしくない時がある。
取り込んだ画像はjpegファイルになっている、PDFで取り込めばPDFビュワーで見ることになる。Windowsの画像ビュワーではMangaMeeyaを使っています。今も使えるが開発サイトは閉鎖されているので不具合が出ても改善されることはないと思います。IrfanView、susieなどを使っていたが、最近のソフトウェアの人気はよくわからない。タブレットで見る場合はiPad
アプリをダウンロードする必要があると思う。 スマートフォンで本を画像で取り込んだ場合は見づらいことがある。画像を分割拡大してみるアプリもある。 windowsではNeeView、Honeyview、IrfanViewが現在も開発中。
jpegをフォルダーかzip圧縮して一つにまとめるかという問題。zip圧縮はファイルの一部が壊れると全体が読めなくなることがあるので、リカバリーレコードを用意してまとめるほうがいいと思う。 結局どうするかというといろんなところに分散して保存するという対策しかなかった。
CD、DVD、ブルーレイディスクがあまり流行らなくなったので保存媒体としてはHDDが一番いいのではと考えている。SDカードやUSBメモリ、SSDなどの保存方法もある。ただし定期的に通電しないとデータが消えるといわれている。
４月４日発売のそのほかの本kyukyunyorituryo.github.io
４月５日発売のそのほかの本kyukyunyorituryo.github.io
４月６日発売のそのほかの本kyukyunyorituryo.github.io
４月７日発売のそのほかの本kyukyunyorituryo.github.io
４月８日発売のそのほかの本kyukyunyorituryo.github.io
４月９日発売のそのほかの本kyukyunyorituryo.github.io
４月１０日発売のそのほかの本kyukyunyorituryo.github.io
Githubで活動をしているとissue（要望）が来てコードの修正を取り込んでほしいと来ることがある。ただしプルリクエストについて知っていないと。コードの修正の提示だけの場合がある。 一つのファイルだけであれば、苦労することはないのだけど。複数ファイルにまたがっていると変更点を探すのが面倒になる。プルリクエストは変更点を明示したり、誰が書き換えたかということも同時にわかるので便利だ。問題はプルリクエストの仕方の説明がgitコマンドを利用したものが多いということ。デスクトップの操作でマウスを使いながらであればそれほど抵抗がない人でも、コマンドラインには抵抗感がある人がいる。 一応gitの本を読んでgitコマンドも一度はやったが、Github Desktopが楽なのであとはGithub Desktopを使ている。一つのファイルの書き換えだったらGithubのサイト上で書き換えるほうが楽だが、二つ以上のファイルの場合はGithub Desktopがいいと思う。
という形になる プルリクエストの仕方を説明しているが、自分はサンドボックスにしかプルリクエストをしたことがないのであっているかが怪しかったりする。そんな私でもgithubリポジトリを管理できている。 github.com
AndroidStudioでgradleには触れていたが、動作の仕組みまでは調べてなかった。ライブラリを追加するときにimplementationに追加する程度の認識だった。 jar生成の部分ではimplementationで読み込んだライブラリをjarファイルとして全体を固めている。 ant.xmlでは配布するファイルに同梱する内容を生成している。
jar {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
manifest {
// attributes 'Main-Class': 'AozoraEpub3'
attributes 'Main-Class': 'AozoraEpub3Applet'
}
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
}
ant.importBuild 'ant.xml'
Githubではビルド方法を指定すると、何かのアクションをもとにビルドを実行してくれるようだ。というのもこれを私は書いてないので詳しくなかったから。その後、参考情報を読んでだいたい理解したのでプルリクエストをマージした。 nightly.yml
などといったことをGithub Actionで行っている。 こういうのをCI（継続的インテグレーション）というらしい。
一日に２００回ずつ腹筋背筋腕立てを３週間していたらだいぶ筋肉がついたような気がする。ただし体重や体脂肪率が少ししか変わらないので気のせいかもしれない。主に腕やおなかを触ってみると皮下脂肪の下の筋肉が膨らんでいるきがする。筋トレの回数を増やすと、体が痛くて動きづらい感じが初めはあったが、２週間を過ぎたあたりから物足りない感じがしだしてきた。より負荷がかかるように腕立てを深くまで下げたり、背筋は高くまでとしていたがそこまで負荷として感じなくなってきた。回数を増やすかほかのメニューを増やすなどの取り組みを考える。 筋トレ以外には有酸素運動の歩いたり走ったりという運動も減量にはいいみたいだ。どうしても歩くのを増やすと膝の負担が増えるので膝が痛まないように気を付けながら運動量を調整している。ひざを痛めて休むと結果として運動量が減るのであまり意味がない気がする。
筋肉を増やすの次は体重を落とすのをやりたいが、体重が落ちると今度は体脂肪率が下がらないので難しい。 一般の体重計ではそこまで正確に体脂肪率が図れないので毎回図ってメモをするのは体重ぐらいにしている。 体重も水分をとったら体重が変わるし、起きた後は体重が減るので同じ時間に同じ状況で測るのがいいのだろう。
