にせねこメモ

はてなダイアリーがUTF-8じゃないので移ってきました。

このブログについて

文字・フォント・プログラム・技術・趣味などについて、Twitterでは書きづらい長い内容などをまとめるためのブログです。基本的には自分用のメモとして書いている部分が多いです。

リンク等

note https://note.com/nixeneko 残らなくてもいい記事
Pixiv Fanbox https://nixeneko.fanbox.cc/ 活動まとめと有料の週報(大したこと書いてないが…)
Pixiv https://pixiv.me/nixeneko
Pleroma @nixeneko@nixeneko.info Mastodonとかやってる人はフォローしてください
Bluesky @atproto.nixeneko.info 時々見る
Twitter @nixeneko 最近あんまり使ってない
GitHub https://github.com/nixeneko プログラムとか
Bookmeter https://bookmeter.com/users/9166 読書記録。たまに感想
Amazon欲しい物リスト amazon.jp/registry/wishlist/1C43ZFBA4IL6Z

同人誌(無料公開)

https://nixeneko.hatenablog.com/entry/c88_russian_alphabethttps://nixeneko.hatenablog.com/entry/c90_greek_latin_cyrillichttps://nixeneko.hatenablog.com/entry/20170811_dentyuhttps://nixeneko.hatenablog.com/entry/c100_mongol_bichig_unicode

Pleroma 2.6.3→2.7.1へ更新

Ubuntu 22.04のPleromaのバージョンを2.6.3から2.7.1に更新した。
それに伴い、Erlang/ElixirをUbuntu標準のリポジトリから導入したものから、asdfで導入したものに変更した。

環境

共通

  • さくらのVPS 1GB
  • OS: Ubuntu 22.04 LTS
  • Pleromaのインストール方法: ソースからインストール

更新前

更新後

  • Erlang: 25.3.2.15(asdfでインストール)
  • Elixir: 1.15.8-otp-25(asdfでインストール)
  • Pleroma: 2.7.1

問題点

Ubuntu 22.04標準のリポジトリでインストールしたElixirのバージョンがPleroma 2.7.1の要求する最低バージョン(1.13)を満たしていないため、Pleroma更新時に問題になることが予想されていた。

Pleroma 2.6.3では辛うじて動いていたが、更新する際にElixirのバージョンを上げる必要があった。

Elixirの新しいバージョンをインストールするためにはasdfを利用することにした。

手順

Pleromaを停止してデータベースをバックアップ(一応)

sudo apt update
sudo apt upgrade
sudo service pleroma stop
sudo -Hu postgres pg_dump -d pleroma_dev -v --format=custom -f /home/nixeneko/share/pleroma.20241201.pgdump
sudo -Hu postgres pg_dump -d pleroma_dev -v --format=plain -f /home/nixeneko/share/pleroma.20241201.sql

念のため2形式でバックアップしてるが、基本的には--format=plainの方は不要だと思う。

Ubuntu公式リポジトリから入れたErlang/Elixirをアンインストール

これは必須ではないが、意図せずこちらが実行される事態は避けたいので消した。

sudo apt remove elixir erlang-dev erlang-nox
sudo apt autoremove

asdf導入、asdfを利用してErlang/Elixirをインストール

Erlangの依存関係をインストール

GitHub - asdf-vm/asdf-erlang: Erlang plugin for asdf version managerなどを参考に、Ubuntuのバージョンによってインストールするものは変更する必要がある。

sudo apt install build-essential autoconf m4 libncurses5-dev libwxgtk3.0-gtk3-dev libwxgtk-webview3.0-gtk3-dev libgl1-mesa-dev libglu1-mesa-dev libpng-dev libssh-dev unixodbc-dev xsltproc fop libxml2-utils libncurses-dev openjdk-11-jdk
asdfをダウンロードしてきてインストール

Getting Started | asdfを参考に、asdfの最新バージョンに応じてコマンドは変更する必要があるかもしれない。

