Archive for the ‘Linux’ Category

濁音に苦労した話」の続きである。元の稿に加筆したように、SpotifyのAPIで取れる曲情報でもcombining charactersが使われている(= 本体と(半)濁点が分離している)場合があることが分かった。

確かに、APIとそれ以外で別の情報を格納して別々に出すのは無駄だし、合理的でない。

表示は文字列が綺麗に出ればいいが、APIで取った曲情報は自作の音楽再生履歴記録システム MlhiのDBに格納しているので、今ひとつ良くない。というのは、今はまだ完全でない(イマイチな)ので余り使っていないが、将来は自分が聴いた曲をフレキシブルに(要するに、手軽に思ったとおりに)検索できるようにする予定で、その時に、combining charactersの濁音や半濁音を含む曲が出て来ない可能性があるからだ。

そういえば、以前、なぜか検索出来ない曲があったが、それだったのかも知れない。

(1/27 14:55) ちなみに、DBを調べたところ、曲情報(タイトル、アーティスト名、アルバム名、アルバムアーティスト)のいずれかにcombining characters(濁音、半濁音)が使われているものは、延べ27曲だった。DB全体は約1万曲なので、割合は約0.3%未満と少ない。ただ、僕は洋楽やクラシック音楽を聴くことが多く、曲情報が英語のものが多いから、日本の曲での割合は数%くらいではないか。

これを解決するには、以下の方法が考えられる。

  1. DBに正規化した曲情報を格納する。
    • 今までにDBに格納した内容は正規化する。
  2. 検索時に、検索文字列とDBの内容を正規化して比較する。
    • DBには、取得した情報をそのまま格納する。
  3. × 検索時に、検索文字列として、正規化したものとそうでないものを両方指定する。
    • 正規化された文字を逆変換(分離)するのが面倒そうだが、uconvでできそうだ(本当?)。
    • 曲情報に正規化されている文字と そうでないものが混ざっているので、検索パターンが多くなり過ぎる。

Bが筋が良さそうだが、結構面倒そうだ(そもそも、DBに使っているSQLiteはUnicodeのこういう処理に対応しているのだろうか??※)。一方、前者は やればできそうなので、そうすることにした。

sqlean: All the missing SQLite functionsというソフトがあり、それは限定的なUnicode処理機能(upper/lower, like, unaccent)を持つので、SQLite自体は対応していないようだ。

ここで問題になったことがある。: 前の稿に書いたように、uconvで正規化すると、かな に正規化漏れが起こるのと、漢字の旧字体が新字体に変換されてしまう。前者は自作の処理(テーブル変換)で対応できているが、後者に対応するには、日本語の文字(漢字)を正規化しない必要がある。※

※幸い、日本語の漢字には濁点のような着脱可能な要素が なさそうなので、正規化対象から除外するだけで良い。ただ、例えば「辶」(しんにょう)のように、場合によって個数が違う点のような要素はある(→ 興味深い読み物があった)。が、それは純粋に文字の形の問題と思われ、意味や読みは変わらないので別件としたい。

他には、たまに、富と冨ののような着脱可能っぽい点はあるが、それらは同じ文字らしいし、相互に入れ替えて意味を変えることはないので(しんにょうと同様に)ヨシ、だ。

そもそも、今までに、(遊びをのぞいてw)漢字に かな のように点や丸を付けて意味などを変えたことはないし、そういうことを教わったこともないから、それで良さそうだ。

UnicodeやICUに不慣れなので、日本語を除外して正規化することができるのか分からなかったが、いろいろ調べたら できそうなことが分かった。

Unicodeにはscriptという概念があり、Latin文字(いわゆる英字)、カタカナ、ひらがな、漢字※のようなカテゴリ(Unicodeにはcategoryという概念があるが、それではない)を示すことができる。それを使って、uconvの正規化ルール(日本語除外フィルタのようなもの)を指定すればできそうだ。

※実際には、Unicodeの資料では漢字は"Han"と書かれており、おそらく中・日・韓の漢字を一緒にしたもの(≒ CJK Unified Ideographs)を差していると理解している。

具体的には、以下のコマンドで日本語(正確には、漢字、ひらがな、カタカナ)以外の文字を正規化できるはずだ。

uconv -f utf-8 -t utf-8 -x '::[ [:^Katakana:] & [:^Hiragana:] & [:^Han:] ]; ::nfc;'

処理内容は、-xの最初のルール(最初の ; まで)でカタカナ、ひらがな、漢字を除外し、残ったものに正規化(NFC)を実行する("::nfc")。

実は、上の処理には欠陥がある。おそらく韓国語(ハングル文字)はcombining charactersをバリバリ使っているはずだが、それも除外されるのではないか(ハングル文字がHanに含まれているとした場合: 実際には、scriptには"Hangul"というのがあるから、ハングル文字はHanには含まれていなさそうだ)。

が、僕の好みからして、曲名などが韓国語で書かれた曲は聴かないだろうから、とりあえずは良しとする。あと、中国語には簡体字も繁体字もあるし(それは関係ないのかも知れないが)、どうなのか想像も付かないw

上の処理は、以下のテストパターンで うまく行った。

  • パ が 神: 正規化されずに出た。
  • (A + U+0304: Combining Macron): Ā (U+0100: Latin Capital Letter A with Macron)になった。※

を使ったのは たまたま最初に できた(macronなるものが付いた単体のĀがあった)からである。この文字がどういう意味なのか全く分からないし、実際に使われるのかも知らない。

と、出来そうになって気分がいいところで、「残りはあとで」にしたw

 

参考にしたページは以下である。

uconvに指定するルールの書き方は最初と2番目(特に後者)が参考になった。最後に残った謎(どうやって日本語を除外するか? そうするパターンをどうやって書くか?)を解く鍵になったのは、最後のUnicode Regular Expressionsだった。

それについては最初の2つを丹念に読めば分かったのだろうが、余りにも知らない概念が多いうえに機能が多過ぎてチンプンカンプンだった(→ 読む気が起こらなかった)。一方で、-Regular Expressionsは馴染みの正規表現の話なので良く分かった。※ 更に、Hanが かな を含むという思い違いに気付かせてくれて、上のルールが出来た。

※実際、このページを見付けた切っ掛けは、ICU(uconv)のルールが全然思ったように動かないので諦めて、grepで正規表現で除外しようと思い、「『漢字全部』の うまい指定」があればと思って"Unicode regexp"で検索したことだ。

ちなみに、grepは-PオプションでUnicodeに対応した動作(PCRE)になる。

 

PS. Unicode(ICU)の処理には、カタカナ→ローマ字みたいなものがあって(→ Script Transliterationの表の「キャンパス: kyanpasu」)、「誰が使うの?」と思う。ちゃんと動くのならいいが、正規化みたいに中途半端だったら実装するだけ無駄だし、ほとんどの開発者は知らないので、使われない気が・・・ (いやいや、僕が無知なだけだよね)

PS2. こういう細かい話は嫌いだけど好きだ。: 実装や確認は面倒でやりたくないけど、豆知識的に調べるのは好きだ。発展したのがタモリかw

  •  0
  •  0

Chromeブラウザはメモリを大食いするのでメインには使っていないが、追跡されたくないとかプロファイルを完全に分離したい場合などに使っている。それが数日前から、妙な感じになって居た。普通は、タブを多く開くと使用メモリ量が多くなって警告メールが来る※はずなのが、来なくなったのだ。

※システム全体がメモリ不足になるのを防ぐために、定期的に「大食いアプリ」のメモリ量をチェックして出すようにしている。

うるさくなくていいけど却って気持ち悪いのでw、手で使用メモリ量を確認したら確かに少ないようだ。そういえば、近頃バージョンが上がったので改良されたのかと思った。

ただ、不思議なことに、調べてもそういう情報がない。Chromeのリリースノートのようなページには、「詳細は追ってブログに出る」のようなことが書いてあったので、これから分かるのかも知れない(→ 調べると、97での変更内容は山ほどあるので出なさそうだ)。あるいは、Linux版(の情報)は どうでもいいのかも知れないw

なお、一つだけ、外部のページ"Google Releases New Version of Chrome With Extra Security and Memory Safety Features"(2022/1)に近いことが書いてあった。以下に引用する。

... it is important to note that Chrome 97 also incorporates several upgrades to how it uses and manages memory. A common complaint that several users tend to have about Chrome is that it uses too much memory, and to fix this the new version of Chrome is no longer going to keep user profiles and settings saved after it is exited completely which will prevent these settings from using RAM in the background.

ただ、良く読むと終了後の話のようなので、違うのかも知れない。

「それじゃ、同じChromeベースのVivaldiも?!」と期待して調べたら、残念ながら大食いだった。大体、1タブで370MBくらい食う。Firefox(96.0.1)は約230MBなので、約1.6倍だ。そして、最新のChrome(97.0.4692.99)を調べたら約220MB/タブと、わずかながらFirefoxより少ない。

Vivaldi(5.0.2497.48)のUA文字列には"Chrome/96"とあるから、ベースは一つ前のようで、メモリ削減の改良がされていないのだろうと想像した。

ここで、省メモリだという評判のあるEdgeを思い出した(これもChromeベースなので、省メモリになっているかも知れないとも思った)。大嫌いなMS製だが、もし かなり省メモリなら(我慢して)使うのもありだと思って試したら、約370MB/タブ(Edge 98)とVivaldiと同様だったのでがっかりした。

