[CID]Adobe-Japan1-UCS2 - [FORCE]
Adobe Open Sourceの プロジェクトのひとつの Mapping Resources for PDF Downloadsコーナーにある Mapping Resources for PDF ToUnicode Mapping Resources 『Adobe-Japan1-UCS2』が含まれています。 全19000行以上におよぶ GIDとUNICODE値をひもづけるファイルです。 異体字とかも紐付きが確認できます。 が 今日ちょっとビックリしたのが おおおっ合わないじゃん ああぁ〜めんどうだなぁもう LucidaGrande HelveticaNeue ですよねぇやっぱりそうでないと UD新ゴ こうでないいと PDFの中に サブセットで埋め込まれるときに GIDとユニコードは PDF内で紐付くので まぁ大丈夫なんですけど嫌だなぁこうゆうの もう オープンタイプだけでいいやもう 面
![[CID]Adobe-Japan1-UCS2 - [FORCE]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0f319bcb5b58dd128aace9778d70958abb01febf/height=288;version=1;width=512/https%3A%2F%2Fforce4u.cocolog-nifty.com%2Fskywalker%2Fimages%2F2010%2F11%2F30%2Fim00221130_124457.png)
IVD更新 - yanok.net
最近、Unicodeのいわゆる異体字セレクタの新しいグリフコレクションが登録されました。今までは、Adobe-Japan1というコレクションが登録されていたのですが、今回それに加えて汎用電子と呼ばれる日本の政府関係から提案されていたコレクションが追加されました。追加されたコレクションは、異体字データベース (Ideographic Variation Database; IVD) に累積的に追加されています。 IVDの文字表をちょっと見ると分かることですが、Adobe-Japan1と汎用電子とで、どう見ても同じようなグリフに対して別々のIVS (Ideographic Variation Sequence; IVS) が割り当てられています。例えば、「与」(U+4E0E)を見ると、Adobe-Japan1は長い横線の突き出ているグリフと突き出ていないグリフとにそれぞれ別のIVSを割り当てて
[Font]Unicode BMP Fallback SIL - [FORCE]
PDFlibに付属の 解析用にとても便利なフォントです。 fallback.ttf Unicode BMP Fallback SIL ダウンロードはこちらから ↓はパール版ですが フォントの場所は ここね フォントパネルで見ると こんな感じ ユニコード値 だけののフォントなんです。 時々使います。 困った時に...笑 スペースの種類なんかもわかります。 異体字には対応していないので 異体字に変換した文字列に フォントを変更するとダメなんだけれどもね ---追記（上記記事の内容の訂正） Unicode BMP Fallback Fontは SIL Internationalで公開しているフォントでした。 ちなみにPDFlibに同封されているのが バージョン4.1で SILで公開しているのが バージョン5.1ですので Fallbackフォントを使う人は SIL版を使った方が良いかもしれません。
![[Font]Unicode BMP Fallback SIL - [FORCE]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4f1839000a45608222a04ec2277221831548503d/height=288;version=1;width=512/https%3A%2F%2Fforce4u.cocolog-nifty.com%2Fskywalker%2Fimages%2F2010%2F10%2F06%2Fforce4u00221006_110247.png)
Unicode正規化 – ものかの
コンテンツへスキップ 以前書いたものです。旧サイトへのリンクを貼っておきます。 Unicode正規化 その１ Unicode正規化 その２ Unicode正規化 その３ Unicode正規化 その４ Unicode正規化 その５
sed・grepで濁点と改行をまともに扱う方法 - ザリガニが見ていた...。
前回、Automatorの「シェルスクリプトを実行」アクションに以下のスクリプトを設定して喜んでいた。 #sed 's/^/-/g' # 行頭に-を付加する #sed 's/$/-/g' # 行末に-を付加する #sed 's/\(xxxx\)/[\1]/g' # xxxxを[]で囲う #sed 's/xxxx/oooo/g' # xxxxをooooに置き換える 必要なコマンドラインのコメントマーク#を削除して、便利に使うつもりでいた。 さらに、これは便利と思い、気を良くしてgrepバージョンも作って喜んでいた。 grep -i 'xxxx' #-i 大文字と小文字を区別しない #-v パターンに一致しない行を表示する #-n パターンに一致した行のファイル内での行番号を表示する #-c パターンに一致した行の行数のみを出力する #-b パターンに一致した行の先頭からのバイト数を表示する
untitled
Adobe-Japan1-6 Unicode — : Unicode Adobe-Japan1-6 Adobe Systems : PDF CID OpenType/CFF Adobe-Japan1-6 vs. Unicode — Character codes in Japan Koichi Yasuoka Author Abstract: In Japan we use so many kanji variants to describe the names of people and the names of places. Since proper nouns are out of the scope of Joyo-Kanji (daily use kanji characters in Japan), the kanji glyphs used in Jinmei-yo-Kan
The results from a 7.5-year experiment are in: Unicode and OpenType are successes!
CJK Type Blog CJK Fonts, Character Sets & Encodings. All CJK. #AllOfTheTime. HOME > The results from a 7.5-year experiment are in: Unicode and OpenType are successes! 和文 中文 Dr. Ken Lunde Approximately 7.5 years ago — at the end of 2002 — I commissioned the suite of Unicode CMap resources for Adobe-Japan1-x (it was Adobe-Japan1-5 at that time, and Adobe-Japan1-6 was finalized less than two years la
「文字コード技術入門」制作で直面した文字コード問題 - yanok.net
本書 (「プログラマのための文字コード技術入門」)の原稿はコンピュータ上でテキストエディタを使って書いています。そうすると、文字コード値の羅列として文を表現することになります。 本書には、「ト゚」や「か゚」のようにUnicodeで合成の必要な文字や「𩸽」のようなBMP外の符号位置にある文字、あるいは「海」のようにUnicodeの正規化処理で別の符号位置に置き換わってしまう文字などがふんだんに盛り込まれています。 このため、本書の執筆・編集において、まさに文字コードの問題に直面することになりました。 私が執筆に使っているのはEmacs 22です。このエディタでは、テキストをEUC-JIS-2004 (Emacsのcoding system名としてはeuc-jisx0213)として保存している分にはいいのですが、UTF-8として保存しようとすると、「か゚」のように結合文字を使う文字については
Perl5.8 の UNICODE 対応
perl は 5.8 から Unicode(utf-8) がサポートされました．5.6 でも Unicode に対応はしていましたが，ぜんぜん使い物にならず，ようやく 5.8 でまともに使えるようになったということです．ただせっかく使えるにもかか わらず perldoc などを見てもイマイチ使い方がわからないので，独自にまと めてみたのがこのページです． 誤った書き方や勘違いをしてい ることもあるので，形式的ですがこのページの内容は無保証です． 内容 文字コード変換 perlIO jperlからの移行 UTF-8フラグ 文字コード自動判別 Unicode Standard Unicode 正規化 その他 参考資料 文字コード変換 とりあえず perl5.8 で新しく組み込まれた機能を見るために，euc-jp から shift_jis への変換スクリプトをいくつか載せます． openを利用し
なぜUnicodeには分数の「0/3」が入っているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Adobe-Japan1の分数は（特にUnicodeとの関係において）けっこうぐしゃぐしゃなので、ちょっと整理してみよう。下図は、横棒を使う分数のリスト*1。Proフォントでは「分数（afrc）」フィーチャで用いられる。分母が2から12までの約分できない真分数と「0/3」と「1/100」。 上図と同じ字種について、数字を斜めに配置するグリフも用意されている（下図）。これらはProフォントでは「スラッシュを用いる分数（frac）」フィーチャで用いられる*2。 上図のグリフはすべて全角だが、斜めに配置する分数の一部には、プロポーショナル・グリフも用意されている（下図）。 下図は、Unicodeに含まれる分数を、Mac OS Xの文字ビューアからInDesignに入力したもの。Adobe-Japan1ではプロポーショナル（黄色地）優先のマッピングであるため、「2/5」などの全角グリフ（グレー地）
Regex Tutorial - Unicode Characters and Properties
Unicode is a character set that aims to define all characters and glyphs from all human languages, living and dead. With more and more software being required to support multiple languages, or even just any language, Unicode has been strongly gaining popularity in recent years. Using different character sets for different languages is simply too cumbersome for programmers and users. Unfortunately,
unicode range generator
UNICODE RANGE GENERATOR unicode range generator for embeding fonts to flash flex by actionscript. Select range from checkbox or input directly and press 'generate' to output unicode Range. Actionscript開発用のunicodeRangeを生成します。埋め込み範囲をチェックボックスで選択、あるいはテキストフィールドに入力後'generate'を押して生成します。 Language Range
ものかの：Photoshop CS2 同じフォルダに同一名称のファイルがある事態になると、保存操作時に断りもなく勝手にファイルを削除してしまう
InDesignは2019（v14）からメジャーバージョンアップ時にBoost.Regexも更新するようにしたようで、正規表現のUnicodeバージョンも更新されるようになりました。 CC 2018（v13）まで Unicode 5.1 CC 2019（v14） Unicode 9.0 2020（v15） Unicode 12.0 2021（v16） Unicode 13.0 2022（v17） Unicode 13.0 2023（v18） Unicode 14.0 2024（v19） Unicode 15.0, 15.1 正規表現のUnicodeバージョンの調べ方 Unicodeのバージョンにとくに影響するのは、\dや\sといった略記法です。InDesignの「\d」はUnicodeカテゴリーの「Nd」に相当するので、各UnicodeバージョンのNd文字をinddに並べて、\dでマッチす
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
絵文字が開いてしまった「パンドラの箱」第2回--Googleの開けてしまった箱の中味
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Unicode]PDF一覧 - [FORCE]
Unicode CJK互換漢字 F900～FAFF - CyberLibrarian
Unicode Terminology: English - Japanese