2012年8月15日水曜日

Kindle Previewすごい

作家の藤井大洋さんのSF作品「Gene Mapper」はDRMなしで各種電子書籍フォーマットを用意して販売されている、電子書籍について関心のあるSF者には見逃せない作品だ。

作品は、サイバーパンク的要素の強いハイスピード展開、テクノロジー満載の楽しい内容なのだが、いまサイバーパンクと書いた理由は、みっしりと振られたルビ。もはや古典の「ニューロマンサー」を彷彿とさせるものだったから。また、藤井氏はルビや圏点を意欲的に使い、英語の横倒しセンテンスに漢字かな交じりの日本語ルビ、日本語に英語横倒しルビ、まだ読んでいないがベトナム語に日本語ルビの箇所もあるらしい。当然英数字も増えるので、縦組みの場合は縦中横も頻発することになる。

で、Kobo TouchがWebKitに手を加えたNetFrontでうまく表示するのはともかくとして、さきほど藤井氏のブログエントリで、「Kindle Preview」という著者が実機でどう見えるかをPC上で確認するためのソフトウェアがKindle Touchの縦組み表示に対応していることを知り、Koboブックストアで購入した「Gene Mapper」のKEPUBを読み込ませてみた。

CaribreでMOBIにしなければ読めないかと思ったのだけれども、最初の画面でEPUBも読むと書いてあったので、DRM Freeな氏の作品をそのまま読み込ませたという経緯。

するとやはりMOBIに自動変換するようで、詳細画面を開くと、日本語で「コンパイラ」のバナーが出た後、変換処理の進行状況が現れ、いろいろと警告やエラーメッセージを出しながらもMOBIに変換し、完了したという表示が出た。すると、いままでグレーアウトされていた[OK]ボタンが押せるようになり、目次のページが開いたのだが、とにかく素晴らしい品質の縦組みをする。

本文に入れば、行末の揃えはもちろん禁則や追い込み、ぶら下げなど日本語組版のややこしいところをきちんとクリアしている。もちろん三点ダッシュや連続するダーシもきちんとつながっている(ChromiumやSafariでは、文字の間が少し空いてしまう)。本作品の特徴である大量のルビも、普通に印刷物で読むような、うまい配置をする。ルビの配置についてはもしかすると作家がCSSをうまく書いているためなのかもしれないけれども。

とにかく、この品質であれば、Kindle日本語版には十分期待していいと思う。実機の販売が楽しみだ。

なお、役物が連続するところでの空白はKobo Touchと同じだった。もしかするとKindleもWebKitを使っているのかもしれない。

2012年8月13日月曜日

Kobo TouchはGoogle Analyticsにデータを送信しているらしい

MobileReadのフォーラムを眺めていたら、こんな記事があった。
KT's Google Analytics integration, and how to disable it.
おやまぁ、最悪〜。Googleのサービス使いながらAnalytics宛はすべてfirewallで遮断している僕にとってはほっておけない話。超訳してみる。
----

  • KTがオンラインでGoogle Analyticsにアクセスできるときには利用データを送信している
  • 1.9.16からじゃなくて、最初のファームウェアからそうだったよ
  • 利用データの内容は、例えば「ホームスクリーンが@timeにロードされた」「読書画面が@timeにX分開いていた」「デバイスは@timeにスリープした」など
  • 機内モードにずっとしとけばデータは送られないけど、WiFi経由のアップデートのときにデータは送られちゃうかもね
  • 電源を切るか再起動するまでひとつのセッション(それか500個のデータがたまるまで。ただ、そこでログを止めるのか新しいセッションになるのかは不明)
  • 送信されないでたまっていたデータは再起動のときにクリアされる
  • ひとつのセッションの間、ランダムに与えられたユーザIDが共通して使われる。セッションをまたいで同じIDが使われることはない
  • クレジットカード番号やペットの名前や読書中の本やメールアドレスがGoogleに送られることはない(これはやってあるよね?)
  • Kobo社はあなたのIPアドレスやあなたのKoboアカウントと関係する行動は見ることができないけど、Googleはそれができる。間違いなくIPアドレスは記録している
  • データがGoogle AnalyticsからKoboに転送されているわけではない
  • データ送信は内蔵ブラウザとは関係なく行われる
  • devices.kobo.comはまやかしだ(後述)
