ぼくらの電子出版がやってきた ヤア!ヤア!ヤア!

ついに 2010-10-31 に最初のβが出ました達人出版会のご紹介エントリ。

達人出版会とは

達人出版会

  1. 今のところ原則 IT 関係の書籍のみ
  2. 支払いは PayPal
  3. データフォーマットは ePub or PDF
  4. 基本的には DRM フリー
    • ライセンス情報として登録者のメールアドレスがメタデータに自動的に埋め込まれたデータをダウンロードする1
  5. iBookstore など外部の販売チャネルは使わない

という、とんがったサービスではありますが、個人的には電子書籍のド本命かなと思っています。

少なくとも動くとか音が出るとかそんなの全然欲しくないし、現時点で縦書きが出ない ePub も内容が内容なのでまったく問題にならないです。DRM バリバリのデータも欲しくないので、この程度の扱いで済んでいるのは非常に好感が持てます。

そもそも買ったデータは本人のものなんだから、著者を含め他者の権利を侵害しない限りは本人の自由にならなきゃおかしいですよね。なんで自分の所有しているデータなのに自分の所有している機械で自由に再生できるとは限らないんですか、そんなのおかしくないですか。

脱線しました。

初めてまともにePubを読んだ

買ったのはやはりこれです。

はじめる! Cucumber - 達人出版会

で、iBooks と Mac 上でちらっと読んでみました。以下、感想。

iBooks はよくできてる

  • 目次
  • しおり
  • ローテート対応
  • デバイスの大きさへの対応
  • 明るさの調節をその場で行える
  • 文字サイズ調整

電子ブックリーダを比較したことがほとんどないのですけど、よくできてるなぁと思いました。しおりもたくさん挟めるし。

メモが書けるといいんだけど、そういう機能は iBooks にはないのかな? それはおいおい探していきます。ePub のリーダーも今後は増えていくでしょうし2

パソコンではあまり読みやすくない

  • Preview.app
  • Adobe Digital Editions
  • calibre
  • Sigil

で試してみました。どれもこれもイマイチでした。

Preview + PDF はウィンドウサイズに合わせて表示を調節する機能があるんですが、横長の画面にフィットさせても読みやすくないし、かといって 13" MacBook の画面で見開きにすると小さすぎて読みにくいです。iPad + iBooks みたいに自動じゃなくてもローテートして読みやすいツクリになってるとだいぶ違う気がしますが、ローテートした状態を維持するのはパソコンの格好をしている MacBook にはつらいですね。

ePub 対応アプリはどれも「読む」ことに集中できる完成度ではない感じです。「ライブラリ管理」と「開く」ことはできても本当に「読む」環境にはまだなり得ていない印象。少なくとも iBooks と同じレベルで読めるものはないですね。せめてウィンドウサイズに1ページをフィットさせて読む機能さえあればずいぶん違うんですけど3

まぁパソコンで読む分には自分で再加工して読みやすい大きさの PDF にしちゃうとか、たぶん達人出版会のデータならできるような気がするんですけど、目的は本を読むことであってデータの加工ではないですからね。そこら辺には積極的に手を出したくはないですね。

まだ模索が必要な感じです。

なにはともあれ

書き手にも読者にもメリットのある出版社として育っていってほしいですね。頑張れ達人出版会!

  1. 簡単に言うとそのまま流せば誰がやったか分かる 

  2. たぶん現状でも選択肢はいくつもあるんだろうけど、探してもいないです。でも探さずに読めるのがいいわけで。 

  3. まさか見つけられてないだけ? 

OOoでPDF化、クロスプラットフォーム前提ならIPAフォントを使う

今回の目的は

  • OOo で PDF に export した文書を共有したい
  • OOo Writer で作った文書を Win, Mac 間で共有したい

です。

Mac 使いとしてはヒラギノを使った美しい文書を作ってよしとしたいのですが、文書の共有を前提に考えるとこれは良い選択ではありません。

Twitter のログ

例によって Twitter のログから。

