2019年10月13日

映画「蜜蜂と遠雷」

 見てきましたっ!! 期待に違わず、素晴らしかった!

20191013-1.jpg

 実は原作は読んでないんです。いいに違いない、とは思っていたんだけど、恩田陸さんの文体がちょっと苦手なもので。だから、大まかなあらすじだけの予備知識で臨みました。ただし、「おはよう日本」でやっていた松岡茉優さん・松坂桃李さん・石川慶監督のインタビューはしっかり見たし、あちこちの紹介記事も読んでいた。

 何が素晴らしかったって、音楽が、これ以上望みようがないぐらい見事だった。まず、演奏・作曲を担当するメンツがすごい。河村尚子・福間洸太郎(ごめんなさい、この人だけ知らなかった)・金子三勇士・藤田真央の各氏がピアノ演奏担当。そして、「春と修羅」の新作書き下ろし。この作品を映画化する、と聞いた時、真っ先に思ったのが「『春と修羅』どうするんだろ?」ということだった。読んでないけど、新作課題曲である「春と修羅」が重要な役割を担っていることは知っていたから。その作曲を藤倉大さんが引き受けられたと聞いて、「これは製作陣、本気を出してきたな」と思った。このメンツに音楽パートを引き受けてもらって、下手な映画は作れないでしょ。相当プレッシャーだったんじゃないかな。

 2月にこの音楽担当メンバーが発表された時のそれぞれのコメントが、こちらのページに紹介されている。金子さんだけちょっと異質なんだよな。他の人はみな、原作に則って、音楽に詳しくない人でも受け止められるようにうまくコメントされているんだけど、金子さんは「プロコフィエフの2番は難曲で、自分の演奏がどう映像になったか楽しみ」と、そりゃそうなんだけどそれって今言う話か?的なコメントをされている。でも私は金子さんのこういうちょっとピンボケな感じが好きです。

 実はだいぶ昔に、岡崎の「コロネット」に金子三勇士さんが来られて、ソロコンサートをされたんですよ。コロネットは小さなホールなので、演奏者と聴衆の距離が近い。そういうコンサートで、金子さんは MC もされたんだけど、選曲の理由とか、演奏上の技術的なこととか、けっこう細かいことを思い入れたっぷりに語るので、聴衆は「?」という雰囲気になっていた。でも、話している金子さんがすごく楽しそうなんですよ。あれ以来、金子さんのファンになっている。CD やコンサートを追っかけするほど熱心ではないけど。

 映画の話に戻ると、河村尚子=栄伝亜夜=松岡茉優というのも、すごいキャスティングだった。河村尚子さんって、小柄だし、顔も可愛らしい印象じゃないですか。でも、演奏はすごくダイナミックで、フルオケと渡り合って一歩も引かない、豪腕でねじ伏せるような迫力がある。そのパワーがあるから、繊細な表現が逆に生きてくる。

20191013-2.jpg

 映画では、迷いを感じさせる予選(弾くシーンはない)、少し覚醒のきざしを見せる二次予選(「春と修羅」のカデンツァ)、出番の直前に再びやってきた深い迷いを振り切って、完全覚醒する本選(プロコの3番)。河村さんの演奏と、松岡さんの演技の両方が、大きな振り幅を持っているからできた表現だと感じた。

 あと、本選で藤田真央=風間塵=鈴鹿央士が弾いたバルトーク3番もすごく良かった。バルトークってもともと、生涯戦い続けた人じゃないですか。しかも、この曲を書いた時はもう死にかけてた。だから、曲想は明るいはずなのに、どこかに「陰」を感じてしまうんですよ。でも、塵くんのバルトークにはそういうのがなかった。軽やかで楽しげなバルトーク。全曲聴きたい!

 福間洸太郎=高島明石=松坂桃李にも一言触れておかなくちゃ。本選には進めなかったけど、「生活者の音楽」は敗北してない。あなたの「春と修羅」は、アカデミックな音楽家には届かなかったかもしれないけど、地べたに生きる人たちにはちゃんと届いていた。そのことが逆に明石に伝わって、彼に勇気を与えてくれたらいいなと思う。

タグ:映画 音楽
posted by toshinagata at 17:33| 日記

2019年10月12日

和田誠さん逝去

 享年83歳。あらゆる方面ですばらしい才能を発揮した人だった。思い出す作品はたくさんある。印象深いのは、谷川俊太郎さんとのコラボ作品。絵本の「これは のみの ぴこ」や「ともだち」、「けんはへっちゃら」など、エッセイ集の「ナンセンス・カタログ」、それからショートショートの「ペ」もそうだったんじゃないかな(手元にないからわからん)。もちろん、単著もすばらしい。「倫敦巴里」には衝撃を受けた(と同時に思い切り笑った)。私は洋画をほとんど見ないので、映画関係のところはよくわからんかったけどね。

 すごく好きなエピソードが一つある。丸谷才一さんのエッセイ(「男ごころ」収録)に書かれていたものだ。プロ野球の西武ライオンズのロゴマークは手塚治虫氏によるものだが、その制作がライト・パブリシティ社に依頼された時、和田さんは同社とつきあいがあったそうだ。