.kobo/Kobo/Kobo eReader.confの変数GAQueueに、次回KTがネットに接続するまでのGoogle Analyticsに送信するデータがたまってる。GAQueueは再起動ごとにクリアされる。

GAQueue変数のなかみを読み解きたいなら、以下の文書を参照:
最もわかりやすいやつGAのcookieについてutmsのパラメタについて

ナード向けに具体例を置いといた。
http://pastie.org/3079390

KTは「http://devices.kobo.com/ReadingView/Book」みたいなURLをGAに送るけど、devices.kobo.comは存在しない。これは実在しないし、だからといって悪いやつが「隠蔽の証拠」にしようとしたわけでもない(もしそうなら設定ファイルのなかみは難読化するはずだし、KoboのCEOはもっと儲けてるはずだ)。

Google AnalyticsはWebサイトをモニタするためにあちこちのサイトに組み込まれている、簡単で、無料のプラットフォームだ。Kobo端末はGAに対して、自分がWebサイトを見ているような形でデータを送ってる。彼らが使っているのは、ここにあるような、モバイルデバイス用GAと同じやりかたを使っている。

Lanchtrayが言うように、デバイスが利用状況を測定するのは別に驚くようなことじゃない。だけど僕は彼らがモバイルゲームを例にとって、詳細なスタッツ(どんなオプションを使ったかだとか)は必要で有用だというのには納得しない。

僕はKTがGAと統合されているってのはしばらく前から知ってたけど、いまその実装をしっかり見て、詳しいスタッツについて考えてる。でも、KoboがGAが提供しているツールのような、ひどく押し付けがましくて、使いものにならないトラッキング情報のほとんどを避ける努力をしているのが見て取れて喜んでる。Koboはアカウントや明白なIDを追跡しないし、セッションをまたがる(再起動しても追跡する)データは送信しない。

だけど、ホームスクリーンをロードしたり、本をX分読んだとかいちいち報告されるのは僕にとってはオーバーキルだ。測定しているのは、すごく深い情報をとられるってわけじゃないし、CarrierIQがやったみたいなこととや、メニューやボタン操作の追跡をされるのとは程遠いんだけど。

要するに、少なくとも僕にとっては、「気持ち悪い」の一線を超えてるんだ。だって、データはGoogleに送られて、スタッツはGoogleの個人情報保管庫に入れられて分析されるんだ(これがKoboに送られるんだったら、やっぱり考えるけど、かなりましだ。Koboは個人情報の収穫でビジネスを立てているわけじゃないから)。

Marco Armentは、僕よりずっとうまく「モバイル分析が気持ち悪くなる境目」について説明してる(49分目以後、コーヒーの話が終わったところから)。

Kobo TouchでGoogle Analyticsを無効にする方法

たったこれだけ:Kobo Touchのhostsファイルに、www.google-analytics.comがループバックアドレスの127.0.0.1を指すように書いておく。これでデバイスはGoogle Analyticsとは通信できなくなるから追跡を断ち切れる。

正確には、/etc/hostsファイルに
127.0.0.1 www.google-analytics.com ssl.google-analytics.com
と追記した。
(以下アップデート用ファイルとその適用のしかたが説明されてるけど割愛)

この仕掛けはアップグレードに関係なく有効だと思う。開発者がhostsファイルを更新するってことは考えにくいから。

(以下、擁護派のLanchtrayとその他の人の間で議論があるけど割愛)

----
(2012年9月3日追記:PCのKoboアプリもGAと統合されているようだ。Mac版には、~/Library/Preferences/com.kobo.Kobo Desktop Edition.plistというのファイルとcom.kobo.Analytics.plistがある。バイナリなのでコピーしてXML形式にすると、前者にはBrowser.cookiesというキーで、b64エンコーディングされたバイナリの配列がある。そしてその次にはGoogleAnalytics.visitorCookieというキーでなにやら数字とドットの組合せからなる長い文字列が値としてついている。後者にはただひとつだけのエントリがあり、キーはGAQueue、値は配列のようだ(いまは空だった)。)

Kobo TouchはCoretex-A8開発ボードらしい

@h_kenkenさんのツイートを追って、単なるブックマーク。