15:02:45 >wtnabe< OOo からPDFエクスポートしたらフォントがみんなゴシッ
クに…。なにこれ。
15:06:45 >wtnabe< OOo 訳分からなす
15:18:54 >wtnabe< ヒラギノがダメなんかなぁ
15:26:35 >wtnabe< Windowsに送りつけてPDF CreatorでPDF化してみた。する
と同じく全部ゴシックになったかと思ったら特徴が出た。ヒラギノProは全部
ゴシックに、ヒラギノProNは明朝とゴシックの違いがでた。
15:37:01 >wtnabe< ただしヒラギノProNをPDF化して得たゴシックは今度はな
ぜか角ゴシックではなく丸ゴシックのように見えた。ここまでで検証に掛ける
時間がもったいないのでファイルは送ってしまった。
15:40:41 >wtnabe< また、ヒラギノProだろうがProNだろうがOOoのwriterで
exportすると全ゴシック化する現象は一緒。
15:43:03 >wtnabe< IPAフォントを使うとOOoからexportしたときに明朝とゴシッ
クの違いを保持できた。今度から全部IPAフォントにする。
15:44:17 <suisui> これ、何でなんでしょうね?どこかに変換テーブルがある
のでしょうか?探しても今のところ見つからない… RT @wtnabe: また、ヒラ
ギノProだろうがProNだろうがOOoのwriterでexportすると全ゴシック化する現
象は一緒。

ヒラギノを使った場合の問題

  • Mac 上で ヒラギノPro(ProN) を使って書いた文書を PDF 化して開くと明朝もゴシックも全部ゴシックになってしまう(Win で開いても Mac で開いても一緒)
  • ヒラギノProN を使って書いた文書を Windows に持っていって PDF Creator で PDF 化すると明朝とゴシックの違いは保持できたけど、ゴシックがなぜか丸ゴシックに

解決策

IPAフォントを入れてそれを使う

IPA フォントの場合は明朝とゴシックの違いを保持できるので OOo でも安心して文書を作れます。ヒラギノ好きとしては IPA フォントはちょっとギスギスしすぎているように見えるのですが、仕方ないですね。フォントの違いで意味の違いを表す紙向けの文書では、フォントを保持できない方が致命的ですから。

SPF対策…

今度は SPF 祭りだワショーイ。

と思ったけど、メル鯖プロバイダ任せのおいらは何をすれば?と思ったが DNS はこっち管理だった。おっと。

しかーし、プロバイダのメールの出口が分からない orz

  1. 試しに PC で違うドメインに送ってゲートウェイを推測
  2. DNS に反映
  3. 携帯に送信

失敗。

以下ループ。

しばらく悩んだが手持ちの au の携帯でメールヘッダを見るオプションがあった。(パケ代はこっち持ち。)これを確認してみた。

携帯向けは全然違うホストから出ていることが発覚 orz

しかも、見るからに IP アドレスが複数あるような雰囲気。しょうがないので適当な範囲を指定してごまかしておいた。たぶんこんなもんだろう。

つか、「公開しています」と書かれている文書は見つかるが肝心の IP アドレスの情報がどこにも見つからないプロバイダさんは一体何をやってるの?

要らん苦労をユーザーに掛けるな。

それにしても au って半年前からフィルタ掛けられるようになってたのね。気づかなかった。そして docomo がスルーしてしまった設定でも au は弾いてきた。

……。

実は docomo の今回の措置ってそんな慌てるほどではなかった? そもそも au はもっと大々的にアナウンスしといてよ! 半年もスルーしちゃってたよ!

cf.

blog本文の文字サイズの話

古川ブログで行間まで含めてようやく落ち着いたようだ。

が、今度は石田優子さんのコメントで「多くの人にとって大きすぎて読みにくい」というものがついた。

この話は奥が深いが、基本的には

  1. 本文のサイズは「紙」のサイズによって決めるのが原則1
  2. Web の場合は「紙」に相当するウィンドウサイズ、モニタサイズなどの条件が多様すぎて見せる側で設定するのは困難を極める
  3. だからユーザーの設定を尊重する

のが「正解」だと思うのだが、こういう結論に達することのできないデザイナが大半なのだろうことは容易に想像がつく。というか、そういう人たちの頭の中では、Web がインタラクティブなメディアであるという意味の中に「ユーザーが自分でコントロール可能」という項目は入ってないんじゃないかなぁ。だから

  • ユーザーの環境に最大限に対応できるようにいろいろな調整を行う2

という発想になるんじゃなかろうか。

