Adobeの異体字セレクタのなぞ

最近異体字を使う必要があっていろいろ調べている。まず自分のような古い人間にとって異体字というのは外字であって各メーカーが勝手に使っているイメージだった(違ったらすまん)。しかし調べてみるとユニコードがとうとう異体字を認めたということに今更気づいた。UTF8というのは文字によって長さが違うというかなり扱いたくない感じになっているらしい。つまりアルファベットは1バイトだけど、漢字は2バイトの場合もあれば3バイトの場合もあるというような具合だ。どうやって処理しているのか知りたくもないが、幸い、賢い人が書いたライブラリなどがあるのでよくわからないまま処理できる。で、昔ユニコードができた当初に似た漢字を無理やりまとめていたのをUTF8ではきちんと登録できるようになっており、きちんとある漢字の異体字はこれとこれみたいに登録するようになっていた。しかもたくさんの異体字をどうやって選択するのかというのもAdobeのソフトは異体字セレクタというものがあって、候補文字を表示して選べるようになっているらしい。(自分のPCには入っていないので確認できないが)そこで、自分も異体字を書体に登録して異体字セレクタを使いたいと思ったのだ。

最初UTF8のIVSという仕組みにのっとって異体字を登録すればよいのだろうと思っていたがどうやらそうではないらしい。というのもIVSは異体字はどこかの機関が管理しておりIVSでいう異体字はあくまでユニコード上に登録が漏れてしまった字形ということらしく、例えば高と髙(はしご高)は自分的には異体字だが、IVSでは別文字コード割り当て済のためIVSに沿って異体字選択機能を作っても選択肢に出てこないことになる。もちろん自分専用で使う分にはIVSの仕組みを使って異体字として登録してしまえばよいのだが、Adobeの異体字セレクタはIVSを使っていないようで選択肢にでてこない。

いろいろ調べていくと、異体字にはIVSでの登録とaaltテーブルでの登録という2種類あるらしくAdobeの異体字セレクタはaaltテーブルを使用しているらしい。こちらはIVSと違って文字コード上の一貫性ではなく同じ文字の字形違いを登録できる。

ここで問題となるのは自分で異体字セレクタを作るにあたってである。今回の用途的にはIVSのほうがやりやすい。というのもIVSはベースの文字の後ろにセレクタ文字を付ける形になるので異体字を選択しているというのがわかりやすい。というか、元の文字列とセレクタ文字を別で覚えておけばどの文字が異体字選択中かがわかる。ところが異体字セレクタの場合は選択した後は文字を異体字の文字コードに入れ替えることになる。今回の用途では異体字を選択したのを覚えておいて後でわかるようにしたいのである。なにか良い方法は無い物か悩むのであった。

Bingが考えたゲームシナリオのなぞ

BingのAI検索エンジンにかまいたちの夜みたいなミステリーを書いてと頼んでみた。実は正確にどう頼んだかは忘れてしまった。次の日に同じように頼んだつもりだが、私は小説家ではありませんと断れてしまったのである。もしかするとBingの設定が変わったのかもしれない。

一度は成功したBing先生のミステリーであるが、なかなか面白いというか普通にありそうな内容で興味深かった(もしかしたら著作権侵害のパクリだった可能性もあるが)。主人公は友人の実家の家に男2人、女1人でやってきたらしい。どうやら友人が実家を相続して一緒にリフォームしようぜみたいなのり。で、その実家には何か謎があるというストーリであった。謎が何なのかとか一緒にリフォームするかどうかなどといったときにBing先生は選択肢を表示してくれてその選択肢通りに話が進んで、正直このまま最後?まで見てみたいとかそのまま絵を付けてゲームにしたいと思ったくらいである。しかし無情にもBing先生の質問回数制限にかかって途中で終了してしまった。ちなみにChatGPT先生にも頼んでみたが、最初の導入は書いてくれるのだが、選択肢を表示して続きを書いてくれることは無かった。