まず、日経ITProがKobo Hackについてまとめた記事。Raspberry PIを前フリにしてさっさとKoboの分解に進む潔さが好ましい。Kobo Touchだが、昨夜ヤフオクを見たら、ついに1000円台で投げ売っている人もいた。多くは5000円を切っているので、いまの騒ぎが続けばKobo Touch(ただし開発ボードとして)複数持ちという人も増えるのではないかと思う。

もうひとつは、MITOUJTAGを使った、どう考えてもKobo Touchを念頭に置いたとしか考えられない、iMX508のバウンダリスキャン事例紹介。ここまで可視化して内部を追えるというのがすごいなぁと感心。意外だったのは、MITOUはIPAの「未踏プロジェクト」とは何の関係もなさそうなこと。よく見たら、正式名称は「未踏ソフトウェア創造事業」で、ハードウェアごりごりするのは少し違うみたい。FPGAのHDLだってソフトウェアじゃないかのとかいうのが筋違いなんだろう。

KEPUBとはなにか(Kobo EPUB)

給料日までに少し財布に余裕があるような気がしたので、Koboブックストアで日本語書籍を購入してみた。それまでは、カナダのサイトで購入した英語の本とか、O'ReillyのDRM FreeのEPUBを入れていたので、日本語書籍は初めてだ。

それでようやく気づいたのだが、Kobo Touchの日本語書籍はACCESSのWebKitを使わなければならないから、従来のnickel(Kobo Touch内部のLinux上で動く読書アプリ)のレンダリングエンジンではなく、NetFront BookReader EPUB Editionを選択しなければ、日本語組版として破綻することになる(はず)。

Kobo Touchは、村上真雄氏のエントリにあるように、ファイルの拡張子で従来のEPUBのレンダリングエンジンとEPUB3対応レンダリングエンジンを切り替える。拡張子が単なる「.epub」なら前者、「.kepub.epub」なら後者ということだ。

KEPUB(Kobo EPUB)は、Koboのブックリーダーに合わせて作られたEPUBというような意味合いになるようだ。つまり、IDPFの規格からは逸脱していないが、他のブックリーダーでの表示は知らないよ、ということになる。

KEPUBについて、MobileReadのWikiの記述は必ずしも正確に記述されていないようだが、KoboブックリーダーとPC側アプリの関係についての記述はとりあえず現状に即している。詳しくは書かれていないが、ここで問題になるのはKDRMという独自のDRMだ。Wikiの記述どおり、PC側アプリやWiFi直接で入手する書籍は、KEPUBのみとなる。そして、KEPUBは3つのDRM方針、つまりDRM Free、Adobe DRM、KDRMの3つで配布されている。具体的にはDRM Freeは、藤井大洋氏の「Gene Mapper」。Adobe DRMは日本語書籍ではまだ確認されていないが、MobileReadのフォーラムには存在するようなコメントがある。そして、伊藤計劃の「虐殺器官」「ハーモニー」はKDRMだった。KDRMは、.kepub.epubをunzipして得られるトップディレクトリのrights.xmlで用いられている要素名なので、便宜的にそう呼ぶことにしている。

KDRMは、他のプラットフォームでは開くことができない。Adobe DRMと同様、ファイル名はそのままで、本文に関わるすべてのファイルが暗号化されており、unzipしても一切内容を見ることはできない。Adobe DRMならばそれに対応した他のリーダーでも開くことができるが、KDRMではそれができない。オープンプラットフォームと考えていたが、版元など権利者の要望及び営業の都合(Kobo独占発売や特価など)で囲い込む仕組みは用意されていたということになる。

カナダのサイトに接続すれば、「My Library」以下はAdobe DRMのダウンロードリンクがついた状態で表示される。しかし、日本語書籍は一切現れなかった。一方、日本向けKoboブックストアの「マイライブラリ」は書誌情報を出すのみ。たしかに日本語書籍はKEPUBで提供しているのだから、Webブラウザから個別に配信を受ける筋合いのものではないだろう。従来のKobo社の方針と齟齬はない。とはいえ、何か腑に落ちないものは残る。

ついでなので、SONY Readerについて誤解していたことをここに告白する。SONY ReaderはAdobe DRMのEPUBのみを扱っているものとばかり思っていた。しかし、日本の製品であれば、また、EPUB3の規格が定まる以前から販売していたのだから、当然日本独自の縦組み可能なフォーマットで本は配信されていたことに気づいていなければならなかった。具体的には、XDMFと.bookだ。日本のReaderストアで扱われている日本語書籍は多くがこのどちらかだろう。紀伊國屋書店のKinoppy以後、EPUB3の書籍もあるかもしれないが、KinoppyもXDMFと.bookに対応しているので何の保証もない。