自分はデザイン性を強く前面に出したいという明確な意図がない限り、ユーザーの設定にそのまま従い、本文を 100% として他の要素はすべて相対的に決めるのがインタラクティブなメディアとしての Web 的にはスマートな解だと思っている。少なくとも通常の blog でそれ以上を求めるのは行き過ぎだろう。画像などピクセル単位で決める必要のある要素があるのは認める。それはしかし現時点での限界というだけで本質的な問題とは異なる。3

「多くの人にとってサイズが大きすぎる」のは確かに事実かもしれないが、だからと言ってそれを基準にするのは短絡的に過ぎるのではないか。そんなもん「IE のデフォルトサイズ変えて」って言えばいいんじゃないのか4と思う。このサイズだって絶対のものじゃないんだから。そもそもお膝元でコメントしてるんだし、個々のサイトで苦心するよりもよほど効果が大きい。

まぁ、現時点でのサイト側の現実解としては、フォントサイズ無指定も環境に応じてバリバリに変化するのも、両方間違っちゃいないんだろうけど、必要以上に高機能化を求める方向だけは、みんなが幸せに向かっているようには自分には思えない。ブラウザが無限に増えるのは明らかなのだから、ブラウザ別にあれこれ調整を行うのがコストに見合う作業とは思えないし、ユーザーにとっても新しいブラウザ(携帯の新機種でもいい)を使い始めたときはあちこちで不便な思いをすることになりかねない。

※ この話はタイポグラフィーの本を最近チェックしていた、元DTP界住人の otsune さんの見解も気になるところ。

と思ったらその石田さんのところで「紙媒体から学ぶもの」というエントリが追加されていた。導入部はいいんだけど、やっぱりコンテンツとサイト運営の話にすっ飛んでしまっている。デザインについて現実的な落としどころをどう論理的に導きだしているのかちっとも分からないのが歯がゆい。だったらなぜデザインについてサイトに意見するのだろうか。そこが見えてこないのだ。

工場出荷時の設定のまま使っているのが大半で、大半の人にとって文字が大きすぎる、これは問題だと思うのであれば、やはりサイトが個々に文字サイズを調整するよりも IE のデフォルト文字サイズの変更と文字サイズに関する UI の変更を、少なくとも Microsoft には言うべきじゃないのかな。そのうえで「現状ではサイト上にも文字サイズ変更のボタンなどを用意するのが望ましい」という意見であるなら、まったく異論はない。5しかしそういうことは言わずに今回の件に触れてフォントサイズについて意見を述べられると、なんだか変だという印象がどうしても拭えない。(石田さんの興味がフォントサイズなんかではなくアクセシビリティ、ユーザビリティであることは承知のうえです。情報大工 ML も読んでます。)

で、話は戻るがそういう諸々の部分を抜きにして紙と Web では環境が違いすぎて上っ面のデザインなど参考にならないって一言で言われても腑に落ちないんだよなぁ。どこに主眼を置いているのかよく分からない。サイトの側で対処すべきこととソフトの側で対処すべきことがごっちゃになっているように読めてしまう。

  1. 今ごろ気づいたが、私は書籍をイメージしていたので、「紙」と言っても新聞や雑誌が最初に想起される場合はこの前提は成り立たないな。 

  2. ユーザーの環境の配慮はするが、ユーザーの設定の尊重はしないという意味。 

  3. 現時点でも JavaScript と CSS を組み合わせればサイズ調整は可能だし、Opera の拡大縮小は画像も追随する。以前この日記で SVG なら云々という話を書いたこともある。 

  4. だってシステム全体のフォント設定に対して不自然に大きすぎるもの。仮に当時、Netscape の時代と違って IE の時代はモニタサイズも大きくなるからフォントサイズはもっと大きい方が適切だ、と判断したのだとしても明らかに大きすぎる。デフォルトサイズ自体が間違っていると判断するのはそんなにおかしな話じゃない。 

  5. クッキーに覚えさせればそのユーザーにとってちょうどいいサイズが常に再現できて万々歳だ。 

Studying HTTP

いい資料を見つけたのでメモ。

「知的所有権」という言葉は人の心を奪う幻影である—その理由

from japan.linux.com

