セルフバリカン、セルフ坊主
予想以上に禿が進行してることに気づいたんで、坊主頭にすることにした。
以前間違えてセルフバリカンで坊主にしたことがあったので気楽なもんだ。
ただ、やっぱりというか、電車や街中で見かける坊主頭は、首すじの生え際から後頭部はきれいなグラデーション。プロの仕事は違うよなあ、と感心していた。神は細部に宿る、というやつだ。
全部3mmぐらいなら均一でいいんだろうけど、さすがにそこまでのスキンヘッドもどきは、もっと禿げてからにしようかと思う。
てことで。
基本12mmで、耳の上あたりの側頭部から後頭部は9mm、刈り上げは6mm。という丁寧な仕事を目指してみた。
マダラというかマバラというか。どこにもグラデーションなんて見当らないのは素人芸の限界だなあ。
頭寒足熱とはいえ、冬場に坊主頭は寒さ直撃だということを忘れてた。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
Ingress Lv15になった
7月3日にlv14になって、先月9月18日にlv15となった。
メダルは揃ってたんでlv14からはただただAP稼ぎ。敵陣営のリンクが集中してるポータルを見つけたら焼き、自陣営のポータルを強化しつつ、CFを狙ってリンクを張る、というIngressの基本に立ち返ったプレイスタイル。
アクションしてればもろもろメダルの実績に繋がるので、銀が金に、金がプラチナにステップアップしていく…のが、とりあえずの面白みといったところ。うーん、ビミョー。
予定通り(?)Rechargerがオニキスとなり、lv16へ必要なメダルはあとオニキス1つとなった。これまた予定通り、そのうちTranslatorかTrekkerでオニキスが取れそうなのでメダルについてはじたばたする必要はない。
この先AP稼ぎとなる。
lv16は4000万AP必要。こりゃ先が長い(現状約2500万AP)
さすがに、ちょっと飽きてきた、かも。
オニキス
Recharger 遠隔で見方ポータルの回復
プラチナ
Sojourner 24時間単位でハックし続けた日数
Translator グリフハック成功ポイント
Trekker 歩いた距離
金
Builder デプロイ数
Connector リンクを張った回数
Engineer 自陣ポータルへのmod差し回数
Explorer ユニークポータルのハック数
Guardian 自ポータルの維持日数
Illuminator CF作成時のmu獲得数
Liberator ポータルのキャプチャ数
Mind Controller CF作成数
Pioneer 初めてキャプチャしたポータル数
銀
Hacker ハック回数
Purifier 敵のレゾネーター破壊数
SpecOps クリアミッション数
前回よりステップアップしたのは
Recharger。金からオニキスへ昇格。
Engineer、Illuminator、Liberatorの3つ。各々、銀から金へ昇格。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
一発芸：縦書き段組レイアウトのためにテキストを分割
Firefox41がようやく縦書きに対応したのでこれからは遠慮なく縦書きを使える、すばらしい、というネタの続き。
WEBブラウザでの縦書き表示のあるべき姿について。いや、横書きでいいというひとにとっては意味のないネタ。
縦書きの場合、テキストをそのままブロック要素に流し込むとスクロールとなる。
これはありえない。
・文字が切れるのをコントロールできない。
・ページは縦にスクロールして見てるのに、なんでここだけ横スクロール。
ということで、前回も書いたように、縦書きでは段組でレイアウトされるのが正しい。
(※どうやら今日時点、Firefoxは縦中横が効かないので「!?」がひっくり返っているけど、ChromeやSafari、IEは問題なし)
で、これがちょっと面倒くさい。
１段落に入る字数と行数によって、どこで次の段落に移動するのかを確認する必要がある。これはやっぱ面倒くさい。
スクリーンショットでいうと「家屋が」で段落が終了して、次の段落が「かしぐ」から始まるというのを判断して段落を分けなきゃいけない。
なもんで、字数行数改行をチェックして文字数を数えて段落単位でテキストを分割するスクリプトを書いた。
[10/02 11:22:44]追記
CSS3のmulti columnを使えばそのまま文字通り段組が実現できる。N字xN行ではなくて、画面幅やテキスト量で柔軟に表示してくれるので、webは本来このCSS3のマルチカラムを使うべき。
版面というかN字xN行のレイアウト表示で見せたい場合にこのスクリプトの出番(css3の完全リフローとは少し違って、N字xN行の箱に入る分のテキストの塊を作るイメージ)
ルビや縦中横に関しては、テキストにHTMLでタグづけされてれば生かす。
でも、わたしは素人のヘタレなので制約はあって。文字数を数えるために。
縦中横の指定のない半角の数字と、半角のアルファベットや記号類は全角に変換。
また、なんちゃって禁則でバグくさいところがある。
https://t2aki.doncha.net/tmp/dangumi-sample.pl
(例によってここは直リンクできないのでこちらからどうぞ)
↑ここでテキストや字詰め行数を入力すると、縦書き段組表示用に分割されたテキスト(縦書き用のスタイルシート付き)のHTMLが手に入ります。
テキトーにテキストを放り込んで試してみてください(わたしはこれで表示の調整をしてました)
縦(字詰め)、横(行数)を確認して縦書きサンプルとして、ブログなどにコピペしてご利用いただければ。
『創作文芸見本誌会場HappyReading』 に登録した立ち読み用のテキストなど、ご自分のサイト、ブログで縦書き表示して読者さんに希求できると思います。
(※HTMLが編集登録できるブログ限定でしょうか)
小説は縦で読んでもらおうず！
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
青空文庫のルビや傍点をHTMLタグに変換
小ネタ。
青空文庫形式で書かれたテキストをちょっといじる機会があったんで、例によってperlでごそごそと。
『青空文庫 組版案内』（https://kumihan.aozora.gr.jp）に詳細な資料や、青空記法で書かれたテキストをXHTMLに変換するrubyのスクリプトも提供されている。
青空文庫からXHTMLへはrubyのスクリプトを使わせてもらえばそれで解決なんだけど、用途・前提が青空文庫。当然ながら青空文庫用のcssが埋めこまれる。
電子書籍にするのにそのままでは使えない。
本文で青空記法が使われてるのはルビと傍点、太字程度だったので、その3つをHTMLのタグに変換するスクリプトをでっち上げ。
perlのスクリプト的には、漢字かななどの判定にUnicodeブロックが便利でおすすめ。
無名サブルーチンも便利。
意外なところで青空記法が使われててちょっとびっくりだった。
テキストデータ利用ということで、ボランティアさんが入力するのに青空記法はわかりやすくていいんだろうなあ。
青空EPUBの現バージョン3-1.1.0ｂ45はepubcheckでエラーになる。
原因はnav.xhtmlのlandmark部、「Undefined property:title-page」で、ここを「titlepage」にすれば大丈夫。
自転車置き場の新顔…のわりに態度がデカイ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
サンプルの縦書き段組表示
やっとFirefoxが縦書きに対応したことで、すべてのブラウザで縦書きでの表示ができるようなった。
今までは、「サンプルを読む」みたいなリンクをクリックすると、Firefoxの場合は横書き、それ以外のブラウザは縦書きのポップアップウィンドウを表示させていた。苦肉の策。
今後はブラウザ判定して分岐させる必要がなくなったので、以前やってたようにページに縦書き段組のサンプルをajaxで埋め込む方法に変更した。
(とはいえ、新しいバージョンが出たからといってみんなすぐにインストールするとも思えないので、しばらくは必要だと思うけど)
ajaxにしたのは。
サンプルはそれなりに多いんで、ページ表示がひょっとして遅くなっちゃいけないと思ったから。
サンプル以外の表紙やキャッチなんかのいわゆる書誌情報は、とっとと表示してもらいたいということ。WEBで唯一断言できるのが「速さは正義」だ。表示にもたもたしてたらそれだけでそのページは終了だ。
ajaxならまずページは先に表示されるので、体感的なページ表示速度に影響しない。
縦書きのポップアップを使わなかったのは。
クリックはコストが高いから。
以前にも書いたかもしれないけど、オンデマンドの動画配信サイトで仕事をしていた頃に何度も(毎日)計測していた。ほとんどのユーザーはランディングページ→離脱。
いや、楽天のチラシのようなフンドシのような長いページをダセエーと思ってるけど、あれは正しい。
ユーザーのクリック誘導がいかに大変かという結果。理由もなくあんなクソみたいなページ構成にしてるわけじゃない、てことだと思う。
また、WEBページで、ページを縦にスクロールしていって、サンプルの縦書きのコンテンツだけ横にスクロールというのは違和感がある、目線の動きとUI的にありえない。
縦書きの文章は段組されて、目線の流れ的に、右上から左に読んで行って、左下端にきたら、下の段の右上端から読むものだ。
てことで(表示速度のリスクとクリックコストと縦横混在混乱を検討して)、縦書き段組を復活させた。
（のはいいけど、Safari、ChromeはともかくIE(ver.10)がまたCSSの解釈が微妙に違ってるぽいなあ）
もちろん不満点はあって。
とにかくWindowsはフォントが汚いんでビックリ。
ディスプレイの設定でマシになるとのことだけど、そんなことを来訪するユーザーに強要するわけにはいかない(昭和のホームページでは「画面1024px以上推奨」とか「フォントサイズ12px推奨」とかあったけど)
ダッシュが繋ってくれない。
これは電子書籍でも苦労してるところだからしょうがないか。
ただ、WEBというかブラウザにあまり多くを求めてもしょうがないんで、現状はこれでOK。
電子書籍を読むなら、それに特化した専用端末か専用アプリを利用するし。
この雑記帖を「縦書き」で検索するとどっさりヒット。2009年とか2004年ぐらいから待望の縦書き実現、というやつ。
やっと、Firefoxありがとう、だ。
日野裕太郎の作品紹介ページでサンプルが読めるのでゼヒゼヒ！！
↓このへんからどうぞ
https://t2aki.doncha.net/?id=1362724515
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
作品の寿命
なるほどなあ、そういう考えかたもありかもしれんなあ、という微温い小ネタ。
本を書いて出版するからには、読者に届いてその作品をずっと愛でられていたい・大切にしてもらいたい、というものばかりだと思ってたし、実際、底辺とはいえ出版社で編集をやってた頃の作家さんは例外なくその通りだった。
でも、そうじゃないこともあって、ちょっと驚いた。
・本を買ってもらって、読んでもらったら、本はその場で消えてなくなってほしい。
・わたしが死んだら、わたしの出した本はすべて燃えて消えてほしい。
なんでやねん、と聞いてみたらば「だって気持ち悪いじゃないですか」と。
いつまでも自分の文章や絵が残ることが気持ち悪いということだろうか。
でも、なんかわかるような気がした。黒歴史の積み上げというか…とか言うと叱られそうだけど。
あるいは、その時、思いが伝われば良くて、カタチはいらないというか。
もしくは、古い自分の作品は、今の自分から見ると完成度が、とか(そういや、再録や単行本化で古い作品を引っ張り出して見せると、これまたほぼ例外なく、ヤメテ！見せないで！という悲鳴があがった)
なので、みんながみんな、自分の書いたもの発表したもの出版したものについて、同じ思いではないということも少しは意識しておきたいかなあ、と思ったしだい（今さら）
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