「ですから、もしあのとき、ぼくにやらせろと頑張つたら……」
「なるほど」
「……西武は今ほど強くないかもしれませんね」
と和田さんは謙虚である。奥床しい。

(丸谷才一「男ごころ」 新潮文庫)

 いつかは来る別れの時だが、やはり寂しい。安らかにお眠りください。

タグ:読書 社会
posted by toshinagata at 23:54| 日記

2019年10月09日

ZeroBrane Studio すごいぞ

 wxLua の現在のメンテナー(と言っていいだろう) pkulchenko 氏謹製の Lua 専用 IDE, ZeroBrane Studio。誰かが "*THE* IDE for Lua" (Lua IDE の決定版)と書いていた。ほんとその通りですね。スクリプト言語がこんなに簡単にデバッグできるなんて、と感動してしまう。

20191009-1.png

 開発中の wxLuaApp もこれでデバッグできるようにしたいと思ったが、どうもうまくいかない。原因がよくわからないので、ZeroBrane Studio とデバッグ対象プログラムの間のソケット通信を解読して、自力で実装しようとしている。一応それなりには動くようになった。いろいろ穴があるので改良中。今は通信コードを Lua で書いているが、かなり重いので、ゆくゆくは C で書き直したいところ。

posted by toshinagata at 20:49| 日記

2019年10月06日

「おまじない」(西加奈子著、筑摩書房)

 西さんの小説、初めて読了しました。

20191006-1.jpg

 帯に「女子たちの背中をそっと押してくれる魔法のひとこと−」とある。いろいろと背伸びして、頑張って生きて、でもそういうことに実は疲れていて、思い悩んでいる女性たち。そんなときに、彼女らの心に届く言葉がある。何か劇的なことが起きるわけではないんだけど、どんよりした雲が少し薄らいで見える、そんな感覚がある。

 言葉を発する人は、どれも男性である。それも、はたから見てあまりぱっとしない人であることが多い(「孫係」のおじいちゃまはちょっと違うけど)。この短編集は、そういう設定の世界なのだろう。女性が女性の言葉に救われる話を読みたい人は、他の本を読めばいい。「ぱっとしない人」とは、たとえばいちごのことしか頭にない田舎のじいさんとか、まったくうだつの上がらない売れない芸人とか、むやみに物識りだけど仕事もせずに90歳の母親のスネをかじっているおっさんといった面々である。そういう人たちの言葉に、なんともいえない「優しさ」がにじみ出ている。

 西さんは、こういう人たち、つまり悩んでいる女性たちと、その周りにいるぱっとしない男性たち、に愛おしさを感じているんだろうな、と思う。

なんてダサい、そして下衆な人間なのだろう。

私は弱い。

立ち上がると、視界がなんだかクリアだった。薄くはっていた膜がぽろりと取れた。(「マタニティ」)

 ダサくても、下衆くても、弱くても、そのまま生きていくんだ、という実感。それは、「ありのままでいいんだよ」という応援メッセージともちょっと違う。もう少し、「生きていく」ことの面倒くささまでも包み込んだ上での実感が、この短編集にはある。これはきっと、西さんの人生観でもあるんだろうな。

タグ:読書
posted by toshinagata at 14:14| 日記

2019年09月22日

LuaHPDF + wxWidgets で日本語 PDF

 「LuaHPDF:日本語の PDF 文書を作る」のつづき。Mac, Windows のクロスプラットフォームにしようと思って、また一苦労した。

 先日のコードでは、フォントのファイルパスを /Library/Fonts/Microsoft/MS Gothic.ttf とハードコーディングしている。これを何とかできないか、せめて「フォント名」を指定して、そこからフォントファイルを探すようにできないかと考えた。しかし、Windows ではこれが非常に難儀だった。どうやら、公式の API は存在しないようで、レジストリを自力で探すか、フォント名からデータを取得してファイルの内容と突き合わせるか、非公開の API を使うか、そんな方法しかないらしい。

 今作成しているプログラムでは、フォントは「MSゴシック」固定でも特に問題はないので、下のように対応することにした。フォントのファイルパスはハードコーディングしておき、見つからなければ埋め込み無しの「MS-Gothic」を使う。