どうやら、省メモリなのはWindowsでの話のようだ。想像だが、ChromeやVivaldiもWindows版とLinux版ではメモリ管理方法が異なっていて、Linux版は ずさんでメモリを浪費しているのではないか? あるいは、Windowsではアプリの使用量は少なく見えるが、実際には陰で大量に使っているのかも知れない。

まあ、いずれにしても、Edgeを使う意味は全くないことが分かった(そもそも使いたくないから、それでいいw)。

 

参考までに、以下に、各ブラウザのタブ1個当たりのメモリ使用量(増分)をまとめる。

  • Firefox(96): 約230MB/タブ
  • Chrome(75): 約220MB/タブ
  • Vivaldi(5): 約370MB/タブ
  • Edge(98): 約370MB/タブ

※すべてLinux版で、約6個のタブを開いて増加したメモリ使用量から求めた。メモリ使用量はpsコマンドの"RSS"(resident set size)を使った。

 

結局のところ、Chromeの使用メモリ量が減ったと言っても、ようやくFirefox並みになっただけなので、すぐに移る意味は ないことに気付いた。そもそも、Chromeには標準で縦のタブバーがないなど使いにくいので、移るとしてもVivaldiだ。それが更新されて省メモリになるのを待ち、それから使い勝手で判断することにした。

Vivaldi以外に ほのかに期待しているのは、同じく大食いのElectronやSpotifyも使用メモリ量が減らないかということだ。それらもChrome(chromium)を使っているはずなので、改良の効果があるのではないか。

 

以前にも書いたが、MozillaにはThunderbirdでも嫌気が差しているので、Firefoxから移れば離脱できそうだ。Mozillaは もう少し、ユーザーや開発者が喜ぶ(せめて、怒らない・使う気を なくさせない)ような進め方を考えればいいのにと思う。

  •  2
  •  0

夏が来た!
夏が来た!

上下の違いが分かる方は居るだろうか?: 同じに見えるけど違う。ブラウザ(かなり古いもの?)やフォントによっては、分かるかも知れない。

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、Unicodeのひらがな・カタカナは、濁音や半濁音を半角カナ的に 本体+(半)濁点 のように分離して記述し、なおかつ くっつけて一文字のように表示することができる。Combining charactersとかいって、日本語以外でも そういう処理ができるとのことだ。

上の例の「が」は、最初の行はcombining charactersで 「か」+「”」(← 見にくいのでダブルクォートにした) で、2番目は普通に書いてある。全く区別できない。※ 良く出来過ぎていることに、マウスでコピーする時は1文字として扱われるし、等幅フォントのエディタやターミナル(コンソール)でも くっついた状態で表示される。

※おそらく、フォントの字体としては、本体に濁点を加えたものが濁音の文字になっており、combining charactersの濁点は それを再現するような位置に表示されるようにできているのだろう。ただ、この方式ではすべての濁音で濁点が同じ位置に置かれるが、そこはフォントの 描き方でうまく合わせたのだろうか。

↑ ちょっと確かめたら、そう単純なことではないようだ。というのは、下の左図のように、「ヾ」と「ヷ」では濁点の大きさや形が明らかに違うからだ。ということは、フォントに濁点を付けるための情報があるのか、表示する時に、combining charactersの濁点が付く場合は自動で濁音の字に変換されるのか。見たところ、濁点の形が微妙に違う気がする(特に、線の太さ)ので前者なのかも知れないが、本当に そこまでやっているのかという気はする。どちらにしたって、「余計なところに力を入れ過ぎていないか?」と言いたくなる。 (1/22 5:18)

その後、文字に色を付けて濁点を重ねて比べたところ(下の右図)、同じ文字の濁点の形状は、combining charactersでもそうでなくても同様だが、異なる文字同士では異なっている(この例では、「ヾ」の濁点は「ヷ」のより大きい)ことが分かった。 (1/22 14:19)

僕が見付けた唯一の識別方法は、エディタ(ペーストする)で濁点側から1文字削除することだ。Combining charactersの場合は濁点だけが消えるが、そうでない場合は全部消える。

そして、今回の切っ掛けに関係することは、どういう訳か、Spotifyで出る曲情報(タイトル、アーティスト名、アルバム名)※の中に、本体と濁点・半濁点が分離して記述されたものがあるのだ。全部ではなく、たまにあるのが不思議だ。特定のレーベルという訳でもない気がするが、老舗(例: ビクター、ソニー)や昔の曲に多い気がしている(と書きつつ、1990年代の(一番下の図)もあるので関係ないかも)。

想像だが、レーベルが曲情報を電子形態に登録する際、打ち込む人の癖などで分離してしまったか、それ以前の半角カナも使うシステム(そういうものがあったかは不明)から変換した時に、濁点・半濁点を統合しないままだったのではないか。

※詳しく確認していないのだが、同じSpotifyでも、アプリから取れる情報(Dbusのイベントで取れるもの)とAPIで取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。 ← どちらも同じように分離している場合があることが分かった。例: 飯島真理 「palette(パレット)」(2007)の「パ」。 (1/25 16:31)

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作のSpotifyのミニプレーヤーMinispが駄目だった(これが発端である)。次の左図のように、combining charactersである「が」のあとに空白が出来て、半角カナ的な見苦しさになってしまっている。今見ると、本体(か)と濁点の間隔も少し広い。本来は右側のようになるべきである。

どうやら、表示に使っているTcl/Tk(wish)がcombining charactersに対応していないようだ(調べた限りではTcl/Tkのページの"Unicode combining characters"の項にはコメントだか状況説明が書いてあるだけのようだし、 そういう設定や属性などがなかったので非対応なのではないか)。

これを何とかしようと調べたら、Rubyのソフト(unicode_utils)の紹介が出て来たものの、インストールするのが面倒なので試行錯誤したら、既存のプログラム iconvでは駄目だったものの、既に入っているパッケージ icu-devtoolsのuconvでできることが分かった。

Combining charactersを まとめる(くっついた文字にする)のは「正規化」という処理で、uconvのマニュアルに例(下記)が書いてあった。

uconv -f utf-8 -t utf-8 \
  -x '::nfkc; [:Cc:] >; ::katakana-hiragana;'

上は他の処理も混ざっているので、以下の例のように、曲のタイトル、アーティスト名、アルバム名をそれぞれ正規化してから表示するようにし、上の右図のように解決した。

echo "夏が来た!" | uconv -f utf-8 -t utf-8 -x '::nfc;'
夏が来た!

※正規化処理は、マニュアルではNFKCだが、調べたらNFCのほうが良さそうなので そうした。この辺りは全く詳しくないので手探りだ。また、上のコマンドでnfc前後の :: ; は なくていいようだが、例にならって付けている。

今 上の参照ページを読んだら、NFCでも今ひとつな場合(「例6: 神と神」)があって気に入らないが、仕方ない(レーベルも、旧字体は余り使わないだろう)。一番いいのは、正規化しなくてもwishで綺麗に表示できるようにすることか。

あるいは、(一番最初に考えた方式の、)uconvでなくプログラムで変換するのがいいか。ひらがな とカタカナだけの対応になるが、濁音・半濁音と そうでない音の文字の順序には概ね規則性(元の音のコード= 濁音-1, 半濁音-2)があるので、それでcombining charactersを くっついた文字に置換するのだ。これなら漢字の旧字体は問題ない。

というか、いちいち計算するのでなく、今の追加処理のテーブル方式で全部処理するほうが良さそうだ。濁音・半濁音は多くないから、テーブルを作るのは容易だ。 → 基本的に、uconvを使うのを止めて追加処理だけにすればできるので、早速そうした。

この方式なら、あとから追加変換が必要になことが分かっても、変換テーブルに追加するだけなので容易だ。 (1/21 17:05)

ところがどっこい!w

下の左図の「グ」のように、なぜか、頑固に正規化できない文字がある(図で「ベ」は くっついているので、処理されていない訳ではないことが分かる)。

更に調べたら、どうやらuconv(使っているのは uconv v2.1 ICU 66.1)が正規化しない(素通しする)文字があるようだ。ひらがな・カタカナの濁音・半濁音について調べたところ、以下の文字が駄目だった(正規化されずにそのまま出て来た)。

ど ば べ ぼ ぱ ぺ ぽ ガ ギ グ ズ ゼ ゾ ダ ヷ ヾ

ところで、上の最後のほうにある見慣れない文字、Unicodeにある「ヷ」、「ヸ」、「ヹ」、「ヺ」って実際に使われたのだろうか? どういう読み?? 謎だ。 (→ 4/1に出た、参考になるページがあった。)

その後、PHPの国際化関数のTransliteratorのtransliterator_transliterate()でuconvと同様の正規化処理を試したら、なぜか上の文字も正規化できた。よって、下ではICUやUnicodeのライブラリの問題と書いているが、uconvの問題の可能性が高い。だが、どうしたらこういう抜けが起こるのか見当がつかない。 (1/27 16:08)