cd /opt/pleroma
sudo -Hu pleroma bash
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.14.1
nano ~/.bashrc

~/.bashrc末尾に次の内容を追記して保存し、閉じる。

#asdf
. "$HOME/.asdf/asdf.sh"
#asdf completion
. "$HOME/.asdf/completions/asdf.bash"

~/.bashrcを読み込む。

exec bash

インストールできたか確認する。

asdf --version

すると、次のように表示される。

v0.14.1-f00f759
Erlangインストール

list-allなどを参照しながら、今回は25系の最新っぽいやつを入れた。

asdf plugin add erlang https://github.com/asdf-vm/asdf-erlang.git
asdf list-all erlang
asdf install erlang 25.3.2.15
asdf global erlang 25.3.2.15
Elixirインストール

list-allなどを参照しながら、今回は1.15系の最新っぽいやつで、Erlangのバージョンに合わせてOTP 25のものを入れた。

asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
asdf list-all elixir
asdf install elixir 1.15.8-otp-25
asdf global elixir 1.15.8-otp-25

インストールできたか確認する。

elixir --version

すると、次のように表示される。

Erlang/OTP 25 [erts-13.2.2.11] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]

Elixir 1.15.8 (compiled with Erlang/OTP 25)

Pleroma更新

コードを2.7.1に更新
cd /opt/pleroma
git pull
git checkout v2.7.1

git checkoutgit switch使った方がいいのかな。

以前のバージョンで利用していた依存関係などを初期化する
MIX_ENV=prod mix deps.clean --all
MIX_ENV=prod mix local.rebar --force
MIX_ENV=prod mix local.hex --force
rm -r _build
Pleromaのコンパイルマイグレーション・データベースのVACUUM ANALYZE
MIX_ENV=prod mix deps.get
MIX_ENV=prod mix compile
MIX_ENV=prod mix ecto.migrate
MIX_ENV=prod mix pleroma.database vacuum analyze

なんかvacuum analyzeするときに次のエラーが出てたのでやや気になるが、動いてはいるみたい。

11:12:38.182 [debug] Tzdata polling for update.

11:12:39.619 [info] tzdata release in place is from a file last modified Wed, 21 Oct 2020 18:40:20 GMT. Release file on server was last modified Thu, 05 Sep 2024 18:47:42 GMT.

11:12:39.634 [debug] Tzdata downloading new data from https://data.iana.org/time-zones/tzdata-latest.tar.gz

11:12:40.678 [debug] Tzdata data downloaded. Release version 2024b.

11:12:40.810 [error] GenServer :tzdata_release_updater terminating
** (ArgumentError) errors were found at the given arguments:

  * 2nd argument: not a tuple

    :erlang.element(1, :error)
    (tzdata 1.0.5) lib/tzdata/util.ex:223: Tzdata.Util.to_int/1
    (tzdata 1.0.5) lib/tzdata/parser.ex:38: Tzdata.Parser.process_rule/1
    (tzdata 1.0.5) lib/tzdata/parser.ex:24: Tzdata.Parser.process_tz_list/1
    (tzdata 1.0.5) lib/tzdata/parser.ex:86: Tzdata.Parser.process_zone/5
    (tzdata 1.0.5) lib/tzdata/parser.ex:24: Tzdata.Parser.process_tz_list/1
    (tzdata 1.0.5) lib/tzdata/parser.ex:86: Tzdata.Parser.process_zone/5
    (tzdata 1.0.5) lib/tzdata/parser.ex:24: Tzdata.Parser.process_tz_list/1
Last message: :check_if_time_to_update
State: []
pleromaユーザーのbashから抜ける
exit
Systemdユニットの設定を変更

/etc/systemd/system/pleroma.serviceを編集する。

sudo nano /etc/systemd/system/pleroma.service

次の内容を探し、

; Path to the Mix binary.
ExecStart=/usr/bin/mix phx.server

これを次の内容に変更する。