XDMFと.bookは形式こそXMLに準じているが、シャープもボイジャーも古くから日本語の縦組み読書環境を提供してきた経緯があり、文字コードはシフトJISなのだそうだ。JIS X 0213:2004に対応したShift_JIS-2004というものがあるそうだが、入力システム(IME)が対応しているかどうかは知らない。いずれにせよ、JIS X 0213止まりではまだ多くの文字が「外字」として、XML文書のなかでは「画像」として組み込まれることになる。EPUB3においても、Unicode対応について明確な定めはないようだし、あれば逆に制約になるので、現状はJIS X 0213:2004を逸脱しない範囲のUTF-8ファイルをマークアップすることになるのだろう。実際、楽天Koboをセットアップして最初に入る青空文庫の「吾輩は猫である」には、OEBPS/Image/gaijiというフォルダがあり、ページごとに使われている「外字」がPNG形式で入っている(なぜかKDRMがかかっているので開けないのだが)。

こうした「外字」問題に対しては、特に多くの役物や各種異体字に関しては、2006年のUnicode 5.0でIVS(異体字辞書システム)が導入され、2012年現在Adobe Japan 1-6に対応したグリフを持つフォントならば公式にIVD(異体字辞書)に登録されている文字の多くが、さらに汎用電子コレクションを含めば、現時点で日本語でUnicode 6.1のコードポイントが割り当てられている文字はすべて表示できる。具体的には、IPAmjフォント(明朝のみ)には汎用電子コレクションが含まれ、Adobeの最新のヒラギノはAdobe Japan 1-6対応ということになるだろう。明治の活版印刷に由来し人気の高い秀英体は、2008年の「平成の大改刻」のAdobe Japan 1-5対応版をモリサワが販売しているのが現在最新の状況のようだ。IVSは拡張性のある規格なので、状況次第で今後グリフが追加されることはありえる。ただ、従来の印刷書籍でも作字して、全く独自の文字を版面に加えるということはあったので、そのような場合には画像、特にSVGやWebフォントのようなベクター形式の図形を用いることにはなるだろう。しかし、シフトJISという制約がない分、UTF-8を使うEPUBのほうがXDMFや.bookに比べ「外字」となる文字数は少なくなるはずで、EPUBが望ましいのだが、現在日本語書籍をEPUB3のみで提供しているのは楽天Koboのみ、しかしKDRMで囲い込まれているというのはどうにも釈然としない。

話がそれたついでに、EPUBと外字問題に関しては、先月のセミナーの動画をご覧いただくとよくわかると思う。

2012年8月7日火曜日

Kobo Touchにはオープンソースが似合う

前のエントリに追記を書いていて、別エントリにすべきと思ったのであらためて。

まず、日本語EPUB対応はNetFront BookReader v1.0 EPUB Editionであるということ。これに関しては、下川さんのEPUBに寄せる強い思いもあるだろうし、出版社の要望に沿うためにも日本特有のきめこまやかな(というか、芸術的職人芸に基づく)組版を実現させる必要があって、代わるものがなかったということなのだろうと思う。むしろ、WebKitの現状を考えるに、それを調整する、つまりオープンソースコミュニティに関わっていく時間が、ビジネスの側面から考えると待てなかった側面はやむを得ないのだろう。SONY ReaderはAdobe Reader Mobileを採用しているということなので、競争上、プロプライエタリで、これを超えるものがあるなら搭載することは当然のことなのだろうと思う。

また、様々な使い勝手について、日本の消費者は完璧なものを望むので、もとのKobo Touchに対してソフトウェア的に対応できるものは何でもやっていかなければ今回以上に炎上したであろうことは想像できないことはない。