-- プラットフォーム名。"Mac", "Windows" などになる
local platform = string.match(wx.wxGetOsDescription(), "^(%S*)")
local pdf = hpdf.New()
local page = hpdf.AddPage(pdf)
local height = hpdf.Page_GetHeight(page)
local width = hpdf.Page_GetWidth(page)
hpdf.UseJPEncodings(pdf)
local font_name
--  MS ゴシックの ttf/ttc があれば使う、なければ UseJPFonts の MS-Gothic を使う
if platform == "Mac" then
  font_name = hpdf.LoadTTFontFromFile(pdf, "/Library/Fonts/Microsoft/MS Gothic.ttf", 1)
elseif platform == "Windows" then
  font_name = hpdf.LoadTTFontFromFile2(pdf, "c:\\Windows\\Fonts\\msgothic.ttc", 0, 1)
end
if font_name == nil or font_name == "" then
  hpdf.UseJPFonts(pdf)
  font_name = "MS-Gothic"
end

 もう一つ、地味に面倒なのが、UTF-8 文字列を Shift-JIS 文字列に変換する方法。UTF-8 と Shift-JIS の文字の並びには何の関連性もないので、表を引くしかない。車輪の再発明は避けて、それぞれの OS の機能を素直に使う。Lua の関数として実装した。

/*  UTF-8 string to CP932 (Windows Shift-JIS) string  */
static int
utf8_to_sjis(lua_State *L)
{
    size_t len;
    const char *utf8 = lua_tolstring(L, -1, &len);
    if (utf8 == NULL)
        luaL_error(L, "Cannot get string");
    
#if defined(WIN32)
    size_t widelen, sjislen;
    wchar_t *wide;
    char *sjis;
    widelen = MultiByteToWideChar(CP_UTF8, 0, utf8, -1, NULL, 0);
    wide = calloc(widelen + 1, sizeof(wchar_t));
    if (wide == NULL)
        goto error_alloc;
    if (MultiByteToWideChar(CP_UTF8, 0, utf8, -1, wide, widelen + 1) == 0) {
        free(wide);
        goto error_conv;
    }
    sjislen = WideCharToMultiByte(CP_THREAD_ACP, 0, wide, -1, NULL, 0, NULL, NULL);
    sjis = calloc(sjislen + 1, sizeof(char));
    if (sjis == NULL) {
        free(wide);
        goto error_alloc;
    }
    if (WideCharToMultiByte(CP_THREAD_ACP, 0, wide, widelen + 1, sjis, sjislen + 1, NULL, NULL) == 0) {
        free(wide);
        free(sjis);
        goto error_conv;
    }
    lua_pop(L, 1);
    lua_pushlstring(L, sjis, sjislen);
    free(wide);
    free(sjis);
    return 1;
#elif defined(__APPLE__)
    CFStringRef ref = CFStringCreateWithBytes(kCFAllocatorDefault, (const UInt8 *)utf8, len, kCFStringEncodingUTF8, false);
    if (ref == (CFStringRef)0)
        goto error_conv;
    size_t widelen = CFStringGetLength(ref);
    char *sjis = (char *)calloc(widelen * 2 + 1, sizeof(char));
    if (sjis == NULL) {
        CFRelease(ref);
        goto error_alloc;
    }
    if (!CFStringGetCString(ref, sjis, widelen * 2 + 1, kCFStringEncodingDOSJapanese)) {
        CFRelease(ref);
        free(sjis);
        goto error_conv;
    }
    lua_pop(L, 1);
    lua_pushlstring(L, sjis, strlen(sjis));
    free(sjis);
    CFRelease(ref);
    return 1;
#endif
error_conv:
    luaL_error(L, "Cannot convert");
error_alloc:
    luaL_error(L, "Cannot get string");
    return 0;
}
posted by toshinagata at 12:03| 日記

2019年09月21日

LuaHPDF:日本語の PDF 文書を作る

 「Lua で PDF 作成:LuaHPDF」のつづき。日本語を含む PDF 文書を作るには、次の関数を使う。

  • hpdf.UseJPFonts(): 日本語の「MS明朝」「MSゴシック」「MSP明朝」「MSPゴシック」の4つのフォントを使えるようにする。
  • hpdf.UseJPEncodings(): 日本語の「90ms-RKSJ-H」「90ms-RKSJ-V」「90msp-RKSJ-H」「EUC-H」「EUC-V」エンコーディングを使えるようにする。
package.cpath = "./?.dylib;" .. package.cpath
--  "mysampleあいうえお" をシフトJISで表記
local s = "mysample\\130\\160\\130\\162\\130\\164\\130\\166\\130\\168"
hpdf = require "hpdf"
local pdf = hpdf.New()
local page = hpdf.AddPage(pdf)
local height = hpdf.Page_GetHeight(page)
local width = hpdf.Page_GetWidth(page)
hpdf.UseJPEncodings(pdf)
hpdf.UseJPFonts(pdf)
local font = hpdf.GetFont(pdf, "MS-Gothic", "90ms-RKSJ-H")
hpdf.Page_SetFontAndSize(page, font, 24)
hpdf.Page_BeginText(page)
hpdf.Page_TextOut(page, 60, height - 60, s)
hpdf.Page_EndText(page)
hpdf.SaveToFile(pdf, "jp_from_haru.pdf")
hpdf.Free(pdf)

 できました。