; Path to the Mix binary.
Environment="PATH=/var/lib/pleroma/.asdf/shims:/var/lib/pleroma/.asdf/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ExecStart=/var/lib/pleroma/.asdf/shims/mix phx.server
ユニットファイル再読み込みとPleroma再始動
sudo systemctl daemon-reload
sudo systemctl restart pleroma

できた!

(2024-12-05時点)現状の不具合

  • Subway Tooterから通知を取得するときに、タイムアウトして500が返ってくることがある
  • Subway Tooterで画像投稿しようとすると、「MIMEタイプ image/png には対応できません」「MIMEタイプ image/jpeg には対応できません」などと出て、アップロードができない
    • WebのPleroma-FEからは投稿できる

参考

最新ガラケーOrbic JOURNEY Pro 4Gを使った感想

2024年7月に発売された折り畳み式ケータイ「Orbic JOURNEY Pro 4G」を10月に購入し、1カ月ちょっと使ってみたので感想を書いていく。
www.orbicmobile.jp

Orbic JOURNEY Pro 4Gの特徴

使用目的

  • 3Gガラケー(FOMA)の代替
  • 電話できればいい
  • 一度の充電で一週間以上待ち受けできてほしい

ファーストインプレッション

本体

でかい。
以前FOMAで使っていたケータイより一回りでかい。ボタンは押しやすいので、でかいのも悪いことだけではないが…

バッテリーを取り付けるためにはカバーを外す必要があり、切り欠きに爪をひっかけてバキっと外す。最初、力任せにやってしまっていいものかわからず心配だったが、そうするしかないっぽい。

バッテリー

バッテリーは取り外し可能なので、端末の廃棄時に困ることがないと思う。ちゃんとPSEマークもスリーアローマークもついている。

バッテリーの充電は、満充電まで5時間ほどかかるようだ。

バッテリーは、Wifiがオンで6日、Wifiをオフにすれば10日程度待ち受けできる。一週間充電なしで持てば御の字と思っていたので、悪くないと思う。

一応Wifiだけで使うこともできる。

ドコモのirumo 0.5GBを契約

以前はFOMAケータイを電話だけで使っていて、それから機種変更の形でirumo 0.5GBのプランに変更した。

ドコモ店員さんによると、ドコモでは動作確認をしていない機種なので、通信できない可能性があるとのこと。それでも自己責任ということでやってもらった。
SIM挿して起動すると電話は可能になった。

そのままではネット通信はできなかったが、

  • 設定→モバイルネットワークとデータ→APN設定→データ設定→「NTT Docomo」を選択

と設定したら通信ができるようになった。

アプリ

Google検索やGoogleマップYouTubeなどのアプリがはじめからホーム画面にある。自分でKaiOSストアからインストールすることもできる。

とはいえ、昔のガラケーフルブラウザでネット見てるみたいな感覚で、あんまり操作性はよくない。
マップは割とよくできていると思う。

YouTubeについても、動画再生はアクセラレーションあるから普通にできるけど、サイトを操作するのがそこそこ重く、実用するにはあまり快適ではないかなあという気がした。

関係ないが、実用性といえば、ブラウザで動画サイトを閲覧した時、例えばPornhubはサイト読み込みが重荷すぎてろくに動画までたどり着けなかったものの、XVideosはフィーチャーフォン向けのサイトが用意されていて比較的快適に視聴できるっぽい。

問題点

端末の問題

謎の急激なバッテリー切れ

十分なバッテリーがあったはずなのに気づいたらバッテリー切れになっていることがあった。
おそらく、サイドのボタン(シャッターボタンと音量ボタン)が押される度に背面のサブディスプレイが点灯するため、押しっぱなしか頻繁に押される状態で携帯していたところ、サブディスプレイが光りっぱなしになってバッテリーが0になってしまったのだと思う。設計が悪い。

サブディスプレイが表示されないことがある

