「正字と略字」ネタ、ようやく(勝手に)納得。
ええと…2004JISネタ再びとゆー事で。
#たぶん今日で最後…のはず。
とりあえずは、 南堂久史さんの記述による「略字 侃侃諤諤（かんかんがくがく） 」にある「付録 （字形の変更について）」を拝読。
(「論点」と「Ｑ＆Ａ」は読む価値すらないような気が…とりあえずは一通り読んだ上で無視することに。)
南堂私案についての Ｑ＆Ａ、および案そのものについても読んでみました。
とりあえず引っ掛かったのは「タグ字」の「ルビ指定文字」かな…
たしかUnicodeでタグ字(正確にはルビ指定文字)が採用されそうになったときに、「タグ字が豆腐になると誤読される恐れがある」とかいう話になって、結局は却下になったはずなので。
その時のお題は「私は出羽内(ではない)」だった気が…月刊ASCIIで読んだ気がするものの、該当号は廃棄済みのため出典は不明。
個人的にはルビ文字だけは採用しない方が良いかと。
他のタグ字は…一応あっても害はない様なので、特に意見は無し。
(いや、こちらも「非対応環境で編集されるとまずい」から、ない方が良いかと…特に、欧文にタグ字を交ぜ書きする人がいると、かなりヤバそうです。逆にUnicodeでも等価採用されるならば、あった方が便利かも…とは思いますが)
他の文字については…“逆卍”、“ハーケンクロイツ”、“ダビデの星”が存在するならば、これらは「フォント側で潰す事を許容」としたうえで掲載する…とか明示する必要はありますね。
うーん…そもそも縮小コピー版な文字数に制限されている「JISXシリーズの漢字コード」を、そのまま他の(より文字数の大きな)規格と整合させつつ使うと言うこと自体が無理なのかもしれません。
ならば、規格にある例示図形のうち「略字しかないもの」は印刷物と同一に置換してしまって、コンバータを用いて「より大きな文字集合」へと変換する時点で「区別できないものは旧規格の字形と見なして変換」もしくは「区別できないものは印刷物の字形と見なして変換」と指定できるようにするほうが、技術的にはスッキリするのではないかと。
逆に、大きな文字集合から「JISXシリーズの漢字コード」へとコンバータで変換する場合には、「JISXシリーズで区別できない(包摂されている)文字があった時点で警告」し、「2004JIS(例示図形どおり)に変換」「2000JISに変換」「1990JISに変換」「1983JISに変換」「1978JISに変換」を選択させる(同じ字と見なされてしまう異字体については、包摂基準を用いて処置する)しかないでしょうね。
…結局は「文字コード側で対処」ではなく「コンバータ側で対処」するしかないと思う。そして、それは唯一確実に実現できる方法でもある…ということで。
#最近は多くのOS内部がUnicode化されているはずなので、OS側にはそもそもこの処理が入っているはずなんですよね…って、それを採用しているOSならば、JISX0208は考慮していない可能性が高いか。
「技術は人のため」とゆー言葉をはき違えてはいけない。
もちろん、この言葉を人に押しつけてもいけない。
…ならば、今するべき事は「DTPと印刷の整合性を確保すること」が一番重要なのではないかな、と。
「WYSIWYG(What You See Is What You Get;見たまま表示、見たまま印刷)」の確率を極限まで上げるには、「既にある印刷物(の多くで採用されている字体)に合わせる」がもっとも妥当な選択なのではないかと。
例示図形とコードが一対一で対応しているわけではなく、包摂範囲と文字コードが一対一で対応している以上、包摂範囲の異なる文字コード同士を「例示図形を見て一対一で対応させる」こと自体が、技術的に無理なのかも…と、そう思っています。
そもそも今回の問題は、
- 国語屋かつ国語審議会支持の人。
- 国語屋かつ略字支持の人。
- 技術屋で「図形とコードは一対一じゃないと許せない」という人。
が三つ巴になっている事が原因なんですよね…。
(私が拝見した限り、「正字正かな」支持の方は国語審議会側を支持しているように思いました)
で、南堂さんとこの言及では前2者についての言及があっても、後者(実装側)に対する適切な説明が見あたらないんですよ。唯一見つけたのは…これ(↓)だけかもorz
(4) データ処理について
この私案では、人名字のデータ処理を無視するわけではない。そもそも、人名字をすべて新ＪＩＳの枠内で扱うことは原理的に不可能（字数不足）なので、別の方法を使うことにする。新ＪＩＳの枠を越えて、unicode や ＴＲＯＮの利用を推奨する。あるいは、この私案の第７章で述べるタグ字による方法を使う。この方法なら、すべての人名字を扱うことができる。（ただし、扱いにくいのが難点。）
(from http://hp.vector.co.jp/authors/VA011700/moji/codesian.lzh )
この解答の元となる質問をぶつけた方は、たぶん「データ処理」ではなくて「文字コードの相互変換処理」の事について不安をお持ちだったのではないかと想像してみたわけですが…違うのかなぁ。
この前提に立つと、この解答は「見当はずれ」かと。
とゆーわけで(何がだ)、問題解決のために「コンバータ側で対処しましょうよ」という提案でした*1…コンバータを制作されている皆様に、本件方法について考慮頂けますと幸いです。
この記事には続きがあります。
下の方に「文字コード、その後」という記事があります。
興味がある方のみどーぞ。