20190921-1.png

 Windows 以外の環境だと「MS……」というフォントは標準搭載ではない。私の環境では、Mac でも Microsoft Office が入れてあるので、「MS……」が後からインストールされている。「MS……」が入っていない環境ではどう見えるか。VirtualBox に Debian を入れて、チェックしてみた。表示しているのは、ファイルビューアーの Evince。小文字の m のスペーシングがおかしい。

20190921-2.png

 代替フォントで何が使われているかは、「プロパティ」で見ることができる。DroidSansFallback だそうです。

20190921-3.png

 埋め込みなしで「MS……」を指定して PDF を作成するのは、「使う人がほぼ必ず『MS……』フォントをインストールしている」という環境では実用的と言える。だけど、そもそも PDF は「どういう環境でも同じように表示できる」ことを期待して使うことが多い。ということは、haruPDF で文書を作成する場合でも、フォントを明示的に指定して、埋め込む方がいい。

 「MSゴシック」を明示して埋め込んでみた。hpdf.UseJPFonts() をやめて、代わりに hpdf.LoadTTFontFromFile() を使う。

package.cpath = "./?.dylib;" .. package.cpath
hpdf = require "hpdf"
--  "mysampleあいうえお" をシフトJISで表記
local s = "mysample\\130\\160\\130\\162\\130\\164\\130\\166\\130\\168"
local pdf = hpdf.New()
local page = hpdf.AddPage(pdf)
local height = hpdf.Page_GetHeight(page)
local width = hpdf.Page_GetWidth(page)
hpdf.UseJPEncodings(pdf)
--hpdf.UseJPFonts(pdf)
--font_name = "MS-Gothic"
local font_name = hpdf.LoadTTFontFromFile(pdf, "/Library/Fonts/Microsoft/MS Gothic.ttf", 1)
local font = hpdf.GetFont(pdf, font_name, "90ms-RKSJ-H")
hpdf.Page_SetFontAndSize(page, font, 24)
hpdf.Page_BeginText(page)
hpdf.Page_TextOut(page, 60, height - 60, s)
hpdf.Page_EndText(page)
hpdf.SaveToFile(pdf, "../jp_from_haru2.pdf")
hpdf.Free(pdf)
print("../jp_from_haru2.pdf created")

 Debian で表示してみた。うまくいきました。

20190921-4.png

 「プロパティ」で確認する。フォントが埋め込みされている。

20190921-5.png

 残念ながら、Mac に標準でインストールされている日本語フォントは、うまく埋め込みできなかった。ヒラギノ系も Osaka も "Unsupported ttf format." というエラーが出る。ヒラギノ系は OpenType なのでしょうがないとしても、TrueType の Osaka は読めて欲しかった。

posted by toshinagata at 16:50| 日記

2019年09月14日

Lua で PDF 作成:LuaHPDF

 wxWidgets アプリを Lua で記述する wxLuaApp。これで PDF を作成したいと思ったのだが、wxWidgets には PDF 関連の API がない。誰か作ってるでしょ、と「Lua PDF」で検索すると、「Lua 関連の PDF 文書」が大量にヒットして、なかなか有益な情報にたどりつかない。PDF 関連の情報をネット検索で探すのは、案外面倒なんですね。

 「Lua PDF create」で探して出てきた、LuaHPDF が良さげだったので、試してみた。

20190914-1.png

 「Haru Free PDF Library」の Lua バインディングらしい。そうか、このライブラリは前に一度調べたことがあったな。オリジナルの作者が日本人なので、日本語対応がちゃんとしている。これは大事なポイントです。

20190914-2.png

 使い方の方針を決めておかないといけない。今回は、Lua スクリプトから見える場所に hpdf.dylib (Mac) または hpdf.dll (Windows) を置いて、hpdf = require "hpdf" で読み込むようにする。動的ライブラリは1個だけにしたいので、libHaru は静的にリンクすることにする。

 まず libHaru と luaHPDF をダウンロードする。

$ curl -L https://github.com/libharu/libharu/archive/RELEASE_2_3_0.zip >libharu-RELEASE_2_3_0.zip
$ unzip libharu-RELEASE_2_3_0.zip
$ curl -L https://github.com/jung-kurt/luahpdf/archive/master.zip >luahpdf-master.zip
$ unzip luahpdf-master.zip

 ここで大事なお知らせ。libHaru は libpng, zlib に依存します。Mac では、zlib はシステム標準のものを使う。libpng は X11 関連のライブラリにあるが、インストールされていない可能性もあるので、自前でビルドして静的リンクする。Windows では、両方自前でビルドすることにする。libHaru, luaHPDF と同じ階層に、libpng_zlib というディレクトリを作って、その中に zlib, libpng をインストールする。