論点はシンプルだ。異なる法律を一緒くたに考えるなということだけである。でも振り返ると日本で知的所有権をごちゃ混ぜにした議論は見たことがないな。自分が目にしていないだけかもしれないけど。ビジネスの文脈でこういう言葉を目にする機会ってないから。でもこの所有ってのは財産の所有という意味であって、モノの所有という意味じゃないよね? 財産は無形物でも所有するものだから、そういう文脈で使っているのは間違いじゃないと思うんだけど。

ただ例えば日本では著作権は名前を変えるべきという話ならそれには賛同するなぁ。著作権は一般に copyright と言われるけどそれって複製権じゃん!というツッコミはあまり見ない。でも実際には著作者と、著作者と契約を交わした人だけが複製を印刷できるというのがもともとの意味でしょ、copyright って。で、著作者人格権が author's right に当たるのかな。{{fn "この辺はヨーロッパ大陸は author's right よりで北米大陸は copyright よりで、日本も伝統的には author's right よりだったけど最近 copyright よりという流れになっているらしい。"}}この段階でもう全然ベツモノ。著作物に関する法律群とか、もう少し正確な言葉にした方がいいんじゃないかな。そうすれば日本の著作権法が著作者ではなく、著作権管理団体やコンテンツ”流通”業者を保護するように機能しているという現実が見えやすくなるし、コンテンツの複製がすなわち禁止されているわけではないとか、デジタルコンテンツについて曖昧なままなんとなく規制が強くなってるとか、還流 CD どないやねんとか、考えやすくなるんじゃないかな。

セキュリティ研究者とそうでない人との間の溝

開発者のプライドか、それとも「脆弱性」のネガティブイメージの影響か (高木浩光@茨城県つくば市 の日記)

一言で言うと文化が違うというか。高木さんですらまだセキュリティ技術者、研究者の指摘が世間的にどういう風に受け取られるかよく分かっていない例だと思う。

簡単に言うと、RFC などの規格に厳密に作るという姿勢はごく最近の動きなんですな。1けっこうこの辺の細かい部分は「現物合わせ」な作り方の方が主流なんじゃないかと思います。もちろんそれを是としているわけじゃないけど、とりあえず現状認識としてそこからスタートしなきゃいけないんじゃないかと。話を広げて申し訳ないが、インターネット普及以後の、標準準拠を重視し、閾値チェックなどの基本的なセキュリティ対策を施す、という作りはやっぱりアプリケーション開発の歴史の中ではごく最近の話でしょ。つまり、まだまだこれから浸透させなければいけない文化であって、例えばメーラ、Web ブラウザ、サーバなどのアプリ開発者がすべからくこの文化の中に居るなんてことは到底考えられないわけ。もちろんそのことはきっと高木さんなんかは総論として分かっているんだろうけど、1対1で相対するときにそのことが頭の中で確固たる位置にあるかというと疑問だなってことなのです。

でも、従うものがあるときは従うべきというのは開発者ならどこかで分かると思うんですよ。例えば Windows アプリを作るときに Windows のルールから外れてたらまともに動くわけないんだから、Windows のルールはまぁ普通守るでしょ。トリッキーな作りの方が好きっていう人を除けばその方がテストも楽だし、悩むポイントが減る。同じように、これこれこういう仕様に従っておいた方が何かと楽であるという認識に至らせてしまえばよいのですよ。あぁ、仕様に合わせておいた方がセキュリティも含めごちゃごちゃした問題で悩まなくて済むようになるな、と。

だけどこれまでの「セキュリティ問題の指摘」という文脈には「異なる文化の人間と相対していて、相手を自分の文化の中に誘導する」という視点はまったくないと思う。簡単に言うと指摘する側に思いやりがないというか、あんたビジネスの経験まったくないでしょ?というくらいに言葉が冷静すぎて冷たくて、聞いててむかつくって感じ。この場合むかつくのは聞かされた担当者であり、例えば office の裁判記事を読む日経オヤジであり、標準厳守の文化にいなかった開発者なわけだ。問題は「開発者のプライド」じゃーないと思う。指摘する側が「対話の言葉」を持っていないってことじゃないかな。

技術屋の論争術は法廷で通用するか? (/.-j)

なんかを読んでも感じることだけど、正しいことを論理的に主張できても、どんだけ証拠が積みあがろうとも、それが相手に伝わるとは限らないわけ。そこんところの想像力が足りてない感じがするのです。

相手に伝えるために必要なのは資料じゃなくて「できる限り相手と近い視点」だと思います。