起動時に失敗すると背面のサブディスプレイに何も表示されなくなる場合があるようだ。この端末だけの問題なのか機種全部がそうなのかは知らないが、そうなると再起動するしかない。
こうなる条件はよくわかっていないものの、電源ボタンを押してから完全に起動が完了するまで開いたまま放置した方がよさそうな気がする。

KaiOSの問題

日本語入力がこなれてない

日本語入力があまり良くない。
候補の決定だけを行うキーがわからず、次のおすすめの入力候補が出てきたところで消すという順番で入力している。

また、漢字変換(予測変換)の候補があまりたくさん表示されないため、入力できない漢字がでてくる。特に連絡先登録などでの人名入力で困る。別の端末で入力してコピペするとか、Googleの連絡先を利用するようにしてこの端末で電話帳登録はしないなど運用の工夫が必要そうだ。

連絡先アプリの姓名の表示順

連絡先アプリで、姓・名が漢字だけの場合、名→姓の順になる。どちらかに仮名が含まれていれば姓→名順になる。

例えば、

  • 姓が「田中」、名が「太郎」なら「太郎田中」
  • 姓が「田中」、名が「たろう」なら「田中 たろう」

になる。なんでやねん。

姓・名は無視してフルネームを「名」欄に突っ込む運用でもいいのかもしれない。

まとめ

  • 電話用端末として最低限の機能はあるように思うが、まだまだ発展途上といった印象。
  • スマホやパソコンなどの情報端末を他に持っていて、電話機能を中心に利用する場合には問題なく使えると思うが、こなれていない感じは強く受ける。
  • KaiOSを試したい人やKaiOSの発展に貢献したい人は買ったらいいと思うが、万人にお勧めできる端末ではないと思う。

『文字符号の歴史 ―アジア編―』を読んだ

三上 喜貴『文字符号の歴史 ―アジア編―』(共立出版、2002年)を読んだ。
www.kyoritsu-pub.co.jp


Unicode以前のアジアの文字コードについてまとめられた大著である。アジア編と題しているが、文字の種類ならアジアが世界の地域で最大なので、カバーする範囲はめちゃくちゃ広い。

本書では活版印刷・タイプライター・電信から始まり、電算処理の需要からASCIIなどの文字コードが作成され、文字コードが多言語に拡大されていく流れを描き出している。2000年代以降の動向は別に調べないといけないが、Unicode以前の世界の文字コードについて知る最初のソースとして最適だと思う。


本書を読んだことで気づき、とくに興味深く感じたことは、(特に初期の)Unicodeには元ネタがあるということだ。
Unicodeは既存の文字コードを処理するときの内部コードとして使えるように意図されており、既存の文字コードとのある程度の互換性があることが期待される。そのため、既存の符号化文字集合を取り込んでしまうというのは自然なやり方である。

例えば、インドの諸文字はISCIIと呼ばれるインドの国家規格(IS 13934)のドラフト版を元にUnicode 1.0入ったらしい(4.5節)。また、スリランカシンハラ文字はSLS 1134:1996というシンハラ文字符号表に由来するが、これはISO/IEC 10646Unicodeと同内容の国際公的標準)に組み入れることを目的として開発されたとのことだ。

シンハラ文字を入力してみると、デーヴァナーガリーなどのインドの諸文字とは入力のモデルが異なるのが感じられると思う(特にヴィラーマの扱い)。このような異なる出自の文字符号表をパッチワークのようにまとめたものであるのだから、Unicodeが用字系ごとにエンコーディングモデルがばらばらであるのも納得である。


2000年ころにはUnicode普及以前で、コンピュータで多言語を扱うことすら困難であり、ネット上にも文字や言語に関する情報は少なく、語学書も今ほど多様に出版されていなかったと思われる。その当時このような多様な文字を扱うには困難があったと推察でき、偉業と言うべきものだ。

一方で、著者は各種文字の専門家ではないようで、少なくともタイ・ミャンマー・クメール・シンハラ・モンゴル文字に誤植と思われるものを見つけた。
誤植によって本書の価値が毀損されることはないものの、文字解説については本書をあまり信頼せず、別の文献も参照した方が良さそうではある。

