一昨昨日の日記に関連して、アイヌ語の「イワイサルㇱペ」を調べていたところ、B・ピウスツキ『樺太アイヌの言語と民話についての研究資料<26>病弱な者でも有能な憑き神によって開運する由来話』(創造の世界, 第77号 (1991年2月), pp.138-145)に、以下の文章を見つけた(p.140)。 ネヤイケヘ         そうしたら(ちょうど、そこへ) アンポニウネ       ぼくの年下の ホㇱキラムフ       兄さんが キラアニエㇸマヌ   逃げてやってきた。 オーポニ           (よく見ると)その後を イワイサルㇱカムイ 六尾をもつ神(という魔性のオオカミ)が アンホㇱキラムフ   ぼくの兄さんを ノㇱパ             追いかけていた。 アノㇱキラムフ     ぼくの兄さんを アネソㇹキ         ぼくは(わきに手早く)よけ(てやり過ごし)た。(夢中に

私(安岡孝一)の9月19日・20日・25日の日記の読者から、的場光昭『現代語で読む蝦夷島奇観』(展転社、2021年4月)を読んでみてほしい、との御連絡をいただいた。読んでみたのだが、言語に対する妄想が書き連ねられていて、正直なところワケが分からなかった。たとえば、38ページ。 また言語の基本構造である語順については、S(主語)、動詞又は述語(V)、目的語(O)の語順によって、なじみの深い英語や中国語など多くの言語では、 S+V+Oが基本である。日本語ではS+O+Vが基本である。 現代アイヌ語学習ではどのような教育をしているかは知らないが、一八〇〇年当時からアイヌ語は、S+V+Oとなっている。 ワケが分からない。語順が問題になるのは孤立語の場合で、英語がSVOなのは屈折語の中でも独特だったりする。ましてやアイヌ語は、人称接辞が動詞の前後に付くタイプの言語なので、人称接辞が付きやすい場所(たと

『キーボード配列 QWERTYの謎』の読者から、ラジオ関西トピックスの記事『なぜこの並び？　パソコンのキーボード　開発者「タイプライター時代の名残です」』(2023年8月21日)を読んでみてほしい、との御連絡をいただいた。 このクワーティ配列は、使う頻度が高い母音などを離れた位置に配置した“あえて入力しづらい”並べ方なのだといいます。その理由は、18世紀ごろから欧米を中心に文字を紙に印字するために使われてきた「タイプライター」を参考にしているからだと考えられているそうです。

法務省は、戸籍に使われている文字を全て戸籍統一文字に追加すると同時に、ISO/IEC 10646 (UCS)への追加提案をもおこなうことを決めた。UCSへの追加提案をおこなう漢字は、戸籍統一文字555650・558160・559970や登記統一文字01020750・01048110など。なお、世界最先端IT国家創造宣言において

一昨日の日記の続きだが、ku-nlp/deberta-v2-base-japaneseのトークナイザは、常用漢字表2136字のうち「楷」「憬」「錮」「𠮟」「朕」「塡」「剝」「頰」「慄」「厘」の10字をサポートしていない。これらの文字は未定義語になってしまうため、[UNK]に化けてしまう。最新のtransformersで試してみよう。 $ pip3 install -U transformers fugashi $ python3 >>> from transformers import AutoTokenizer >>> tkz=AutoTokenizer.from_pretrained("ku-nlp/deberta-v2-base-japanese") >>> for t in ["楷書","憧憬","禁錮","𠮟責","朕","装塡","剝製","頰","慄然","一分一厘"]:

1月26日の日記で引用した『ウアイヌコㇿ コタン アカㇻ』の挨拶文を、esuparの助けを借りつつ、手作業でUniversal Depedencies化してみた。 # text = イランカラㇷ゚テ。 1    イランカラㇷ゚テ    irankarapte    INTJ    間投詞    _    0    root    _    SpaceAfter=No 2    。    .    PUNCT    記号    _    1    punct    _    _ # text = ウアイヌコㇿ コタン オルン シネウパ ウタㇻ、 エチコプンテㇰ ナ。 1    ウアイヌコㇿ    uwaynukor    VERB    他動詞    _    2    amod    _    _ 2    コタン    kotan    NOUN    名詞    _    3    n

国立アイヌ民族博物館第3回テーマ展示『ウアイヌコㇿ コタン アカㇻ』を見に来た。最初の挨拶文が非常に印象的だったので、ここに引用しておくことにする。 イランカラㇷ゚テ。 ウアイヌコㇿ コタン オルン シネウパ ウタㇻ、 エチコプンテㇰ ナ。 アヌココㇿ アイヌ イコロマケンル 第3回テーマ展示 『ウアイヌコㇿ コタン アカㇻ ―民族共生象徴空間(ウポポイ)のことばと歴史―』 セコㇿ チレコ ワ オロ タ エチエカノㇰ。 2020パ 7チュㇷ゚ 12ト ワノ アイヌ プリ カンナ アシトゥリレ クニネ ウアイヌコㇿ コタン アン。 タン コタン オルン アイヌ ウタㇻ カ シサㇺ ウタㇻ カ レプンクㇽ ウタㇻ カ シネウパ。 アイヌ プリ エヤイパカㇱヌ。 “ウポポイ” アナㇰネ ウアイヌコㇿ コタン ポンレ ネ。 タン トゥンプ オッタ “ウアイヌコㇿ コタン ヘマンタ クス アカㇻ ル

大学入学共通テスト初日の「国語」第4問(漢文)は『白氏文集』が出題された。【予想問題】と【模擬答案】をUniversal Dependenciesで見てみよう。 # 【予想問題】 # text = 問 1    問    問    VERB    v,動詞,行為,伝達    _    0    root    _    Gloss=ask|SpaceAfter=No # text = 自古以来 1    自    自    ADP    v,前置詞,経由,*    _    2    case    _    Gloss=from|SpaceAfter=No 2    古    古    NOUN    n,名詞,時,*    Case=Tem    4    obl:tmod    _    Gloss=olden-times|SpaceAfter=No 3    以    以    V

思うところあって、国語研長単位係り受け解析モデルroberta-base-japanese-aozora-ud-goeswithを作ってみた。Google Colaboratoryで動かしてみよう。 !pip install transformers ufal.chu_liu_edmonds deplacy class UDgoeswith(object): def __init__(self,bert): from transformers import AutoTokenizer,AutoModelForTokenClassification self.tokenizer=AutoTokenizer.from_pretrained(bert) self.model=AutoModelForTokenClassification.from_pretrained(bert) def __c

昨日発表されたIPAmj明朝フォントの正式版を、ざっとチェックしてみた。とりあえず、以前に指摘した「えんにょう」の問題は、だいたい解決しており、たとえばMJ011110とMJ011111は、ちゃんと起筆(筆押さえ)の有無で見分けがつくようになっている。 だとすると、MJ035473の「えんにょう」に起筆がないのは、正直いただけない。というのも、この字のもととなった住基統一文字AAE3でも戸籍統一文字108220でも「えんにょう」には起筆があるからだ。「えんにょう」の起筆の有無をデザインし分けるのなら、MJ035473にはあえて起筆をつけるべきだ、ということになる。さて、このあたり、どうするべきなんでしょ？

文字情報一覧表で、IPAmj明朝Ver.000.01の各グリフをチェックしていたのだが、やはり「えんにょう」の周辺がかなりまずい。第12分冊のMJ011110とMJ011111のように、全く同じグリフが2つずつ収録されてしまっている。これらは本来、「えんにょう」の筆押さえの有無を別々のグリフとして収録すべきところ、筆押さえをあえて全て無くしてしまったために、こういう訳のわからないことになってしまったのだ。 もちろん、IPA側にも言い分はあって、これらの筆押さえを無くしたのは、平成20年度『汎用電子情報交換環境整備プログラム成果報告書』のデザインコンセプトに合わせた、ということだ。ただ、そうであれば、たとえば戸籍統一文字の108280と108310を見分ける方法は、もはや残されていないのだから、これらに別々のグリフID(MJ011110とMJ011111)を割り当てるということ自体ナンセンス

ではPRI 184が通った後、日本として取れるカウンターアクションはないのか、と、昨日の日記の読者から、懇願にも似た質問を受けた。あるにはあるが、それは非常に嫌われるアクションだ。 1つは、Hanyo-Denshiの既存IVSに新たなグリフを追加する、というアクションだ。たとえば、「U+6B21 U+E0103」に対し、現状の平成明朝JA2801グリフに加えて、戸籍統一文字181670のグリフを追加する。つまり、CIDが追加されそうなHanyo-DenshiのIVSに対して、先手を打って日本国内の別のグリフを追加してしまうのだ。かなり効果的なアクションだが、国際的には嫌われること、この上ないだろう。 もう1つは、Hanyo-Denshiの追加要求の際に、単一のグリフに対し複数のIVSを要求する、というアクションだ。たとえば、住基統一文字FA20に対する新規IVSには、「U+8612 U+E

「Unicode のIVSがもたらすメリットとデメリット」の読者から、PRI 184をこのままにしておいていいのか、と、お叱りの言葉をいただいた。1つのIVSに複数のグリフを並べられる、という点で結構スリリングな改正案だが、案そのものに瑕疵があるわけではないので、もはや止めるのは無理だと思う。で、この改正案が通ったあとのKen Lundeのアクションだが、大きく2つが考えられる。 1つは、Adobe-Japan1の各CIDを、Hanyo-DenshiのIVSに重複して割り当てるというアクションだ。たとえば、CID+2253は現在「U+6B21 U+E0100」に割り当てられているが、これを「U+6B21 U+E0103」にも重複して割り当てる。これにより、「混乱」したAdobe-Japan1とHanyo-Denshiの関係を、ある程度スッキリさせることができる。 もう1つは、Hanyo-D

一昨日と昨日の日記で書いた、既存のIVSに対する新たなグリフの追加だが、この問題に対する落とし所はあるのか。ここのブログにコメントしたり、赤いメガネのおねえさんに首をかしげられたりしながら、私(安岡孝一)なりに多少考えてみた。 日本が「U+6B21 U+E0103」に対し、現状の平成明朝JA2801に加えて、戸籍統一文字181670のグリフを追加しようとした場合を考えてみよう。この追加提案に対し、UnicodeとAdobeは共同して、「U+6B21 U+E0103」ではなく、「U+6B21 U+E0102」に181670のグリフを追加するよう「強く推奨」するだろう。また一方で、AdobeはCID+2253のグリフを「U+6B21 U+E0103」に追加するよう日本に要請する。たぶん、CID+13799のグリフを「U+6B21 U+E0104」に追加要請もするだろう。というか、私の知っている

住基統一文字FA20に対する新規IVSには、「U+8612 U+E0105」と「U+FA20 U+E0100」の両方を要求する。 に対し、互換漢字「蘒」(U+FA20)はIVSの基底文字になれない、とのコメントをいただいた。だったら、IVSの基底文字に互換漢字を許すようにするか、さもなくばU+FA20を互換漢字から統合漢字に格上げすればいいと思う。そもそも、互換漢字の中で特別扱いされてる12字にしたところで、JTC1/SC2/WG2 N1698 (March 2, 1998)の Among these compatibility characters, CJK ideographs have been encoded to either represent duplicates of characters already encoded in the main CJK Unified Id

PRI 187の公開レビューが無事はじまった、との連絡をいただいた。Hanyo-DenshiのIVS登録第2弾にあたるもので、9078字を追加提案したものだ。しかも今回は、戸籍統一文字や住民基本台帳ネットワークシステム統一文字に加え、登記統一文字までIVS提案しているので、かなりアナーキーなことになっている。これから3ヶ月間の公開レビューの後、再チェックをおこなってIVDに追加される予定である。 ただ、今回ややこしいのは、このPRI 187が、PRI 184やPRI 183と並行して進んでしまっていることだ。この結果、たとえばU+2B751には、cid13866とIB0623とJTAE48の3つがIVS提案されている。これらのうち、どの2つが同じで、どの2つが違っているかなんて、正直なところ私(安岡孝一)ですらわからない。平成明朝IB0623が住基文字C0E2のデザインを十分反映しきれてい

Encode - 規格のバグまでは直せませんにコメントしながら思ったのだが、JIS X 0208の1区33点「波ダッシュ」をUnicodeに変換する際、U+FF5EのFULLWIDTH TILDEに変換するのは明らかに間違いだ。この件に関して、私が知る限りのことを、ここに記しておこうと思う。 平成5年度のUCS調査研究委員会WG1において問題となったものの一つが、既存のJISの文字コードとISO/IEC 10646との対応をどうするかだった。JIS X 0208-1990の1区33点「波ダッシュ」に対しては、U+223C、U+223D、U+223E、U+223F、U+301Cが候補となったが、結局U+301Cと対応させることとなった。U+301Cの名前がWAVE DASHだったからである。ただし、ISO/IEC 10646-1:1993のU+301Cの例示字形は、JIS X 0208の「波

tarosukeの日記にもコメントしたのだが、YEN SIGN問題の歴史的経緯は、あまり知られていないように思える。そもそも、情報処理学会コード標準化委員会が1965年1月28日に完成した文字コード案では、「¥」は0x24に収録する予定だった。ところが、1966年4月のISO/TC97/SC2 + CCITT/GM ALPパリ会議において、ISO 7ビットコード最終案の0x24は「$」に固定されてしまい、1967年12月22日にISO R 646として制定された。やむをえず日本側は0x5Cに「¥」を移し、JIS C 6220として1969年6月1日に制定した。一方アメリカは、1970年10月のISO/TC97/SC2ロンドン会議において、ISO R 646の0x5Cを「\」にするよう要求してきたが、日本はこれに反対、ISO 646の1973年7月1日改正においても、0x5Cを国内使用箇所と

「UnicodeのIVSがもたらすメリットとデメリット」の読者から、IVSに対するフォント・フォールバックはどうあるべきか、という趣旨の御質問をいただいた。たとえば、CSSのfont-familyで複数のフォントが指定してある場合に、最初のフォントに表示したいIVSが収録されていなかった時、表示プログラムはフォントの中をどう探していくべきか、という問題だ。 例として、3つのフォントが指定されている時に、「U+845B U+E0103」を表示するための理想的なフォント・フォールバックを、私(安岡孝一)なりに考えてみよう。 最初のフォントから「U+845B U+E0103」を探す。なければ 最初のフォントから「U+845B U+E0101」を探す。なければ 2番目のフォントから「U+845B U+E0103」を探す。なければ 2番目のフォントから「U+845B U+E0101」を探す。なければ