これをテストしていて思ったのだが、AI先生の息を吐くように嘘を吐ける能力はこの用途には向いていると思った。なにしろ自然に感じる文章を書くのに特化しているので荒唐無稽なミステリー設定でもごくごく自然に書いてくれる。前提条件を指示できるのであれば、かまいたちの夜のようにいろいろなシナリオに分岐するゲームのアイデアを無限に作ってくれる予感がする。正確さが求められる用途に使わなければ現状無敵かもしれないと思ったのであった。

新しいBing検索のなぞ

AI?を駆使した新しいBingが公開されている。ChatGPTよりはましなのか確認してみた。

まずは一般社団法人Colaboの問題を聞いてみた。こちらは2021年1月の話は全く出てこず、ちゃんと会計不正疑惑について教えてくれた。ただ、ネット情報をまとめているためだろうかまだはっきりと不正と確認できていなさそうなことを確定した事実であるかのように教えてくれる。この点は知ったかぶりChatGPTと同じ癖があるようだ。彼らにとってはウェブの全ての情報が事実として扱われているのかもしれない。ChatGPTより良いのは元となった情報を都度リンクしておいてくれるのでソースの確からしさを自分で確認できるところだろう。この辺りは検索エンジンらしくてよいところである。

次に水泳のクイックターンについて聞いてみた。こちらはちゃんとクロールで行われるという点とタッチターンと比べて時間短縮できるということを教えてくれた。ただ、教えてくれたやり方は途中に手を壁から話すという手順があり、何かと勘違いもしくは混ざってしまっている感じである。手を壁につけるのか確認したら違うと言ってくるので整合は取れていない。どうも自分の発言を自分で精査するという機能が不足している感じがするが、最新の情報とつながっており生きたリンクを紹介してくれる分ましなようである。ただ、すこし古い情報を求めたところネット上のニュースソースが公開停止されてしまうとBingはわかりませんとなってしまうようである。嘘を図れるよりは良いが、記憶力が無いというのも問題かもしれない

息を吐くように嘘をつくChatGPTのなぞ

最近人間と同じように会話ができるAIと大人気のChatGPTを試してみた。個人的には、こういった会話AIで仮想ネットワークRPGとか、アドベンチャーゲームとかやってみたいと思っていたのだが、使ってみていろいろ違和感を感じたのであった。

まず最初は無難に英語でHawaiiの観光案内を頼んでみた。英語での返しは非常に早く読むのが大変な量を提示してくる。Hawaiiのトレッキングコースというマイナーな話題を聞いたのに多分正確と思われる情報を返してくれた。(自分でもすごく昔に調べて何か所か行ったことがある)。ところが、なんでもいいから聞いてみてと言ったところそれはあまり得意ではないらしい。話題を特定してくれと言ってきたり、話していると会話が終わってしまったりする。もちろん相手からどんどん会話するというようにはできない仕様となっているからであるためそこを変えればもっと自然に会話感が出るかもしれない。

しかし最も問題と感じたのは、明らかに嘘を教えてくることであった。というのも最近TwitterとYoutubeで話題の一般社団法人Colaboについて聞いたところ2021年1月に会計不正で元会計担当者を刑事告訴していて現在警察で捜査中といってきたのだ。流石にこんな話があればとっくにYoutubeでほじくり返されているはずなので明らかに嘘である。詳細がわかるURLを教えてくれといったらNHKや新聞社の記事のURLをくれたがすべてリンク切れであった。

間違いではないかと指摘するも頑なに認めない。(ChatGPTには間違いを認められない、知らないと言えない癖があると思う。何かしら答えなければいけないと思っているのか知ったかぶりをするのだ。)ちなみにColaboの公式ウェブサイトを教えてくれと言って返ってきたURLが間違っているのにさらに驚いた。現在のChatGPTは息を吐くように嘘を言う機能が備わっているらしい。

