SHARP書院WD-A521のマニュアル「WD-A521/A541/A551 日本語ワードプロセッサ取扱説明書(文書編)」を読んでいたところ、文字コードの記号一覧のところに、絵文字が160種類ほど収録されているのを見つけた。絵文字の中にマル金とマルビが含まれていることから、あるいは1984年頃にデザインされた可能性が考えられるが、WD-A521それ自体は1990年11月の発売だ。だとすると、これより古い書院にも、絵文字が搭載されているのかもしれない。 ただ、ワープロのマニュアルは、どこの図書館を探しても所蔵がない。SHARPも、既に当時のマニュアルは破棄してしまっており、全く在庫がないようだ。だとすると、個人蔵のマニュアルを探すことになるのだけど、全く雲をつかむような話で…。この日記を読んだ方で、手元に古いワープロ(書院に限らない)のマニュアルをお持ちの方は、ぜひ文字コードのページを調べて
InDesign CS4で「厩」を入力・選択し、字形パネルをダブルクリックしてCID+13647に置換。フォントは(たとえば)小塚明朝Pr6N。そのウェイトを変更してみる。と、CID+13412に化ける(下図)。 このグリフ化けのおもしろい点は、cmapテーブルもaaltテーブルも共通だと思われるフォント間で(ウェイトの違いのみで)化けていること。以下、化ける理屈(推測)について、大雑把に述べる。 InDesignにおけるaalt(すべての異体字)タグを利用したグリフ置換のメカニズムは、cmapテーブルまたはaaltテーブルが異なるフォント間では、基本的にうまく機能しない。実際、InDesign 2では、いろいろ化けていた。 CS以降のInDesignでは、Adobe-Japan1-4とAdobe-Japan1-5のcmapテーブルの違いおよび2系統存在するaaltテーブルの違いへの対策が
InDesign CS4はUnicodeのIVS(異体字シーケンス)をサポートしている。IVSは、親字に続けてU+E0100などの特殊な文字(異体字セレクタ)を入力することで、たとえば下図のようにグリフを指定するメカニズムである。 同様のグリフ指定は、もちろんOpenTypeタグでも可能である(下図)。 では、1つの文字にIVSとOpenTypeタグで競合する指定を行ったらどうなるのだろう。U+990C「餌」を例として試してみた結果が、下図。横軸がIVS、縦軸がOpenTypeタグ。IVSの指定が顕在化しているものを青地、OpenTypeタグの指定が顕在化しているものを緑地で示した。白地は両者の指定が一致しているもの。 この例では、異体字セレクタがU+E0101またはU+E0102ならIVS優先、そうでなければOpenTypeタグ優先、というように見える。しかしInDesign CS4は、
http://d.hatena.ne.jp/mandel59/20090904/1252071738の答え 同じ名前のファイルが存在しているように見える。 これはそれぞれ 「ほげほげ.txt」(NFD、「げ」は U+3051 U+3099 というシーケンス*1) 「ほげほげ.txt」(ZERO WIDTH SPACEが含まれている*2) 「ほげほげ.txt」(NFC、「げ」は単一のコードポイント U+3052) となっている。 Mac OS X標準のファイルシステム HFS+ ではファイル名がNFDで正規化されるが*3、Linuxのファイルシステムでは正規化は行わない。 *1:結合文字シーケンスにフォントが対応していなければ「け゛」みたく表示されるかもしれない。ここでは、IPAフォントを結合文字シーケンスも表示出来るように改造したものを使っているので、「フォントを弄った」というのも
何でもいいから英語の単語に「痴」を付けてGoogleで検索してみる。例えば「he痴」でもいい。うまく見つからなければ,例えば Shakespeare痴 Got A Gun を見てみる。英語のサイトなのに何でこう「痴」が多いのか(うまく「痴」に見えないなら,ブラウザのデフォルトのエンコーディングをシフトJISにしてみてください)。 答え:Windows-1252(CP1252)のアポストロフィは 0x92 であり,これにs(0x73)が付くと 92 73 となり,これはシフトJISで「痴」になる。つまり,「He's」が「He痴」に化けるページはアポストロフィをWindows-1252でエンコーディングし,エンコーディング指定をしていないのでシフトJISで表示してしまったのである。書いた本人はLatin-1(ISO 8859-1)のつもりかもしれない。 アポストロフィは '(0x27)でいいの
InD-Boardの「字形について」というスレッドで話題になっていた「SINGで拡張された小塚Pro」の文字化けについて、InDesign CS4と小塚明朝Pro Rで検証してみた。 再現性にあいまいさはあるが、次のように言えそうだ。SINGで拡張された小塚Pro書体において、グリフXがSING拡張分ではなく(CIDが15443以下)、なおかつグリフXの親字PがSING拡張分であり(CIDが15444以上)、なおかつ親字Pの符号位置が基本多言語面の範囲外(Unicodeスカラ値が5桁)である場合、ドキュメントを保存して閉じた後に再び開くと、グリフXが親字Pに化けることがある。 わたしの環境では、字形パネルからダブルクリックで入力して(コピー&ペーストや書体の変更などをせずに)すぐに保存し開き直した場合、前項の条件を満たすものは100%化けた*1。 下図は、化ける文字のリスト*2。グレー枠の
InDesignの勉強部屋さんの掲示板での話題を検証していて、CMapバージョンの違いの好例が出てきたので……。 あちらの話題は小塚明朝Pro Rにおいて、文字パレットから入力したCID8443「山立可」がCID17009「石立可」に化けるというものだったが、私の環境では発生しない。 文字パレットで確認するとCID8443はCID17009=ユニコード2550Eの異体字となっており、CS3からタグ付きテキスト(S_JIS)で書き出すと<02550E>となっている。 その親字のユニコード2550E(D855+DD0E)=CID17009が化けた後の文字なのだが、Adobe-Japan1-4準拠である小塚明朝Pro Rには含まれていないハズだが、これがSINGで拡張された部分に含まれている*1。 私の環境では文字化けは再現しないのでこれ以上は検証しようもないが、その流れの中でモリサワのユニコー
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
あまり時間がないので短くご報告。 Microsoftの「Windows 7向けJIS90互換フォントパッケージの提供と今後について」記者説明会に行ってきました。これについてはプレスリリースも出ています。 Windows(R) 7 向け JIS90 互換フォントパッケージの提供 より詳しくはINTERNET Watchの記事などをご参照ください。 マイクロソフト、JIS90互換フォントの提供はWindows 7で最後 細部は記事にゆずるとして、ぼくが重要だと思ったことは以下の点です。 Windows Vistaによるフォント変更について、同社コールセンターに対し、クレームの電話は1件もかかってきていない。 Microsoftは(今のところ)この件について、ユーザーに大きな混乱は発生しなかったと考えている。 Windows Vistaでフォント・デザインが変更されたことについては、2006年に
CMapの系統図を描いてみた。 上図左上、源流となっているUniJIS-UCS2は、Adobe-Japan1-4(AJ14)をレパートリとするCMapである。 Appleは、2001年9月リリースのMac OS X 10.1でApple Publishing Glyph Set(APGS)を投入し、JIS X 0213:2000をサポートした。APGSはレパートリとしてはAJ14のスーパーセットだが、主にJIS X 0213との整合性を高めるために、既存のマッピングに変更が加えられている。 2002年9月、AdobeはAPGSを追認する形でAdobe-Japan1-5(AJ15)を策定したが、Appleによるマッピング変更の一部(主としてプロポーショナル・グリフの採用)には追随しなかった。このためAJ15以降のCMapには、Apple用のもの(UniJISX0213系)とそれ以外(UniJ
NAOIさんのところで触れられている以下の件。 モリサワStd・Pro・Pr5・Pr6の違い(Mac OS Xの文字コード問題に関するメモ) 最後に提示されている資料ですが、Adobeからも同様の資料は提示されてますね。 ということで、文字コードだけではなく、全体的な検知から以下NAOIさんのところの話題からはどんどん内容がずれる話を長ったらしくしますので、混乱しないでください。されそうですが。 ■モリサワ Adobe-Japan1-4(Pro)から Adobe-Japan1-5(Pr5)への変更に伴う字形相違の資料 (OpenTypeフォント関連資料) ■Adobe 小塚明朝・小塚ゴシックにUniJIS-UTF CMapへの変更とそれに伴う字形の変更及び削除 (小塚フォントのアップデートにおけるデータ受け渡しの注意点/TechNote:224301) 資料のわかりやすさ・読みやすさ・付加
1989年、Appleは漢字Talk 6をリリースし、また、初の日本語対応PostScriptプリンタであるApple LaserWriter II NTX-Jを発売した。NTX-Jに搭載されていた日本語フォントは、モリサワのリュウミンL-KLと中ゴシックBBB。 プリンタ・フォントであるリュウミンL-KLと中ゴシックBBBの文字セットとエンコーディングは、Adobeによって83pv-RKSJ(以下単に「83pv」と呼ぶ)*1として定義されており、その外字部分(下図・左)は、NECのPC98外字のサブセットとなっていた。 リュウミンL-KLと中ゴシックBBBに対応するスクリーン・フォントとしてAppleから提供されたのが、細明朝体と中ゴシック体。漢字Talk 6.0.7でForeign System Fontをインストールすると、上図青地部分を画面表示することができた。 上図ピンク地部分の
Mac OSで使われるShift-JISであるMacJapaneseは、Unicodeにない文字を含んでいる。このためMacJapaneseをUnicodeに変換する際には、PUA(私用領域)の6文字(U+F860、U+F861、U+F862、U+F87A、F87E、F87F)を、特殊な機能を持った文字として利用する。今回は、Unicodeのサイトにあるテーブル(http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT)に基づいて、この6文字の使われ方についてまとめてみようと思う。図に用いたフォントは(フォント名を明示していない場合は)Osaka。 Mac OSでは、U+F860は後続する2文字をまとめて1つの文字であるかのように扱うための特殊な文字である。また、U+F861は後続する3文字を、U+F862は後続する
おなじみの Fonts フォルダではなく、C:\Windows\ehome なる場所を覗いてみると… 一番下に WTVGOTHIC-R.ttc, WTVGOTHIC-RB.ttc, WTVGOTHIC-S.ttc の3つのファイルが。開いてみると、それぞれ Windows TV 丸ゴシック & Windows TV P丸ゴシック Windows TV 太丸ゴシック & Windows TV P太丸ゴシック Windows TV ゴシック & Windows TV Pゴシック が入っていた。どれもバージョンは001.000、コピーライトは (c)2007 TypeBank Co., Ltd. となっている。IPAフォントと同じく、タイプバンク製らしい。 で、「TV ゴシック」の「TV」って何さ?というと、 (クリックで拡大) こんな感じでデジタル放送用の記号類(ARIB外字)が入っているので
2008年6月、ソフトバンクは新デザイン絵文字の提供を開始した*1。下図は、そのうちFB44(Shift-JISの16進数表記)の変更を示したもの。 この「ソフトバンクFB44」は、新旧のデザインで表情の違いが大きく、そのためauの絵文字に変換する際の対応も変更されたようだ*2。旧対応はauのF395[勝ち誇り]、新対応はauのF485[うっしっし]。 という知識を前提として、ケータイ絵文字のUnicode収録提案*3を見ると、ちょっと不思議なことになっている。 「ソフトバンクFB44」はU+1F39F経由でauのF395[勝ち誇り]に対応している(下図)。つまり、U+1F39Fのマッピングにおいては、新対応表ではなく、旧対応表のほうを参照しているようだ。しかしその一方で、U+1F39Fは明らかに「ソフトバンクFB44」の新デザインを参照している。マッピンクとデザインが一致しないのだ*4。
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く