正誤表は著者のサイトに掲載するとなっているが、著者のサイトは消滅しているため確認できない。そのため、気になった点を以下に書いておく。

誤植と思われる点

間違いと思われる点を列挙しておく。

続きを読む

『State of Text Rendering 2024』を読んだ

https://behdad.org/text2024/

HarfBuzzの筆頭開発者であるBehdad Esfahbod氏によるState of Text Rendering 2024 (2024年テキストレンダリングの現状)という記事が、今年7月に公開された。
現在のフォントやテキストレンダリングに係るソフトウェアやエコシステムについてを広くカバーした論考であり、その分野に興味がある人は一読をお勧めしたい。しかし大著であるので読むのには時間がかかるかもしれない。というか、かかった。


さて、私は当該記事を読み、自分の理解の補助とするための雑な日本語訳を作成した。後ろに記載する。
始めはまとめのつもりで書いていたが途中からだんだん翻訳に近い形になった。厳密な訳になっていない場所もある。自分はこう読みましたという理解であり、間違いも多々あるかもしれない。
この訳を公開するのは、他人を助けるというよりは、自分は読みましたよということを表明するためだけに近い。

これ単独で読むことを意図してはおらず、読む場合は元記事と対照しながら読んでください。リンクやイタリックなどは省いたところがあり、原文を参照してください。参照をしやすくするために見出しには一部原語表記を併記した。
また、試訳では原文の一文ごとに改行を行っている。これは、原文の一文を複数の文に分けている場合があるからである。


和訳の2パス目が終わり、3パス目をやる時間がないので、欠陥があるだろうが公開する。訳に対する指摘は歓迎だが、反映できる保証はないし、この記事を原文のアップデートに合わせて都度更新するつもりもない。
なお、参照したのは2024年7月8日版(initial public release)であるが、公開媒体がGoogle Docsのプレビューページであるため、訳してるうちに原文の方が変化してしまっている感じがする。2パス目は2024/9/21~2024/10/3頃にやった。

ライセンスは、元記事がCC BY-SA 4.0であるため、この翻訳についてもCC BY-SA 4.0でライセンスされる。


以下試訳↓

ライセンス / License

(オリジナルの)このテキストはCC BY-SA 4.0でライセンスされている。

概略 / TL;DR

2009年からの、OpenType標準およびオープンソースのテキストスタックとアプリケーションにおける進展について書く。さらに、現在検討されている今後の進歩についても議論する。

大まかにいうと、OpenTypeが追加したのはカラーフォント、バリアブルフォント、Universal Shaping Engineである。
フリー/オープンソーススタックでは比較的低レベル(低レベルプログラミングの低レベルの意)ではそれらをすべてサポートしているが、アプリケーションのUIとして現れるのはより後になる。
オープンソーステキストスタックは巨大なマーケットシェアを獲得した。これはAndroidGoogle Chromeが採用したからである。
AdobeはOpenTypeシェイピングのためにオープンソーススタックの一部をPhotoshop, Illustrator, InDesignなどのフラッグシップアプリに統合している。

今後に目を向けると、テキストスタックをRustへと移行することが現在行われており、安全なプログラミング言語でフォントのコンパイルと実行が可能になる。
Incremental Font Transferによりwebブラウザにフォントをストリーミングすることが可能になる。
私の提案するWasmフォントにより、OpenTypeシェイピングモデルでは完全にサポートされていない(というか根本的にサポート不可能な)もっとも複雑な類の書記体系の正しいレンダリングを行うことが可能になるだろう。そしてまた、ラテン文字などの単純な書記体系でももっと表現力のあるフォントが作れるだろう。