$ mkdir libpng_zlib
$ cd libpng_zlib
$ curl -L https://download.sourceforge.net/libpng/libpng-1.6.37.tar.gz >libpng-1.6.37.tar.gz
$ tar xzf libpng-1.6.37.tar.gz
$ curl -L https://www.zlib.net/zlib-1.2.11.tar.gz >zlib-1.2.11.tar.gz
$ tar xzf zlib-1.2.11.tar.gz

 Mac 用のビルド。libpng を libpng_zlib/build-osx にインストールする。SDK として /Developer/SDKs/MacOSX10.6.sdk を指定する。--disable-shared--enable-static を指定して、静的ライブラリのみ作成する。

cd libpng-1.6.37
$ CFLAGS="-isysroot /Developer/SDKs/MacOSX10.6.sdk" CPPFLAGS="$CFLAGS" ./configure --prefix=$PWD/../build-osx --disable-shared --enable-static
$ make
$ make install

 libHaru のビルド。これも静的ライブラリのみ作成する。

$ cd ../../libharu-RELEASE_2_3_0
$ export SDK=/Developer/SDKs/MacOSX10.6.sdk; CFLAGS="-isysroot $SDK" ./configure --prefix=$PWD/build-osx --disable-shared --enable-static --with-sysroot=$SDK --with-png=$PWD/../libpng_zlib/build-osx --with-zlib=$SDK/usr
$ make
$ make install

 luaHPDF のビルド。ファイル1個だけなので、Makefile を書くより手打ちの方が早い。LuaJIT は、wxLuaApp の中でビルドしたものをリンクする。

$ cd ../luahpdf-master
$ gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -I../wxLuaApp/LuaJIT-2.0.5/src -I../libpng_zlib/build-osx/include -I../libharu-RELEASE_2_3_0/build-osx/include -Wall -O2 -fomit-frame-pointer -fPIC -c -o hpdf.o hpdf.c
$ gcc -shared -fPIC -isysroot /Developer/SDKs/MacOSX10.6.sdk -o hpdf.dylib hpdf.o -L../wxLuaApp/build-xcode/build/lib -L../libpng_zlib/build-osx/lib -L../libharu-RELEASE_2_3_0/build-osx/lib -lhpdf -lz -lpng -lm -lluajit-5.1

 できた!

$ ls -l *.dylib
-rwxr-xr-x  1 nagata   staff  1176140  8 29 23:28 hpdf.dylib

 試してみる。

package.cpath = "./?.dylib;" .. package.cpath
hpdf = require "hpdf"
local pdf = hpdf.New()
local page = hpdf.AddPage(pdf)
local height = hpdf.Page_GetHeight(page)
local width = hpdf.Page_GetWidth(page)
local font = hpdf.GetFont(pdf, "Helvetica")
hpdf.Page_SetFontAndSize(page, font, 24)
hpdf.Page_BeginText(page)
hpdf.Page_TextOut(page, 60, height - 60, "Hello from Haru")
hpdf.Page_EndText(page)
hpdf.SaveToFile(pdf, "hello.pdf")
hpdf.Free(pdf)

 できました。

20190914-3.png

 次は Windows (64 bit) のビルド。zlib でちょっと手こずった。

$ cd path/to/libpng_zlib
$ cd zlib-1.2.11
$ CHOST=x86_64-w64-mingw32 ./configure --prefix=$PWD/../build-win --static
...
Please use win32/Makefile.gcc instead.

 えー、大きなお世話じゃ。win32/Makefile.gcc は 32bit 限定なので、64bit 版はビルドできない。仕方がないので、configure に手を入れた。

  MINGW* | mingw*)
# temporary bypass  次の3行をコメントアウト。
        #rm -f $test.[co] $test $test$shared_ext
        #echo "Please use win32/Makefile.gcc instead." | tee -a configure.log
        #leave 1

 再トライ。今度はうまくいった。

$ CHOST=x86_64-w64-mingw32 ./configure --prefix=$PWD/../build-win --static
$ make
$ make install

 次は libpng。CFLAGSCPPFLAGS を両方指定しないといけない。気づくのに時間がかかった…

$ cd ../libpng-1.6.34
$ CFLAGS="-L$PWD/../build-win/lib" CPPFLAGS="-I$PWD/../build-win/include" ./configure --prefix=$PWD/../build-win --host=x86_64-w64-mingw32 --disable-shared --enable-static
$ make
$ make install

 libHaru は特に問題なし。