特に、画面上の操作が赤外線センサであることについて販売員が知らず、スリープ状態ですぐ電池がなくなることに疑問を持ったまま店頭に立っているというのは(いや、きょう某店頭で偶然販売員と会話して知っただけで、全国的にどうなのかは知らない)どうなのかと思ったりした。Appleやソニーのように直売店があるわけではないので、商品のなかみに詳しい必要はないのだろうが、これだけ炎上した以上、苦情の分析に専任を当てて得意のスピード経営で販売員への対応マニュアルを随時更新するとか楽天はしたほうがいいんじゃないかと懸念してみたり。ちなみに、「電源オフ」にすれば赤外線センサを見なくなるのでかばんに入れても電池は減りませんが、スリープ状態では画面上に障害物があるとLEDが点灯するのでぐんぐん電池が減ります。って書いてみたら、デフォルト設定が悪いんじゃないかという気がしてきたぞ。

デスクトップアプリにしても、おそらく出版社の要望にきめ細かく応えた日本語EPUB3の美しい組版を実現するには現状のWebKitはまだ実装が及ばないところがあるので、しばらくは出ないだろうし、出てもおそらくNetFrontのコードを持ち込むことになるだろうから、プロプライエタリなコードがまた増えることになるんだと思う。

そう考えると、Kindle日本語版の「出る出る詐欺」も、組版エンジンの実装とMOBIなりAZWなりのフォーマット改訂に手間がかかっているせいではないかという気がしてきた。その意味では、楽天は率先して前線に出て十字砲火を受けたわけで、あっぱれというほかないと思う。内部筋の情報では三木谷はかなりへこんでいるらしいが、お前が出ずに誰がこんな危険なギャンブル、もとい偉大なる勇み足ができるか、よく考えて、もっとましな開き直り会見したほうがいいのではないか。まぁ、ほとぼりが冷めた頃にAmazonが楽天の失敗の上に満を持して登場とかありうるわけだけれどもそこはそれ、先行者利益ということで(ほんまかいな)。

しかし、そうして重厚な品質の上に成り立つのはAppleしかり、大事なところはほとんど外から触れない製品にならざるを得ないわけで、もともとあったKoboのカジュアルなところとは対局になってしまうことを懸念せざるを得ない。例えばKobo書店サイトについて苦情を言う日本人は、従来のサイトを知らないから言えるのであって、あんなに買いにくいサイトはなかった。安いのは若者向けの恋愛小説とかホラーとかの軽いやつばかりで、欲しい本は検索に偶然引っかかっても他の書店のほうが安かったりと、売る気があるのかどうか、あんまり考えてなさそうなところが逆に好感を持ってしまったりするような作りだったのだが。

やはりここは、すでに出ているソースコードをもとに、オープンソースコミュニティのファームウェアをがんばらざるを得ないのではないか。すでに基本はできているので、nickelに相当する部分はWebKitの最新版にしっかり追随する形、もしQtの更新が遅ければOpenFrameworkに置き換えていくぐらいの勢いがあってもいいのではと思った。若者がんばれ。おじさんはもうだめだから。

2012年8月2日木曜日

Kobo Touchをhackする日本人たちに敬意

2ch有志カスタムファームウェアがあるというので、いろいろ探してみたら、Kobo Touch のソースツリー(及びパッチ)が出ているのね。
https://github.com/kobolabs/Kobo-Reader
2年前の最終更新だけれども、製品が出た当時のことを考えれば、まぁカーネルを置き換えるようなことは特にしていないのかもしれないなどと思いつつ。それにしても、Linuxで動いているからにはGPLに従ってソースを出さなければならないわけで、GPL強力と驚きました。いやまじで。

Linuxについては詳しくないので、daemon関係については正直さっぱりなのですが、アプリケーションがQt Embeddedというのもびっくり。電子書籍端末なのでなんかWebKitを使うプログラムが動いているんだろうと思ったら、Qtに含まれるWebKitを使っているというわけですね。ということは、日本語対応はQtを新しくするだけでそれなりに、ということですか。アプリ名はどうやらnickelらしい。