実際には、原因はuconvではなく、それが使っているICUやUnicodeのライブラリの問題だろう(日本語に詳しくない人が作った??)から、パッケージを(Linuxディストリビューションのものでない、)オリジナルの最新に入れ替えるか、設定とか調整すれば直せる気はするのだが、パッケージの交換は あとあと面倒になるのでせず、設定・調整はuconvなどのマニュアルを読んでも分からない用語が多くて どうすればいいか分からなかったので、以下のような力技で対応した。

  1. 起動時(初期化)
    1. uconvで正規化できない濁音・半濁音を調べてリストを作る。
    2. それらの正規化後の文字のリストを作る。
  2. 曲情報(タイトル、アーティスト名、アルバム名)を表示する前
    1. uconvで正規化する。
    2. uconvで正規化できなかった文字がある場合は、正規化した文字に置換する。

これなら、将来ICUやUnicodeのライブラリが更新されて、すべての濁音・半濁音が正規化できるようになれば(なんか、永遠にそうならない気が・・・w)、自動的に追加処理が不要になる。

処理を実装し、上の右図のように、駄目だった文字が ちゃんと表示され、(今のところは)一件落着となった。ただ、いつものように、他にも何か問題がありそうなので、表示やログを注視しながら音楽を聴いている。

これ、日本語以外でも あったらお手上げだが、読めなくて気付かないだろうから良し?www

 

PS. 中程("1/21 17:05"の辺り)に書いたように、これを書いたあとで、実は、uconvを使うのでなく一番最初に思い付いた単純なテーブル変換方式が一番良かったというオチだった(今のところは)。Unicodeの考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

  •  0
  •  0

(電気羊じゃなくてw)

先日見た記事で、また少し期待が高まった。

“Snapdragon PC”でMSや主要メーカーと連携を加速 クアルコム

ただ、Snapdragonて、ARMでも熱い・電力効率が悪そうな気がするので、やっぱり今のところはM1チップがいいが、こういうのが増えると、そのうち「いい感じ」のチップやセットが出て来そうだ。もちろんM1でもいいが、Linuxが大前提だ。

とにかく、クソ効率の悪いx86は止めにしよう!!

 

PS. これを切っ掛けに ちょっと調べたら、ロシアのBaikal-MというチップのPCが発表されて居て、ハードの機能としては結構使えそうな感じだしTDPも30W以下で悪くないが(とは言え、10Wくらいになって欲しい)、海外には出ないようだ。

  •  0
  •  0

僕が!

ラブコメだと「もう、バカバカバカ!」とかになるのかw

1年以上、このサーバのファイアウォール(正確にはパケットフィルタ)に大穴があった。去年、IPv6を有効にした時のチェックが不充分だったため、v6には全く制限が掛かっていなかった。

幸い、ほとんどのソフトは外部からの接続を許可していなかったので、OSに入りはするものの接続相手がないので、おそらく実害はなさそうだ。けれど、OSの穴を突く攻撃に対してどうだったかは分からない。

突かれた穴で分かっているものは(メールの外部送信用に使っている)SMTPだ。それが気付いた切っ掛けになった。たまたま見たログに、なぜか(v6での)外部からの接続が記録されていたので気付いた。幸い、SMTPのソフトの設定のおかげで、スパムの踏み台にはならなかったようだ。

もちろん、そのソフトの穴を突く攻撃をされた可能性は0ではない。だから、SMTPを使うのを止めたいと思っている。ただ、自分(自宅)にメールを転送するのに使っているので、簡単ではない。

失敗した原因は、ファイアウォールに使っているソフトiptablesの設定はIPv4とIPv6に共通ではなく、別々だったことだ。調べてそれが分かり、急いで対処した。

おぼろげに思い出す(気がする)のは、v6に対応した時、外部からのポートスキャンの結果がv4とv6で違っていた気がすることだ(記録を調べれば分かるが、余り意味がないのでしない)。その時にもう少し深追いすれば良かったが、後の祭りだ。

今は、とりあえず、意図したとおりにファイアウォールは動いている。が、それで完全かは分からない。それをチェックするには外部のチェック(ペネトレーションテスト)サービスなどを使う必要があるが、無料ではないのでしていない。

もちろん、無料のツールはあるが、それら(一つだけでは済まないだろう)をちゃんと使えないことには完全なテストはできず意味がないので、手軽ではない。

 

PS. iptablesをIPv6用に設定する時、最初はICMPv6を通さないとv6で接続できなくなるのが分からなくて、ちょっと手間取った。

PS2. ファイアウォールの設定のチェックのためにncコマンドでポートスキャンしたのだが、時間が掛かるので、実行しているのを忘れて結果がどっかに行ってしまい、何度も再実行した。

PS3. その後、もう少しログを調べたら、外部からの接続は、今月中旬にSMTPのソフトの設定を修正してから始まっていたことが分かった。その修正は、いつからか、設定は変えていないのに致命的なエラーが出続けて居た(そのソフトの更新の影響と思われる)ことに(たまたま)気付いたためにした。

なので、v6を有効にしてから最近までは、たまたま設定に問題がなかった(エラーが出る前)・不備だった(エラーが出てから)ために外部から接続できない状態になっていて、ひどい攻撃を受けていなかった可能性が高い。

致命的なエラーが出る状態でも問題なく使えていたのが不思議だし、できれば動かないで欲しかった。でも、それを早期に修正していたら、外部からの接続が可能なことに気付かなかった可能性もある。

まったく、怪我の功名だ。そして、やっぱり記録は重要だと再認識した。 (12/22 5:29)

 

(12/23 8:15 わずかに加飾)

  •  1
  •  0

(突発的に?)光とモバイルのプロバイダを移ったり、窓の異臭漏れ防止シートを正式版に張り替えたりして停滞しているが、Zim+Joplinのシステムは概ね問題なく使えている。