ネットに繋いで自分で調べられるようになったら(Bing検索みたいな感じか?)もっと面白いのかもしれないが、現時点ではオフラインのためか一般的な内容はそれなりの精度で答えてくるが、時事はごくごく自然に嘘を吐いてくることが分かったのであった。

訂正、一般的な内容もかなり精度が低い。というのも水泳のクイックターンのやり方を聞いたら壁に手を付けてから云々と言い出した。指摘したらすぐに訂正。しかしそれがまた間違っている。現状のChatGPTは検索で出てきた内容を適当につなぎ合わせて読める文章に整形しているだけでとてもAIというレベルではなさそうである。Bing検索がどうなるのか楽しみである。

JPEGに変換できないImageMagickのなぞ

ImageMagickといえば知る人はしる画像変換ソフト(コマンド?)だ。Windows版、Linux版あり、多種の画像フォーマットに対応しているうえに一括変換コマンドまで持った非常に便利なソフトであるのだが、故あってソースコードからビルドしたらJPEGに変換すらできなくなってしまった。公式にあるビルド、インストール方法のやり方はシンプルで誰でも簡単にすぐ終わる。コンフィグしてメイクしてメイクインストールの3ステップくらいのものである。だからこそこのトラブルは初心者殺しといっても良いものになっていた。

細かく調べ切ったわけではないから間違っていてもご容赦願いたいが、ImageMagickが画像を扱うには2種類の方法がありそのことが初期インストールのImageMagickと自家製ImageMagickの処理結果が変わってしまう原因であった。どうやらImageMagickはビルド時に各画像フォーマット用のライブラリをリンクする場合と実行時に外部コマンドで画像処理を行う2種類の方法を持っているらしく、コンフィグするときにライブラリの存在を確認してあるものはライブラリをリンクし、無い物はあらかじめ決められた外部コマンドを使うようにビルドされるのであった(外部コマンドの存在有無は未確認のまま進行)。つまり何も考えずにビルドするとほぼすべてのコマンドを外部コマンドに頼る単なるランチャーのようなImageMagickが出来上がってしまう。今回JPEGにすら変換できなくなったのはJPEGに変換するための外部コマンドが無かった事が原因であった。

ここで問題なのは各フォーマット用に必要なライブラリ名のリストが見つからないということである。つまり何とかして自分で必要ライブラリをインストールしてからビルドする必要があるのである。そこで一応発見した物をここに記載しておこうと思う。(ちなみにではあるが通常のUbuntuDesktopであればほとんど入っているようである。自分の場合はサーバーのImageMagickをバージョンアップを試みている)

ライブラリ名用途
libjpeg62-devJPEG
libwebp-devWEBP
libwmf-devWMF
libheif-devHEIC
libx11-devX
libxml2-devxml
libopenexr-devopenexr
libopenjp2-7-devjpegxl?
libbz2-devbz2?
libtiff-devtiff
liblcms2-devlcms2
libfontconfig-devfontconfig
libfreetype-devfreetype
libjpeg-devjpeg ?
liblqr-devlqr?
libglib2.0-devglib
libpng-devpng
libz-debz?
libdjvulibre-dev?
libfftw3-dev?

といった感じである。インストールはsudo apt install ライブラリ名 でいける。上記すべて入れるとubuntuの初期インストールとほぼ同じ状態でビルドできる。実際に使うフォーマットに関係したライブラリだけ入れたほうが良いのかもしれないが何に使っているかよくわからないライブラリも多いのでできるだけ同じになるようにした。同じかどうかの確認はconvert -versionでバージョン確認すると最後にDelegates(built-in)という表記でビルド時にリンクした一覧が表示されるのでそれが一致することで確認している。ImageMagickをわざわざビルドする必要はそれほどないはずではあるが、いざというときのためにメモとして残しておく。参考になれば幸いである。

一年遅れのGalaxyA30アップデートのなぞ