$ cd ../../libharu-RELEASE_2_3_0
$ ./configure --prefix=$PWD/build-win --host=x86_64-w64-mingw32 --disable-shared --enable-static --with-png=$PWD/../libpng_zlib/build-win --with-zlib=$PWD/../libpng_zlib/build-win
$ make
$ make install

 luaHPDF のビルド。前に書いた通り、fopen をマルチバイト対応のものに置き換える必要があるので、win_fopen.o を作成してリンクする。

$ x86_64-w64-mingw32-gcc -I../wxLuaApp/LuaJIT-2.0.5/src -I../libpng_zlib/build-win/include -I../libharu-RELEASE_2_3_0/build-win/include -Wall -O2 -fomit-frame-pointer -fPIC -c -o hpdf.o hpdf.c
$ x86_64-w64-mingw32-gcc -I../wxLuaApp/LuaJIT-2.0.5/src -I../libpng_zlib/build-win/include -I../libharu-RELEASE_2_3_0/build-win/include -Wall -O2 -fomit-frame-pointer -fPIC -c -o win_fopen.o win_fopen.c
$ x86_64-w64-mingw32-gcc -shared -fPIC -o hpdf.dll hpdf.o win_fopen.o -L../wxLuaApp/build-win/build/lib -L../libpng_zlib/build-win/lib -L../libharu-RELEASE_2_3_0/build-win/lib -lhpdf -lpng -lz -lm -llua51

 できた。

$ ls -l *.dll
-rwxr-xr-x  1 nagata   staff  1926112  9 11 21:57 hpdf.dll

 日本語 PDF を作成するには、Lua の文字列を Shift-JIS (CP932 = Microsoft Code Page 932) に変換する必要がある。libHaru は日本語エンコーディングとして CP932 か EUC しか対応してないためである(libharu:Encodings)。この件は後日。

posted by toshinagata at 22:44| 日記

2019年09月07日

アメリカの銀行口座を解約した

 20年以上前にアメリカに滞在していた時に作って放置していた銀行口座を、やっと解約しました。いろいろ調べたので、メモしておく。自分が今後使うことはないと思うけど。

 銀行は Wells Fargo Bank です。口座を作った時は Norwest Bank だったけど、合併して Wells Fargo に吸収されたみたい。とりあえずウェブサイトに行ってみたけど、解約の手続きがなかなかわからなかった。オンラインの相談サービスとかないのかと思ったけど、オンラインバンキングみたいなのを契約してないとだめっぽい。探し回って、やっと見つけた。Customer Service → Checking and Savings Help → Opening and Closing Accounts Questions のところ。見つかってみれば、そりゃここだろう、と思う場所ではある。

20190907-1.png

 解約の書類に記入して郵送しろ、と書いてあるので、書類をダウンロードする。一番最初に "Notarization is required" と書いてある。これが曲者なんですね。

20190907-2.png

 Notarization というのは、書類のサインが「正式なもの」であることを証明するためのもの。アメリカではよく必要になるので、Notary Public(公証人役場)がそこらじゅうにある。ところが、これは「アメリカの法律に基づく証明制度」だから、日本国内には当然存在しない。以前解約手続きについて調べた時、「アメリカ領事館に行けば notarization が可能」という情報を得たんだけど、なんだかハードルが高そうで、断念したのだった。

 解約書類を読み進めて、Notarization のページに来ると、こんなことが書いてある。

20190907-3.png

 アメリカ国外で notarization を受けるには、大使館・領事館に問い合わせるか、政府機関でサインの正当性を証明する "Apostille Guarantee" を取れ、と書いてある。ほう、領事館以外の方法もあるんだ。Apostille Guarantee ってなんだ、と調べてみると:

「外国公文書の認証を不要とする条約(略称:認証不要条約)」(1961年10月5日のハーグ条約)に基づく付箋(=アポスティーユ)による外務省の証明のことです。提出先国はハーグ条約締約国のみです。アポスティーユを取得すると日本にある大使館・(総)領事館の領事認証があるものと同等のものとして、提出先国で使用することができます。

外務省「公的確認・アポスティーユとは

 じゃあ、そのアポスティーユはどうやって発行してもらうんだ、というと、こういう流れだそうです。

20190907-4.png

外務省「申請手続きガイド・申請の流れ」より

 一般的には、日本の公証役場に行って、私文書の認証をしてもらったあと、法務局長に押印証明してもらい、それをさらに外務省に提出して証明を受ける、という手順。時間がかかりそう。ところが、東京・神奈川・大阪の公証役場なら、いきなりアポスティーユまで受け取れるらしい。これは、帰省した時に大阪の公証役場に行くのが手っ取り早いな。

 8月の超暑い日、梅田公証役場に出向いた。予約はできないとのことだったので、待たされるかもしれないなと思っていたが、そうでもなかった。到着してすぐに受け付けしてくれ、しばらくして担当の公証人さんのデスクに案内された。身分証を出して、書類の所定の場所に自分のサインをして、しばらく待つと、書類ができあがってきた。全部で30分もかからなかったと思う。手数料は 11,500 円。けっこうかかりますね。

