コメント: 作りそこないならまだいいんですが (スコア 1) 1
デザイン統一基準とやらの92番で「統一」されちゃったんじゃないですか。文字情報基盤の文字情報一覧表では、TK01094560があるべき位置(MJ027257)は欠番になっていますね。なんでIVDへ別々にSubmissionされたのかは知りませんが、Submissionの段階ですでに区別が不明で取り下げもされずレビューが終了したようですから、Unicode Consortiumとしてはそのまま受理するしかないですよね。
Idle.slashdot.jpは、あなたの人生において完全な時間の浪費です。見るなよ、見るなよ。
コメント: Re:MIKO GNYO/Linux はもう少し新しいかも (スコア 1) 128
少なくともMIKO GNYOが頒布されていた昨年末のコミケ81はストーリーになっていましたが。
http://slashdot.jp/story/11/12/28/1024244/
コメント: 朝日新聞ェ… (スコア 1) 1
・毎秒100メガバイトと毎秒1ギガバイトはそれぞれ毎秒100メガビットと毎秒1ギガビットの誤り。8倍速度が違う。
・定義された用語はIMTアドバンストであり、4Gではない。4GはITUでは未定義のままだが、LTE(アドバンストではない)・HSPA+・WiMaxなどIMTアドバンストの前身を指す用語として使われつつある、と言及しているだけ。4GがIMTアドバンストそのものであるとは言っていない。
ソース: http://www.itu.int/net/newsroom/wrc/2012/reports/imt_advanced.aspx
サモア、12月30日を飛ばして12月31日に
タレコミ by headless
headless 曰く、
南太平洋の国、サモアはタイムゾーンを日付変更線の西側、これまでのUTC-11からUTC+13に変更した。これにより、12月29日の翌日が12月31日となった。これにあわせてニュージーランド領のトケラウもタイムゾーンを変更している (Herald Sunの記事、 本家/.)。
サモアの首都アピアでは12月29日の深夜、時計塔の周りに多くの人が集まったとのこと。時計が0時を指すと同時に日付は12月31日となり、打ち上げ花火などで歴史的なタイムゾーン変更を祝った。サモアでは現在夏時間のため、時刻はUTC+14となる。そのため、世界で最初に新年を迎える国にもなった。
このタイムゾーン変更は、オーストラリアやニュージーランドとのビジネスが重要度を増したことによるもの。サモアは日付が1日近く遅れていたため、月曜日と金曜日がつぶれていたが、今後はスムーズな取引が行えるようになるとのこと。
コメント: 抽象代数学では (スコア 1) 2
通常加群は交換法則が成り立つもの、乗法群は成り立つとは限らないものと定義されることが何か関係あるのかもしれません。
どうしてそういう定義になっているのかは知りません。歴史的な理由があるのでしょうか。
もっとも関係あるとしても、算数教育に持ち込むのはどうかしているとしか思えませんが。
コメント: Re:補足 (スコア 1) 4
この日記は今日発見したのですが、まったく同じ疑問を独立に抱いたので、当該日記エントリで質問していました。
http://d.hatena.ne.jp/ockeghem/20111109#c1322192984
「絶対に」というのは初心者向けの方便のようなものらしいです。「goto文は絶対に使うな」みたいな。
コメント: ジェダイの帰還 (スコア 1) 31
ジェダイは復讐しない! とか?
コメント: 光は (スコア 1) 1
同じ条件でイタリアまで地中を突き抜けて進んだりできません。
コメント: Re:N1698が提出された時点ならともかく (スコア 1) 3
> 互換分解マッピング
「互換漢字の分解マッピング」に訂正
コメント: N1698が提出された時点ならともかく (スコア 1) 3
今さらU+FA20を互換漢字から統合漢字に変更するのはstablility policy的に無茶な気がします。U+FA20と同じ字形を統合漢字として新たに追加提案するほうがまだ見込みがありそうです。Unicode 3.2以降に互換分解マッピングを訂正した前例もあるにはありますが、Unicode 6.1では訂正しないで互換漢字の追加で対処するみたいですし。
> IVSの基底文字に互換漢字を許してしまう
許されても分解マッピングが訂正されない限りU+FA20 U+E0100の正準分解はU+8612 U+E0100になってしまうので、ちっとも嬉しくないです。
「互換漢字を基底文字にしても構わないが選択されうる字形は正準分解後のIVSと常に同じで、独立して登録することはできない」ならアリかも。U+8612 U+E0100とU+FA20 U+E0101とか書けるようになるので。
コメント: 住基のB0FCと5EFAが割り当てられているので (スコア 1) 3
正式版ではそれらを作り分けることになってるんじゃありませんでしたっけ?
コメント: えー (スコア 1) 2
「U+6B21 U+E0103」に対し、現状の平成明朝JA2801グリフに加えて、戸籍統一文字181670のグリフを追加
むしろ個人的にはぜひやっていただきたいのですが。MJ014749をU+6B21 U+E0103で符号化できることも明確になりますし(安岡先生がそれにも反対なのは存じていますが)。
「U+FA20 U+E0100」
わかってて言っているのでしょうけど、互換漢字はそもそもIVSのbase characterになれませんからこっちは無茶だと思います。互換漢字もとうとうマルチカラムになってしまいましたから字形を選択できないと困りそうな気はしますけど。
コメント: Firefoxのfallback (スコア 1) 2
そうなんですよ。Firefoxでは
- 最初のフォントから「U+559D U+E0101」を探す。なければ
- 2番目のフォントから「U+559D U+E0101」を探す。なければ
- 3番目のフォントから「U+559D U+E0101」を探す。なければ
- 最初のフォントから「U+559D」を探す。なければ
- 2番目のフォントから「U+559D」を探す。なければ
- 3番目のフォントから「U+559D」を探す。なければあきらめる。
というfallbackにしたかったんですけど、レビュアーに却下されて
- 最初のフォントから「U+559D U+E0101」を探す。なければ
- 最初のフォントから「U+559D」を探す。なければ
- 2番目のフォントから「U+559D U+E0101」を探す。なければ
- 2番目のフォントから「U+559D」を探す。なければ
- 3番目のフォントから「U+559D U+E0101」を探す。なければ
- 3番目のフォントから「U+559D」を探す。なければあきらめる。
という順序になってしまいました。だから「font-family: "MS PMincho", KozMinPr6N-Regular, IPAmjMincho」とか指定するとMS明朝に含まれている漢字についてはIVSがまったく使えませんし、Adobe-Japan1と汎用電子の両方を実装したフォントがないと両方を混在して使うこともできないんです。
コメント: 訂正 (スコア 1) 36
> IVDをすべて含んだ
汎用電子のことを失念していました。「IVDのAdobe-Japan1コレクションの文字をすべて含んだ」です。
5万字を越える多漢字Unicodeフォントのリリースが相次ぐ 36
タレコミ by emk
emk 曰く、
/.Jでもたびたび取り上げてきたフリーな日本語漢字フォントの花園明朝が、5月16日リリース版でついに現時点でUnicodeに収録されているすべてのCJK統合漢字・互換漢字に対応した。TrueTypeフォントには1ファイルにグリフを65,535個までしか含められないという制限があるため、このバージョンからBMPの全文字+JIS X 0213:2004の文字+IVDをすべて含んだ花園明朝Aと、Unicodeの2面(SIP)の漢字をすべて含んだ花園明朝Bに分割されている。ライセンスは独自のフリーライセンスとSIL OFLのデュアルライセンス。
一方、経産省が昨年から公募していた文字情報基盤構築に関する研究開発事業の成果物として、IPAmj明朝(検証版)が5月18日に公開された(Impress Watch)。こちらは日本の戸籍行政などで必要とされる文字を収集しているという性質上、Unicodeの漢字を完全収録しているわけではない一方、現時点のUnicodeで符号化できない文字7,000字以上を外字として収録している。あくまでも検証版であり、収録されている文字のグリフや符号の割り当ては今後変更される可能性がある(つまりIPAmj明朝の文字を前提に電子化した文書は今後のバージョンアップで文字化けの可能性がある)ことに注意されたい。問題点の具体例は委員として参加していた安岡先生の日記を参照のこと。ライセンスはIPAフォントライセンスv1.0。
これらのフォントが収録している文字を完全に活用するには、UnicodeのBMP外文字やIVSに対応したOSとアプリケーションが必要。