また、今回の高木さんやスラドでよく見る技術屋が陥りやすいのは、「相手に対して発しているはずの言葉が、資料や証拠に基づいているうちに、いつの間にか第三者向けの言葉になってしまっている」という現象じゃないでしょうか。それは相手への投げ掛けではなく、第三者が論理的に読み解いたときに納得できる資料になってしまっているのです。ハタから見ている分には「あぁこっちが正しいな」って分かるんだけど、たぶん当事者は「バカにしてんじゃねぇよ」という気持ちになると思うなぁ。で、そうなっちゃうと「勝ち負け」になっちゃうからもうダメなのですよ。それはもう説得としては失敗してる。

相手に「負けた」と思わせたら気持ちのよい説得とはほど遠い。セキュリティ研究者、および今後現れる「相手に問題を指摘しなければいけない立場」の人はまずこのことを肝に銘じるべきだと思う。

ACCS がなんで office氏の告訴に至ったか、47氏が警察と協力関係にあったはずなのになぜ逮捕に至ったか、おおいに疑問だったんだけど最近の一連の記事を見てなんとなく分かってきた気がする。一言で言うと使い古された言葉だけど、技術屋が人間を分かってない。

  1. ごく最近でない人はヲタです。セキュヲタ、標準ヲタ。例えば valid html + css ってのは最近でこそ blog を見習って SEO を考えると説明しやすくはなったけど、以前は何このヲタクとしか見られなかった。それと同じこと。 

ゲーマー世代の若者といかに付き合うか

from CNET Japan

いっとき Web 上でぷち流行した世代論の続編的なものかな?

自分はバッチリこのゲーマー世代の分水嶺にいるんだけど、これは日本の話じゃないし、日本というか自分ローカルの話をさせてもらうと、

1970年代生まれの前半と後半にも割と大きな溝がある気がする。

なんてゆーかな、70年代前半生まれまでは良し悪しは別にして体育会系的な先輩後輩関係、奢り奢られドロドロとした和を形成していくプロセス、ってのは通用したと思う。でもちょうどうちらの世代に「それはあまりいいことじゃないな」「いい場合もあるけどそうじゃない場合も多々あるな」という意識が芽生え始めて、その下になると「面倒くさいこと強制しないでよ」という意識に変わると思う。

例えば飲み会でとりあえずの挨拶としての酌がある。自分は酒飲みとして酌はきらい1だし、飲み会で出てくるぬるいビールもまったく好きじゃない。しかし挨拶の酌だけは別モノと考えている。何も「下の人間は何がなんでも挨拶回りしてこなきゃいけない」とは考えてない(所属するグループによる)が、とりあえず挨拶としての酌はどんな酒でも断らないし、そこからしばらくはたいがいどんな話題でも話はする。だってそれが挨拶だものと思っているから。

でもね。若い人にはこれ通用しないのよね。なんつーの、マシャ的に言えば昭和型の人間のぼやきなんだろうけどさ。

飲み会の例は分かりやすいから出しただけで、別に酒を飲む飲まないは関係ないんだよね。もちろん若者の飲酒量が減ってるってのは事実としてあるけども、もっと深いメンタリティの部分なわけ。

自分は他人に興味ないB型だ。でもさ、それでも日常一緒に居る人間のことくらいは分かっておいて損はないじゃん。例えば何が好きとか何がきらいとか。きらいなことはできるだけこっちが避けておけばトラブルも起きないしさ。だからある程度コミュニケーションて大事じゃないですか。でもさ、なんかこう若い人ってきっかけつかませてくれないのよ。分かる?このもどかしさ。きっかけって大事じゃない。自分にとってタイトルに挙げた「いかにつきあうか」って、まさにこの部分の難しさなんだよね。

  1. 自分のペースで自分の好きな酒を飲ませろ、と強く思う。相手の盃なんか見てないでもっと自分が楽しめよ、と非常に強く思う。 

げっ

いいとも増刊号に広瀬せんせが出てる。いや、直接の面識はないんだけど。

そうなのか、見たことはあるなぁ。

About

例によって個人のなんちゃらです

Recent Posts

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami Document SVG AsciiDoc Pandoc DocBook Develop Jekyll macOS Node.js Vite Heroku Transformer AI Data Cloud Wasm