海外ではGalaxyA30が最新OSにアップデートされているのを横目で見ながらいつかau版でもアップデートしないかと定期的にアップデート確認をしていた。もしかするとこの確認回数で優先度が上がらないかと思ってすらいた。そして最近ついにアップデートありというメッセージをみたのだ。やっと来たという思いと、まだアップデートする気あったんだという思いを抑えてアップデート内容をチェックしてみたところ単なるセキュリティーアップデートでがっかりさせられたのだが、そこに輪をかけてがっかりしたのが、セキュリティパッチレベルの日付である。なんと2021年10月1日となっているのだ。アップデート前のパッチレベルの日付の見間違いかと何度も見直したが間違いなかった。なんとauは一年前のセキュリティアップデートを今さら適用してきたのだ。なんという無能感あふれる仕事なんだろうかと思いつつ原因を考えてみるとさらにがっかりするのである。

というのも、オリジナルのGalaxyA30は2021年の前半にOSアップデートがあった。自分が心待ちにしていたのはこれであるのだが、今回の2021年後半のセキュリティアップデートというのはつまりOSのバージョンが上がった後にでた旧OSのセキュリティアップデートということである。。つまりつまりOSアップデートするつもりがあるなら不要なセキュリティアップデートであり、これを配信したということはA30のOSアップデートはしないよという宣言に等しいということに気づいてしまったのだ。

アプリの切り替えなどがものすごくもっさりしながらも電池持ちが圧倒的によい携帯なのでOSアップデートしてもう少し使いたかったがそろそろ交換時期ということなのだろうか。この携帯は業務用で機種提示されて契約しているのであるが、最後のセキュリティアップデートを配信したということは1年くらいで代替品の提示があったりするのであろうか?業務用携帯の終活が気になるのであった。

EV電費のなぞ

EVが流行っているようだ。使うたびに充電なんて面倒なことをしたくはないが、燃料代が安いというのには魅力を感じる。自家用車が2台とも10万キロを軽く超えてきたので実際どのくらい違うのか計算してみた。

EVはどうやらエアコンONで6km/1kwh、OFFで7km/1kwhくらいが相場らしい。
1kwhの電気代は夜間で15円、昼間で25円くらいらしいが、これに再エネと調整費がのる。調整費は昔はマイナスだったが最近は+6円とかしているのでトータルで+9.5円くらいだろうか。
対してプリウスの実燃費は17km/lから20km/lくらいらしい。で最近のガソリン価格が200円(補助金なしとして)らしいのでそこから58円の税金を引くと142円/lということになる。
EV
 夜間 24.5/6.5 = 3.77円/km
 昼間 34.5/6.5 = 5.31円/km
プリウス
 142/18.5 = 7.68円/km
ということで電気自動車は自宅で夜間に充電すると大体プリウスの半額の燃料費でよいらしい。これは昔の車が10㎞/lで良いといわれていた時代にプリウスが出たくらいのインパクトはある。あとは本体価格次第であるが10年で10万キロ載るとするとプリウスの燃料費が76万8千円に対してEVが37万7千円となり最近頻度が少ないとは言え、1年に1回オイル交換4000円とすると43万円くらいのアドバンテージがあるようだ。つまりEVがプリウス+40万くらいの価格で変えるならメリットがあるということになる。(ただし、登録費用、重量税の優遇は考えない。面倒なので)

ここまで調べて結構いいところまで来てる(というか最近のガソリン代の高騰でだいぶ変わった)と思ったが、車代を調べて愕然とした。リーフ(2017年モデル)とプリウス(第4世代)の価格差が100万以上あるではないか。プリウスも車両価格差をガソリン代で元が取れないとさんざん言われていたがそれでも差額は50万くらいだったのにそのプリウスと比較してさらに100万アップとかもはやどうやっても元が取れるわけないレベルである。というわけで税金という下駄をはいた状態ではどうかを考えてみる。
プリウス
 200/18.5 = 10.81円/km