目次

  • ライセンス / License
  • 概略 / TL;DR
  • 目次
  • 前書き / Foreword
    • 献辞 / Dedication
    • 前提条件 / Prerequisites
  • 導入 / Introduction
  • 振り返って / Looking back
  • これからの展望 / Looking forward
    • Better-Engineerd Font Formats (より優れた設計のフォントフォーマット)
      • 退屈な拡張: 漸進的なフォント形式の改善
      • より良い人間工学: Rust移植と統合
      • エミュレーションの先: 全面的にプログラム可能なフォント
    • 他の取り組み / Other efforts
      • Fontra
      • Incremental Font Transfer
  • 分析 / Analysis
    • 強み(S)
    • 弱み(W)
    • 機会(O)
    • 脅威(T)
  • 他のリソース / Other resources
  • 謝辞 / Acknowledgements
  • 著者について / About the author
  • バージョン履歴 / Version history
続きを読む

Raspberry Piがwifiから切断されたら再接続する

Raspberry Pi Zero Wがwifiでネットワークに接続されているが、時々そこにアクセスできなくなる。
自動で再起動してくれればありがたい。

(この記事は書いた時点ではちゃんと動作するか未検証である、しばらく動かしてつながらない状態がなくなれば動いてるに違いないということになる。とはいえログ見れば動作はわかるが。)

環境

方法1. watchdogデーモンを使う

watchdogデーモンは、pingが通らない場合にシステム自体を再起動するような設定が可能であるらしい。

利用法

インストール
sudo apt install watchdog
設定ファイルのバックアップ
$ sudo cp /etc/watchdog.conf /etc/watchdog.conf.backup
設定
sudo nano /etc/watchdog.conf

次のように設定を変更する。

interface = wlan0    # ネットワークインタフェースとしてwlan0を使う
ping = 192.168.1.1   # ping先のIPアドレス(環境に応じて変える)
interval = 300        # 300秒(5分)毎にチェック

その後再起動する。

備考

watchdogデーモンは、設定したような個所について何か問題が発生した場合、システム自体を再起動するものであるらしい。
そのため、ネットワークがない状態だと再起動を繰り返すことになる。
ネットワークに繋がってなくても動き続けてほしい場合は不適かもしれない。

方法2. スクリプトを使う方法

Raspberry PiでWi-Fi切断時、自動的に再接続されるようにする方法 #RaspberryPi - Qiita
このページで自動で再起動を行うスクリプトが公開されている。
スクリプトが古いため、wifi再設定コマンドは変更の必要がある。

次のような内容でreconnect.shを作成する(デフォルトゲートウェイが192.168.1.1の場合)。

#!/bin/sh
ping -c 1 192.168.1.1
test $? -eq 1 && sudo wpa_cli -i wlan0 reconfigure

その後、実行権限を追加し、crontabに書くなどして定期実行させるようにする。

ネットワーク再接続のコマンドはいくつかのやり方があるっぽいが、どれが動くかわからないので、動くものを選ぶ必要があるかもしれない。

Paints-UNDO触ってみた

www.itmedia.co.jp
画像を入力として、それを作成するお絵描きタイムラプスのような動画を生成するAIが公開されたというニュースを見た。名前をPaints-UNDOという。

サンプルページの生成サンプルをみて、「すごい!」と「まだ変なところがあるな…」と思った。
で、どんなもんかと実際に触ってみることにした。

サンプルページには

Note that all input images in this webpage are AI-generated (except that Rickroll). Their "ground truth" drawing processes do not exist.

https://lllyasviel.github.io/pages/paints_undo/

と書いてあるが、うるせえテメーのground truthと比較せんかい💢という気持ちになった。
こっちにはground truthがあるんだぞ…😕

動作方法はこのあたりを参考に

ちなみにNvidia RTX3060 12GBで動作した。PCのRAMは32GBあれば動きそうな気がする(このマシンは64GBだけれど)。

Paints-UNDOのスクリーンショット

結果

それぞれ3つほど生成してみた。もっといいものはできるかもしれないが、特別悪いものを抜き出したわけでもない。

例1

入力画像

出力結果A

www.youtube.com

出力結果B

www.youtube.com

出力結果C

