Windows 8のIVSサポートについて、セミナーでMicrosoftの人に質問するための想定問答集(PDF)をtwitterで公開しつつ更新中(http://dl.dropbox.com/u/50939295/NAOI/MS_IVS_Q.pdf)。 Microsoftの人になりきって大いに語っているが、内容は「わたしの想像」に過ぎないので、あしからず。あと、あくまでネタなので、会場で実際にこういう質問が出るって期待しないでね!
昨日のエントリ(「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ)読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね? うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と? いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ? 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「・」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
OS X Lion 10.7.3のAppleカラー絵文字についてまとめておく。Appleカラー絵文字は、下図のような段階を踏んでレパートリを拡充してきた。iOS 4の時代は、SoftBank互換の絵文字のみ(下図左、黄色地)。Lion 10.7.0とiOS 5では、docomo/au互換の絵文字がモノクロで追加された(下図中央、淡いグレー地)。10.7.3では、docomo/au互換の絵文字も、Unicodeの絵文字エリア(U+1F300〜U+1F6FF)の残りの文字(ケータイ絵文字をソースとしない文字)も、すべてAppleカラー絵文字でカラー表示できるようになった(下図右)。下図の部分集合に振ったA〜Eのアルファベットは、以下の図と照応している。 10.7.3でモノクロからカラーになったのは、下図の213文字。 docomoまたはauの絵文字との対応を持つ文字のうち、10.7.2まではA
Appleカラー絵文字が変わった。OS X Lion 10.7.3では、一気に300以上の絵文字が、新たに追加されたり、カラー化されたりした。 これらは、現時点では文字ビューアの「絵文字」からは入力することができないので、見つけにくく、あまり話題になっていないようだが、大きいサイズで表示されうることを前提とした気合いの入った描き込みがすごい*1。 入力は、文字ビューアの「Unicode」から。今回掲載した絵文字は、U+1F301 FOGGY、U+1F30B VOLCANO、U+1F30C MILKY WAY、U+1F402 OX、U+1F404 COW、U+1F405 TIGER、U+1F406 LEOPARD、U+1F408 CAT、U+1F409 DRAGON、U+1F40A CROCODILE、U+1F40B WHALE、U+1F415 DOG。 *1:そのぶん、以前からある絵文字と
ここに2匹のプードルがいるんだけどね。 間違い探しですか? ズバリ、左にだけ眉毛がありますね。 うん。眉毛があるほうが、iPhoneやLionに入ってる絵文字フォントのプードル。眉毛のないほうが、Unicodeのコードチャートに載ってるプードル。 えっ、どういうことですか? そもそもUnicodeにケータイ絵文字を入れようって提案したのがGoogleとAppleだからね。提案書のための絵文字をAppleが用意して、それがUnicodeに収録された。そのあとで、iPhone絵文字に含まれていなかった文字については、データを流用して絵文字フォントに追加したってことじゃないかな。 だからほとんど同じなんですね。でも、眉毛はどうなりました? ケータイ絵文字をUnicodeに収録する過程では、いろいろあってさ。たとえば、日本の絵文字のマンガっぽさをめぐる戦いとか。ほら、アイルランド・ドイツ修正案って
もうすぐお正月だし、こんな図を作ってみたんだけどね。 十二支ですか? いろんな国の十二支? そうそう。実はこれ全部、「どこの国の十二支の何番目の動物」という情報まで含めて、Unicodeのコードチャートに載ってるものなんだよね。 いちばん左の列が標準的な十二支ってことですね。 うん。日本だと、12番目のイノシシだけが独自仕様だな。それが標準仕様だとブタ。 カザフスタンでは、来年の干支はカタツムリですか。 よくわからないけど、そうなのかな。 このペルシアのネズミは、どうして小さいんですか? 標準仕様のネズミの絵を縮小したみたいに見えますけど。 それはネズミの種類が違うんだよ。ドブネズミとハツカネズミ。 え? でもこれ、文字なんだから、たとえばゾウでもアリでも同じ大きさに描かれるものですよね。 原則は、そうだね。 じゃあ、どうしてドブネズミを縮小したのがハツカネズミなんですか? まあ、ちょっと
この項追記。2012年1月27日、au iPhoneはケータイ絵文字に対応したので、以下の記述はすでに古い。詳しくは「auとSoftBankのiPhoneにおける絵文字対応を比較する」を参照。 auのiPhoneにおける絵文字の文字化けについては以前にもまとめたことがあるが、化ける理屈を重視して書いたので、わかりにくかったかもしれない。また、docomoやSoftBankのケータイに触れていなかった。そこで今回*1は、ケータイ間での絵文字のやりとりに絞って、理屈抜きのシンプルな図にまとめてみた*2。つまり、auのiPhoneは、ケータイ絵文字を表示することも、送った絵文字をケータイで表示してもらうこともできない。 この問題の解決方法は特にないが、強いて言うなら、Gmailのアカウントを使ってウェブでメールの読み書きをする(要するにパソコンでケータイと絵文字のやりとりをする手段と同じだが)と
前回のエントリのコメント欄で、「auのiPhoneの『メッセージ』アプリで*1少年がヒゲおじさんに化けた」という事例を教えていただいた*2。さっそく試してみた*3。 上図は化ける文字の例*4。巻き戻せない季節を経て、少年は男に、少女は女に変わる。孤高の狼は、あろうことかペロちゃんに変わっている。 もちろん送信側も受信側もUnicode環境なのだけれど、経路中で一度auのISO-2022-JPに変換されているようだ。auの絵文字にはU+1F466 BOYと直接対応するものがないので、フォールバック・マッピング(下図の赤矢印)により0x7657(「おにいさん」くらいのかんじ?)になる。これだけなら違和感は大きくないが、ここからさらにUnicodeに戻ることにより、少年が2段階成長してしまう。 というわけで、この現象は文字化けというよりはフォールバックであり、おそらくバグではなく仕様なのだろう。
ゴホゴホ。なんですか? IVS? また新しいオモチャですか。 フフフ。話題のテクノロジーなんだよね。 でもそういうのって、実際に使えるようになるのは、ずいぶん先なんでしょ? いや。それが今すぐにでも使えるんだな。 わざわざそんなよくわからないものを使いたがる人なんています? MacはシステムレベルでAdobe-Japan1-5をサポートしているよね。でも、AppleのAPIを使ってグリフ置換を行うアプリ*1とAdobeアプリの間には断絶があって、異体字情報を交換することができなかった。それが、IVSを使えば、たとえばJedit Xで編集したテキストの異体字情報を、そのままInDesignに持っていくことができる*2。そういう意味では、すぐに使いたいという人はいると思うよ。 用途は、むずかしい人名とか? 別に人名異体字に限らず、たとえば原稿中に「謎」って文字があったとするじゃん。この字は二点
異体字シーケンス(IVS)の特徴について、OpenTypeフィーチャのグリフ置換(GSUB)と比較しながら考えてみた。重要だと思われる点をメモしたものであり、IVSの体系的な説明ではない。 IVSは文字コードのレベルの枠組みなので、異体字の情報をプレーンテキストで交換できる。この最大の特徴に加え、GSUBよりも新しい分、よりすっきりとした論理的な仕組みになっている*1。 IVSの概念は、下図のようなかんじ。符号位置に包摂される複数のグリフ(集合)のなかから、ある特定のグリフ(集合)をVSによって指定する、というイメージ*2。 上図はUnicodeの視点から描いたものだが、Adobe-Japan1フォントではデフォルトのグリフはcmapで指定されているので、実装としては下図のようなかんじ。IVSでは、原則として基底文字(親字)の包摂範囲を超えたグリフは指定できないので、VSを付けることによっ
前回述べたように、IVSはGSUBよりも新しい分、すっきりと論理的にできている。だから、「漢字の異体字指定に関してはGSUBからIVSに乗り換える」というような思い切った転換を行い、なおかつInDesignなどにおけるIVSの扱いが信頼できるものであるなら、みんなハッピーになれそうだ。 しかし、たぶん現実には、「GSUBはそのまま残って、IVSも使える」ということになるだろう。というか、すでにそうなっている。要するに、もともと複雑な状況が、さらに複雑化したわけだ。加えて、もちろん今後改善されていくとは思うが、InDesignにおけるIVSの扱いには、まだまだ問題が多い。以下、InDesign CS4における実装あるいは運用上の問題。 IVSとGSUBの競合・重複の問題。たとえばInDesign上で、ある文字にGSUBとVSを両方適用したらどうなるのか。詳しくは「InDesign CS4にお
Appleカラー絵文字の「勝ち誇った顔」(U+1F624 FACE WITH LOOK OF TRIUMPH)をUnicodeのコード表と比べると、かなり印象が異なる。予備知識なしに両者を見て「同じ字」だと思う人はいないだろう(下図)。 Appleカラー絵文字のうちモノクロのもの(Lionで追加された分)は、ケータイ絵文字のUnicodeへの収録過程におけるGoogle・Apple提案(いちばん最初の提案)の字形を流用しているようだ。 しかし、「勝ち誇った顔」は、非常にややこしい経緯のあった字で、審議の過程で本質的な修正がなされている。この字については、Appleカラー絵文字でもUnicode 6.0の例示を尊重したものを実装して欲しかった。 Google・Apple提案の「勝ち誇った顔」のグリフを修正するべきだった理由は「Unicodeのケータイ絵文字対応表への疑問」(この記事におけるU
Appleカラー絵文字って何? iPhoneやLionに搭載されている絵文字フォントの名前だよ。Lionをインストールすると、iPhoneのカラー絵文字がMacでも使えるようになるんだ。文字ビューアの「絵文字」から入力できるよ。 iPhoneとLionでは、絵文字に違いはあるの? いちばん目立つ違いは、Lionでは文字が増えてることかな。 わあ、どんなのが増えたの? ナマハゲとか天狗とかナルトとか。 これ、モノクロじゃん。 増えてるぶんは、ぜんぶモノクロ。Lionは、Unicodeに収録されたケータイ絵文字のうち、Softbank絵文字以外を、いわば「docomo/au互換絵文字」としてモノクロでサポートしている*1。このモノクロの絵文字は、文字ビューアの「絵文字」には表示されない。Font Bookでレパートリーを表示すると、下のほうに入ってるよ。 Gmailを使えば、以前からMacでも
これまで、ケータイ絵文字は「外字」であり、一般の文字とは明確に区別されていた。しかし今後は、ケータイ絵文字がUnicodeの(私用領域ではない)符号位置を用いて表現されるようになってくるだろう。LionのAppleカラー絵文字は、その先駆けである。たとえばU+2665「♥」は、JIS X 0213にも含まれるポピュラーな文字だが、これをAppleカラー絵文字で表示すると、トランプの絵になる(下図)。今までの常識とは異なる世界だ。というわけで、Appleカラー絵文字とUnicodeの関係を把握するためのリストを作成した。以下、リンク先のPDFはUnicodeのチャート。その下の図は、Appleカラー絵文字のマッピングを示す。 C0 Controls and Basic Latin(http://www.unicode.org/charts/PDF/U0000.pdf) C1 Controls
「あとはフォントをAppleカラー絵文字に変えるだけ」の図をInDesignで作ってLionを待ちかまえていたのだが、実際にやってみると、Adobeアプリではカラーの絵文字は表示されないようだということがわかったので、PDFを貼り込んだりして作り直したのが、以下の図。 各文字の左上に記したのが、Unicode絵文字の符号位置。その下の青字は、iOSが利用している私用領域(PUA)の符号位置。この青字の符号位置が記されている文字が、現状のiOS互換。これらの文字は、LionのAppleカラー絵文字でもカラーで表示できる。 黒字の符号位置は、(Softbank以外も含めた)日本のキャリアのケータイ絵文字をソースとするもの。ざっと見たところ、これらの文字のうちiPhone絵文字をソースとしないものは、ほぼ「モノクロの絵文字」としてサポートされているようだ。このうち以下の図で濃いグレーとなっている
(ホー先生)Macの画面で「●▲■」の「●」と「■」だけが小さく見えることがあるのはなぜじゃ*1。 「●」と「■」が欧文フォントで表示されているからだよ。たとえばMacのFinderでは、ファイル名は「Lucida Grande優先」で表示される。Lucida Grandeは「●(U+25CF)」や「■(U+25A0)」のグリフを持っているけれど、「▲(U+25B2)」のグリフを持っていない。だから「▲」はヒラギノで表示されて、「●」と「■」だけが小さく見えるんだ。同じ理由で起きる現象としては、三点リーダの位置が下にズレたりすることも、よくあるよね。 Finder以外でもよくあるんじゃが。 Appleのソフトは世界共通の仕様なので、デフォルトは欧文フォントだよ(下図)。 日本語フォントを指定すれば、この問題は避けられるのか。 うん。Finderでは基本的にフォントの変更はできないけどね。そ
Spotlightの検索がダメで、先日ハードディスクを初期化し、システムを再インストールした。移行アシスタントで以前の環境を引き継いでしまっては元の木阿弥なので、各種の設定やアプリケーションのインストールは新たに行い、ドキュメント類のみ、バックアップ先の外付けハードディスクから内蔵ハードディスクに手動でコピーした。 が、やはりSpotlightで内蔵ハードディスクの検索ができない。具体的には、Spotlight用の索引作成プロセス(mds)がCPUをほぼ100%占有したまま、いつまで待っても終了しない。この状態に陥ると、Time Machineによるバックアップもできなくなってしまう。 わざわざ初期化までした以上、バックアップ先から持ってきたファイルに問題がある可能性が高い。そこで、内蔵ハードディスク内のファイルを「システム環境設定>Spotlight>プライバシー」に入れたり出したりして
前回のエントリで見たように、Adobe-Japan1フォントでは、欧文約物形状のダッシュ(CID+138)がU+2014 EM DASHに、和文約物形状のダッシュ(CID+661)がU+2015 HORIZONTAL BARに対応している(下図)。しかし、U+2015 HORIZONTAL BARがもともと「日本語組版のための全角ダッシュ」としてUnicodeに収録されたものだとは考えにくい。では、これは何なのか。わかっているいることを以下にメモするが、あらかじめ言っておくと、あまりまとまりはない。 Unicode Standardの「6.1 Writing Systems」には、「U+2015 HORIZONTAL BARは、ある種のタイポグラフィのスタイルで、引用文の導入に用いられる」と記されている。 U+2015 HORIZONTAL BAR is used to introduce
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く