これなら10万キロで108万円でEVがプリウス+70万なら互角ということになるがEVはプリウス+100万なので以前勝負にならない。ただここにEV補助金85万が入ってくると話は大きく変わる。EVを購入するほうが10万キロの燃料費を加えると50万くらいお得ということになる。ただしプリウスPHEVにも50万の補助金が出るらしいのでそうなってくるとプリウスPHEVを補助金でプリウスと同じ金額で購入してできるだけ充電をまめにするというのがお得かつ燃料の多様性という点でよいのではないだろうか。

磨いちゃだめなガーミンのなぞ

古いガーミンを中華電池に交換して稼働時間が全く増えなかったというログを書いた。その結果新しいガーミンを買うことになったのだが、購入して1か月でガラス面を傷つけてしまった。うっすらと一本の線が入った程度なのだが購入して1か月なのでがっかりである。さらに悪いことにガラス磨きを購入して磨いてみたところ傷は完全に消えない上に曇り防止や撥水が無くなってしまった。磨いたところだけ親水性になった上に手の油が残るようになってしまった。今まで手の油が付かないことに何の疑問も感じていなかったが何かのコーティングがしてあったらしい。幸い外出中に付いた傷だったので車の携行品補償の対象となって免責5000円で修理できるとのことなので修理に出すことにした。やはりガーミンは保護フィルム必須だと実感したのであった。修理(といっても新品交換らしいが)終わったらフィルムを貼ることを心にちかったのであった。

OpenPeppol

4コーナーモデルを採用しているらしい。要するに電子メールと同じモデルで、発行者、発行側サーバー、受信側サーバー、受信者の4アクターがいて、発行者は送り先を指定して発行側サーバーに渡すとサーバー間でやり取りをして受信者のメールボックスのようなところに届くらしい。おそらく発行側サーバーは発行者の受信側サーバーでもあるだろうからこのシステムでデータを送るにはどこかのサーバーと契約してアカウントをもらう必要があることになる。

ハードインフラ的にはメールサーバーと大差なさそうなので格安でアカウントを取得できれば問題ないがなんとなくだが初期はかなり高価なのではないだろうか。Peppol自体がヨーロッパによくある仕様書を公開してオープンと言いながら実際は特定の団体の実装を買うしかないという商売っぽいので安く普及というのは期待できないかもしれない。日本用に拡張もされてるのでそのまま使えるオープンソースのコードも期待できなさそうである。これを自社システムに組み込めたらそのコードで商売できるレベルの最新中の最新の話っぽいので仕様書を長めならがもう少し様子を見てみたいと思う次第である。

PDF請求書の寿命のなぞ

PDFで請求書を出すために電子帳簿保存法の保存要件であるタイムスタンプを付与したことは以前書いた。これで発行する側の保存要件と受取側の保存要件の中で一番面倒なところは完了した(残りは検索可能要件なので何とでもなる)ので受取側も特に電子帳簿保存法を意識しなくてもフォルダを決めてPDFを保存しておけばよいと思っていたところ、デジタル庁が電子データでの取引データのやり取りを進めていることに気づいた。昨年電子化のプレゼンを電子請求書屋から受けた時にはそんな話まったく出てこなかったからかなり急ピッチでデジタル庁は活動しているようだ。どうやらマイナポータル的なことをやろうとしているらしい。相変わらず仕様だけ決めてインフラ整備は民間任せっぽいのが不満ではあるが、数年以内にPDF請求書と電子データでの受け取りを選べるように改良することを考えておいた方がよさそうだ。なにしろ、お客様のメールアドレスを聞くのにものすごい手間をかけたので今さらどこかの電子請求書屋を通して電子データを送ってくださいとか言われたらかなわない。最低でも5年は現システムでやらないと元が取れた気がしない。

とはいえ、電子請求書屋のプレゼンを受けた時に一番ダメだと思ったのが、電子請求書屋間でデータ交換がない(つまり受取側はたくさんの電子請求書屋にそれぞれアカウントをもつ必要がある)ことだったのでシステム的にはまともになったのは間違いない。あとはオープンソース系で送受信ができるかどうかということで少し調べてみたい。