'nlck'テーブルの現状についてのまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
'nlck'タグが使用するテーブルには4種類のバージョンが存在し、このうちヒラギノProNや改定後のモリサワPr5フォントで用いられているものが最も新しい。今回は、このテーブルの動作についてまとめてみようと思う。 以下、ヒラギノProNおよび改定後のモリサワPr5フォントの'nlck'テーブルの置換対象を、5つのグループに分けて図示する。「表外漢字字体表における印刷標準字体欄の例示字形を参照しているグリフ」を「印刷標準グリフ」と呼び、図では水色地で示す。「簡易慣用グリフ」（ビンク地）、「備考欄グリフ」（黄色地）も同様。 JIS X 0213:2004で例示字形を変更された168文字のうち、「Adobe-Japan1では変更前・変更後の違いが区別されない8文字」および「印刷標準字体以外に関する変更1文字（芦）」を除いた159文字のグリフを置換（下図）。 JIS X 0213:2004で追加さ
OpenTypeフォント用のCMapの4つの系統 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Unicodeの符号位置とCIDの対応を定義したCMapのうち、Adobe-Japan1-5以降のものは以下のとおり。これらはhttp://examples.oreilly.de/english_examples/nutshell/cjkv/adobe/からダウンロードすることができる。 UniJIS-UTF8-H UniJIS-UTF8-V UniJIS-UTF16-H UniJIS-UTF16-V UniJIS-UTF32-H UniJIS-UTF32-V UniJIS2004-UTF8-H UniJIS2004-UTF8-V UniJIS2004-UTF16-H UniJIS2004-UTF16-V UniJIS2004-UTF32-H UniJIS2004-UTF32-V UniJISX0213-UTF32-H UniJISX0213-UTF32-V UniJISX02132004
そういや前にも触れていたけれども - 実験る～む
この間出したエントリに、n-yujiさんからコメントいただいたんですが、 けど、すべてを外部のCMapに依存させてしまえば、仕様の違うフォントなんか出す必要なかったんじゃないのか？っていう気がしてきます。 コメントだけにしようかと思ったんですが、少し余分めな情報と、以前に起こしたエントリも交えつつちょっと考察を。 CMapの存在を見落としがちなCIDフォント CIDフォントはCMapとセットで運用されることを主体に触れたものですが、そのデメリットについて触れてなかったので、改めて記載したいと思います。 一部、独りよがりな考えも混じってますが。 CMapは、入力された文字コード（Shift-JISまたはUnicode）に対して、どの字形（字形コード:CID）で出力するかを記述したマッピングリストです。 前述の通り、CIDは外部のCMapを利用して字形出力を行うわけですが、これにはいくつかの問
新常用漢字（仮）は、本当に2010年に答申可能か？ - もじのなまえ
どうも常用漢字ネタは荒れますね。いえ、たくさんのコメントをお寄せいただくのはうれしい限りなのです。しかしまあ答申まで最低2年あります、じっくりいきましょうよ。じつのところ、延びる可能性だってない訳じゃないのです。 ここでちょっと表外漢字字体表の当時を振り返ってみましょう。これは1993年11月の国語審議会の第20期開始から審議がはじまって、第22期が終わる2000年12月に答申されました。*1 足かけ7年にわたる審議の大きな流れは以下のとおりでした。 1993年11月……審議開始（第20期） 1995年11月……「一つの考え方として（略）康熙字典体を本則としつつ、略字体については原稿のJIS規格や新聞などで用いられているものに限って許容していくという方向も考えられる」という一文をふくむ審議経過報告を発表（第20期） 1998年7月……表外漢字字体表試案を発表、広く意見を募集（21期） 20
矛盾した警告だなあ - 実験る～む
「なんでやねんDTP」さんのところで「合成フォントにPr6N書体の使用はご法度！」というエントリが。 概要は「InDesign CS2の合成フォント機能にPr6（JIS2004版Adobe-Japanフォント）を使用すると、デフォルト字形変わってしまうぞ」というもの。 昨日コメントを寄せさせていただいたけれども、念のため自分でも、各バージョンによる挙動を確認してみたり。 実は昨日途中までやってたけど、睡魔に負けたのは内緒（ぉ ■Illustrator CS1:不可 CS2:不可 CS3:不可 ■InDesign CS1:不可 CS2:不可 CS3:可 てことで、InDesign CS3しか駄目です。あとは全部、JIS90字形に戻ってしまう結果に。 そのうえで、works014さんが推測されている以下のもの。 私の場合は、可能な場合「印刷標準字形」をデフォルトにしようと思っているところなので
やな推測だな - 実験る～む
てことで前回エントリの続き。 InDesignとIllustratorの合成フォント機能の挙動から、もしかしたら、なんて推測をはじき出しました。 まあ、裏は取れたんだけど、こういう時の推測が当たってしまうのはある意味嫌なもんです。まったくもって汎用性がないのがアレ。 これを行えるというべきかどうか、っていうのは別として。 実は前回、こんな推測をしてました。 合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている。 これは至極単純で、フォントに内包されたCMapを無視して出力されていることから推測したものです。で、思いっきりそれが当たってしまっていたという。 これの確認は非常に単純です。CMapの記述を直接触ればOK。 今回弄ったのは「C:\Program Files\Common Files\Adobe\Fonts\Reqrd\Cmaps」（Windows）にある、「Un
JIS X 0213とUCS-Unicodeとの対応について
JIS X 0213からUCS/Unicodeへの変換 JIS X 0213:2004に規定されたもののうち、以下の25個の面区点位置はUCS/Unicodeにすでに収録済み(2文字からなる文字列で表すべきもの)であるため、UCS/Unicodeの一符号位置に対応づけることができません。このため、JIS X 0213:2004では、これらの面区点位置を2つの符号位置からなるUCS列に対応付けるよう規定しています(附属書4)。これは、UCS/Unicodeとの国際的な整合性の上に立てば、このとおり変換すべきと考えられます。 JIS X 0213 UCS/Unicode # [informal name for USI (cf. JIS X 0213:2004, 5.3, note 1)] 1-04-87 <304B, 309A> # [HIRAGANA LETTER BIDAKUON NGA
PDF 千夜一夜: 2007年01月24日「日本語の文字についての用語について_10」
日本語の文字についての用語について(10) — 文字コードと漢字の字形 日本語における漢字の字形と文字コードの関係について、とりあえず、まとめて見ます。 UnicodeやJIS X0213のような、文字コードの規格は、コンピュータで日本語を処理するために漢字を含む文字に符号を与えた、漢字を抽象化した存在であるということです。 それに対して、現在のコンピュータの画面や印刷される漢字は、フォント技術を使って可視化した具体的なものです。Adobe-Japan１のような文字を集めたものは、フォントの開発用のものであって抽象化した文字集合ではないと思います。 漢字は、ラテンアルファベットとは違って、1文字＝1単語という意味合いが強いもので、その成り立ちからしても、形が単語の意味に密接に関係しています。しかし、抽象化した文字コードと具体的な字体を同列に論じることはあまり意味がないと思えます。 コンピュ
PDF 千夜一夜: 2007年01月21日「日本語の文字についての用語について_08」
日本語の文字についての用語について(8) — 文字コードとフォント 次に、OpenTypeなどのフォントを使う場合において、文字コードと実際に表示される文字の形状との関係について考えてみたいと思います。 コンピュータ間で、通常、交換したり処理するデータは文字コードであって、文字の形ではありません。画面に表示したり、印刷する文字の形を表すためのデータは、フォントファイルに含まれています。 例えば、アウトラインフォントで文字を表示する仕組みについては、 2006年04月24日PDFとフォント(15) アウトラインフォント などでお話しました。 アウトラインフォントで文字の形を現すためのデータは、グリフデータと言いますが、フォントファイルの中には多数の文字のグリフデータが収容されています。そして、各文字を表示するためのグリフデータには、識別番号がついています。OpenTypeフォントでは、これを
PDF 千夜一夜: 2007年01月20日「日本語の文字についての用語について_07」
日本語の文字についての用語について(7) — Adobe-Japan1の用語 Adobe-Japan1では、CIDは、文字形状の種別に対して付けられている、と説明されています。しかし、実際には、そうではなく、次のようにまったく同じ字形の文字に対して、別のCIDが割り当てられています。 これは、歴史的な要因、およびJIS90規格との互換性を維持するためと説明されています。 また、Adobe-Japan１では、他にも微妙な字形差のグリフが別のCIDで登録されているケースがあります。 例えば、安岡孝一氏が作成した「Adobe-Japan1の漢字(部首画数順)」を見ますと、次の図のようにまったく同じグリフと思われるものが別のCIDになっているものが頻繁に見つかります。 ※上図は「Adobe-Japan1の漢字(部首画数順)」より加工 http://coe21.zinbun.kyoto-u.ac.j
PDF 千夜一夜: 2007年01月19日「日本語の文字についての用語について_06」
日本語の文字についての用語について(6) — Adobe-Japan1の用語 Adobe-Japan１については、丁度１年ほど前にも取り上げました。その概要は、前回の記事をご覧いただきたいと思います。 PDFと文字 (23) – Adobe-Japan1 Adobe-Japan１の資料は英語版ですが、その文書で使われている用語をチェックしてみましょう。 仕様書の中から、用語に関連しそうな部分をピックアップしてみます。 ○A character collection contains all gryphs required to make fonts for a particular language.（ひとつの文字の収集には、ある言語のためのフォントを作るのに必要なグリフの全てを含んでいる。） ○Each CID (Character ID) in a character collecti
参考資料 - CyberLibrarian
図書館員のコンピュータ基礎講座 TOP 参考資料 基礎情報 2進数、16進数と10進数 情報の単位 論理演算 数詞 ローマ数字 年月の表現 西暦・和暦対照表 暦の年月と季節 暦注 月の大小 紙の寸法 人名 文字、文字コード Unicode JIS X 0208コード表 JIS X 0212コード表 JIS X 0213コード表 JIS83制定時の変更点 JIS90制定時の変更点 JIS補助漢字および拡張漢字で復活した字体 JIS2004制定時の変更点 JIS X 0208およびJIS X 0213の字形・字体の変更点 JIS包摂規準 新旧字体表 常用漢字表 人名用漢字 文字 > ラテン文字 | ラテン特殊文字 | キリル文字 | ギリシア文字 | アラビア文字 書字方向 ローマ字 点字表 URIで使用できる文字 文字サイズ GB 2312-80コード表 Big5-1984コード表 KS X
今年度最後の漢字小委員会が開催 - もじのなまえ
9日は新装なった文部科学省の庁舎で、第20回漢字小委員会が開催されました。この日の審議の大きな目玉は、上部組織である国語分科会総会に提出する『国語分科会漢字小委員会における審議について』をめぐる議論。これは今年度の審議内容をまとめた文書で、つまりこの日のテーマは今年度の総括ということです。 これについては、すでにいくつか報道されていますね。 鹿、奈、岡……常用漢字にやっと仲間入り・2010年刷新で（日本経済新聞） なぜ無かった？都道府県名の１１字、常用漢字に（MSN産経ニュース） いずれも2010年2月に答申を予定されている新常用漢字表（仮称）に新しく入るであろう漢字にスポットをあてた記事です。べつに内容は間違ってません。広範な読者に向けた一般紙としては耳目を集めやすい切り口を工夫するのは当然でしょう。しかし傍聴を続けてきた者としては、あまりその部分だけを取り出すのはミスリードを誘うように
U+29FCEとU+29FD7の混乱 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
「ヒラギノProNにおけるCIDと符号位置の1対nマッピング」でも触れた「両方とも統合漢字なのにCIDと符号位置が1対2マッピング」のU+29FCE、U+29FD7について、気になったので少し調べてまとめてみた。ただし、あまりまとまっていない。 JIS X 0213のドラフトおよびUCSへの文字追加提案では、2-94-5は下図ピンク地の形（「了」形）だった。ISO/IEC 10646-2のドラフトには、この2-94-5を単独ソースとして29FCE（「了」形）が入った（実際には、ドラフトの段階の符号位置は規格票と同じではないが、ここでは話をシンプルにするために規格票発行後の符号位置に表記を統一する）。 JIS X 0213:2000の規格票では、2-94-5は上図水色地の形（「予」形）に変更された。ISO/IEC 10646-2のドラフトでは、この「予」形は別の符号位置29FD7に入っていた
ヒラギノProNにおけるCIDと符号位置の1対nマッピング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
UnicodeとCIDでは、一般にCIDのほうが細かい区別が可能だが、逆にCIDではUnicodeにおける区別が消える例も存在する。Unicodeでは、見た目で区別がつかない文字であっても、属性の違いによって区別して収録されている場合があるのに対して、Adobe-Japan1では、基本的に形でしか区別されないからである。 たとえばU+0060 GRAVE ACCENTとU+0300 COMBINING GRAVE ACCENTは、いずれも単独ではCID=65で描画されるが、アルファベットの母音の後ろに置いた場合の振る舞い（結合属性）が異なる（下図）。 このようなUnicodeの符号位置とCIDの1対n対応について、利用者は通常意識する必要がない。しかし、InDesignの字形パレットのようなCIDベースの入力ツールでは、1つのCIDに対応する複数の符号位置のうち、いずれか1つ（CID=65
IVDのダブリ | yasuokaの日記 | スラド
Ideographic Variation Databaseの2007年12月14日版をチェックしていたところ、Adobe-Japan1のCID+13912がダブって収録されているのに気づいた。「U+9039 U+E0101」と「U+9054 U+E0101」の2個所にある。これ、たぶんU+9054の方が正しいんだけど、どうしてダブってるんだろ? あと、ざっと見てみたところ、CID+13383が「U+4F75 U+E0101」ってのは正直、気に入らない。やっぱり「U+5002 U+E0101」でしょ。同様にCID+8436、CID+13356、CID+13989、CID+13725、CID+13370なんかも、それぞれU+5BEC、U+613C、U+665A、U+9115、U+93ADに移したいところだ。とりあえずKen Lundeには連絡しておくけど、移したらマズイ事情でもあるのかしら?
ヒラギノProとProNの違い・その2 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ヒラギノProNは、一言で言えば'jp04'グリフをデフォルトとしたフォントであり、そういう意味でのヒラギノProとの違いは、「ヒラギノProとProNの違い」にまとめたとおりだが、それ以外にも若干の違いがある。 Unicodeの符号位置とCIDの対応を定義したマッピング・テーブルは、Adobe-Japan1-5が策定された後にも何度か改定されている。ヒラギノPro内部のcmapテーブルがMac OS X 10.2.4以降「据置き」であるのに対して、ヒラギノProNはより新しいテーブルを採用している。 下図は、ヒラギノProNでマッピングが変更された例。ヒラギノProではU+02C0に対応しているCID=15897が、ヒラギノProNではU+02C1に対応している。 下図は、ヒラギノProNでマッピングが追加された例。InDesignでこれらの符号位置の文字を選択し、ヒラギノProNからヒ
InDesignにおける引用符の謎の挙動についての文字コード的なまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
引用符が全角かプロポーショナルかは、フォントによって異なる。Adobe-Japan1-5以降のCMapを採用しているフォントなら（レパートリはAdobe-Japan1-5でなくても）プロポーショナル、そうでなければ全角である。下図のリュウミンでは、Proが全角、Pr5がプロポーショナル。グレー地は文字幅、枠の下の数字はCIDを示す。 InDesignで引用符を縦組みにすると、全角のものは縦用グリフに置換されるが、プロポーショナルのものは置換されず、回転もしない。以下の図では、H：横組み＝グレー地、V：縦組み＝水色地とする。また、InDesignの設定はすべて「文字組み：なし」「CIDベースの文字組みを使用：オン」。 引用符はUnicodeでU+2018、U+2019、U+201C、U+201Dだが、InDesignは縦組みの際、これらを全角（和文属性）の文字だと想定して（古いCMapを想定
第十回 XML開発者の日に行ってきた。 - Clash Cymbal Concerto
今年も行ってきたでよ。 村田さんあいさつ XMLが97? 98年に勧告になって10年で10回くらい 今回もdeepな話でみんな楽しみにしてるでしょう。 昼休みにたべるところは近くに何箇所かあります。 発表中の突っ込み歓迎 2番目の発表者は面の皮が厚いのでぎったぎったにしてあげてください。 源氏物語の世界 再編集版 by 宮脇文経さん 村田さんによる紹介 思い入れは今回の発表の中で一番強いのでは? 元は趣味で作成していたもの。 コンテンツの拡張をしようとして、IPAに提案した後でXMLでやろうと決めた。 オリジナル by 渋谷栄一教授（高千穂大学） V2：XML V3：XML 採択の経緯 元の提案はコンテンツの整備だったけど、却下された。 PMに興味を持ってもらえて、「〜なプログラムとデータ構造」に限定し、調査費として採択してもらえた。 既存コンテンツとのタイアップとか、ボランティアの活用と
PDF 千夜一夜: Adobe-Japan1-6をUnicodeのUTS 37 Ideographic Variation Databaseに登録
第10回 XML開発者の日(1) 21日は第10回XML開発者の日。去年より１ヶ月ほど遅く、暮れの押し迫った季節で忙しかったのですが、1日参加してきました。（来年は、もう少し早めに開催してほしいな）。 プログラム：http://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu10.html 今回は、どうもジャストシステムのプレゼンテーション・デイのようで、半分位xfyとジャストの技術・製品の宣伝だったように思います。 昨年は、宮川さんのPlaggerのプレゼンなどがあって盛り上がりました。今年は、それに比べて、やや目新しさに掛けたようですが、XML技術というのは、それ自体として色々な技術的な挑戦とそれを使った新しい応用があってとても面白いものだと思います。少なくとも文字コードなどよりは面白いでしょう。 で、面白くない方の文字コード関係では、アドビの山本さんによる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