(2012年8月7日追記:日本語EPUBは、イースト社のNetFront BookReader v1.0 EPUB Editionを使っていると、ろす氏のブログに書かれておりまして、氏の立ち位置からして間違いない情報と思いますので訂正いたします。ちなみにNetFrontはACCESSがガラケーや組み込み向けに出してきた、別の意味で歴史のあるWebブラウザですな。イーストは電子書籍業界の有名人、下川さんの会社ですから、かなりEPUB3に思い入れの入った作りであろうかとは想像できます。それから、某有料メルマガ方面から、コストの問題で搭載すべきソフトウェアコンポーネントが別のものになっているという話がきこえてきて、それがもとからあったものなのか、楽天の要望を解決するために購入すべきものが代替物になったのか、そのへんは不明です。ただ、楽天なり日本の消費者の要望で、カラッとオープンだったKoboが囲い込まれた商品になっていくならそれは残念なことだと思います。)
(2012年8月13日追記:NetFront Book Reader v1.0 EPUB EditionのレンダリングエンジンはWebKitだということが、村上真雄氏のブログに書かれていた。氏はEPUB3の縦組みに必須のCSS3 Writing-Modeの規格に深く関わっていた方。他にも、いかにもWebKit的な特徴的なレンダリングが観察されるという言及は複数あり、ACCESSまったくオリジナルのレンダリングエンジンというわけではないようだ。この記事によれば、ACCESSはIDPFメンバーとして、WebKitベースのEPUB3組版リファレンス実装Readiumにコードを貢献し、それが反映されたものがMac OS X用カスタムバイナリとして現在提供されているようだ。つまり、一般的なChomeやChromiumブラウザにChrome Web StoreのReadiumを追加しただけでは、少なくとも日本語組版については不完全だということなのだろう。)

EInkディスプレイのドライバソースも出ているし、指の検知は縦横にずらりと並んだ赤外線LEDとフォトトランジスタだけなので、そりゃNetBSDの移植も即座に出てくるわなぁ、と思った次第。@h_kenkenさんがんばれ。ああ、なんと動機はMikutterの組み込みですか...なるほど。

と、どうやらTogetterに着々と解析結果が集積されているようで、僕がぐだぐだ書く必要性が感じられなくなってきたので、以下リンクのみ。

2012年8月1日水曜日

MacPortsのqt4-macをMountain Lionでコンパイルする

山獅子について、Xcode 4.4にバージョンが上がったこともあり、いろいろと不安はあったが、特にこれといって大きな問題はなかった。

しかし、Qtについてはこれまで避けてきたのであまり困っていなかったのだが、フリーのノンリニアビデオ編集ソフトウェアKdenliveを入れるにあたってqt4-macを入れる必要が生じ、格闘することとなった。

まず、最新版のQt libraries 4.8.2が山獅子に対応していない。単純なところでは、OSのバージョンチェックに引っかかるのであれもこれもコンパイルが通らない。

これは、src/corelib/global/qglobal.hに書かれているバージョンチェックをごまかしてやればよい。とりあえず、まっさらなところで手を入れたいので、先に

  $ port patch qt4-mac

で、ソースの展開とパッチ当てまでやっておく。

そのあと編集するわけだが、具体的には、以下のようにMAC_OS_X_VERSION_10_7の定義をしているところに続いて10_8を作ってやる。

#  if !defined(MAC_OS_X_VERSION_10_8)
#       define MAC_OS_X_VERSION_10_8 MAC_OS_X_VERSION_10_7 + 1
#  endif
#  if (MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_8)
最後の行は、もとは10_7だったのを8に変えた。

これでcorelibのコンパイルは進むのだが、途中でファイルシステムがらみのところでdeprecateの警告が出る。おそらく、SandBox対応あたりではないかと思うが、とりあえず無視しておく。

しかし、最後にライブラリをリンクするところで未定義シンボルのエラーが出る。これは、Bug Trac Ticket 35313にあるように、いったんport configure qt4-macでMakefileまで作ってから、このMakefileのLIBSの末尾に「-framework Foundation」を追記してやればよい。

あと、WebKitの山獅子版が出ているらしいので、同じTicketのリンクにあるように、src/3rdparty/webkit/source/WebKit/qt/QtWebKit.proを置き換えるのと、山獅子用のWebKitライブラリを、同じディレクトリにダウンロードして入れてやる。

これで、コンパイルは通るようだ。

しかし巨大なフレームワークだなぁ。長大なコンパイル時間がかかる。

あとひとつ気になるのだが、いつのまにやらOpenVGが紛れ込んでいて(/opt/local/include/VG)、でもqt4-macのconfigure時にコンパイルができずに、「OpenVGを使わないQt4」ができたようだ。OpenVGのサポートはX11R7.5からということなのだが、XQuartzに入っているわけでもなく、よくわからない。