20190907-5.png

 アポスティーユのついた解約書類を、Wells Fargo Bank の Exception Payment 係に郵送する。残金は International Wire Transfer で自分の銀行口座に送ってもらうことにした。SWIFT code というのが必要になりますが、これは銀行のホームページで「外国送金」のところを調べると出てきます。

 しばらく経つと、こういうお手紙が来ました。電話しろ、ちゅうことなんですよね。めんどくさい…

20190907-6.jpg

 電話で、英語で、銀行員との会話なんて、できるわけないじゃないですか。日本語でも怪しいのに(苦笑)。でも、仕方がないので、聞かれそうなことをいろいろ準備して、日本時間の夜12時(太平洋時間の朝8時)に電話。向こうの言ってることは2割ぐらいしか聞き取れないけど、上の手紙の "EP-...." という番号を伝えて、"Wire Transfer" 希望、と伝えると、後でこちらから折り返し電話する、と言われました。さあ、何時にかかってくるんだ!? 電話機を枕元に置いて就寝。

 日本時間の朝8時(現地の夕方4時)に電話が来ました。ちゃんとこちらの時間を配慮してくれたんですね。これも、言ってることが2割ぐらいしかわかんないんだけど、「生年月日」「口座を開いた時の Social Security Number」「口座を開いた場所と時期」を聞かれました。無事確認できて、そのあと、向こうの担当者と、国際送金の担当者との3者の電話会話になりました。向こうの2人が私の名前、住所、口座番号などをやりとりしている様子が聞き取れた。終わったあと、確認してくれて、最後はたぶん「月曜日に送金手続きする」と言ってたような気がする。この電話は20分ぐらいかかりました。疲れた…。

 あとは送金が無事届くかどうか。これが届かなかったらまためんどくさいんだけど、とりあえずは待つ。

 2019.9.13. 追記。無事送金が届きました。これにて一件落着。

タグ:社会
posted by toshinagata at 17:58| 日記

2019年09月01日

wxLuaApp: Windows の日本語ファイル名に苦戦

 wxWidgets アプリを Lua で記述する wxLuaApp。wxWidgets 3.0 系列でビルドできるようにするパッチをPaul Kulchenkoさんに送ったら、採用してもらった。これを機会に、こちらのプロジェクトの構成も少し整理して、開発を続けている。

 Mac でだいたい動くようになったので、Windows でもビルドしてみた。動くには動くんだけど、日本語のファイル名が通らない。調べてみると、Windows の fopen 関数は、マルチバイト文字のファイル名に対応していない。文字列を wchar_t の配列に変換して、_wfopen 関数を使うように指定されている。

Fopen関数は、 filenameによって指定されたファイルを開きます。 既定では、ナローファイル名の文字列は、ANSI コードページ (CP_ACP) を使用して解釈されます。 ... _wfopenは、 fopenのワイド文字バージョンです。 _wfopenの引数はワイド文字列です。 それ以外の場合、 _wfopenfopenは同じように動作します。

fopen, _wfopen: Visual Studio 2019 の関数リファレンス

 対策は、原理的にはそれほど難しくない。自前の fopen 関数を書いて、UTF-8 で書かれたファイル名をマルチバイト文字列に置き換えて、_wfopen を呼べばいい。コーディングも難しくない。

/*  win_fopen.c  */
/*  2019.8.31. Toshi Nagata  */
/*  Public Domain  */

#if _WIN32 || _WIN64
#include <Windows.h>
#include <stdio.h>
static int utf8towchar(const char *utf8, wchar_t **outbuf)
{
  size_t buflen = MultiByteToWideChar(CP_UTF8, 0, utf8, -1, (void *)0, 0);
  wchar_t *buf = calloc(buflen, sizeof(wchar_t));
  if (MultiByteToWideChar(CP_UTF8, 0, utf8, -1, buf, buflen) == 0) {
    free(buf);
    return -1;
  }
  *outbuf = buf;
  return 0;
}