前回から以下を修正・改良して、随分良くなった。

  • 行の(ソフト)ラップがないように振る舞う場合があるのを概ね解消した。
    • ノートに埋め込んでいる画像の表示幅が広過ぎることが主な原因だったので、設定した最大幅※より大きかったら、自動的に縮小するようにした。
      • ただ、設定値が不適切だったり、画像がインデントされていて、画像の幅+インデント量がペーンの幅を超える場合には駄目である。
      • ※本来、ペーンやウインドウの幅から画像の最大幅を求めるべきだが、まだそれらが取得できないので、設定に依存している。
    • また、テキストのラップ方法にも よるようだったので、単語単位から単語+文字単位に変更した。
      • 日本語では単語単位のラップは意味がないので、どうにかして「ちゃんと」したいが、これしか やりようがないのかも知れない。
        • そういう点では、このWordPressのエディタや表示は全く優れものだ。
    • 依然として、問題が起こった場合にHomeキーが思うように効かないので、何とかしたい。
  • ノートを開いた時に、より確実に前回のカーソル位置を復元できるようにした。
    • この処理は元々ハッキング的に実装されていたが、時々動作が不完全だったので、復元するための待ち時間(= スクロールする時間?)を結構長くした。
  • 起動するたびに/tmpにログディレクトリ(zim-xxxxx)が作られないようにした。
    • 特定のディレクトリ(例: /run/user/ID)にログファイルを作るようにした。
    • 以前のログは10個くらい残すようにした。
  • MDへのエクスポートの改良
    • 見出しのMDのタグを標準的なもの(Joplin= gfm?)に合わせた。
      • インポート時も同様な修正が要るようだが、未対処である。
  • ノート名のボタンのラベルの文字サイズを小さくし、なるべく多くの文字を表示できるようにした。
  • (特に書式のエクスポート・インポートのテスト用ノートで)ZimとJoplinの行き来を繰り返すとテストができなくなってしまうので、Joplin→Zimの一方通行だけにできるようにした。
    • 画像のインポート用ノートを無駄にZimからJoplinにエクスポートしないようにも使っている。
  • (以下、書いたあとでの追加: 12/18 12:43) Joplin→ZimとZim→Joplinの変換(エクスポート・インポート)処理を改良した。
    • [Joplin→Zim] コードブロックが正しく表示できない場合があるのを解消した。
      • MDをZimに変換するpandocの仕様で、コードブロックを囲むタグが ~~~の場合、ZimのSource Viewというプラグインを使うようになるが、うまく動かないようで、先頭に"{{{code: lang="(改行)"linenumbers="True""などと入り、ブロックの終わりが認識されず、最悪の場合はZimが強制終了する(ブロックが大きくなり過ぎるため)。
      • そこで、Joplin→Zimの変換プログラムで、MDの2種類のコードブロック(~~~, ```)をどちらもZimのもの(''')に変換するようにした。
    • [Joplin→Zim] 上と同様に、水平線(HR)も、Zimが認識する ---に統一するようにした。
    • [Joplin→Zim] 見出し(##など)に下線が付く場合があって煩雑なので、下線を削除するようにした。
    • [Joplin→Zim] 同様に、見出しの前後に余分な空行が入らないようにした。
    • [Zim→Joplin] ノート先頭に書いた見出しがなくなることがあるので、なくならないようにした。
      • 直すまでは、先頭の見出しの前に . のようなダミー行を入れて しのいでいた。修正も同様にしているが、Joplinにインポートする前に除去している。

それでも、依然として すごく気になる問題や改良したい点は残って居る。特に以下である。

  • 描画の更新がおかしいことがある。
    • 大きいノートを変更すると、その行が上下に重複して表示されることがある。
      • 他のアプリでは見たことがないのに、どうして起こるのか不思議だ。
      • ここにキャプチャを載せようと思って試すと、起こらないw
      • とりあえずは「軽い再描画」(ブラウザのF5のもっと軽いイメージ)ができるようにしたい。
  • 新しい画像が入ったノートのJoplinへのエクスポート
    • Zimで追加した画像をJoplinに取り込めるようにしたい。

前者については、いろいろいじってZimの内部構造やPythonでのグラフィック(GTK)のやり方が分かって来たので、調査・試行錯誤すれば できそうな気はするが、まだ原因が掴めていないので、根本的な対処は難しい。

後者はやり方は分かっているけど面倒なので、純粋に僕のヤル気の問題であるw

逆に言えば、大きな問題は もう2つしかなく、時々イライラはするものの充分実用的(Joplinより10倍以上使いやすい)なので、残った難しい・面倒な問題を片付ける気が なかなか起こらない。まあ、年末の宿題か来年の初仕事だ。

 

(12/18 12:17) Zimならではの良さの一つに、gitなどでバージョン管理できることがある。Joplinにも履歴機能はあるが、指定期間で削除されてしまうため、古いノートの履歴が参照できない。※ そのため、古いノートの変更に失敗して戻したくなってもできないのだ。

※少し前までは最大*日分残ると誤解して古くても残って居ると思い込んで居たが、そうでなくてがっかりした。

Zimではそんなことはなく、履歴は無限に残る(はず)。データ量は増えるが(それほど多くはないはず)、それよりも、確実に復活できることが重要だ。そして、汎用のツールを使っているので、好きなアプリで履歴を見られるのもうれしい。ただ、履歴を記録するのは定期的なので(ノートを保存した時にも記録されると思う)、残らない履歴もある。

それでも、なくなるよりはずっといい。当初はgitのようなものを使うのは安直だと思っていたが、Joplinのように いい加減な機能を内蔵してプログラムとDBを肥大化させるうえに、いざという時に役に立たずにがっかりさせられるよりはずっとマシだし、ずっといい考えだと思う。

 

PS. 意外にオリジナル版も少しずつ(残念ながら、細かいものばかり)修正されているので、まとめて適用したい。あと、僕の改良・改造もオリジナル版に入れてもらいたいが、説明や準備が結構な手間なので、やってもフォーク(分岐)程度かと思っている。いずれにしても、描画の更新がおかしいことがある問題が直ってからだ。

  •  0
  •  0

IIJの光回線(IPoE)が開通して数日しか経っていないが、問題はない。まだ確定していないが、一番気にしていた、IPoEでもIPv4が遅くなる(DTIの時は混雑時に数Mbpsになることが多々あった)ことは なさそうだ(今までのところ そういうことはなかった)。※

とは言え、ネットの混雑状況に通信速度が影響されるようで、混んでいる(と思われる)時間帯(例: 午後-夜)は空いている時(例: 早朝)より30%近く遅くなることはある。(例: ダウンロード: 90Mbps → 66Mbps)

ただ、早朝でも遅くなったことがあったので、混雑だけではないのかも知れない。

まあ、近頃実感したのだが、速度測定結果で数百Mbpsなどという値を頻繁に見るにつけ、「そういう人が多ければ、いくらフレッツやプロバイダの回線・機器がすごくても、遅くは なるわなあ」と思う。もちろん、常時数百Mbps使っている訳ではないだろうが、利用者が多ければ、平均しても ものすごい転送量・速度になるはずで、混む時はやっぱり遅くなるだろう。

※その後、やっぱり、混む時(例: 休日の夕方)は数Mbpsくらいに遅くなることが分かった。ただ、DTIよりは頻度が少なそうだし、遅くなる時間も短そうだ。 (12/19 18:19)

そして、問題ではないが、いくつか(分かっても何の役にも立たないw)謎があるので書く。

  • 速度測定サイトfast.comがIPv4でしか繋がらない。 ← 推測だが、fast.comの仕様(速いほうを選ぶ)ではないか。
    • IPoEが開通してから、一度もv6になったことがない。
    • こちらのIPv6(特にDNS)周りに問題があるのかと思って いろいろ調べ、試行錯誤したが、問題はなさそうだ。
    • ブラウザはRFC8305などの"Happy Eyeballs"でv4とv6を切り替えているとのことだが、常に変わらず、ブラウザを変えても変わらないので、それによるものではなさそうで、fast.comが自分でv4にしているようだ。
      • また、/etc/hostsにfast.comのv6のアドレスを書いてv6だけで繋がるようにしてもv4で測定されたので、ブラウザの機能によるものではなさそうだ。
      • 推測ではあるが、RFC8305より もっと細かい応答時間・速度差でv4を選んでいるように思う。 (→ 参考資料: ただし、v4/v6の選択に関してはNetflixの原典には明記されていないので、推測だと思われる。)
        • 参考: RFC8305の推奨しきい値(v6/v4の時間差): 名前解決: 50ms, 接続: 250ms
      • 実際、Firefoxで他のサイトにアクセスする場合、v6も可能なら ほとんどv6が使われる(もちろん、いつも調べては居ない)。
    • このこと自体は問題ではないのだが、そのために、今まで同サイトをv6の速度測定に使っていたのが駄目になったので、別のサイト(iNonius)を探して使っている。
      • iNoniusではv4とv6の速度を両方測れる。その時々でv4とv6で優先されるものが異なるのは、ネットの混み具合によるのかと想像している。
        • そのv4とv6の選択は、上記のブラウザの機能によるようで(おそらく、名前解決の時間で決まるのだろう)、一旦どちらかに決まったらしばらく固定されるようだ。そのため、別のブラウザでは別の選択になることもある。
    • 以上のことから、IIJのIPoEのIPv4は結構空いていて(注: PPPoEは駄目)、v6と同じくらいの応答時間・速度が得られるのではないかと想像している。
      • 実際、iNoniusで表示される応答時間(RTT)のv4とv6の差は数msしかない(その代わり、ジッタはv4が大きいことが多い。 ← v6より多く利用されるためだろうか)。
      • また、v6のホップ数(途中の段数)がv4より多いために、fast.comはv4を優先するのかも知れない。
  • ルータのFWの(勝手な)off/onがなくなった。 ← MAP-EとDS-Liteの違い?
    • DTIの時は、使っているルータ(I/Oデータ WN-SX300GR)に ほぼ毎日、ファイアウォールがoff/onしたというログが出ていたが、ここ数日は出ていない。
      • 以前、メーカーに問い合わせたら「回線の品質によるのでは」という答えが来て怪しいと思って居たが、やっぱりそうではなかったようだ。
    • これから出るのかも知れないが、出なくなったとしたら、v6にv4を載せる方式(MAP-EとDS-Lite)の違いによるのではないかと思う。
      • MAP-Eは定期的に何かをしていて、それでルータの何かの処理が再起動したりするのではないか。
  • スリープからの復帰時に、既存のIPv6一時アドレスが まだ有効なうちに新しいアドレスが割り当てられる。 ← プロバイダ側のルータの違い?
    • 今朝、PC(Linux Mint)をスリープから復帰させたら、なぜか、IPv6一時アドレスが2つになっていた。
      • 普通は1個だけ有効で、残りは無効(deprecated)なのだが、今は両方ともアクティブだ。
      • 実用上の問題はなく、2つのうち新しいアドレスが使われている。
    • これは上のルータのFWのoff/onに似て、プロバイダ側のルータの違いによるのかと想像している。また、MAP-EとDS-Liteの違いも関係しているのかも知れない(それらはv4を載せる仕組みなので、直接の関係はないだろうが)。
    • 書いてから不安になったが、実は以前もそうだったのかも知れない。PCが復帰する時にはDHCPが動くはずで、それで新しいアドレスが割り当てられるのは普通のことだ。
      • ああ、IIJのルータのDHCPのリース時間がDTIより短いのかも知れない。
    • → (12/13 7:31) 今朝の復帰時はアドレスは増えていなかったので、DHCPのリース時間の関係だったようだ。
  • fast.comでIPv4アドレスの接続元地域が分散している。 ← IP-Geoloc DBの問題?
    • おそらく表示(IPアドレス-地域DBの情報がおかしい?)だけの問題だろうが、fast.comで表示される接続元の地域が日本中に分散している。県内や隣の県も多いが、調布や柏崎や旭川や函館などということもある。それでも遅くないので良しであるw
      • もしかして、接続地点の混み具合によって本当に分散させているのだろうか? ただ、それで速くなるのかは不明だ。もしそれが効いているのなら、IIJはすごいと思う。
        • でも、さすがに それはない気がする。実際、遠い地点なら応答時間が長くなりそうなものだが、ほとんど一定だ。
        • 実際、"IP geolocation"で検索して出て来る いろいろなサイトでの地域表示は、同じIPアドレスなのに「てんでバラバラ」だから、当てにならない感じだ。
    • その後、同じIPアドレスでも実行する回によって表示される地域名が異なるので、どうやら、fast.comの参照するDBがおかしいようだ。あるいは、IPアドレスでない何か(経路?)で地域を割り出している? (それでも合ってないがw)
      • そういうところから見ると、(一部で「速過ぎる」と言われているようだが)fast.comの速度測定は それほど確かでないのかも知れない(まあ、この件は関係ないとは思うが)。

 

PS. fast.comが必ずIPv4でアクセスされる件で、フレッツのIPv6のDNSサーバ(2404:1a8:7f01:a::3, -:b:-)が悪いのかと思って無効にしてみたが関係なかった。その時は、このサーバは役に立たない(フレッツ関係のドメイン(iptvf.jp?)だけサポートしている)と思い込んで一旦無効にしたのだが、良く調べたらちゃんと使えることが分かった。 (これを書いている時に、念のために確認して分かった。)

それで、IIJのDNSサーバはv4だけで、それはIPoE(またはPPPoE)が使えないとアクセスできなさそうで ちょっと弱い気がしたので、いざという時のために残すことにした。

まあ、IPoEが使えない(≒ v6のアドレスがもらえない?)とかDNSサーバが停まっている状況で外(インターネット)に出られる可能性は低そうだが・・・

なお、フレッツのDNSサーバはNetmorkManagerの設定で無効にすることができる。: 具体的には、IPv6の設定で、Methodを"Automatic, addresses only"にすると、IPアドレスと経路情報は自動設定するが、DNSサーバの設定はしないようになる。 (12/13 14:37)

更に考えたら、Linuxの設定やNW構成により、どうやらIIJのDNSサーバは使っておらず、フレッツのだけが使われているようだ。というのは、僕のPCのDNSサーバはデフォルトでルータになり(そこに上記のフレッツのサーバが自動追加される)、ルータはフレッツのサーバを参照している(推測)ためだ。

結局、IIJのDNSサーバのアドレスは どこからも取得されず、設定もされないので、使われていない。それで、やっぱり、PCでフレッツのDNSサーバを設定するのは無駄(ルータだけで充分)なようなので、(上に書いた手順で)無効にした。

いざという時のことを考えるなら、それにIIJのDNSサーバを追加することだが、まあ、そこまでは要らない気がする。 (12/13 15:24)

どうでもいいことだったが、いろいろ考え、DNSサーバとしてローカルのルータを指定すると、PCからはv4でしかDNSサーバへの経路がなくなるのと、ルータ内でv4→v6変換が行われる(元々v6なのに馬鹿らしいし、それほど速くなさそう)のが ちょっと不満だったので、以下のようにNetmorkManagerに指定して落ち着くことにした。

  • v4: IIJのDNSサーバ
  • v6: 自動設定(→ フレッツのDNSサーバ)

実際には、PC内のアプリからキャッシュサーバ(systemd-resolved)への経路はv4だけなので、それほど大きな意味があるとは思えない。効果が発揮されるのは、フレッツかIIJのDNSサーバが落ちた場合だが、そういう時に まともに外部にアクセスできるとも思えないので、まあ、単なる自己満足であろう。 (12/14 6:31)

  •  0
  •  0

CERONで「フレッツ光回線でscpが遅かった話」(以下、参照ページ)というのを見て、僕は今までそういうことを経験したことがなかったので(もちろん、IPv6を使っている)、不思議に思って試してみた。すると、僕の環境(Linux Mint 20.2、以下Mint)のscp(おそらくUbuntu系は同じでは)は参照ページとは設定が異なっているので、問題が起こらないことが分かった。

こういうのは参照ページにコメントするといいのだろうが、Qiitaのアカウントを作るのが面倒なので、ここに書くだけにする。

具体的には、Mintのssh_configのマニュアルによれば、IPQoSオプションのデフォルトは、インタラクティブセッションの場合は"lowdelay"、非インタラクティブの場合は"throughput"とある。実際のそれらの値が何か書かれていないので調べたのだが、正確な値は分からなかった。ただ、Wikipediaにそれらしい値が書いてあった。以下に関連する設定を引用する。

Service class: DSCP Name: DSCP Value
Low-latency data:  AF21, AF22, AF23: 18, 20, 22
High-throughput data: AF11, AF12, AF13: 10, 12, 14
Low-priority data: CS1: 8

上より、scpではIPQoSに10, 12, 14のどれかが指定されると推測できる(正確な値はパケットをキャプチャすれば分かるのだろうが、問題が起こっていないのと、後述のとおりIPQoSに"cs1"を指定したら問題が再現したので省略した)。

参照ページでは、IPQoSに"cs1"(8, "Lower Effort")が指定されて遅くなっていたとのことだ。それで、僕の環境でcs1を指定したら、確かに遅くなった。元々4MB/s(僕の環境はVDSLなのでアップロードは元々遅い)だったのが1MB/sくらいになった。これは参照ページと同様の値なので、現象が再現できたと思われる。

なお、IPQoSに"none"を指定しても速度は(設定しない場合と)変わらなかったので、Mintのデフォルト設定(10, 12, 14のどれか)はフレッツ光のIPv6に悪影響がないようだ。

 

不思議な(もやっとする)のは、参照ページには使われているLinuxのディストリビューションやバージョンが書かれておらず(単に"Linux")、参照されているssh_configのマニュアルがOpenBSDのものだったことだ。おそらく別のディストリビューションを使われているんだろうけど、ちょっと「うーむ」だ。

 

もう一つ腑に落ちないというか変なのは、参照ページで参照されていたフレッツの仕様書では、「トラヒッククラスフィールドの先頭6ビットに、DSCP値として8(001000)を指定することで、優先トラヒックとして転送します。」とあるが、上の表では8は"Low-priority data"で逆の意味である。どういう訳かは分からないが、実はフレッツの仕様書の記述が誤りで、「優先トラヒック」のつもりでcs1(8)を指定すると本来の低優先度で扱われて転送速度が遅くなるというオチなのかも知れない。

あ、実はフレッツは一般用サービスではここは無視していて、scpがcs1(8)を指定したから、途中のNW機器が「それなり」に扱うために遅くなるのかも知れない。まあ、僕にしてみれば、今まで「QoSなんて指定したって実際には効かない」と思って居たので、途中の機器がそんなに従順なのかは「知らんけど」だ。

ただ、v4だと問題は起こらない(参照ページにあったかは不明)ということなので、ユーザ側でなくフレッツ側の機器が関係しているのかも知れない。

→ その後、フレッツのあとのプロバイダのIPv6系統の機器によるのではないかと思った。IPv4の場合は別系統で、DS-Liteなりの処理(AFTR)が入るので影響されないのでは。

また、pingのパケットのQoSの値をcs1にしても落ちないので、ある程度の連続した流量(データ量)がある時だけ速度が下がるようで、まさにルータの帯域制御のようだ。ただ、それは自分のルータでも起こる可能性があるが、その帯域が逼迫することはまずなく、一方、プロバイダのルータ(とその先)は結構「いっぱい いっぱい」だろうから、「低プライオリティならいいか」と帯域制限されそうな気がする。 (12/9 6:06)

それから、なぜ わざわざcs1を指定する版があるのかは分からないが、昔とQoSの仕様が変わったのか、scpを作った・QoS対応にした当時は「良く分からないのでテキトーに」設定してしまったのかも知れない。あるいは、当時は本当にscpには速度を求めていなかったのかも知れない。

 

まあ、僕としては一件落着(というか、分かったつもり)で、"close"できたので良しである。^^

  •  0
  •  0

最初、「首までどっぷり」ってのは"Knee deep in the hoopla."みたいな感じかと思って居たのだが、調べたら ちょっとニュアンスが違うようだ。そのくらい、(全然やりたくなかったのに)Zimに はまってしまっている。

 

(他のノートアプリ同様)Zimも駄目なところが多く、ガッと捨てようと思ったのだが、探しても他にいいものは全くなかった。それで考えて、細かい問題は いろいろあるものの致命的なもの(例: 遅い、メモリの浪費)は ないので、慣れたり発見したり手を加えたりして使っている。前回も少し書いているが、今までに以下のようなことをした(詳細は追って追加したい ← と書いた割には ほとんど書いた気がする)。

  • JoplinからZimへのインポート関連
    • ノート・ノートブック名の変換、正式な(または本来の)ノート・ノートブック名の保存。
      • Zimはノート・ノートブック名に使えない文字が多いので、それらを削除したり別の文字に置換するようにした。
      • 正式なノート・ノートブック名を保存するため、追加ノート情報ファイルに記録するようにした。今のところ、以下を格納している。
        • 正式なノート名
        • 正式なノートブック名
        • JoplinのノートID: Zimで更新したノートをJoplinに戻す(反映させる)時に使う。
    • 書式の修正
      • pandocでZimの形式に変換する時に仕様の差があるので、その対処をした。
        • 具体的には、水平線("-"3個以上)をZim("-"20個)に合わせている。
      • また、ノートにZim用のヘッダ(pandocは付けない)を追加している。
        • そこにノートの作成日時を入れるため、Joplinから取っている。
    • Zimのノートブックの作成
      • Joplinのノートブック名と同じディレクトリを作るようにした。
      • その時、Zimのノートブックファイル(notebook.zim)も作るようにした。
    • インポートを手軽に。
      • Joplinのノートを外部編集を開始する操作で、ノートをZimにインポートできるようにした。
      • インポートが終わったら通知が表示されるので、外部編集を終了する。
  • ZimからJoplinへのエクスポート関連
    • ノート・ノートブック名を戻す。
      • インポート時に保存しておいた正式なノート・ノートブック名に戻す。
    • 書式の修正
      • ZimからMDに変換する時に誤変換のようなものがあるので、その対処をした。
        • Zimから出す時に書式が欠けるため、出す前後に処理を入れないと うまく行かない。
      • 例えば以下である。
        • "// 文字 //": "//"が"*"になってしまうので、"/"をエスケープする。
        • (行頭)"--- 文字 ---" : 水平線ではないので"*** 文字 ***"に変換する。
          • 手でJoplinに入れても問題ないので、Zimが"---"を誤変換してしまうようだ。
        • 行頭のn個のTAB + 文字 (インデント): MDに同様な書式はないので、引用にする。 → n個の">" + 空白 + 文字
          • ただし、TABで始まるものにはインデントされたコードブロックや箇条書き、チェックボックスもあるが、それらは変換しない。
        • 行頭の空白 (+ 文字):  上と同様に引用にする。 → ">" + 空白 (+ 文字)
          • 空白の数で">"の数を増やすと良さそうだが、どうやって数を決めるべきか分からない。
        • チェックボックス: ""と""になるので、MDの"[ ]"と"[X]"に戻す。
    • リソース(画像など)ディレクトリの変換
      • ZimとJoplinで同じファイルを指していても、ディレクトリの表現や階層が異なるので変換する。
    • Zimで作った新規ノートへの対応
      • 正式なノートブック名(あれば)でJoplinのノートブックを作る。
      • 正式なノート名(あれば)でJoplinのノートを作る。
      • Joplinにインポートして割り当てられたノートIDを、追加ノート情報ファイルに保存する。
      • TODO
        • 正式なノート・ノートブック名を手軽に(追加ノート情報ファイルに)設定する手段(例: 入力ダイアログを出す)が必要だが、まだない。
        • Zimで追加したリソース(画像など)をJoplinに取り込み、ノート中のディレクトリを変換する処理が必要。
          • 今は、Zimで普通に追加した画像はJoplinでは見えない。
    • エクスポート(更新・追加)を手軽に。
      • 自動または手動(ツールバーのボタン: 後述)でできるようにした。
      • 自動の場合、約30秒間隔で、ノート(のファイル)の更新時刻が前回のチェック開始時刻から現在時刻の約90秒前までの間のものを探し、それをJoplinにエクスポートするようにしている。
        • 約90秒というのは「ノートを書き終わったかも?」と判定する時間である。
        • ファイル検索が頻繁で効率が悪くて気に入らないが、とりあえずは使えている。
          • 効率を良くするにはinotifywaitなどを使えばいいのだが、変更後に一定時間(今回は90秒)経過するまで保留するのが難しいので、保留している。
      • 自動でエクスポートされるまで待てない場合は、手動でもできるようにした。
  • UIの改良
    • GTKのCSDのようなものを止める。
      • Zim(実際にはGTKの流儀のようで、他にもいろいろなアプリがそうしているが、なんでそんな勝手なことをするのかと思う)がタイトルバーを勝手なUIにしていて、通常あるメニューのボタン(▼)が出なくなるため、僕の場合は最小化(_)と×(ウインドウを閉じる)が隣になってしまって間違って押しやすいので、ソースを改造してウインドウマネージャが付ける普通のボタンに戻した
        • 今のところは、GTKやZimがタイトルバーを変更しないようにしているだけのため、Zimが追加しているボタン(前・後のノートへ移動, ホーム, 編集のon/off, 検索)は出ないが、最初から余計だと認識していて使わないので問題はない。
          • Chromeもこういう感じになったが、今のディスプレイは広いんだからタイトルバーの面積くらいケチらなくてもいいのに、どうしてこういう発想になるのか理解できない。
        • TODO
          • 前・後のノートのボタンは あれば便利な気がするので、あとで付けたい。
    • 正式なノート・ノートブック名の表示
      • ソースを改造して、Zimのファイル名ベースのノート名などの代わりに、上述の保存しておいた正式なノート・ノートブック名を表示するようにした。
        • ごく当たり前のことなので見ても何がいいか分からないとは思うが、例えば、Zimでは使えない"#"や"/"が(代用文字でなく)出ているし、"_"は空白に変換されずに出る。
        • なぜか、図では本来は"-)"の")"がなくなっているが、短縮処理のためだろう。
      • 処理概要: ノートを読み込む時に追加ノート情報ファイルがあればそれを読み、キーと値をノート(Zimでは「ページ」)のメタデータ(Page._parsetree.meta)に追加し、タイトルバーなどのUI部品でページ名などを表示する時に それらがあれば使う。
      • 今のところ、以下で出る。
        • タイトルバー: ノートとノートブック名
        • タブのようなボタン(パスバー(下図の中段), ブックマークバー(下図の下段)): ノート名
      • TODO
        • 左サイドバーのpage index(ファイルマネージャーのようなもの)は作りが違っていて変更すべき箇所が分からないので、まだである。
    • バージョン表示に追加
      • 改造版であることが分かるように、バージョン表示ダイアログに出るようにした。 (: 中央の".B-3"と最下行)
  • 簡単な機能追加とツールバーへの登録
    • 以下の処理をZimのCustom toolとして追加し、Zimのツールバーボタンに登録して手軽に実行できるようにした。
      • 現在のノートのJoplinへのエクスポート(更新・追加) (: 中段左寄りの青い"J"のボタン)
        • 処理内容は上述のとおり。
      • クリップボードをテキストとしてペースト(LibreOffice Calc対応) (: 中段左寄りのペーストのボタン)
        • 前回も書いたが、ZimかLibreOfficeのクリップボードの扱いが変なのか、LibreOffice Calcからテキストをペーストすると画像になってしまうので、xsel(その後、xclip -quietのほうがハングしにくいことが分かった: 11/22 5:26)コマンドでPRIMARYバッファのテキストを取得して、ノートに挿入できるようにした。
          • なぜかCLIPBOARDバッファを取ろうとするとハングするが、PRIMARYで問題はなさそうだ。
            • 調べると、CLIPBOARDはPRIMARYなどと処理が違うようなので、その関係だろうか。
          • (12/1 12:06) その後、LibreOffice CalcからだとCLIPBOARDでないとテキストが取れないようなので、結局、xselを使い、ハング回避のためにタイムアウトさせることにした。
          • 以下にコマンド例を示す。

sh -c 'to_ms=120; to_s=`echo "scale= 3; $to_ms / 1000" | bc -l `; xsel -o -b -t $to_ms < /dev/null & xs_pid=$!; sleep $to_s; kill -TERM $xs_pid'

        • これはボタン以外にショートカット: Ctrl+Shift+Vに割り当てている。
        • TODO
          • なぜか、Zimでコピーしたテキストはペーストできない。Zimとxselが競合しているのかと思うが、今のところは通常のペーストと使い分けが必要で、ちょっと気に入らない。
      • 選択範囲をインターネット(Google)で検索 (: 中段左寄りのGoogleのボタン)
        • 選択したテキストをGoogle検索のURLに追加して、デフォルトブラウザに渡して検索できるようにした。
        • これができるエディタは ほとんどない(知らないだけかも)が、是非欲しかった機能なので付けた。
        • TODO
          • セキュリティホールになりそうな気がするが、個人用なので注意すれば良さそうだ。

 

随分手間が掛かっている(これでも全然終わりでない・・・)が、ソースなどを見れば結構分かり、ツールバーのように簡単にできて効果が大きいものも多いので、ストレスは少ない。そして、今まで仕方なく使っていたMDと違って、Linuxのコマンドやプログラム(`とか~とか-とか*とか#など、MDで特別な意味を持つ記号がバンバン出て来る)を書くのに何も気を遣わなくていい、いや それ以上に、本来の記述とノート(ファイル)が全く同じに書けることが重要・必須だ。まさに、「まだMDで消耗してるの?」だ。

ただ、Joplinに送る時(見る時)にMDに変換されるので、あまりいろいろな記号や書式を入れると、うまく変換されるか心配には なる。そして、運が悪いとバグが見付かって、余計な作業が増えるw

なお、QOwnNotesかZettler(かZimにインポートする時)に書式がおかしくなったノートが結構あって、見付けた時に手で直している。まあ、そんなの可愛いもので、見れば分かるので問題ない。

 

PS. 自分の整理のため、本システムで今分かっている残件・TODO・直したい・やりたいことを以下に挙げる。 (19:54)

  • Zimの不具合・変な点など
    • 描画の更新がおかしいことがある問題への対処。
      • 大きいノートを変更すると、その行が上下に重複して表示されることがある。
      • これを一番先に直したいが、見当が付かない。
      • 直せないなら、デフォルトのフォント(問題が起こらないようだ)の行間や太さを変えて、すっきり見えるようにしたい。 ← デフォルトでも問題が起こったので、駄目。 (11/21 12:35)
    • 行の(ソフト)ラップがない(ように振る舞う場合がある)。
      • これも早く直したいが・・・
      • せめてHomeキーで行頭に戻れるようにしたい。
    • ノートの先頭の見出しがMDに出ない場合がある。
      • 先頭に空行以外があれば、その次が見出しになるようだ。
    • [済] 書式に余計なものがある。 → ソース(pageview/__init__.py)を変更しても反映されないので調べたら、Zimのスタイル設定ファイル(.config/Zim/style.conf)で変更できることが分かって、自分の好みにできた。 (11/22 18:01)
      • 見出しのH1に下線が付き、H3は斜体になる。: 文字サイズだけでいい。
      • 下線は色付きになってしまう。: 下線だけでいい。
  • 機能追加・修正
    • Zimの書式指定タグ関連 (11/24 16:10)
      • 書式指定のタグ(後述の"@"で始まるタグ(ページタグ)とは異なる)に、Linuxやプログラムに良く出て来るもの(例: "__XXX__"(下線), "// YYY //"(斜体)※)があり、インポートしたり貼り付けたりしたあとにコードブロックにし忘れると、次回開いた時に下線(例の場合、"XXX")や斜体(例の場合、" YYY ")になってしまって嫌なので、それらを滅多に出て来ない文字列(例の場合、"⟪_XXX_⟫", "⟪/ YYY /⟫")に変更した。
        • ※本文の「"// 文字 //": "//"が"*"になってしまう」はこれが原因だった。 WYSIWYGなので、中身までは気付かなかった。
        • 似たようなものは、他に"** ZZZ **"(太字)や"~~ WWW ~~"(取り消し線)もあるが、同様に変更可能である。
        • この関係で、インポート時に本来のタグを変更したものに変換するようにした。
      • ページタグも同様にしたかったが、書式が異なるうえに処理が分散していて完全に変更するのが難しいので、ひとまず無効にした。
    •  エクスポート関連
      •  Zimで追加した画像のJoplin向けの処理
        • 本文に書いたとおり。
      • コードブロックのインデントをMDに反映させる。
        • 今はコードブロックが引用になってしまう。
      • 未更新の全ノートを手動で更新(エクスポート)できるようにしたい。
      • Joplinの新規ノートブックを階層も含めてちゃんと作成する。
    • インポート関連
      • インポート時の誤変換などの修正・対処
        • [外部] 空行を挟まない改行が繋がることがある。: pandocの問題? → Zimで書いた場合は繋がらないので、以前のエディタ(Zettlr?)の仕業だろう。 (11/22 18:01)
        • [正常] "@"+文字がZimのタグ(ページタグ)になることがある。 ← Zimの仕様だった。ただ、こういうところがMDみたいになっているのが気に入らない。が、シンプルなテキストファイルなので こうするしかないのも分かる。 (11/22 18:01)
          • とはいえ、ノートにはヘッダ部があるので、そこにタグを書けばいいのにとも思う。そうすれば、タグに空白や記号も含められる。 (11/22 18:27)
          • 逆に、Zimのタグを付ける方法が不明。。。 ← "@"+文字で付ける。(11/22 18:01)
          • → 結局、これの良くない点は、良く使う@をタグのマークとして使っていることだった。上述のように他にもそういうことがあったのでマークを変更したが、このページタグの変更は難しいので、ひとまず無効にして、意図せぬタグができないようにた。僕はタグを使わないので、当面は問題ない。 (11/24 16:10)
        • [外部] IPv6アドレスの一部が記号になる。 ← 再現しないので、以前のエディタの仕業だろう。 (11/22 18:01)
          • 例: ":b:"が"🅱️"(色は黒)になる。
          • 以前のエディタがおかしくした?
      • Joplinでのノートの変更をZimに反映できるようにする。
        • スマフォで更新することもあるかも知れないので。
        • → ひとまず、エクスポート時にJoplinとZimの変更が競合したら、Joplinのノートのバックアップを作り、Zimのノートを上書きし、メッセージを出すようにした。 (11/22 18:01)
          • また、インポート時(Joplinから操作)も同様にした(Zimのバックアップを作る)。
      • ノート中のscheme(例: http://)に見える記述やリンク(パスがリンクになる)の無効化または正常化? → ノートを読んでからフォーマットするため、指定箇所の無効化は無理そう(もちろん、その部分の書式をコードにすれば可能だし、全部を無効にすることはできそうだ)。 (11/22 18:01)
        • Joplinからインポートした時に変なノートができるのを防ぎたい。
        • また、変なリンクがあると、Zim自身でノートをペーストできない場合がある。
        • これに関連して、不正な"file:"のURLがあるとfs.pyがAssertionErrorになってエクスポートできない問題があったので、assertしないように修正した。 (11/22 18:01)
    • UI
      • 正式なノート名などの表示の追加(例: page index)
      • 正式なノート名などの入力UIの追加
      • ツールバーの箇条書き, 番号付きリスト, リンクなどの書式設定ボタン(: "x2"の右の箇条書きとその右の"H"の右のボタン)で出るメニューの要素を独立させて横に並べる。
        • プルダウンメニューは面倒なので。
        • ただ、多過ぎると邪魔になる。
      • カーソルの点滅を止める。
      • CSDを止めてなくなった前・後ページボタンを付ける。
    • その他
      • Zimでコピーしたテキストも、追加したテキストのペースト機能(本文に記述)でできるようにしたい。
      • 起動するたびに/tmpにログディレクトリ(zim-xxxxx)を作らないようにする。
      • アイコンが超ダサい。これだけで随分損しているのでは?
        • でも、そんなことは僕にはどうでもいいので放置w
  •  1
  •  0

Zim+Joplinで自分用ノート管理システムを作ろうとしたが、挫折しそうだ。Zimの完成度が低くて、先行きに十抹くらいの不安を感じた。いろいろ苦労して、Zimで変更・作成したノートを自動でJoplinに更新・取り込みできるようにしたのだが、Zimの不可解な動作や問題が次々と現れて これ以上対処するのが嫌になり、ガッとひっくり返したくなった。

単体でちょっと使うのには良かったが、Joplinと連携させて使い込むと、機能不足、不具合、変な仕様がバラバラ出て来て、そのカバー("workaround")が大変だ。ただ、それなりに まともな考えで ちゃんと作ろうとしているのは感じられるし、「普段」の使用では概ね快適に使えているので、今までの他のソフト(例: Evernote, Joplin, QOwnNotes, Zittlr)と違って腹は立たず、「クソだ」とは言わない。単に未完成なだけ(まあ、「ちょっと実力が足りないね」みたいな)だ。ただ、これが完成するとは到底思えないのが痛い。。。

参考までに、僕にはキツい問題を挙げる。

  • ノート名に使えない文字が多い。
    • 仕様の問題: ファイル名をノート名にしているため。
      • そうは言っても、Linuxで普通に使える文字でも駄目なものが多い。
    • 多くの記号(例: ()[] #)と空白が使えない。
    • ノート名先頭の文字は更に制限が厳しく、 おそらくすべての記号が使えない。
      • 仮に全角文字や非英語の文字にしても、記号のカテゴリは駄目。
    • 文字のカテゴリで余計なチェックをしているのか。
      • → 確かにチェック・制限していた。: zim/notebook/page.py の _pagename_invalid_char_re で行っている。 (11/16 10:21)
        • なぜ、(ASCIIのでない)Unicodeの記号も駄目にするのだろう???
    • → 仕方ないので、記号に見える普通の文字で代用してみたが(例: 下図)、本質的でない無駄な努力(例: ガラケー的なw)に思える・・・
      • Zimでノート名に使えない文字(() 𛰙𛰚, 空白 )を代替してみたが・・・

  • 表示の更新がおかしいことがある。
    • テキストの入力後に行が重複して表示されることが多く、迷子になってしまう。
      • ページを上下させると直る。
    • → その後、フォントが関係していることが分かった。デフォルトのフォントだと問題は起こらず、僕の愛用している源真ゴシックPだと起こることが分かった。 (11/16 10:02)
      • 源真は行間が広目なので、それが関係しているのか。
      • ただ、デフォルト(なぜかTakao Pゴシックのようだ)は行間以外に色が濃くて(線が太い?)すっきりしない・読みにくいのが嫌なので、問題が起こっても源真で頑張りたい。
      • また、Noto Sans CJK JPは漢字が等幅なので嫌だ。
  • 謎の動作・仕様がある。
    • ノートの先頭に書いたタイトル(見出し)がエクスポートされないことがある。
      • → とりあえず、そうなった時は先頭に何か(例: "."だけの行)を書くことで、しのぐことにした。 (11/16 12:15)
    • ノートを取り込むと、実在しない変な名前のノートができてしまうことがある。
      • ノート中に"file:"があると、そうなるようだ。 → URLに見えるもの、Joplinのノート間リンクが駄目な感じ。
        • 名前はそのURLになっている。
        • そんなことされたら邪魔臭い。
      • その場合、エクスポート(インポートも?)がエラーになることがある。
      • → 目障りなので、Joplinから取り込む時に削除するようにした。それが分かるように、その前の行にその旨を入れるようにした。と書いたが、本当に動いているか あやふやだw そうしようと思っただけだったかも知れない。まあ、やればできる。 (11/16 18:45)
    • エクスポートがすごく遅いことがある。
      • エクスポート時にもトップ以下のファイルをスキャンしているため?
  • 結構落ちる。
  • ノートの保存ができないことがある。
    • ノートを外部で変更すると弱い?
    • → どうやら、同じノートをZimと外部で同時に変更すると「負ける」ようだ。これは仕方ない。 (11/16 10:15)
      • Zimから自動でJoplinに追加する時、Joplinで新規だった場合には あとで更新する時のためにJoplinのIDを入れるのだが、それが良くないようだ。難しい。
        • → 今後は、JoplinのIDは別ファイルに入れることにした。そうすれば、あとで追加ノート情報も入れられる(今は未定だが、例えば「本当のノート名」が入れられる)。 (11/16 12:18)
  • 行の(ソフト)ラップがないように振る舞う場合がある。
    • 長い行でカーソルが編集ペーンの右端近くに行ってしまい、Homeキーで行頭に戻れない。マウスでスクロールバーを動かすしかない。
      • スクロールバーは出さなくていいんだが・・・
  • LibreOffice Calcからの文字のペーストが画像になってしまう。
    • 「テキストとしてペースト」(例: Ctrl+Shift+V)の機能がない。。。
    • → 調べたら、(Linuxで)他にも起こっている人が居た(ペースト先のアプリはZimとは限らない)。ただ、例によって「LibreOfficeの問題じゃない。あっち(例: アプリ側)で聞け」や「クリップボードマネージャを止めろ」などで終わって原因が分からないので、本質的・一般的な解決策はない。 (11/16 12:05)
      • そりゃあ、受け側アプリのクリップボードの中の値の選び方が悪いのは確かだが、そもそもスプレッドシートの「値」をコピーした時に、画像を(も)クリップボードに入れるってのは あきらかに非常識だと思うのだが・・・ いったい どういうメリットがあると考えたのだろう? せめて設定にすればいいのに。
    • → コマンド: xclip -selection clipboard -o でクリップボードのテキストが取れるので、それをZimのカスタムツールに入れた。また、ショートカットが割り当てられるので、Ctrl+Shift+Vにして一般的な操作でテキストがペーストできるようになった。 (11/17 9:38)
      • -selectionはprimaryでテキストが取れこともあるが、secondaryは駄目。 → Zimはsecondaryを取っている?
      • また、なぜかZimでコピーしたテキストは取れず、ハングすることもある。 → タイムアウトを付け、clipboard, primary, secondaryの順に試すようにした。: Zimの謎は多い。
        • ハングするのはxclipを普通に動かしていたためだった。オプション-quietを指定すれば良い。
        • が、それでもclipboardではハングし、どうしても解決できない。Zim自身と競合しているのだろうか。
        • → 結局、 xsel -n -o -p (primaryを取得, フォアグラウンドで動かす)だけにした。 (11/17 11:07)
  • UIが整理されていない。
    • メニューは どこに何があるか迷う。
    • ブックマークが多くなると全部が見えなくなる。
    • CSDらしいのが嫌(例: ウインドウのタイトルバーにアプリのボタンがある)。
  • 起動するたびに/tmpにログディレクトリ(zim-xxxxx)を作る。
    • これは ちょっと違うだろ・・・

 

他に、僕のシステム構成の問題として、画像(リソース・添付ファイル)の処理の難しさがある。Zimで追加した画像をJoplinに入れるのが面倒だ。ディレクトリが異なるので、コピーだけでなく、ノート中のディレクトリ名も変える必要がある。

→ とりあえずは、Zettlrの時と同様に、まず画像をJoplinの作業用のノートに貼り付けてJoplinに取り込み、そのノートをZimに戻し、その画像(のタグ)を本来のノートに貼ることでしのいでいる。面倒だが、頻繁でないので それほど苦ではない(プログラムを作るよりは楽だw)。 (11/16 12:27)

 

そして再び振り出しに戻って、次の候補探しを始めた。今度は、やっぱり、前回諦めたWPみたいなwebでできるものがいい気がしている。それなら、最後に書いた画像の問題は起こらないはずだ。が、セキュリティの問題はある。

その後、他のエディタやWPに近そうなWikiのソフトを検討・試してみたが、僕に丁度いいものが全くなく、なかなか意外な結果となった。以下を検討・試した。

  • 検討で却下したもの。
    • OpenNote(Wikiではない), MyTetra(同), TiddlyWiki, TagSpaces, BookStack(前回も却下 → その後試したが・・・), Wiki.js, PmWiki
  • 試したもの。
    • RedNotebook(Wikiではない)
      • MDみたいな入力でプレビュー型
      • 機能が貧弱で話にならない。
      • Zimのほうがずっといい。
    • MediaWiki
      • デモを使った感じでは一番良かったが、WikiPediaのような公開Wikiがターゲットのため、個人のノート用には いろいろ使いにくい。
        • 例: 画像を入れると、「それはあなたの?」などと聞かれる。
        • カスタマイズすればいいのかも知れないが。
      • デザインがイマイチ。
      • 引用がない。: WikiPediaの特徴?
      • 例によって日本語がひどい。
        • 英語にしたつもりが日本語になっていた・・・
    • MoinMoin
      • 著名なオープンソースプロジェクトに採用されているらしいが、良く使ってると思う。10年以上前の感覚。
      • 設定が分かりにくく、不親切。
        • ファイルがいくつもあるが、検索しないと説明がない。
        • サイトも不親切。
        • 簡単にWYSIWYGエディタにできない。 → ガイドを参考にして ようやくできた。
      • エディタがすごく使いにくい。
        • ショートカットがない。
          • → ブラウザなので、太字にするつもりでCtrl+Bを押すとブックマークになってしまう・・・ 「うむ。」
        • タブでインデントしない。(上と同じ)
        • ボタンのアイコンがボケている。
    • XWiki
      • JAVAでメモリを食うので不可。
      • エディタは まともだが、書式の指定が ちょっと使いにくい。
    • Foswiki
      • エディタがすごく使いにくい(MoinMoinと同じ)。
      • 登録時のキャプチャが全然読めなかった。5回くらい繰り返した。
    • WackoWiki
      • WebサーバがApacheでないせいか、うまく動かなかった。
    • DokuWiki
      • 試したうちでは一番好印象(使い勝手がWPに近い)だったが、エディタに問題があって却下した。
      • デフォルトのエディタは使いにくいが、プラグインのCKGEditorを入れれば使いやすくなるものの、うまく合っていない。
        • 画像(説明では直ったと書いてあるようだが・・・)や引用ブロックが ちゃんと表示できない。
          • 画像はデータが表示され、引用は前後にタグが出てしまう。
      • プラグインがwebで入れられて楽。
      • インストールなどの説明も分かりやすかった。
      • Webサーバはlighttpdやnginxが使える。
      • ただ、新しいページの作り方が不明。Wikiのせいか?

 

我ながら要求が厳しすぎるようだ。まあ、ノートを書くソフト(特にエディタ)は いつも使うので、仕方ない面はあるが・・・

結局、今のところは、Zimで まさに「頑張る」※かWPを使うかの二択となった。

※骨を埋める覚悟ならソースに手を入れるが、ちょっとまだその気になれない。

(17:45)

本文を読み返して、Zimで頑張ることは あり得ないと確信した。「だめだこりゃ。次行ってみようだ。」 (19:22)

更に少し考えたら、WPはそもそもブログ用なので、使い方がノートとは合わないことに気付いた(以前検討した時にも気付いた気がする)。例えば、「更新」ボタンを押さない限り、編集内容は反映されない。しかし、ノート用エディタは書いて放置すれば反映される(アプリによっては、履歴が保存されるから、それで全然問題ない)。その気軽さが重要で、ノートにはワープロが使えないと感じるのも、そういうことである。

てな訳で何も残らん・・・

せいぜい、DokuWikiやMediaWikiを頑張って改造する? いや、それらにしたって「保存」ボタンはある。 (21:06)

その後、再度Wikiなどを試したが、まあ全滅だった。

  • BookStack: 綺麗ではあるが、実用性がない。サポートする気が感じられない(「こっちでは再現しない」的な回答ばかり)。
    • 大きなノート(約4000行)の保存に失敗する(既知の未解決の問題)。
      • いろいろなタイムアウトを伸ばしたが、駄目だった。
      • HTML関係の処理が悪いのではないかと思う。
    • 大きなノート(約3000行)の変更(編集)が遅い(Zittlrと同様)。: 「ブラウザ(≒ JS)もElectronも似たようなもの」ってこと。
  • MediaWiki: 詰めが甘い。セキュリティがいい加減。サポートも いい加減(問題を放置)。やっぱり、Wikiはノートには使いにくい。
    • Visualエディタでノートを読み込む動作がおかしい(既知の未解決の問題)。エラーが出たり出なかったり・・・
      • WikiとHTMLの変換処理("Parsoid"とかいうモジュールらしい)の出来が悪いのではないかと思う。
    • 設定ファイル(DBのパスワードなどが平文で書いてある)がwebサーバのドキュメントルートにあるって、とんでもない落とし穴だよ。。。
      • 「Webサーバを適切に設定しろ」と書いてあるだろうし、それを忘れて流出して実害がないとしても、作った人の意識の低さが知れる。
  • DokuWiki: 出来が悪く、使い物にならない。終わったソフト?
    • Visualエディタにノートをペーストして保存して開くと、フォーマットが崩れる。
      • HTMLやMDをインポートしても同様。
      • 大きめのノートで起こりやすいが、小さくても起こると思う。
    • 入れると何もかも動かなくなる(表示が真っ白になる)プラグインがある。
      • そういう情報は何も書いてないのに。
    • プラグインを入れても、どこにもその操作(ボタン)が出て来ないものが多い・・・

あと、BookStackで実感したが、WPもブラウザ(JS)なので、やっぱり大きなノートの変更(編集)は遅くなるだろうから、いくら使い勝手が良くてもノート用には使えない。

そうすると、結局Zim(+Joplin)しか残らないが、「何とかすべきこと」が多過ぎる! でも、さし当たっては(曲がりなりにもw、そして、僕には一番ストレスなく)Zimは使えるので、様子を見ながら考えたい。 (11/15 19:00)

  •  1
  •  0