Archive for the ‘Linux’ Category

夏が来た!
夏が来た!

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

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、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で取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作の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に出た、参考になるページがあった。)

実際には、原因は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

夏に作った、ディスプレイの輝度自動調整システムの明るさセンサの ついでに付けた室温測定機能。冬になってから、朝などに温度センサ(以下、「センサ」)と一般の温度計(以下、「シチズン大」)の差が大きいのが気になって居た。1℃くらい温度センサが高いようだった。合う時もあるので、「たまたま」wか、測定場所が違うせいかと思って居たのだが、そもそも、朝起きた時には ずっと空調が停まっていて室内の温度が ほぼ同じと考えられるにも関わらず違っているのはおかしいし、段々ズレがひどくなって来て見過ごせなくなったので、重い腰を上げて調整した。想像以上に大変だったが、センサと温度計が合うようになったのが気持ちいいし、今まで分からなかったことが分かった(気がする)。

なお、ここでは、シチズン大が「真の温度」を示すと仮定し、センサの示す温度を それに近づけるような補正を考えている。もちろん、シチズン大にも誤差はあるが、市販品なのでセンサよりは正確で安定している(突発的な誤差の変動が起こらない → ほぼ一定のオフセット誤差が長時間続く)と想定する。

ズレの原因は、推定した温度センサ(サーミスタ)のパラメタ(B値, 基準抵抗値, 基準温度)が異なっているのかパラメタが温度依存なのか、温度が下がるにつれてサーミスタの抵抗値から得られる温度が高くなるためだった。そのズレの量は、パラメタが合っているであろう温度からの差に比例しているようだ(簡単に言うと、温度が上がるとズレは減る: 下図の灰色の点線が補正量(= ズレの符号を逆にしたもの)。

YL-40の温度センサを直線で補正した。

今までの測定と調整から、補正の式は以下のようになった。

補正パラメタ:

    • 補正する下限の温度: Ta (実際にはこれより低い温度も可能)
    • Taでの補正量: Da
    • パラメタが合っているであろう温度: Tb
    • Tbでの補正量: Db= 0

→ 補正直線の傾き: k= (Da-Db)/(Ta-Tb)

温度補正式: センサの温度をtとすると、補正後の温度t'は以下である。

t < Tbの場合: t’= t + k * (t – Ta) + Da
t >= Tbの場合: t'= t

実際のパラメタは以下になり、kは0.0905となった。

  • Ta: 14.0 (℃)
  • Da: -1.72 (℃)
  • Tb: 33.0 (℃)
  • Db: 0 (℃)

以下に補正の例を示す。

  • シチズン大: 15℃: 補正前のセンサ: 16.35℃, 補正量: -1.51℃ → 補正後のセンサ: 14.8℃
  • シチズン大: 20℃: 補正前のセンサ: 21.15℃, 補正量: -1.07℃ → 補正後のセンサ: 20.1℃
  • シチズン大: 22℃: 補正前のセンサ: 22.84℃, 補正量: -0.92℃ → 補正後のセンサ: 21.9℃

ズレは結構大きく、しかも、ほぼ全温度(33℃以下)でズレて居たことになり、一体僕は何をしていたんだと、なかなか がっかりだ。確かに、夏に調整していた時も、夕方などに なぜか0.6℃くらいズレたままだったことがあって、当時はシチズン大の「熱・冷え溜まり」と思って片付けたが、実は こういうことだったのかも知れない。※ ただ、温度が高くなると上の補正式からズレてくると思う(実際には曲線なのではないか)ので、春や初夏に再度確認・調整したい。

※今、上の式で26℃での補正量を計算したら、-0.63℃だった。合わない0.6℃の正体は これだったのだろうか? (だったら楽で いいが・・・w)

 

何日間も寒い朝に暖房なしで測定するなどの苦労をして、上の補正式とパラメタを求めてプログラムに適用したところ、概ね合うようになった(下に例)。

YL-40とシチズン大の温度が合っている例。: YL-40の温度は右端下部の"Rm ℃"の下。

上のグラフを説明する。: グラフは補正式が分かってからの数日間の測定・補正結果を示している。横軸は温度センサでの温度、縦軸(左)はシチズン大での温度または補正後の温度、縦軸(右)は補正量(オフセット)である。グラフ中央の斜めの点線は補正前後の温度を示す。測定した温度の点が この直線上にある時※、温度センサ(補正後)とシチズン大の温度が「合っている」状態である(ほとんどの点はセンサの分解能の約±0.25℃に収まっている)。

※正確には、「この直線の近くにあるはずの、センサの温度とシチズン大の温度を対比する線上」であるが、センサの温度とシチズン大の温度を対比させることは正確な補正することであるので、描くことはできない。

下のほうの灰色の線は温度センサの温度に対する補正量(縦軸は右)を示す。

たまにズレが大きいことがあるが、暖房をし始めたり、日が出て来たりして温度変化が急な場合に、温度計とセンサの温度反応速度の違いが影響していると推測している。不思議なのは、なかなか合わない領域があることだ(グラフの20-22℃の膨らんだ部分)。

他におもしろいのは、日によって測定点の直線からのブレ方(上か下か)が違うことだ。センサのADCの特性が長短時間的にブレるためかと想像している。そのため、補正後の値のグラフが そのブレの範囲の中央辺りを通るように調整した。

 

最後に苦労話を書く。

センサとシチズン大の温度差をちゃんと測れるようになるまでが大変だった。そもそも、「同じ温度」を比べていないのに気付かずに惑わされたので、何度も試行錯誤した。空調(暖房)の影響にも惑わされた。一時は、机の下の電気ストーブや日射しや横にあるディスプレイの熱もズレる原因かと思ったが、それらはセンサとシチズン大の両方に効くので、直接の原因ではないことが分かった。ただ、反応速度に差があるので、短時間的にはズレるため、原因と誤解してしまった。

やはり、以前も書いたように、正しい測定・計測が一番重要だ。これを しなければ・できなければ、何もできない・始まらない。

測定ファースト!

それから、電源を入れてからセンサが温まるまで(約10分)は温度が低目に出ることにも惑わされた。夏でもそうだったが、寒い場合はその時間が長引くことに気付かなかった。それが分かるまでは、補正は中央辺りでV字に交わる2つの直線(低温側の傾きは負)なのかと思ったが、そんな器用なものではなかったし、日によって結果が異なった(電源を入れる時刻が違うので、開始時の温度も違うため)ので、そのたびに補正パラメタを変更していた。

あと、センサのケースの通風が悪いのかと思って、側面のほぼ全体を開口にしてみたが、効果があったかは不明だ(温度の精度の点では ないだろう)。まあ、埃が入りやすくなる以外は、通風が良くて悪いことはないのでそのままにしているが、もし、センサ付近に埃が溜まるようなら、狭めたい。

 

PS. センサの温度分解能の0.25℃は物足りない。ちょっとした時に差が大きく見えて、気分が悪い。今はADCの測定可能範囲の半分以下しか使っていないので、フルに使うようにすれば0.1℃オーダー(例: 0.18℃)にできる。のだが、かなりの手間が掛かる(例: 明るさも温度も調整・較正し直し)ため保留している。というか、やりたくないw

そもそも、分解能を上げても それに合う精度が あるかは疑問で、「雑音で ふらついているだけ」ってことになるかも知れない(それでも、平均すれば精度が高められる可能性はある。音や画像のディザーのイメージ)。

分解能以外に、ADCの誤差(オフセット, 直線性)を補正できないかと思って基準電圧源を調べたが、手軽なものではADCの分解能(約14mV)を超えるものは なさそうなので諦めた。また、1個だけでは駄目で、少なくとも2個(高・低電圧)必要なので、なかなか大変だ。

  •  1
  •  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

乗り換えたばかりのZettlrは使い込むと駄目だった。Electronのため、大きいノートの編集が遅くなるのが一番イライラする(日本語なんて、入力に追いつかなくて ひどい)。※あと、余計な補完だの書式を勝手に変える(勝手に破壊して、なかなか直せないことがある)とかも、やっぱりイライラする。

※JavaScript≒ブラウザでテキスト・画像その他を処理しているので、どうしても無理があるのではないか? 最新のマシンなら問題ないのかも知れないが、元々効率が悪いものだけど すごい環境で動かせばいいという思想なのだろうか? まあ、Intelには馴染みが良さそうだw

そもそもMDが嫌いだ。書いている途中で いちいち書式を思い出したり調べたり、(エディタのせいでプレビューがおかしくて)調整するなどと、本質でないことに手間が掛かって書くことに集中できないし、見た目も煩雑だ。※ 今は流行っているが、僕にすれば全く奇妙な現象で、そのうち もっといいのが出て来て廃れるのではと思う。

※文章に書式指定が混ざっていて、良く普通に読めるものだ。MD愛好家・信者は そういうのが透明にでも見えるものなのか。至るところに混在していても「ないもの」にできる? 全く器用だ。

そこで浮上したのがZimである。前にも書いたように、これはワープロほど高機能ではなく、"Desktop Wiki"を自称しているように とてもシンプルなものだが※、僕がノートを書くには必要充分で、まさに「こういうのでいいんだよ」だ。あと、(ElectronのJoplinに比べて)超省メモリ(約1/3-1/10!)なのも 好感が持てる。もちろん高速だ。

Zim:  「こういうのでいいんだよ」って感じ^^

※ツボは押さえており、ちゃんと上/下付き文字もできるw もちろん、画像も貼り込める。

気になるのは、作者が多忙(あるいは疲労?)で いつ終了するか分からず、そこまで行かなくても、この先も改良される期待ができないことだ(それでも、細かい修正は続いている)。まあ、オープンソースなので、終了する時はソースを引き取って自分で面倒見ることも可能だと考えて、使ってみることにした。

 

ただ、僕の使い方(スマフォからもアクセスしたい)としては、Zimはノートの共有・同期の機能、あるいは それを補助するような機能を持っていないのが困る。※

※実際にはwebサーバの機能が内蔵されていて確かに動くが、Zimの完成度や作者の状況を見るに、このサーバをインターネットで使うにはセキュリティ面でのリスクが高過ぎるので、「持っていない」と書いた。もちろん、使いたい人は使えば良い。

いろいろ検討したが、スマフォからのアクセスに関しては、どうにも いいものがない。Dropboxなどのファイル共有でZimのノートやMDなどを共有すれば、MDエディタで見られる(MarkorはZimのノートをサポートしている)。が、残念なことに画像が表示されない。事前に画像もスマフォに同期しておけばできるが、見るかどうかも分からないノートと画像など全部を常にスマフォに同期しておくのは余りにも効率が悪いし、電池や通信データ量を浪費する。

逆に、ユーザが指示した時だけ同期するソフトだと、ノートを見たいだけなのに、まず「同期」の操作をし(て、同期を待た)なくてはならず、面倒この上ない。そんなの忘れて古い情報を見てしまうか、面倒で使わなくなってしまうだろう。

もう一つ、ノートをHTMLに変換してwebサーバに置けば、スマフォからのアクセスはとても容易になる。上に書いたような同期は不要で、必要な情報だけがダウンロードされるし、特別なアプリも要らない。が、いろいろなノートを全部平文で格納してwebで公開(もちろん認証する)するのは多くのリスクがあって、かなりの勇気と慎重さが要る。

そこで出て来る(生き延びているw)のがJoplinだ。Joplinも実際にはノート全部をスマフォにダウンロードしておくようだが、画像はノートを開く時にダウンロードするので効率が良い。また、不具合のおかげなのだろうが、設定していてもバックグラウンドで同期しないので、アプリを開かない限り電池も通信量も消費しない。その代わり、アプリを開いた時に同期が終わるのを待たないと(そのあとで再度同期が要る場合が多い)、ノートが最新にならない(同じアプリなので、面倒さは少ない)。

という訳で、最新のシステム概要は以下のようになる。

  • PC
    • 僕: Zimでノートを作成・変更、表示する。
      • 当初はJoplinのノートを変換して取り込むことが多いので、そのためのプログラムを作成する。
    • ノート変換・更新プログラム: (スマフォで見たい)ノートが作成・更新されたらMDに変換し、Joplinに入れる(ノートが既にあったら更新する)。
      • 自動で行うようにする予定。
    • Joplin: サーバにノートを同期(アップロード)する。
  • サーバ: ノートを格納する。
  • スマフォ
    • Joplin: サーバからノートを同期(ダウンロード)する。
    • 僕: Joplinでノートを表示する。
      • ノートの更新はせず(Joplinが重いので諦めている)、記録は別のシステムを使う。

そして今は、いくつかのノートをZimに移して機能や操作性などを確認しつつ(ダメ出し+習熟)、ZimとJoplin間のノート変換・取り込み/更新プログラムを作っている。

システムを作る際にZimのいい点は、グラフィカルに(WYSIWYGで)書式設定できるにも関わらず、ノートのファイルが非常に単純なテキスト形式(MDに近い)なので※、テキスト処理ツールで自由に処理できることだ。

※紛らわしいが、ZimのファイルフォーマットはZIMというファイルフォーマットとは異なる。なので、前者は"Zim-wiki"などと書かれることがある。

また、意外なことにpandoc(テキストフォーマット変換プログラム)がZim形式での出力("zimwiki")に対応している(JoplinのMDを入力するには"gfm"を指定するのがいいようだ)※ので、MDからの変換が可能だ。また、Zim自体でMDへのエクスポートが可能なので※、pandocと併用すれば、一応はMDとの相互変換が可能だ(今までのところ、MD-Zimの変換・逆変換をしても書式は崩れていない)。

※なぜか、pandocはZim形式での入力はできず、ZimはMDのインポートができない。

 

今まで同様、このシステムも、いつ気が変わって「はい終わり」になるか分からないが、まあ、苦労して作ったからと言って特に固執せず、その時々で良い・使えるものが できれば・見つかれば良いスタンスだ。

永遠のプロト・PoCか、継続的スクラップアンドビルドか、あるいはシステムの焼畑農業か星一徹式開発か?w

 

PS. Zimを使っていたら、早速思わぬ欠点に気付いた。引用の書式がないのだ。あと、段落のちゃんとした(綺麗な)インデントもない。※ 良く使うものだが、ないものは仕方ない。作者なりの考えなのだろう。

※ちゃんとしたインデントはあった。MDにエクスポートする時になくなってしまったようだ。そうだ、EvernoteからJoplinに移行する時に、MDにはそういう概念がなくて困ったのを思い出した。その時は">"を使った。

代わりに、例えば、引用部をコードブロック(verbatim)にするとか、斜体にするとか、上下を目立つマーク(例: "+++")で挟むとか、MDのコードブロックの記号で挟む("```"などは そのままMDに行く)などの代替ができる。他には、単に段落をインデントさせるのもいいかも知れない。

作者としてはverbatimを使うことを想定したと思う。それは間違っていないのだが、そうすると引用部に書式が付けられなくなくなってしまうのが、不満なのだ。まったく、「シンプルなのでいい」と言っていた舌の根が乾かないうちにw

それから、インデントは、まあ、箇条書きで代替すればできるし、現状でも「綺麗でない」インデントは可能だ。

でも、何となく気に入らないので追加したい気もするが、やり過ぎだろう。 (11/9 19:16)

本体を改造するのはハードで やりたくないので、別件で見付かった余計な変換(例: "//...//"が"*...*"になる)を吸収するのと一緒に、MDへのエクスポート前にノートを変換して何とかした。

引用部はインデントすることにすると、ZimはインデントをTABで表現しているが、MDにエクスポートする時に削除されてしまうので、エクスポート前に、とりあえずMDのblockquote(">")のTABの数分繰り返しにして、MDに残るようにした。 (11/10 18:55)

  •  1
  •  0