www.youtube.com
なんかアスペクト比変ですね。キーフレーム生成では正方形にしているので、動画(in-between)作成時にそれを参照できてないのかな。

Ground truth

www.youtube.com

例2

入力画像

出力結果A

www.youtube.com

出力結果B

www.youtube.com

出力結果C

www.youtube.com

なんというか、連続性がなくて最後の方でゼロから書き直しになるとちょっとどうかなあって感じ。

Ground truth

www.youtube.com

何やってるの

で、これ、お絵かきタイムラプス風動画を生成するのだが、全然タイムラプス動画ではない。
人間が描いたタイムラプス動画から学習してるとかではなさそうである。

どうやら、完成形の絵(=入力)の絵から白紙の画像へと近づけていく中間点での画像を生成し、それらを補間するように間のコマを生成して動画としているらしい。

参考:

実際に使ってみると、

  1. 入力画像からプロンプトを生成し、
  2. そのプロンプトを元にキーフレームを生成し(デフォルトで8枚; うち1枚は完成形)、
  3. キーフレームの間を補間するようなフレームを生成し、動画とする。

この3ステップからなる。

2.のステップでキーフレームを生成しているが、ここで失敗すると3.で改善できるわけもなく…。
キーフレームの生成をプロンプトに頼っているので、プロンプトで再現しづらい画像だとうまくいかないっぽい。
というわけで、画像AIで生成しづらい画像を入力すると、キーフレーム生成がうまく行かず、最終的な出力も破綻したものになりがちということがわかった。
そのため、AI生成画像だと比較的安定した出力がしやすいのではないかと思う。

自作の絵のお絵かきタイムラプス風動画の生成がうまくいかなかったのは、そもそもAIによる生成が苦手な類の画像だった可能性があるのと、自分のプロンプティング技術がよわよわな可能性がある。やれたのはキーフレーム生成のseed値ガチャして何度か生成することだけで…。

感想

結局、手描きの絵の作業過程を捏造するみたいな用途には全然使えないっぽいのでうーんという気持ち。AIはいつもそうだ。何もかも自動で生成してくれると思っても、触ってみると思ったより不便で幻滅する。

早く来い来いシンギュラリティ。

スリランカ地名のシンハラ語・タミル語表記の調べ方

スリランカの地名

スリランカ公用語シンハラ語タミル語であり、両言語の話者を繋ぐ共通語として英語が指定されている。

スリランカの地名の英語表記を調べるのは比較的容易だが、その地名のシンハラ語タミル語表記をネットで探すのはなかなか難しい。

スリランカにはProvince, District, DS Division, GN Divisionの順に細かくなる4段階の自治体区分がある。DS Division程度まではWikipediaとかにシンハラ語タミル語表記が書かれていたりするが、GN Divisionまでになってくるとなかなか出てこない。
例えば紅茶のブランドで知られるディンブラはGN Divisionのようだ。

調べ方

ここで検索するとシンハラ語タミル語表記が調べられる。

例えば、Search Villageのところに「dimbula」と入力すると次のような検索結果が出てくる。

「dimbula」での検索結果

これには名前にDimbulaを含む別の地名もリストアップされている。
上表の2列目の、Typeが「Grama Niladhari Division」、Sinhala Nameが「දිඹුල/ திம்புல/ Dimbula」となっているものが、Dimbulaのシンハラ語/タミル語/英語表記に対応する*1

備考

Province, District, DS Division, GN DivisionそれぞれにコードCodeが振ってあり、これらをハイフンでつないだものがLocation Codeとして表示されている。

これとは関係ないが、GN Divisionには番号No.(といっても英字もついたりするようだが)が振ってあり、GN Divisionの特定に利用できるかもしれない。

なお、PDFに書かれているシンハラ語/タミル語はコピペしても正しいデータにならないことがほとんどであるので、自分で入力し直すことになる。

*1:Tamil Name欄とEnglish Name欄は飾りなのか空欄になっており、Sinhala Nameにスラッシュ区切りで全部入っている。なんで?