FILE *
fopen(const char *path, const char *mode)
{
  wchar_t *wpath, *wmode;
  FILE *f;
  if (utf8towchar(path, &wpath) != 0 || utf8towchar(mode, &wmode) != 0)
    return NULL;
  f = _wfopen(wpath, wmode);
  free(wpath);
  free(wmode);
  return f;
}
#endif

 大苦戦したのは、これをどうやって組み込むか。wxLuaApp は、LuaJIT 2.0.5 の動的ライブラリとリンクしている。LuaJIT の中から fopen を呼び出しているところがいくつもあるので、これをどうやって自前の関数で置き換えるかが、なかなかわからなかった。試行錯誤の結果、次のやり方でうまくいくことがわかった。

  • win_fopen.c をコンパイルして win_fopen.o を作っておく。
  • LuaJIT の動的ライブラリ lua51.dll のリンクの時に win_fopen.o をオブジェクトファイルとして追加する。LuaJIT の make を走らせる時に、TARGET_SHLDFLAGS="path/to/winfopen.o" を引数として指定すればよい。
  • wxLuaApp をビルドする時にも、win_fopen.o をリンクする。

 DLL とアプリ本体の両方を win_fopen.o とリンクするのがポイントだった。win_fopen.o のコードがダブってしまうが、これは止むを得ない。(wxLuaApp 本体が lua51.dll の中の fopen を使ってくれればいいのだが、どうやっても msvcrt.dllfopen が優先されてしまう。リンクの順序を変えてもうまくいかなかった。)

 なお、DLL やアプリ本体の .exe ファイルなどが、どの動的ライブラリのどの関数を呼び出しているかは、objdump を使うとわかる。-p オプションを使うと、下のように動的ライブラリごとに使用する関数が出力される。

$ x86_64-w64-mingw32-objdump -p lua51.dll | less
        ...
        DLL Name: msvcrt.dll
        vma:  Hint/Ord Member-Name Bound-To
        679f8      59  __DestructExceptionObject
        67a14      80  __doserrno
        67a22      84  __iob_func
        67a30      95  __pioinfo
        67a3c     126  _amsg_exit
        ...
        67ce0    1235  tmpfile
        67cea    1237  tmpnam
        67cf4    1243  ungetc
        67cfe    1245  vfprintf

 msvcrt.dll 由来の関数の中に fopen があると、日本語ファイル名が正しく開けない。正しく対策すると、msvcrt.dll の関数リストから fopen が消える。

posted by toshinagata at 10:36| 日記

2019年08月24日

名古屋の地下鉄:問題は駅名なのか?

 先日、所用で名古屋市の中区役所に向かっている途中、ネットでこんなニュースを見かけた:「聞いてみたらツッコミ続出! 名古屋の地下鉄の駅名は「長い」「読めない」「分かりづらい」」(東海テレビニュース)。御器所とか新瑞橋とか、確かに難読だけど、地名なんだからしょうがないでしょ。他の地域の駅名と比べて、特別に難しいとは思わんけどなあ。

 私が名古屋市営地下鉄の駅名で「これはいかがなものか」と思ったのは2点。一つは、「徳重」(桜通線)と「徳重・名古屋芸大」(名鉄犬山線=鶴舞線が乗り入れ)が重複していること。桜通線の徳重駅の方がだいぶ後にできたのに、同じ名前にするってめちゃくちゃケンカ売ってませんか。もう一つは、「総合リハビリセンター」のローマ字表記が "Sogo Rihabiri Center" になっていること。"Sogo" はいいとして、"Rihabiri"(英語でも日本語でもない)、"Center"(ここだけ英語表記)というバラバラ感がなんとも気持ち悪い。この駅看板を見るたびに、恥ずかしくて目を伏せたくなる。(あおなみ線の「ささしまライブ」Sasashima Raibu も同様。)

 それよりも、名古屋の地下鉄の大きな問題点は、通路の案内表示がわかりにくいことだと思う。地下鉄駅に限らず、名古屋の地下街は全般的にそう。「道をよく知らない人が、案内表示を頼りに歩く」ことが、全く想定されていない。

 例えば、中区役所は栄駅の12番出口が最寄りなので、名城線の南改札口から12番出口に向かう。途中に「1〜16番出口」と書かれた階段があるので、そこを昇っていくと、表示がこうなるわけですよ。

20190824-1.jpg

 え、12〜16番はどこいった? と思いますよね。左右を見回しても、どこにも案内がない。実は、この地点で「回れ右」をすると、そちらに「12〜16」という案内があるんです。でも、ここで回れ右するって、かなりのトラップじゃないですか? 大昔のアドベンチャーゲームみたいだ。

 中区役所からの帰りも、なかなかのトラップです。地下鉄の入り口はすぐわかるんだよ。

20190824-2.jpg

 ところが、階段を降りるとこうなる。案内板なし! どちらに行けと?

20190824-3.jpg

 きょろきょろ見回すと、右の遠くの方に案内板を発見。でも、「東山線」としか書いてない。名城線に乗りたいんですけど。

20190824-4.jpg

 …とまあ、万事がこういう具合なわけですよ。駅名を変えるのも結構だけど、こういうところを地道に改善していってもらいたいところです。

タグ:社会
posted by toshinagata at 21:38| 日記
email.png
Powered by さくらのブログ