テキストエディター「Mery」ベータ版 Ver 2.7.8 を公開、フォントフォールバックに対応！

コメント (94)

1. お疲れ様です。
   新機能追加お疲れ様です。
   最新に更新してきました、使い倒してみせます！

   2019年5月19日 23:54  |  荒野炎神

2. 更新お疲れさまです！
   他のタブを閉じる系のショートカット対応、ありがとうごさいます。

   フォールバックフォント対応とは、ますますモダンなエディタと化してきましたねー。素敵です。

   ちなみにスクロール速度が速くならないときの条件の自動マーカーですが、ON にして文字選択をしている場合ですか？
   それとも、ON にしていると文字選択の有無に関わらずスクロール速度向上の対象外になりますか？

   2019年5月20日 4:33  |  yuko

3. 縦書き可能なエディターで、フォントフォールバックを使える！
   （アンチック体など）２つのフォントの漢字や仮名を組み合わせて混植のサンプルを見て、
   ピックアップするフォントを選ぶ用途に使えそう。

   合成フォントを作ったり、フォントリンクしたりするより、Word使ったりするより
   ざっと確認しやすそう。

   ブックマークが吹っ飛ぶ件の対処もおつかれさまです。

   2019年5月20日 16:03  |  tak

4. Mery ver 2.7.5 更新おめでとうございます ＆ おつかれさまです。
   一週間の沈黙は体調をくずされてのものかとおもっていましたが、黙々と更新作業をつづけていてのことだったとは！ :o

   > フォントフォールバック
   心惹かれるものはありますが、「ないよりはマシ、という感じ。」という Kuro さんの言葉と、いいオサーンが絵文字を使うことなんてありゃしないことをかんがみれば「まぁいいか」と。 :|
   今回は目玉機能の恩恵にあやかることは適いませんでしたが、ほかの細かな部分での使い勝手の向上について、とても喜ばしく、有難くおもいます。

   > [書き換え禁止]をいつでもできるようにした。
   「書き換え禁止」の仕様変更は、編集状態を気軽にロックできるようになるので、とてもありがたい部分です。読み取り専用属性のファイルでもダブルクリックでの書き換え禁止の解除ができるようになったのも ◎ です。 :)

   > 色選択のダイアログを開いたときにフルオープンにした。
   そもそも Windows 標準の色の設定ダイアログ自体の使い勝手が微妙（RGBの16進表記でコピペできない）っていうのは置いといて…。パレットの色をそのまま使うことなんてほとんどないから、さいしょから右側が開いた状態なのはとてもいいかんじですね。

   > マクロのSetBookmark、ClearBookmarkの動作を修正。
   > [選択範囲の変換]でなるべくブックマークを保持するようにしてみた。
   SetBookmark() メソッドについては先だって手元のマクロからすべて剥いでしまったのですぐには確認できませんが、「選択範囲の変換」でのブックマークの保持については好調なようです。マクロの ChangeCase() や ChangeWidth() メソッドでもブックマークがしっかり保持されるようですね。 :)

   2019年5月20日 19:49  |  sukemaru

5. >> 荒野炎神 さん
   コメントありがとうございます。
   今回はメンテナンスと改善が中心の地味な更新なのでつまらないと思います… ^^;
   お手柔らかにお願いします！

   >> yuko さん
   コメントありがとうございます！

   > 他のタブを閉じる系のショートカット対応、ありがとうごさいます。
   ツイッターでつぶやいていた、リリース直前にバグが見つかったのはそこです ^^;
   たぶん直ってるはず…。

   > フォールバックフォント対応とは、ますますモダンなエディタと化してきましたねー。素敵です。
   モダン化は意識してなくて、ほぼ技術的好奇心のみですね… (w

   > ちなみにスクロール速度が速くならないときの条件の自動マーカーですが、ON にして文字選択をしている場合ですか？それとも、ON にしていると文字選択の有無に関わらずスクロール速度向上の対象外になりますか？
   これは説明が難しいので、記事中ではざっくり書かせていただきました。

   仕様的には、自動マーカーが ON でも全行の再描画が発生しないケースではスクロール速度が改善されています。

   例えば、自動マーカを ON にしていて [カーソル位置の単語を取得する] がオフであれば、スクロール速度は改善の対象となっています。

   自動マーカーが ON で文字選択されていた場合でも、選択範囲を広げながらスクロールすると遅くなりますが、選択範囲はそのままでスクロールバーを使ってスクロールした場合は改善の対象となっています。

   あと、そもそも DirectWrite をオフにしている場合でもスクロール速度は改善されていますが、もともと速かったのでそれほど違いはなさそうです。(1 行が長すぎる場合とかだと若干高速化されたのがわかる程度)

   >> tak さん
   コメントありがとうございます。

   > 縦書き可能なエディターで、フォントフォールバックを使える！
   縦書きでもフォントフォールバック可能ですが、フォントフォールバックって行間の情報とかはメインのフォントに依存しますので、記事中にサンプルで記載している英字フォントをメインにした利用方法だと、縦書きにした場合、縦書きが考慮されていない英字フォントの行間がベースになるので、ちょっと怪しいことになるかもです。

   > （アンチック体など）２つのフォントの漢字や仮名を組み合わせて混植のサンプルを見て、ピックアップするフォントを選ぶ用途に使えそう。
   そんな使い方が！原理的にはそういう使い方もできる気がしますが、テストしていないのでそんな用途で使えたらぜひ教えてくださいね。

   > ブックマークが吹っ飛ぶ件の対処もおつかれさまです。
   ありがとうございます。なはは…、あれは本当に疲れました…。

   >> sukemaru さん
   コメントありがとうございます。

   > 一週間の沈黙は体調をくずされてのものかとおもっていましたが、黙々と更新作業をつづけていてのことだったとは！ :o
   精神と時の部屋にこもってくるって言ったじゃないですかー。
   記事の末尾に疲れ果てたイラストを貼りましたが、まさにあの感じでした。

   > いいオサーンが絵文字を使うことなんてありゃしないことをかんがみれば「まぁいいか」と。 :|
   絵文字以外にも用途はあるのですが、DirectWrite を使っていない場合は普通に Windows のフォントリンクで対応できる範囲ですね。でも、がんばって作ったので PC を新調された日にはぜにお試しいただければと思います。

   > 読み取り専用属性のファイルでもダブルクリックでの書き換え禁止の解除ができるようになったのも ◎ です。 :)
   はい。寝落ち対策にご活用いただければと (w

   > そもそも Windows 標準の色の設定ダイアログ自体の使い勝手が微妙
   わかります。何度、Photoshop みたいなカラーピッカーを実装しようと思ったことか。(exe のファイルサイズがでかくなるので却下)

   そういえば、代わりに裏技を搭載していまして、テーマ作るときの色選択で Ctrl を押しながら [カスタム] や [...] を選択するとコード入力のダイアログが表示されまして、HTML カラー形式「#ff0000」や、RGB カラー形式「rgb(255,255,0)」とか、HSL カラー形式「hsl(261,100%,75%)」で入力できるようになっています。

   > マクロの ChangeCase() や ChangeWidth() メソッドでもブックマークがしっかり保持されるようですね。 :)
   動作確認ありがとうございます。ブックマークを保持した置換はホントヤバイです。

   2019年5月20日 22:06  |  Kuro

6. >> yuko さん
   追伸ですが、他のタブを閉じる系のショートカット対応のバグ、やっぱり直ってなかった気がします。再度、調査しようと思います。

   …と思ったけど、再現しなくなってしまいました。他のタブを閉じる関連の機能で変な挙動したときは教えていただけると助かります。

   2019年5月20日 22:13  |  Kuro

7. Kuro さん

   > これは説明が難しいので、記事中ではざっくり書かせていただきました。

   概ね理解しました。ありがとうございます。

   できる限り遅延の影響を最小限にされた努力が垣間見える条件の内容ですね😯

   > 他のタブを閉じる関連の機能で変な挙動したときは教えていただけると助かります。

   了解です。ちなみに、発生していたバグとはどんな挙動のものなので？

   2019年5月21日 8:51  |  yuko

8. >> yuko さん
   ご返信ありがとうございます。

   テキストエディタって描画速度との勝負みたいなところがあるので細かい仕様を記載するとキリがないのですが、記載した条件以外でも、選択範囲を拡張しながら矢印キーでスクロールした場合は、選択範囲の開始～終了までの範囲が再描画されるので遅い、とかもあります。(もちろん画面外の選択範囲は速度に影響ないですが)

   ベストエフォートみたいな感じですかね ^^;

   > ちなみに、発生していたバグとはどんな挙動のものなので？
   これは [他のタブを閉じる] の機能自体がそもそも発動しないことがあるっていう挙動なのですが、たま～に「あれれ…？」ってなるのですが、再現性がなくて困っています。

   2019年5月21日 22:35  |  Kuro

9. > 精神と時の部屋
   > 記事の末尾に疲れ果てたイラストを貼りましたが、まさにあの感じでした。
   心おだやかに精神をおちつけられるお部屋ではなさそうな？ XD
   イラストのかんじだと、外界から隔絶された「虎の穴」とか独居房、座敷牢みたいなところにいたようにしか想像できません。

   > そういえば、代わりに裏技を搭載していまして、テーマ作るときの色選択で Ctrl を押しながら [カスタム] や [...] を選択するとコード入力のダイアログが表示されまして、HTML カラー形式「#ff0000」や、RGB カラー形式「rgb(255,255,0)」とか、HSL カラー形式「hsl(261,100%,75%)」で入力できるようになっています。
   神さま！
   ありがとうございます。#RRGGBB 入力もコピペもばっちりできますね。 :D
   そういえば、一度どこかで見たような気もしますが、今度こそしっかりと頭にたたきこんでおきます。
   テーマいじりを楽しんでいる人たちがこの機能を利用しやすくなるように、 [...] ボタンにポップアップヒントが表示されるとよさそうな気がします。 :)

   2019年5月22日 1:06  |  sukemaru

10. 「編集モードの設定→＊＊＊→プロパティ→構文」の
    「引用符に囲まれた文字列」の1重引用符や2重引用符を有効にしてるとき、
    囲まれていない場合に行末(改行)まで適用されるのは仕様でしょうか？

    例えば英文で「's」が出てくるとそれ以降の色が変わってしまいます。
    可能であれば、対応する引用符がない場合は適用しないでほしいです。

    2019年5月22日 16:04  |  とおりすがり

11. >> sukemaru さん
    ご返信ありがとうございます。

    > テーマいじりを楽しんでいる人たちがこの機能を利用しやすくなるように、 [...] ボタンにポップアップヒントが表示されるとよさそうな気がします。 :)
    隠し機能にしているので、このブログを見てくれている方だけの特典ですね (w

    >> とおりすがり さん
    コメントありがとうございます。

    > 「引用符に囲まれた文字列」の1重引用符や2重引用符を有効にしてるとき、囲まれていない場合に行末(改行)まで適用されるのは仕様でしょうか？
    仕様です。秀〇エディタさんや E〇Editor さん、Sublime Text、Visual Studio Code などでも同様の仕様なので、割と一般的な仕様なのではないでしょうか。

    また、"対応する引用符がない場合に適用しない" というのは、見た目的には綺麗になるとは思いますが、閉じ忘れているときに気づきにくくなるのではないかと思います。

    2019年5月22日 21:23  |  Kuro

12. 更新お疲れ様です。
    フォントフォールバック機能素晴らしいです。

    フォントフォールバック設定中に浮かんだ要望なのですが、[オプション]>[表示] 画面下のフォントサンプルの文字列（Aaあぁ...）に数字の「0」を加えて頂けないでしょうか。
    「0」はフォントによって中に斜線入りのもの、中黒入りのもの、何もないもの・・・様々なのでフォント選びに便利かなと思いました。
    追加で「１」と「７」も表記の好み選びに便利そうですし、「絵文字」があれば対応フォントか分かりやすいかも。

    要望案Bは 「任意の文字列（文書内で選択中の文字列など）をサンプル表示」
    要望案Cは kuroさんが「コレさえあれば世界中の他のフォントなんて要らねぇ」フォントを作って配布
    なのですが、大変そうなので「0」とか「絵文字」の追加をご検討いただけると嬉しいです。

    ※ 今さら書くのも野暮ですが"エイプリル企画"のコメントは私ですよ。

    2019年5月23日 1:00  |  アイスクライマー

13. ＞閉じ忘れているときに気づきにくくなるのではないかと思います。

    例えばMeryのマクロで

    #include "hoge.js

    と書いてる場合、行末の引用符があってもなくてもすでに色が変わってしまっているので閉じ忘れに気づきにくいです(実際何度かエラー出しました)。「次の行へ続く」にチェックしてない場合は改行で色が戻るのでなおのこと。

    「引用符で括られているから色が変わる」「括らなければ変わらない」「色が変わってないなら括られていない」の方が分かりやすいのではないかと。

    2019年5月23日 17:13  |  とおりすがり

14. >> アイスクライマー さん
    コメントありがとうございます。

    "Aaあぁアァ亜宇" は Windows のメモ帳の仕様に準拠したものですが、確かに数字が含まれていたほうがわかりやすい気はしますね。

    ただ、要望案 A は人それぞれ必要な文字が異なるでしょうし、「新しい朝が来た。希望の朝だ」にしてほしい、などのご意見のたびに個人向けにカスタマイズしていくことになると大変そう。

    やるとしたら要望案 B か C になると思いますが、C はフォント作成のお勉強から始めないといけないので何年かかるかわかりません ^^;

    B もオプション画面のスペースの関係でちょっと厳しそうです。サンプル文字の部分を直接編集できれば良いのですが、あそこはエディタではなくて、ただの絵だし…。

    裏技的にサンプル文字のところをダブルクリックしたら任意の文字を入力できるダイアログが表示される、とかなら可能だとは思います。

    でも、サンプル文字って [表示設定]、[フォント設定]、[DirectWrite 設定] にそれぞれありますが、すべて別々の文字を設定したいとなると面倒です。

    > ※ 今さら書くのも野暮ですが"エイプリル企画"のコメントは私ですよ。
    その節はコメントありがとうございました。って、普通に名前、ひらがなになってただけのような…？ ^^;

    >> とおりすがり さん
    ご意見ありがとうございます。
    そうですね、おっしゃることも一理あると思いますが、有名どころのテキストエディタでも同様の仕様ということでご了承くださいませ。

    他のエディタも調べてみましたところ、サクラエディタさんですと、とおりすがりさんのご要望通りの仕様となっているようなので、試してみられてはいかがでしょうか？

    2019年5月23日 19:05  |  Kuro

15. スミマセン、場所の指定間違えてました。
    kuroさんがご指摘の「ただの絵」の部分じゃなく、[フォントの設定]で実際に変化するサンプル表示の部分です。
    ここに、数字の「0」や「絵文字」または、開いてる文書内の選択中の文字列を～ の意味でした。
    私が書いた場所だとフォント切り替えてもサンプルは変化しませんものね。失礼しました。

    C案「フォント作って」はもちろん98%冗談なので、スルーでokです！

    2019年5月23日 21:51  |  アイスクライマー

16. >> アイスクライマー さん
    いいえー、間違っていないと思います。

    サンプルの部分ですよね。[フォントの設定] などのサンプルで "Aaあぁアァ亜宇" って表示されている部分。

    そこ、エディタみたいな感じで文字入力とかできそうに見えますが、エディタに似せて描画してるだけの絵なんです。

    あそこに入力できるようにするのは非常に難しいというかほぼ無理なので、裏技的にその部分を書き換えられる抜け道を用意する感じになるかなーと思います。…選択中の文字を～は面白い案ですが、オプション画面を開いている状態で選択範囲を変更できるように。とか言われませんかね…？

    > C案「フォント作って」はもちろん98%冗談なので、スルーでokです！
    知ってました！ ^^; もう少し鋭いツッコミを入れたほうが良かったですかね。ちょっとお久しぶりだったので距離感が分からなくなってました (w

    って 2% 本気かいっ。(と、恐る恐る)

    2019年5月23日 22:16  |  Kuro

17. フォント設定関連で白熱していたので、ちょっとした要望を…。

    フォント設定画面でのフォントの並び順ですが、今の仕様だと「現在設定中のフォントを最上部に配置し、アクティブにする」となっているかと思います。

    これを、「フォントの並び順はそのままに、現在設定中のフォントをアクティブにする」としてはどうでしょうか？（ちょうどサクラエディタのような感じですね）

    例えば、フォント設定画面を開いて「Ricty」を選択しようと思った際、「R」を入力すればインクリメントサーチ的に R から始まる位置にアクティブ行が遷移します。

    が、現在「Ricty」を設定している状態でフォント設定画面を開き、「Ricty Discord」を探そうと考えて同様に「R」を入力すると、最上部にある「Ricty」にカーソルが移動してしまって、本来表示させたい「R」から始まるフォント群のところに移動できないのです…。

    Mery の綺麗なフォント表示のせいで (おかげで) フォント生成の楽しさに目覚めてしまったのですが、テストフォントを XXX-1、XXX -2 といった調子で作っていくと、上の仕様のためにちょっと選ぶの面倒だな…と感じます。

    あとあと、そんな Mery さんによってフォント生成に目覚めさせられてしまった私ですが、先日とうとう生成したフォントをリリースできました！
    https://qiita.com/tawara_/items/374f3ca0a386fab8b305
    Mery はフォントの表示確認にも役立ちましたが、フォント生成には文字を Unicode で指定することが端々にあるので、文字の Unicode 変換機能にもとても助けられました。

    2019年5月24日 21:54  |  yuko

18. >> yuko さん
    コメントありがとうございます。

    フォントのリリース、すごい！おめでとうございます！
    早速インストールさせていただきましたが、めちゃくちゃ見やすいですね。私もプログラミングでは Ricty が好きだったのですが日本語部分がどうもね…、な一人だったので白源は最強だと思います。

    あと、スマホ Chrome で新しいタブを開くとニュースが出るのですが、先日、その記事が出てまして「世の中にはすごい人がいるんだなぁ」と思ってましたが、yuko さんだったとは！

    少しでも Mery がお役に立てたのであれば幸いです。

    > フォント設定画面でのフォントの並び順ですが、今の仕様だと「現在設定中のフォントを最上部に配置し、アクティブにする」となっているかと思います。
    そうなんですよね。私も、同じフォントファミリーの別のフェイスを探そうとしたときに頭文字 (例えば R) って打ってもインクリメンタルサーチされないので「んもー」って思ってます。

    > フォントの並び順はそのままに、現在設定中のフォントをアクティブにする
    何もしなければそうなるんですけど、Mery は頑張ってわざわざ現在設定中のフォントを先頭に持っていってるんですよね。

    フォントフォールバックの設定画面の [追加] ボタンのほうはその処理を入れてないのでご希望の動作になっていると思いますが。

    なぜ、わざわざ先頭に持ってきているかというと、特に意味はないです。真魚 (Mery のエンジンの作者様が開発されたエディタ) でそうなってたので、そのほうが便利なのかなぁと思って…。

    そして、使いづらいなぁ、いやだなぁと思いながらも誰にも何も言われないのでみんな使いやすいんだろうなぁと思ってました ^^;

    余計な処理を削除するだけなので、対応は簡単なんですけど…。みんなそう思ってますよね、きっと…。

    2019年5月24日 23:27  |  Kuro

19. 更新お疲れさまです。
    マウスホイールを速めに動かしてスクロールするときスムーズになっていて感動しました。

    2.7.4 に比べてカーソルの動き（エディタの描画）が著しく鈍くなるケースがあったので報告します。

    - DirectWriteを有効にする。
    - タブ・半角空白・全角空白を表示するようにする。
    - ウィンドウを最大化したりしてなるべく多くの行が表示されるようにする。

    この条件でタブや空白を含むファイルを開き、「左右に分割」または、「上下に分割」で分割表示にします。
    そしてメインエディタの方で方向キーを長押ししてカーソルを動かすと、カクカクしたり、描画が止まったようになります。

    サブエディタ側に表示される行数が多くなると、より鈍くなるようなので「左右に分割」の方が「上下に分割」より鈍いです。
    また、ファイルの内容によっても差があります。
    Mery 同梱の en_US.aff を開いて、左右に分割し、メインエディタで方向キーの下を押しっぱなしにすると分かりやすいと思います。

    分割表示がらみでもう一つ気になる点がありました。
    これは 2.7.5 からではないのですが、マクロの HighlightFind プロパティを使って検索結果の強調表示を切り替えたとき、サブエディタの方は切り替わりません。
    ちなみに「検索文字列の強調を解除」だとサブエディタの方も解除されます。

    2019年5月25日 1:03  |  ucky

20. >> ucky さん
    コメントありがとうございます。
    スクロール速度は結構がんばったので、そう言っていただけると救われます。

    > 2.7.4 に比べてカーソルの動き（エディタの描画）が著しく鈍くなるケースがあったので報告します。
    ご報告ありがとうございます。

    カクカクしたり描画が止まったようになったりするのは私のほうでも確認済みなのですが、DirectWrite の仕様らしくて、現在のところ対策は見つかっていませんが継続して調査しております。

    今のところ詳細な発生条件が分かっていなかったのですが、頂いた条件で検証してみようと思います。

    DirectWrite はグラフィックボードの性能や種類、OS、CPU の負荷状況などによっても動作が異なるので、よろしければお使いの PC のスペック (OS のバージョン、CPU、メモリ、グラフィックボードなど) も教えていただけると助かります。

    またこの現象につきましては以下のフォーラムのトピックで継続調査中ですので、お手数をおかけして恐縮ですが、こちらにご投稿いただけると助かります。
    https://www.haijin-boys.com/discussions/4329

    > マクロの HighlightFind プロパティを使って検索結果の強調表示を切り替えたとき、サブエディタの方は切り替わりません。
    これはたぶんプログラムミスだと思いますので調査してみますね。

    2019年5月25日 1:30  |  Kuro

21. > フォントのリリース、すごい！おめでとうございます！

    ありがとうございます！

    Mery で綺麗なフォント表示の良さを知り、Ricty がなぜか VSCode では表示品質が悪かったことで、「綺麗にアンチエイリアス掛かるフォント欲しいなぁ」と、創作意欲を掻き立てられました。

    感謝、感謝ですー🙇

    2019年5月25日 7:41  |  yuko

22. おお、フォントのリリースとはすごいですね。
    うちの XP ではアンチエイリアスに「ClearType」を使っているのですが、普段使いの 11 ～ 14 pt サイズだと横線の太さが不均一になってしまうのでダメでした。 :(
    以前スラッシュドゼロのフォントやプログラミングフォントを試したときも表示が汚くなってしまっていたので、最近のサードパーティ系のフォントは使えなくて悲しいところです。
    メイリオや 游ゴシックならキレイにはなるんですが、源ノ角ゴシック Code JP とか IPA ゴシック、Ricty、Migu 1M、Noto Sans Mono CJK JP とかもだめ…。
    Mery にかぎらず別のブラウザや Firefox でもだめなので、MeiryoKe_Gothic から離れられないままです（haijin-boys.com の各ページも指定フォントだと読みづらくなるので MeiryoKe_PGothic にしています）。

    > フォントの並び順はそのままに、現在設定中のフォントをアクティブにする
    賛成です。 ﾉｼ

    2019年5月25日 11:31  |  sukemaru

23. sukemaru さん

    お試しいただきありがとうございます！
    Win 10 でやっと Microsoft が本腰入れてアンチエイリアス品質を改善してくれてから久しいので、Win 7 以前でのイマイチなアンチエイリアスを忘れ掛けていました。(懐かしい…)

    Win 10 だと源ノ角ゴシック Code JP や、めでたく親戚フォントとなった白源はキレイに表示されると思うので、その際にはまたお試しくださいね。

    2019年5月25日 13:19  |  yuko

24. >> yuko さん
    なるほどー、それで白源はアンチエイリアスがこんなに綺麗なんですね。
    Windows 10 だと DirectWrite オフでもほとんど違いが分からないレベルで綺麗ですね。

    DirectWrite オンで遊んでて気づいたのですが、Ricty ってフォントサイズが 1.5 の倍数じゃない場合に半角文字と全角文字の横幅比が 1:2 にならない問題がありましたが、白源だと 10 pt は OK で、1.5 の倍数の 10.5 pt でそうなるっぽい…？

    フォント製作については知識ゼロなので恐縮ですが、もしかして Mery の問題だったりしますかね… ^^;

    一応、隠し機能で、

    [Display]
    GdiCompatible=1

    これを使えば揃いますが…。

    >> sukemaru さん
    > > フォントの並び順はそのままに、現在設定中のフォントをアクティブにする
    > 賛成です。 ﾉｼ
    ご意見ありがとうございます。
    そうですかー、では、これはその方向で検討してみようと思います。

    > haijin-boys.com の各ページも指定フォントだと読みづらくなるので MeiryoKe_PGothic にしています
    えー！このサイトや MeryWiki ってウェブフォントを使っているのですが、実は最近、Google 先生のスピードテストで怒られるようになったので、ウェブフォントを廃止して Windows 10 の BIZ UDゴシックにしようと思っていたのですが、XP の sukemaru さんに申し訳ないなと思って躊躇していたのです ^^;

    そもそもウェブフォントがオフにされていたとは… (w

    2019年5月25日 14:56  |  Kuro

25. > yuko さん
    暖かい言葉、ありがとうございます。 :)
    昨年末に内蔵ファンがいかれたので今年の夏で買い替えかなとおもっていましたが、先日ジャンクの個体からファイを移植したら復活してしまいまして、新調はもうしばらく先になりそうです。
    手に馴染んだ道具は大事にしたい、使い慣れた環境を手放したくない古い人間でごめんなさいです。
    いつか来るXデーまで、フォントは大事に取っておきます。

    > ウェブフォントを廃止して Windows 10 の BIZ UDゴシックにしようと思っていたのですが、XP の sukemaru さんに申し訳ないなと思って躊躇していたのです ^^;
    > そもそもウェブフォントがオフにされていたとは… (w
    ああ、こんな部分出までご配慮いただいていたなんて嬉しいやら申しわけないやら…。 :)
    現役XPユーザーは、WEBブラウジングに関してはブラウザの config をいじってのUA偽装や表示設定の調整やらゴニョゴニョやっている人が多いはずです。XPにインストールできるバージョンのブラウザのデフォルトでは閲覧できないサイトが増えていますし、古いPCでは重いページも多いので、ぐぐり回ってなんとかやり繰りしているのがもっぱらです。
    WEBページの表示については当方なりにダマシダマシやり繰りいたしますので、どんどんおしゃれなサイトにしちゃってください。 :D

    2019年5月25日 16:57  |  sukemaru

26. Kuro さん

    > なるほどー、それで白源はアンチエイリアスがこんなに綺麗なんですね。
    > Windows 10 だと DirectWrite オフでもほとんど違いが分からないレベルで綺麗ですね。

    そこまで言ってもらえて、歓喜の極みです😂

    まぁ実際のところ、元からアンチエイリアスが綺麗に掛かるフォント同士をいい感じのバランスで合成しているに過ぎないんですけどね。
    Win 10 のアンチエイリアスはちょっと太めの字体の方が綺麗に掛かるようで、源柔ゴシック (源ノ角ゴシック) と Hack の Regular サイズはやや太めな字体なので Win 10 とは相性がいいみたいです。

    > DirectWrite オンで遊んでて気づいたのですが、Ricty ってフォントサイズが 1.5 の倍数じゃない場合に半角文字と全角文字の横幅比が 1:2 にならない問題がありましたが、白源だと 10 pt は OK で、1.5 の倍数の 10.5 pt でそうなるっぽい…？

    多分ですが、Mery の不具合ではないと思います。VSCode の DirectWrite 環境でもズレているので…😅 DirectWrite 環境下だと、色々なフォントで微妙にズレるので、もうそういうもんなんだと思って諦めてましたｗ

    それと、1.5 の倍数の件、フォントの EM 値 (EM については後述) やディスプレイ表示倍率によって必ずしも1.5の倍数にはならないようです。例えば白源だと、表示倍率100%の環境下だと11ptでズレませんが、125%の環境下だと11ptでズレるようになったり。

    * EM とは:
    フォントには高さ (Acsent) と深さ (Decsent) という設定値があり、それら両方を足したものが「EM」という、フォントの縦幅を示す値になります。EM の値の元である高さ・深さは自由に設定できるのですが、「EM 値は2の累乗にする」というのが推奨されていて、1024 or 2048 に設定されることが多いです。ただ、理由は分かりませんが1000で設定するのも定番なようです。

    Ricty の合成元になっている Ioconsolata や Migu 1m の EM 値は 1000 で、それらを合成した Ricty 自体も 1000 です。白源や源柔ゴシックは 1024 を採用しています。そして Hack という白源の合成元フォントは 2048 です。

    「同じ 12pt の設定なのに白源よりも Ricty の方が小さい」など、字体の大小が出るのはこの EM 値の違いなんだと思います。

    この EM 値によって、DirectWrite 環境下でズレるサイズの倍率も違っている気がします。(EM 値 1000 の Migu 1m と Ricty が同じ倍率でズレ、EM 値 1024 の源柔ゴシックと白源が同じ倍率でズレることから見た考察として)

    2019年5月26日 9:46  |  yuko

27. > それと、1.5 の倍数の件、フォントの EM 値 (EM については後述) やディスプレイ表示倍率によって必ずしも1.5の倍数にはならないようです。例えば白源だと、表示倍率100%の環境下だと11ptでズレませんが、125%の環境下だと11ptでズレるようになったり。

    EM 値関係なかったかもです…^^;
    白源のビルドミスで、リリース当初からずっと EM 値 1000 で出力していたのが今発覚…^^;;;

    となると、半角文字の幅かな…？
    半角文字の幅は、フォントファイルのメタ情報である OS/2 テーブルというものの中の「xAvgCharWidth」という幅に関する情報で定義しなければいけないのですが、それを見ているのか…？ちょっと何が何やら分からなくなってきました。。。

    xAvgCharWidth:
    https://docs.microsoft.com/en-us/typography/opentype/spec/os2#xavgcharwidth

    2019年5月26日 18:53  |  yuko

28. >> yuko さん
    フォント使わせて頂きました。
    個人的には「0」は中黒より斜線が好みですが、それ以外は読みやすくて凄いと思いました。
    あと何より、ライセンスの面倒臭さが無いのが素晴らしいです。

    >>kuro さん
    そういえば「オプション画面に[適用ボタン]があれば、オプション画面開いたままカスタマイズの結果を確認できで便利なのですが～」の要望に対して「うん、それ無理」との返答を頂いていました（もうログ残ってないみたいです）。何年も経って違う形で蒸し返してしまって・・・
    あと、「フォントの並び順そのままに～」私も一票入れます！

    2019年5月26日 21:56  |  アイスクライマー

29. >> yuko さん
    フォントって大変そう…。解説していただきありがとうございます。

    > 白源のビルドミスで、リリース当初からずっと EM 値 1000 で出力していたのが今発覚…^^;;;
    と、とりあえず何かしらのお役に立てたなら良かったです (w
    しかし、Qiita のコメント欄、お忙しそうですね。私の疑問などはスルーしていただいて大丈夫ですよー。

    私はフォント関連はド素人以前に 1 ミリも知らないので、フォント作成に協力できそうにはありませんが、Mery のフォントまわりでの内部仕様をお知らせすることぐらいなら ^^;

    xAvgCharWidth ですが、Mery ではその値は使っていないと思います。(たぶん)
    BIZ UDゴシックがリリースされたときに、xAvgCharWidth を使ってるアプリが文字幅を誤認してしまう問題があったというのをウワサで聞いたことありますが、そのとき Mery は大丈夫でしたので…。

    フォント関連の情報、Qiita のほうにコメントさせていただいたほうが良さそうですね。フォント製作大変そうですが、ご無理のないようがんばってください。

    >> アイスクライマー さん
    > 「うん、それ無理」との返答を頂いていました
    そうですねー。そこはそもそも無理なのですが、オプション画面を開いた状態でエディタ部分から文字列を選択するのはもっと無理なので、そういったご要望が来ると怖いなーと思いまして ^^;

    なので、[サンプル] 部分をダブルクリックすると文字入力画面が出てくる案でした。[サンプル] 部分の文字列変更って、わざわざ説明を書いてまで使ってもらうべき機能でもなさそうなので、質問が来たら「それならダブルクリックでできますよー」って回答するぐらいの軽い感じでと。

    > あと、「フォントの並び順そのままに～」私も一票入れます！
    うわー。メモっとかないと忘れそうです。メモメモ。

    2019年5月26日 23:06  |  Kuro

30. アイスクライマーさん

    お試しいただきありがとうございます！

    > 個人的には「0」は中黒より斜線が好みですが、それ以外は読みやすくて凄いと思いました。

    その意見は結構多いので、暇になったら対応しようかなと思い始めました…^^; でも、慣れればむしろ可愛らしく見えてくるはずです？ｗ
    この「0」は生成元の英字フォント Hack の特徴の一つでもあるので、できればそこも込みで気に入ってもらいたいなーという私のエゴがあったりもします。

    > あと何より、ライセンスの面倒臭さが無いのが素晴らしいです。

    そうなんですよね。Ricty 最高なんですが、生成面倒で、結局ライセンス問題の無い Ricty Diminished 使ってる人の方が多いんじゃないかと思ってます。

    Kuro さん

    > と、とりあえず何かしらのお役に立てたなら良かったです (w
    > しかし、Qiita のコメント欄、お忙しそうですね。私の疑問などはスルーしていただいて大丈夫ですよー。

    お気遣いありがとうございます。Qiita の方は、ひと通り収束してきたかなってところですね。イイネもすっかり付かなくなりましたｗ

    最初、「ライセンスフリーじゃないやんけ」みたいなコメント飛んできたときには、白目を剥きかけましたが、とりあえず問題なさそうだったので良かったです。
    あと、Qiita のアカウントって Google アナリティクスと紐付けることができるので、自分の記事のアクセス解析も出来たりしてなかなか面白かったですねー。

    ただ、そんなコメントを受け、「フリーなんだからもうちょっと優しくしてよぉ…」とちょっと思ったのは秘密ですが、Kuro さんもそんな気持ちをよく味わっているのだろうと思うと、「Mery もうヤダぁ…」と Kuro さんが言っているのも納得してしまったり…^^;

    あ、それと先ほど、白源 v0.5.0 リリースしたのですが、VSCode で文字ズレが起きていたのは解消できたみたいです。VSCode の場合どのサイズでも文字ズレが起きないので、しっかりと各字体グリフの幅だけで描画しているのかなーと思いました。(白源は今のところ、半角グリフ幅 538, 全角グリフ幅は倍の 1076)

    2019年5月27日 8:41  |  yuko

31. >> yuko さん
    Qiita のほう落ち着いてきたようで安心しました。
    リリース早々、ライセンスフリーの件は大変でしたね。出鼻をハンマーで叩かれた感じ…。私だったら泣いちゃいます。

    Mery も「フリーウェア」って PC に詳しくない人は知らない用語だと思って、「フリーソフト」と表現してしまうことがあるのですが、「フリーソフト」ってオプソで改変、配布が自由なソフトっていう意味もあるので詳しい人からツッコミが入りそうでドキドキしてきました。

    > 自分の記事のアクセス解析も出来たりしてなかなか面白かったですねー。
    面白そうですね。私も以前に Delphi の Advent Calendar に参加したくて Qiita のアカウントは作っていたものの、毎年 12 月のイベントなので Mery のクリスマス更新と重なって参加できないっていう悲しみです。

    > ただ、そんなコメントを受け、「フリーなんだからもうちょっと優しくしてよぉ…」とちょっと思ったのは秘密ですが、Kuro さんもそんな気持ちをよく味わっているのだろうと思うと、「Mery もうヤダぁ…」と Kuro さんが言っているのも納得してしまったり…^^;
    分かります ^^; スラッシュゼロが良ければ君も自分でフォントを作ってみようよ！そして完成したら使わせてくれよな！ぐらいの軽いノリでいければ… (無理

    でも、フリーのものって趣味や勉強のために休日を利用して作ったものをたまたま公開してるだけですから、不具合のご報告はありがたいですが、厳しいコメントはホントつらいですね。

    Mery もうヤダァ…は本音です (w 私はもう精神的に限界ですねぇ。よく 10 年以上続いたなと。多分そろそろ折れると思います。

    白源 v0.5.0 リリースお疲れ様です。やはり Mery で 10.5 pt だとダメなようで、Mery 側の問題な気がしてきました。DirectWrite ほんと意味が分からないよー。

    >> アイスクライマー さん
    すみません、その後、[サンプル] 部分のカスタマイズ機能の開発に取り組んでみたのですが肝心なことを忘れておりまして。

    [サンプル] の部分はエディタエンジンではなくて自前で適当に描画している絵だったので、絵文字や結合文字など、シビアな文字幅の計算が必要となる文字列に対応させることができませんでした。(それに対応させるとなると、エディタエンジンの再開発みたいなことに…)

    やるとしたら、そもそも [サンプル] の部分を適当な絵ではなくてエディタエンジンを搭載した本格的なエディタとして実装するしかなさそうなので、ちょっとした一大プロジェクトになりそうですから禿げちゃいます。

    2019年5月27日 21:19  |  Kuro

32. > Mery もうヤダァ…は本音です (w 私はもう精神的に限界ですねぇ。よく 10 年以上続いたなと。多分そろそろ折れると思います。

    Mery のいちファンとしては、もっと進化する Mery を見たいなと思うのですが、形は違えどこうやって自分の作品をフリーという形で世に出してみると、素直にそう言えなりますね…^^;

    白源もそうですが、根本にあるモチベーションが「自分にとって使いやすいもの」「自分にとって興味のあること」という追求心、好奇心なので、ある程度いくとそれが満たされてしまって、アップデートする必要性を感じなくなってきますよね。

    今後も密かに応援はしていますが、頑張り過ぎないようにしてくださいね。

    2019年5月27日 22:29  |  yuko

33. 白源のコメントに Mery ユーザが降臨して、なんだか妙に親近感出てきましたｗ

    その方からの要望を受け、半角5:全角3 という白源を作ってみました。
    https://qiita.com/tawara_/items/374f3ca0a386fab8b305#comment-22ba1fb913dd360846a2

    Mery だとちゃんと想定の幅で半角全角ともに表示されるですが、サクラエディタだと全角文字の幅が異様に広がってしまって使い物にならず…
    エディタエンジンによってフォントの解釈の違いがこんなに出てくるものなんですね。

    2019年5月28日 8:42  |  yuko

34. 一つご報告があったのを忘れていました。

    検索結果のスクロールバーマーカーですが、置換時にはリセット (置換した部分のマーカーが消える) されますが、全置換をしたときにはリセットされないようです。

    2019年5月28日 9:24  |  yuko

35. Mery更新お疲れ様です。
    常に最新ベータ版をチェックして使わせていただいております。
    昔ベータ版でよくわからないことになったので、バグ検証に協力に消極的で役立たない僕ですが、
    これからもkuroさんのご活躍を応援しております。

    2019年5月28日 18:08  |  ユーケー

36. >> yuko さん
    > ある程度いくとそれが満たされてしまって、アップデートする必要性を感じなくなってきますよね。
    ほんとそれです。機能追加はしたくないけど、品質は高めたいので不具合報告は欲しいっていうジレンマ… ^^

    > Mery ユーザが降臨
    > その方からの要望を受け、半角5:全角3 という白源を作ってみました。
    秀〇さんユーザの可能性もありそうですが… (w

    わお！Mery での文字幅のズレ、なくなってます！
    どういう仕組みなのか全然理解できていませんが、すごい！白源 半角 5 : 全角 3 + Mery はアートですわ。美しすぎる…。

    > エディタエンジンによってフォントの解釈の違いがこんなに出てくるものなんですね。
    そうなんですよね。Windows だと、GDI の文字幅を取得する API がいくつかありまして、それによって挙動が異なってしまいます。さらに DirectWrite の API でも文字幅を取得する API がいくつかありまして、これによっても変わっちゃうんです。

    DirectWrite だと文字幅や行間がおかしいフォントが、結構有名フォントの中にもあるので、Mery では DirectWrite オンでも GetGdiCompatibleMetrics ていう API を使って GDI 互換の文字幅を優先していますから、そのせいで DirectWrite 専門のアプリ (VS Code とか？) とは異なるのかもしれません。

    > 一つご報告があったのを忘れていました。
    わー。スクロールバーマーカーは、2.7.5 で再描画の回数を極限まで減らしたのですが、減らしすぎちゃってました。ご報告ありがとうございました。Ver 2.7.6 で修正しておきました。

    >> ユーケー さん
    コメントありがとうございます。

    > 昔ベータ版でよくわからないことになったので、バグ検証に協力に消極的で役立たない僕ですが、これからもkuroさんのご活躍を応援しております。
    正式版はもう 1 年以上前なので、現在ではベータ版のほうがだいぶ安定していますね ^^; 応援ありがとうございます。今後ともよろしくお願いします！

    2019年5月28日 23:44  |  Kuro

37. Mery使いやすいので愛用しています。
    Microsoft OneDrive＋Meryの環境でエラーがでるので質問です。

    OneDrive上のText file(.txt)をMeryで編集した後、そのファイルをMeryで閉じます。
    この時点で、Meryで開いているファイルはありませんが、MeryはPC上で起動しています。この状態で
    さきほど編集したtext fileがあるOneDriveのディレクトリの名前をエクスプローラーから変更すると
    エラーになってしまいます。
    （Meryでファイルを編集した後、私は進捗などがわかりやすいようにディレクトリ名をよく変更しています）
    Meryをいったんアプリ本体ごと落とさないと、OneDriveのディレクトリ名が変更できないようです。
    Mery上でファイルを保存した後に閉じても、Mery内部ではまだファイルは解放されてはいないのでしょうか？
    Mery beta 2.7.6でも実験してみましたが、同様の事象がでました。

    Meryではなく、OpenOfficeなどほかのアプリでも実験してみました。この場合、
    編集していたファイルだけを閉じればOpenOfficeのアプリそのものは落とさなくても、
    OneDriveのディレクトリ名は変更されました。
    よろしくお願いします。

    2019年5月29日 4:31  |  チョコモナカ

38. Kuro さん

    > わお！Mery での文字幅のズレ、なくなってます！
    > どういう仕組みなのか全然理解できていませんが、すごい！白源 半角 5 : 全角 3 + Mery はアートですわ。美しすぎる…。

    半角2:全角1 派だったんですが、慣れてきたら 半角5:全角3 めっちゃ見易くなってきました…^^;

    昔ながらの 1:2 にこだわって意固地になってたところあったんですが、これ、だいぶ目が楽になりますね。

    これは今後のリリースに同梱するの、決定です。

    ちなみに、よーく見ると 5:3 のやつも 12pt や 13.5pt で微妙にズレてます…^^;

    > Windows だと、GDI の文字幅を取得する API がいくつかありまして、それによって挙動が異なってしまいます。さらに DirectWrite の API でも文字幅を取得する API がいくつかありまして、これによっても変わっちゃうんです。

    ほぉー、そんなに種類あるんですね。いかんせんスタンドアローンなアプリに疎いので、気になります。よければ、その API のリファレンスページなど教えていただけませんか？

    2019年5月29日 8:47  |  yuko

39. yukoさん
    サクラエディターは・・・・決して悪口じゃないのですが、最新の機能を取り入れたかったら、自分でバッチを取り込んでビルドするしかないような状況じゃないでしょうか。

    いくつかの有用そうな修正チケットは、いつまでもCommit とビルドが全然されていませんし。
    https://sourceforge.net/p/sakura-editor/patchunicode/search/?q=%21status%3Awont-fix+%26%26+%21status%3Aclosed

    DirectShowや一部の文字幅についても、2013から2014年に数人が実験的に対応しようとして、そのままペンディングになってましたし。
    （https://sourceforge.net/p/sakura-editor/patchunicode/482/）

    この状況が続いているからかは分かりませんが、最近は新しいパッチのチケットも投稿されていないような状況じゃないでしょうか。

    その代わり、正規表現キーワードの定義が、秀丸やサクラエディターの方が
    複雑な条件の組み合わせで構成できます。

    そのため、職場のTeratermマクロだけはサクラで組んでいたりします。

    また、一部のPerlのソースなどで、私が和英辞書などの変換している処理があり、
    結合分音文字記号であるU+0310～U+35Fを結合させずに表示させたいときや、
    行数が多いファイルを読むときは、少し速く開ける秀丸で読んだりしています。

    逆に、恐ろしく桁数が横に長いファイルは、（内部が論理行でないからか）
    Meryの方が遥かに高速なので、Meryを使っています。

    >> Mery ユーザが降臨
    >> その方からの要望を受け、半角5:全角3 という白源を作ってみました。
    >秀〇さんユーザの可能性もありそうですが… (w

    職場によって5，6個のエディターを使い分けますが、自分で好きなものを
    入れられるところでは、ほぼMeryがメインですよ。

    2019年5月29日 10:19  |  tak

40. > サクラエディターは・・・・決して悪口じゃないのですが、最新の機能を取り入れたかったら、自分でバッチを取り込んでビルドするしかないような状況じゃないでしょうか。

    一応誤解が無いようにお伝えしておくと、サクラエディタはフォントの動作確認でしか起動しないので、現在の開発状況とかは全く把握していないですね…。

    同系列の日本語テキストエディターは、私には Mery さえあれば生きていけます。

    2019年5月29日 11:13  |  yuko

41. > 一応誤解が無いようにお伝えしておくと、サクラエディタはフォントの動作確認でしか起動しないので、現在の開発状況とかは全く把握していないですね…。

    > 同系列の日本語テキストエディターは、私には Mery さえあれば生きていけます。

    了解です。うらやましい限り。

    2019年5月29日 11:24  |  tak

42. > チョコモナカ さん
    Mery が起動（またはタスクトレイに常駐）していない状態で、OneDrive 上のテキストファイルをダブルクリックして開いていませんでしたか？
    その場合、そのテキストファイルを閉じたあとでも Mery.exe のプロセスは「作業フォルダ」としてそのテキストファイルがあったフォルダとヒモづけされたままになります。
    たぶん OneDrive だからという関連性はありません。

    すでに起動または常駐している Mery で開いて閉じた場合には、そのフォルダのリネームや移動ができるとおもいますよ。
    デスクトップなどに Mery のショートカットを作っておいて、ショートカットファイルのプロパティから「作業フォルダ」に Mery.exe のあるフォルダを指定しておき、ショートカットから起動した Mery をタスクトレイに常駐させておけばよろしいかと。

    Mery の再起動が面倒または常駐させたくないという場合は、（あまりよい方法ではありませんが）そのテキストファイルを閉じたあとに Unlocker のようなソフトでフォルダのロックを解除するか、以下のようなマクロを実行するとフォルダのリネームができるようになるかもしれません。

    Unlocker 1.9.2
    https://www.softpedia.com/get/System/System-Miscellaneous/Unlocker.shtml
    https://www.softpedia.com/get/PORTABLE-SOFTWARE/System/File-management/Unlocker-Portable.shtml

    #title="作業フォルダのアンロックマクロ"
    var WshShell = new ActiveXObject("WScript.Shell");
    WshShell.CurrentDirectory = editor.FullName.replace(/\\[^\\]+.exe$/,"");
    Alert("作業フォルダを\n\n"+WshShell.CurrentDirectory+"\n\nに変更しました。");

    2019年5月29日 17:51  |  sukemaru

43. >> sukemaru さん
    サポートのご協力ありがとうございます。

    >> チョコモナカ さん
    ご愛用いただきありがとうございます。Mery を開発している者です。
    ご質問の件ですが、sukemaru さんが説明してくださっているとおり、作業フォルダが原因です。

    > Mery上でファイルを保存した後に閉じても、Mery内部ではまだファイルは解放されてはいないのでしょうか？
    > Mery beta 2.7.6でも実験してみましたが、同様の事象がでました。
    通常、Mery はファイルをつかむことはありません。

    関連付けされたファイルをダブルクリックで起動すると作業フォルダがそのファイルのフォルダに設定されてしまうのは Windows の仕様です。

    アプリケーションが起動している間、その作業フォルダは削除や名前の変更ができません。

    最初にショートカットから起動しておいて、その後、関連付けされたファイルをダブルクリックや、右クリックメニューから開いた場合は大丈夫ですので、Mery を起動するときになるべくショートカットを経由するか、ファイルの [送る] メニューのショートカットを使うなど、最初の起動時だけご注意いただければと思います。

    >> yuko さん
    > ちなみに、よーく見ると 5:3 のやつも 12pt や 13.5pt で微妙にズレてます…^^;
    そうだったのですね、やっぱり DirectWrite だと文字幅を合せるのって厳しいのですね ^^;
    今はどうかわかりませんが、秀〇さんは DirectWrite オンでも GDI の文字幅を使っていたような気がします。(Mery の GdiCompatible=1 機能みたいな感じ)

    > ほぉー、そんなに種類あるんですね。いかんせんスタンドアローンなアプリに疎いので、気になります。よければ、その API のリファレンスページなど教えていただけませんか？
    はい、参考になるかわかりませんが…

    GDI ですと、

    GetCharWidth32W
    https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-getcharwidth32w
    ↑ オリジナルの TNotePad では一部、これが使われていますが Mery では使っていません。

    GetTextExtentPoint32W
    https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-gettextextentpoint32w
    ↑ Mery のエンジンはこれを使っています。

    DirectWrite ですと、

    IDWriteFontFace::GetGdiCompatibleGlyphMetrics
    https://docs.microsoft.com/en-us/windows/desktop/directwrite/idwritefontface-getgdicompatibleglyphmetrics
    ↑ Mery ではこれの DWRITE_GLYPH_METRICS の advanceWidth という値を使っています。
    GDI 互換のために用意されている機能なので、純粋な DirectWrite アプリだとこれは使っていないかもです。

    IDWriteTextLayout::GetMetrics
    https://docs.microsoft.com/en-us/windows/desktop/api/dwrite/nf-dwrite-idwritetextlayout-getmetrics
    ↑ 純粋な DirectWrite アプリだとこれを使っているのかも。これは Win7 でも使えますが、Win8 以降だともっと新しい API があるっぽいです。

    フォントや文字によっては GetGdiCompatibleGlyphMetrics で値が取得できないことがあるので、Mery では予備でこれの DWRITE_TEXT_METRICS の width という値を使うこともあります。

    ちなみに、Mery の GdiCompatible=1 は GDI の GetTextExtentPoint32W で取得した幅を使って DirectWrite で描画する仕組みなので、絵文字とかフォントフォールバックは崩壊しちゃいますね (w

    2019年5月29日 21:12  |  Kuro

44. Kuro さん

    情報ありがとうございます！参考にして私も実験してみます。

    それと、置換時のマーカーの修正やらフォントの並び順やら他のタブを閉じるコマンドやら、色々とご対応ありがとうございます。これでまた捗ります😊

    2019年5月29日 22:02  |  yuko

45. > サポートのご協力
    ネタがあれば即マクロ～。 :D
    ブログ記事のコメント欄とフォーラムの垣根がなくなっているような…。 :3

    2019年5月30日 18:03  |  sukemaru

46. ファイルを上書き保存した直後に、IMEがONの状態で何か入力を始めると

    モジュール "Mery.exe" のアドレス 000000000065CB7 でアドレス
    0000000000000000 に対する読み取り違反がおきました。

    というエラーが表示されます。その後はエラーにならず入力できます。
    エラーが出た後に上書き保存して(未編集状態にして？)同じ操作をするとまた表示されます。
    IME OFFの直接入力では起きません。MS-IMEでもGoogle日本語入力でも同様です。

    ああああああああああああああああああああああああああ.txt
    いいいいいいいいいいいいいいいいいいいいいいいいいい.txt
    うううううううううううううううううううううううううう.txt

    という三つのタブがある状態でいったん終了させて(ワークスペースを保存)、Meryを起動させて「あ～」のタブで日本語入力を始めるとうちでは再現します。ウインドウはタブが2段になる幅。ウインドウ幅を広げて1段にすると起こりません。

    Windows10(1903), Mery (x64) Version 2.7.6

    2019年5月30日 18:31  |  名無しさん

47. 更新お疲れさまです。

    マクロの HighlightFind がウィンドウ分割時に反映されなかった件、修正確認しました。
    DirectWrite オンの時にウィンドウ分割で動作が遅くなっていた問題も、少し試したところ改善されているようです。
    ありがとうございました。

    試していて気づいたのですが、これとは別にウィンドウ分割時のメインエディタで遅くなるケースがあったのでフォーラムに投稿しました。
    https://www.haijin-boys.com/discussions/4531

    お時間のある時にご確認いただければと思います。

    2019年5月30日 19:14  |  ucky

48. 　専門的な話が続いているので入りどころを見失っていますが、空気と流れを読まずに失礼いたします。
    　やはり、機能をかなり限定してでも、動作安定版を出すべきなのではないでしょうか。
    　正式版ではないと紹介しづらいという方もおられるでしょうし、
    「レジストリを使っていないって面倒じゃなさそう」という理由でMeryを選択するような方にとっては、細かい機能よりも、新しくてバグが出ないことのほうが、選択のポイントとなると思います。
    　
    　というわけで、Ｆ１でもＦ-ZEROでも目指してがんばってください（って、でもこの譬えだと、やっぱりピーキーで、選ばれた人のみが扱える仕様、という感じが……）。

    2019年5月30日 23:31  |  道化の真実

49. >>sukemaruさん、kuroさん
    ありがとうございます。ご指摘のとおり
    「Mery が起動（またはタスクトレイに常駐）していない状態で、OneDrive 上の
    テキストファイルをダブルクリックして開く」動作をしていました。
    MeryがファイルのSaveした後、なんらかのリソースをつかんでいてディレクトリ名変更ができないのかもと
    思っていてここに書いたのですが、Windows側の制限でそうなるんですね
    アプリ起動の方法を変更してみます。ありがとうございました。

    2019年5月31日 6:39  |  チョコモナカ

50. >> 名無しさん さん
    ご報告ありがとうございます。
    頂いた情報で現象を再現することができましたので、対策を調べてみたいと思います。

    >> ucky さん
    ご確認ありがとうございます。

    > これとは別にウィンドウ分割時のメインエディタで遅くなるケースがあったのでフォーラムに投稿しました。
    ご報告ありがとうございます。フォーラムのほうで改めて回答させていただきたいと思います。

    >> 道化の真実 さん
    コメントありがとうございます。

    > やはり、機能をかなり限定してでも、動作安定版を出すべきなのではないでしょうか。
    ベータ版って付けているのは、サポートが追い付かないのでユーザ数を減らす目的と、再配布を禁止する目的なので、ベータ版のほうがプログラム的には安定版ですね。

    正式版は Vector さん、窓の杜さんから再配布されるので、このブログを見てくれる人は増えないまま、問い合わせだけ増えるっていう悲しみです。

    おまけに野良アプリなのでウイルス対策ソフトの誤検出の問い合わせ多くて、前回の正式版のときは対応が大変でしたから、デジタル署名を付けるなど対策をしてからでないと厳しそうです。

    2019年6月1日 17:44  |  Kuro

51. 　返信ありがとうございました。
    「正式版では Zen モードやスクロールバーマーカーなどの実験的な要素は廃止するかもしれません」(2019年5月6日 21:35)とお書きになっていたにもかかわらず、新機能を出してきたので、どういうことなのだろう、と気になったのですが、そういうことですか。
    　今になってその前のほうを読むと、「今のところ正式版のリリースは考えていません。」(2019年4月17日 21:57)と、ちゃんと書いてますね。
    　忘れているなぁ。
    　
    　了解しました。
    　

    2019年6月1日 20:34  |  道化の真実

52. フォントの並び順の仕様変更、じわじわとありがたみが増しています。

    おかげさまで白源 v0.7.0 をリリースできました。英数字部分にヒンティング情報という、フォントがレンダリングされる際に画面のピクセルに合わせて上下にズラしたりして文字のコントラストを高める仕組みを追加してみました。(4K 液晶のような高解像度画面ではあまり効果ないですけど……^^;)

    英数字が明瞭になって、Mery さん美しすぎます(*´Д`)ﾊｧﾊｧ

    2019年6月3日 8:11  |  yuko

53. >> yuko さん
    白源いいですね！　元々Ricty Diminishedを使ってたんですが白源に乗り換えました！
    フォントフォールバックで自分好みの組み合わせを見つけてカスタムしよう！と思いつつ、白源に出会ってしまったので、未だにフォントフォールバックを試していないことはKuroさんにはナイショ。

    2019年6月3日 22:20  |  Dainty

54. >>Daintyさん
    Hackgenをフォントフォールバックのフォントに追加するという手も面白いですよ。
    https://camo.qiitausercontent.com/cc94fd8dc2fcebacf61e367d0b94ea244a6f7aff/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3432323330392f34656661386163662d373462612d386433312d643132332d3638643862306437643563612e706e67

    上記は、Meryの設定を以下で表示させました。
    　メインのフォント：Cosolas
    　フォールバック　：Hackgen53
    　協調文字列(１)：斜体

    2019年6月4日 14:43  |  tak

55. ＞頂いた情報で現象を再現することができましたので、対策を調べてみたいと思います。

    2.7.6でエラーが出る状態で終了、アップデート後にエラーが出ないことを確認しました。
    修正ありがとうございます。

    2019年6月4日 22:30  |  名無しさん

56. >> yuko さん
    > フォントの並び順の仕様変更、じわじわとありがたみが増しています。
    もともと存在していたコード (5 行ぐらい) を削除しただけなので、そういわれると複雑なキモチ。

    新しい白源、インストールさせていただきました。私のパソコンが Mac になったかと思うレベルの美しさですわー！

    あと、白背景でも黒背景でも見やすいっていうのがスゴイです。思わず見とれてしまいますね…。

    私も白源があればもう他のフォントは必要なくなりそうです。今までビットマップフォントで戦ってきましたが、これを機にお別れできそうです。

    2019年6月4日 22:31  |  Kuro

57. >> 名無しさん さん
    ご確認ありがとうございます。
    長年潜んでいたバグだったので、ご報告いただき助かりました。

    2019年6月4日 22:34  |  Kuro

58. >> Dainty さん

    Ricty を崇める私にとっては、Ricty から乗り換えたって声が一番嬉しいです。ありがとうございます！

    >> tak さん

    おや、もしや tak さんがあのコメントの主でしたか。
    こう見ると、やっぱり Consolas は見やすいですねー。定番であることに納得します。

    >> Kuro さん

    おおっ、あの Kuro さんがビットマップフォント卒業宣言！ある意味これ以上ない褒め言葉ですｗ

    2019年6月5日 6:34  |  yuko

59. 今さらなことかもしれませんが、マクロのCharRight()って
    挙動的にはCursorRight()ですよね。Leftも同様。

    マクロ書いてて、折り返し位置を跨いだところの挙動でハマりました。
    1文字ズレて「なんで？」って。一度の移動で折り返しを跨ぐ回数分ズレる。

    マクロ内で処理する文字列の文字数ベースで考えてたら混乱しました。
    最終的には、GetActivePointとSetActivePointを組み合わせて自前のヤツ作りましたが。

    マクロリファレンスにその辺の説明もあると混乱せずに済むかなぁ、なんて。

    2019年6月6日 18:51  |  名無しさん

60. >>名無しさん
    > マクロ書いてて、折り返し位置を跨いだところの挙動でハマりました。
    > 最終的には、GetActivePointとSetActivePointを組み合わせて自前のヤツ作りましたが。

    おお、私がこちらに居つく決定打となったなつかしの案件！ :o
    Kuro さんに以下のリンク先のご説明をいただいて理解できましたが、私も CharRight で躓いたことがあります。
    https://www.haijin-boys.com/discussions/3740#discussion-3742
    私の場合、キーアサイン集の「括弧で挟む」マクロのコードに CharLeft が使われていたので "定番で無難な" メソッドなのだろうと勘違いしたのが事の始めだったような…。 あれ以来 ChaRight/Left を使う自作マクロはほとんどなしです。

    指定文字数でのカーソルの移動としては、 SetActivePos( GetActivePos() + n ) がもっとも確実な記述法ですね。

    たしかにキーエミュレーションになっているようなカーソル移動系のメソッド（CharRight/Left, LineUp/Down, Start/EndOFLine, Start/EndOfDocument など）や SelectAll, SelectLine (←これはトリプルクリックですが) 、Copy, Cut, Paste, Delete, NewLine, Undo, Redo などのお決まりの編集操作メソッドなどは、マクロリファレンスの説明文で「対応する（標準状態での）ショートカットキー」が明示されているとマクロ初学者の方に分かりやすそうですね。

    2019年6月6日 20:24  |  sukemaru

61. いつも愛用させていただいております！情シス言いくるめて会社でも使ってます。
    ソフトはもちろんのこと、ブログやコメントも楽しませて頂いております。

    > > そもそも Windows 標準の色の設定ダイアログ自体の使い勝手が微妙
    > わかります。何度、Photoshop みたいなカラーピッカーを実装しようと思ったことか。(exe のファイルサイズがでかくなるので却下)
    MacからWinに乗り換えざるを得なくなった時に一番テンション下がったのが標準カラーピッカーのアレさでした。
    いつか気が向いたら独立ソフトウェア化いかがでしょうか…？（通りすがりに不審者になんか言われたみたいに無視して頂いて結構です）

    2019年6月7日 16:08  |  Base16愛好家名無しさん

62. >> 名無しさん さん、sukemaru さん
    そうなんですよね。マクロ機能はプログラミングに使う以前にキー操作の記録と再生が一番の目的なので、エディタエンジンの仕様に合わせた結果、こんなことになってしまっています。

    メソッドの名前は Microsoft Visual Studio のオートメーション機能のメソッド名に寄せてるので、CharRight になっています。

    > マクロリファレンスの説明文で「対応する（標準状態での）ショートカットキー」が明示されているとマクロ初学者の方に分かりやすそうですね。
    文章を書くのも考えるのも苦手なので、マクロリファレンスは機械的な記述になっていて分かりづらいですよね、すみません。

    >> Base16愛好家名無しさん さん
    ご愛用いただきありがとうございます。

    > 情シス言いくるめて会社でも使ってます。
    なんて恐ろしいことを…。

    > MacからWinに乗り換えざるを得なくなった時に一番テンション下がったのが標準カラーピッカーのアレさでした。
    Windows 10 になってもカラーピッカーはかたくなにアレですねぇ。Windows の標準カラーピッカーを乗っ取って、良い感じのカラーピッカーに差し替えるカラーピッカーアプリがあれば欲しいですね。

    ぜひ、情シスさんのほうで開発していただいて、私にも使わせていただけると嬉しいです ^^

    2019年6月8日 18:01  |  Kuro

63. プチご無沙汰でした。更新お疲れ様です、ありがとうございます

    ちょっと見ない間にバージョンがたくさん進んでいる！
    私はWindows7なのでフォントフォールバックは使えませんが、
    スクロールバーマーカーの速度アップとは……
    もともと「めちゃめちゃ速いな」と思っていたので、もはや私には知覚できない次元に！すごいなぁ

    今更ですけどCtrl+Shift+↑or↓のショートカットな検索が便利でよく使っています
    ブラウザなどでも同じ操作をしてしまって「あれ、飛べない」と思うほどです
    検索箇所を巡るのには便利だけどついでに編集しちゃうと「あ、次に飛べない」なんてことになってましたがスクロールバーマーカーがあれば補えますし良いですよね

    というかスクロールバーマーカーは一覧系のマクロを一網打尽に食ってますよね、しかも速いしｗ　ポップアップメニューか、アウトプットバーか、スクロールバーか、という表示や細々とした違いはあれど、本質的には。
    すごいなぁMery…フーッ

    そういえばサイトの文字が変わりましたね。……←三点リーダが地面に落ちてしまってます

    2019年6月8日 20:37  |  シリル

64. お尋ねします、すみません。
    　フォントを変えると、アウトラインが正しく機能しなくなるようなのですが、そんなことはないでしょうか？
    　ちゃんと表示されなくなったり、正しい位置をささなくなったりするようなのですが……。
    　ちなみに、この症状、全画面モードやＺＥＮモードでは発生しないようです。
    　最初にこれに気がついたのは、行番号を表示させたりさせなかったりしたときなので、そちらでも起こるのかもしれません。ただし行番号のほうは、同じ状態を発生させることができなかったので、もう少し条件が加わるか、カン違いかも。
    　いったん終了するか、全画面（またはＺＥＮ）モードにすればいいので、実害はないのですが。
    　

    2019年6月9日 6:53  |  道化の真実

65. >> シリル さん
    ご無沙汰しております。コメントありがとうございます。

    > もともと「めちゃめちゃ速いな」と思っていたので、もはや私には知覚できない次元に！すごいなぁ
    そうでもなかったのですよ。以前のバージョンですと、変更行と検索結果を同時に表示している状態だと描画速度がかなり低下していましたので。

    > 今更ですけどCtrl+Shift+↑or↓のショートカットな検索が便利でよく使っています
    私は Mery の中ではコレが一番お気に入りの機能です。そして私も他のソフトを使用中に、ついつい同じ操作をやってしまいます ^^;

    > というかスクロールバーマーカーは一覧系のマクロを一網打尽に食ってますよね、しかも速いしｗ
    私は一覧系のマクロは使ったことがないのですが、そんな影響が…。

    > そういえばサイトの文字が変わりましたね。……←三点リーダが地面に落ちてしまってます
    そうなんです。以前はウェブフォントを組み込んで使っていたのですが、最近は Google 先生のスピード評価が厳しくなって「ウェブフォントやめなさい」って怒られたので普通のフォントに変更させていただきました

    Windows 10 の "BIZ UDゴシック" を使っているのですが、7 だと游ゴシックになってると思います。

    >> 道化の真実 さん
    ご報告ありがとうございます。

    > フォントを変えると、アウトラインが正しく機能しなくなるようなのですが、そんなことはないでしょうか？
    調査してみましたところ、行が右端で折り返されている状態でフォントが変更された場合に、アウトラインなどが正しく表示されなくなることがあるようです。

    具体的には、プラグインの Editor_GetLine メソッドやマクロの GetLine メソッドの内部での論理行と物理行の変換処理が誤っているため、それらを使っているプラグインやマクロに影響が及んでいます。

    次のバージョンでは修正できると思いますので、今しばらくお待ちくださいませ。

    2019年6月9日 10:48  |  Kuro

66. 早速のご回答ありがとうございます。
    「行が右端で折り返されている状態で」ということでしたので、「指定文字数で折り返し」でも試してみたのですが、それてもまだ、アウトラインが正しく表示されなくなる場合があるように思えるのですが……。
    そのようなことはないでしょうか？

    2019年6月9日 14:21  |  道化の真実

67. >> 道化の真実 さん
    コメントありがとうございます。

    はい、「行が右端で折り返されている状態で」というのはウィンドウの右端で折り返しという意味ではなく、右端で折り返されている状態全般を指したつもりでした。

    「指定文字数で折り返し」でも同様、1 行が折り返されている場合にこの問題が発生します。

    2019年6月9日 17:37  |  Kuro

68. 1 行が折り返されている場合にアウトラインの問題は発生する、ということですね。
    了解しました。
    お答えいただき、ありがとうございました。
    　

    2019年6月9日 20:22  |  道化の真実

69. > > 今更ですけどCtrl+Shift+↑or↓のショートカットな検索が便利でよく使っています
    > 私は Mery の中ではコレが一番お気に入りの機能です。そして私も他のソフトを使用中に、ついつい同じ操作をやってしまいます ^^;
    これはいわゆる "Mery あるある話" ですね。 :D
    私の場合、検索フラグなし＆検索強調なしのマウス派なので、アイコン化したマクロで「ショートカットな検索」することが多いですが。 :)
    with(document){selection.Find("",0); selection.FindRepeat(meFindNext+meFindRepeatWord); HighlightFind=false;}

    > そうなんです。以前はウェブフォントを組み込んで使っていたのですが、最近は Google 先生のスピード評価が厳しくなって「ウェブフォントやめなさい」って怒られたので普通のフォントに変更させていただきました
    うちの「オマ環」案件だったのだとおもいますが、ブログ＋フォーラムとウィキとで文字サイズが不揃いで使いづらかったのが解消され、見やすくなりました。 ← なぜかココしばらくは、全文が等幅フォントでの表示になっていましたが、やっとプロポーショナルフォントでの表示になりました。
    fontawesome.com/*/webfonts/ を解禁してアイコンフォントを読み込めるようにしましたので、完全なかたちで haijin-boys.com を見ることができます。 :)

    ただ、ここしばらくプロポーショナルフォントで読めなかったときにブラウザをいじりすぎてしまったせいか、マクロライブラリのソースコードの半角英数が以前のような可愛いらしい太めの字体でなくなってしまい、どこをいじったのか分からなくなってて… orz.

    2019年6月9日 21:44  |  sukemaru

70. 他のアプリから、Alt+Tabでタスクスイッチャーを出してマウスでMeryを選択して切り替えると、その時点ではまだAltが押されているためメニューバーが反応してしまいます。

    エクスプローラーやChromeでも反応してしまうのでWindows的に仕方ないのかもしれませんが、Firefoxなんかだと対策しているようなので、Meryでも可能であれば対策してもらえるとありがたいです。

    マウス操作メインのアプリならそれほど実害はないのでしょうけど、Meryでメニューバーが反応してるのに気付かずキー入力を始めて慌ててキャンセルするということが何度かありますので。

    2019年6月10日 16:54  |  名無しさん

71. >> sukemaru さん
    >うちの「オマ環」案件だったのだとおもいますが、ブログ＋フォーラムとウィキとで文字サイズが不揃いで使いづらかったのが解消され、見やすくなりました。
    MeryWiki のフォントサイズは変更していませんが、ブログのほうはちょっと大きくなってますので、たまたま揃った感じだと思います。

    >マクロライブラリのソースコードの半角英数が以前のような可愛いらしい太めの字体でなくなってしまい、どこをいじったのか分からなくなってて… orz.
    MeryWiki のほうもウェブフォントを廃止しましたので、ソースコードのフォントはただの Consolas ですね。XP だと Consolas が入ってないかもしれませんが… ^^;

    >> 名無しさん さん
    コメントありがとうございます。
    Alt + Tab で マウスで切り替えたときの現象、確認しました。

    手元のいくつかのアプリケーションで試してみましたがほとんどダメでした。Firefox はメニュー自体が独自で開発されているものなので対応できているのではないでしょうか。

    少なくとも Mery の開発環境 (Delphi) ですと、ウィンドウにメニューを配置しただけの単純なフォームでもこの現象が発生しました。恐らく Windows のメニューの仕様なのではないかと思います。

    対策するにしても開発環境の内部の仕様なので、手の施しようがなさそうです。

    2019年6月10日 21:53  |  Kuro

72. ＞対策するにしても開発環境の内部の仕様なので、手の施しようがなさそうです。

    そうですか。わかりました。

    2019年6月10日 22:56  |  名無しさん

73. > MeryWiki のフォントサイズは変更していませんが、ブログのほうはちょっと大きくなってますので、たまたま揃った感じだと思います。
    本当にいい感じで揃いました～。 :D
    > MeryWiki のほうもウェブフォントを廃止しましたので、ソースコードのフォントはただの Consolas ですね。XP だと Consolas が入ってないかもしれませんが… ^^;
    いえいえ、ちゃんと入ってます。 つConsolas
    っていうか今もフォント自体は Consolas で表示されていて、いままでは黒字の部分もけっこう太めで表示されていたのが、ふつうの太さになっただけでした。

    いままでブログ/フォーラムとウィキを行き来するときにブラウザの文字の表示倍率をその都度いじったり（ブログを見るときに文字サイズを拡大）いじらなかったりしていましたが、それをする必要がなくなり、共通で通常のサイズで見ているから文字が太くないみたいです。
    15pt 相当～ の表示サイズにすればソースコードの黒字部分もガッツリ太くなるみたいですね。 :)

    あと、Alt＋Tab でのタスクスイッチング後については、XPだとちゃんとエディタにフォーカスが入りますね。メニューバーが反応してしまう症状は起きないようです。

    2019年6月11日 1:50  |  sukemaru

74. 確かに Alt+Tab で表示されるウィンドウからクリック操作で Mery を選択すると、メニューにフォーカスが当たってしまいますね。

    実は最初、私の環境では再現しなかったので何の差だろうかと不思議に思っていたのですが、AutoHotKey で自作した Alt+Tab 操作を便利にするツールを使っていた副作用で、この現象を無意識に回避していたようです^^;
    なので、この自作ツールを OFF にしたら、再現するようになりました。

    もし必要ならこの自作ツールの共有リンク貼っておきますので、ご利用くださいー。(一般のフリーウェア同様、動作に関して無保証なのはご了承ください)

    https://drive.google.com/open?id=154-uLjc0frSg1LV5XOEK4KACfePF4yV4

    ちなみにこのツール、本来の目的は Alt+Tab で表示されるウィンドウ上で以下の操作ができるようにするものです。

    ・H: 左にカーソルを移す
    ・J: 下にカーソルを移す
    ・K: 上にカーソルを移す
    ・L: 右にカーソルを移す
    ・右クリック: Alt+Tab で表示されるウィンドウの中心にマウスカーソルを自動で動かす
    ・左クリックでアクティブにするウィンドウ選択後、Alt を離さないで右クリック: アクティブになったウィンドウの中心にマウスカーソルを自動で動かす

    2019年6月11日 5:58  |  yuko

75. > 確かに Alt+Tab で表示されるウィンドウからクリック操作で Mery を選択すると、メニューにフォーカスが当たってしまいますね。
    私の環境 (Windows 10 1809 x64) ですと、メニューにフォーカスが当たるときもあるし、当たらないときもあるので再現性は 100% ではないのですが、どのアプリでもそうなってますね。

    どうもタスク切り替えで別のアプリに切り替えずに、元のアプリに着地したときに発生する確率が高いような。

    AutoHotKey で問題が発生しないということは、何かしら外部からの操作による対応が可能なのだと思いますが、どういう原理なのか想像がつかないですね。

    プログラム的な対応方法について情報をお持ちの方がいらっしゃいましたらご協力いただけると助かります。

    2019年6月12日 0:01  |  Kuro

76. 「プラグインの Editor_GetLine メソッドやマクロの GetLine メソッドがフォントサイズを変更した直後に誤った値を返していた問題」ですか。
    フォントを変更した場合アウトラインが正しく動作しない問題、が修正されていることを確認しました。
    早速の対応ありがとうございました。

    　できれば、作業画面の側。
    フォントを変更した時に、それ以前とは違う場所が表示されることがあるのも、
    直していただきたいのですが……、むずかしいのでしょうか？
    　

    2019年6月12日 3:35  |  道化の真実

77. 更新と新機能の追加お疲れ様です。
    どんどん使うのが楽しいソフトになっていきますね。
    これからもKuroさんのご活躍を応援しております。

    2019年6月12日 7:36  |  S.N

78. >> 道化の真実 さん
    ご確認いただきありがとうございます。

    > フォントを変更した時に、それ以前とは違う場所が表示されることがあるのも、
    > 直していただきたいのですが……、むずかしいのでしょうか？
    等幅フォントから等幅フォントへの変更だとスクロール位置が保持されていると思いますが、プロポーショナルフォントへ変更した場合は折り返し位置が変わることで、全体の行数が変わってしまいますのでスクロール位置の復元がむずかしいですね。

    何らかの対策を考えてみようと思います。

    >> S.N さん
    応援ありがとうございます。

    Ver 2.7.5 以降、ちょっと小刻みに更新してしまい、お手数をおかけしました。久しぶりに開発意欲が湧いてきたので、この機会を逃したらもったいない！と思いつつ、みなさんには申し訳ないなーと思いつつ、楽しく開発させていただきました。

    またしばらく停滞期に入ると思いますので、よろしくお願いいたします ^^;

    2019年6月12日 23:16  |  Kuro

79. ご回答ありがとうございました。
    「プロポーショナルフォントへ変更した場合は折り返し位置が変わることで、全体の行数が変わってしまいますのでスクロール位置の復元がむずかしい」　
    　そうですか、むずかしいのですか。
    　タイプライタースクロールみたいなことができるのなら、もしかすると可能かな？　などと思ったのですが。
    　了解しました。
    　まぁ、フォントの変更は、滅多にやらないことだとは思いますし、そういうものだと思っていれば問題はないところではあります。アウトラインで復帰できますし。
    　変な動作があると美しくない、というのと、初見者がとまどうかも？　ということぐらいですか、問題は。
    　まぁ、何かできそうでしたらお願いします。

    2019年6月13日 1:03  |  道化の真実

80. ＞マクロで #title="" のときにメニューにファイル名を使用するようにした
    ＞#title="" のときにメニューが空っぽになってたので対策してみました。

    これですが、オプション→キーボード→マクロのところが空白になってしまうので、
    結局#titleも埋めないといけなくて利用しづらいです。

    2019年6月13日 14:23  |  名無しさん

81. Mery 2.7.8 更新おつかれさまです。

    待望のマクロバーの仕様変更、ありがとうございます。 :)
    早速 title="" を試してみましたが…、全マクロでやるとマクロバーに 30 コのアイコンが寿司詰め状態で並び、さすがに扱いづらかったので、アイコンに余白が取れるよう、マクロバーに表示可能な範囲だけ title="" に直しました。
    ウインドウサイズ幅 970pxl に 22 コ半（通常は３段目の外部ツールバーは非表示にしてます）
    https://i.imgur.com/fuu5nFy.png
    5月にスクショをうｐしたときは 16 コ
    https://i.imgur.com/VizaHVo.png
    でしたので、私においてはこれでも十分満足できるかんじです。 :)
    あれからポップアップメニューや GetKeyState で複数機能を集約したマクロをいくつか作って差し替えていた部分もありましたが、部分的に開放しちゃいました。

    しかし、セパレータなしで並べるとなると、矢印系のように似たようなデザインのものが多い拙作アイコンライブラリは使い勝手が悪いという、残念なオチがついちゃいました…。 :(
    とはいえ、外部ツールのほうは似たようなアイコンを隣りあわせにして並べても不自由していないので、配置をおぼえてしまえばいいだけかもしれません、
    ひとまず、当面は一つ目のスクショの「ラベルなし（余白あり）」で運用していこうとおもいます。 :D

    また、名無しさんが指摘しているように「キーボードショートカット」設定、「ポップアップメニューの設定」、「標準ツールバーのカスタマイズ」、「キーボードマップ」パネルでマクロ名のラベルを参照できない状態になってしまっています。
    既存のマクロを title="" にし、マクロメニューの表示名用にファイル名をリネームして、あれやこれやを再設定とか整理しなおそうという場合には困ったことになるかもしれません。
    標準ツールバーに置くマクロを title="" にしてしまうと、ポップアッポヒントも空っぽになってしまいますので、すべてのマクロで title="" にするのは、現実的にはよろしくなさそう。
    私の場合は日本語ファイル名がデフォでしたので各種設定パネルをいじる必要はありませんでしたし、マクロはほとんど自作マクロで 300 パターンの自作カスタムアイコンですからなんとかなっていますが、上にあげた各種設定を整備・再構築しなおす必要がでてくる方においては、まだ手を付けないほうがいいかもしれません。

    2019年6月13日 23:04  |  sukemaru

82. >> 名無しさん さん, sukemaru さん
    コメントありがとうございます。

    > これですが、オプション→キーボード→マクロのところが空白になってしまうので、結局#titleも埋めないといけなくて利用しづらいです。

    >また、名無しさんが指摘しているように「キーボードショートカット」設定、「ポップアップメニューの設定」、「標準ツールバーのカスタマイズ」、「キーボードマップ」パネルでマクロ名のラベルを参照できない状態になってしまっています。

    すみません、まだそこまでは対応できてない状態です。…などと言い訳しつつ、ツッコミが入らなければそのままになってる可能性が高いですね ^^; 要チェックしときます。

    実は、以前から sukemaru さんにご指摘いただいている、#title="" にするとメニューが空になる案件の対応とともに、マクロバーのラベルの表示・非表示を切り替える機能の開発を進めております。

    が、先日、アウトライン関連のバグ (プラグイン関連のメソッドに関する不具合) が極めて緊急度の高い問題でしたので、そちらの対応を行った段階で一旦リリースさせていただいた次第です。(マクロバーのラベルの表示・非表示切り替えはもうちょっと時間がかかりそうなので)

    さすがに、sukemaru さんがマクロを大量に登録されているのは知っているので、全部のマクロに title="" を追記してくださいなんていう無茶は言いません ^^;

    > ウインドウサイズ幅 970pxl に 22 コ半（通常は３段目の外部ツールバーは非表示にしてます）
    うは、もはやどれがマクロバーなのかわからないレベル…。でも、めっちゃオシャレですね！うーん、確かにそういわれてみると、セパレータがないとちょっと見づらい気もしますね。

    > 上にあげた各種設定を整備・再構築しなおす必要がでてくる方においては、まだ手を付けないほうがいいかもしれません。
    マクロバーを使っている人って少なそうなので大丈夫だと思いますが、もうちょっと待ってくださいね ^^;

    2019年6月14日 22:19  |  Kuro

83. >> Kuro さん
    せっかくマクロバーの仕様変更に着手していただいたのに、さいしょから苦言を述べてしまい申し訳なくおもいましたが
    > 実は、以前から sukemaru さんにご指摘いただいている、#title="" にするとメニューが空になる案件
    がありましたから、今回のアップデートではまだマクロバーの新仕様が固まりきっていないもの（アルファテスト版？）であろうとおもって、色々とテストさせていただき、使用感を書かせていただきました。
    そもそもの言いだしっぺなので、まずは私が率先して隅々まで（？）テストしないといけないかなと。 :)

    > 全部のマクロに title=""
    登録済みの全マクロではなく「マクロのカスタマイズ」でチェック ON にしたマクロ（マクロメニュー／マクロバーで可視化するマクロのみ。※私のばあいは元の #title="hoge" の hoge を削除）を #title="" にすれば、「ラベルなし×余白なし」になるようでした。
    …さすがに不可視化している約60のマクロにまでは手を付けていません。 :P

    > マクロバーのラベルの表示・非表示を切り替える機能の開発を進めております。
    > 確かにそういわれてみると、セパレータがないとちょっと見づらい気もしますね。
    まだまだ先がある前提で期待させていただきます！ :D

    > またしばらく停滞期に入ると思いますので、よろしくお願いいたします ^^;
    とのことですので、ごゆるりと。 :)

    ※某巨大掲示板に
    > マクロバーの右クリックメニューに「ボタン名を表示する・しない」
    > の切り替え用の項目を作るだけでいいのに
    という書き込みがありましたが、セパレータなしであれば私もそれでよいのではないかなとおもいます。

    2019年6月15日 0:54  |  sukemaru

84. >> sukemaru さん
    動作検証のご協力ありがとうございます。
    マクロバーをかなり使い込まれているご様子だったので、ご協力いただけて助かります ^^

    > 登録済みの全マクロではなく「マクロのカスタマイズ」でチェック ON にしたマクロ（マクロメニュー／マクロバーで可視化するマクロのみ。※私のばあいは元の #title="hoge" の hoge を削除）を #title="" にすれば、「ラベルなし×余白なし」になるようでした。
    はい、非表示のマクロは title の有無をチェックしていないです。そもそもマクロバーに表示されないので関係ないかなと思いまして。

    > > 確かにそういわれてみると、セパレータがないとちょっと見づらい気もしますね。
    > まだまだ先がある前提で期待させていただきます！ :D
    今のところ何も考えてないですよ ^^; (#title="-" で登録したらセパレータに化けるとか？)

    > ※某巨大掲示板に
    > > マクロバーの右クリックメニューに「ボタン名を表示する・しない」
    > > の切り替え用の項目を作るだけでいいのに
    > という書き込みがありましたが、セパレータなしであれば私もそれでよいのではないかなとおもいます。
    某巨大掲示板、見てきましたがきついこと言われてますねぇ ^^; そっ閉じ。

    2019年6月15日 13:21  |  Kuro

85. >> Kuro さん
    ご返信、ありがとうございます。
    > 今のところ何も考えてないですよ
    とのことですので、稚拙な思いつきになりますが提案させていただきます。

    マクロバー以外の各種設定パネルのラベル表示への対応策として、#title の仕様は以前の状態にロールバックし、「マクロバーのラベルだけ非表示にするためのフラグ」用に #label="" または #label=false のような新規プレフィクスキーを設けるというのはいかがでしょうか？
    2.7.8 の仕様をベースにさらに各種設定パネルの仕様を変更するのと、どちらのほうが Kuro さん的にベターなのかは分かりませんが…。（← 完全にいままでどおり手を付けないのが『ベスト』だよ！ なんて言わないでくださいませ plz）

    > (#title="-" で登録したらセパレータに化けるとか？)
    ユーザーがセパレータ用にダミーファイルを用意して「マクロのカスタマイズ」で任意の位置に配置・登録するということでしょうか？
    マクロメニューのドロップダウンでもセパレータになったりしたら楽しいかもですが、これもまた「マクロのカスタマイズ」パネル以外の各種設定パネルへの影響がでてきちゃいそうですよね…。
    プレフィクスキーでセパレータに対応させるのでしたら、 #tittle="hoge|" （← hoge＋バーティカルバー）とか #title="",1 （← 追加引数）のようなかたちで任意のマクロの右側にセパレータを付加できるようにするというのは開発上むずかしいでしょうか？
    あるいは上の #label キーを新設したうえで #label= "|" or "-" or "",1 とか。

    > 某巨大掲示板、見てきましたがきついこと言われてますねぇ ^^; そっ閉じ。
    ああ、見に行かないで済むようにと「引用」したというのに。
    基本的にあそこには Mery のファンしかいないですし、いつも Mery に致命的なバグなどもないので過疎が基本なのですが、ここしばらくは否定的な書き込みにたいしてきつくあたる原理主義者がいたりするので「ここはおっかないインターネットですね」状態で余計に過疎化してしまっているような気がします。

    2019年6月15日 16:45  |  sukemaru

86. >> sukemaru さん
    ご返信ありがとうございます。

    > マクロバー以外の各種設定パネルのラベル表示への対応策として、#title の仕様は以前の状態にロールバック
    これは #title="" のときにメニューを空っぽにする従来の仕様に戻すということでしょうか？ 空っぽのメニューになる仕様に意味があるとは思えないのですが…

    > #label=false のような新規プレフィクスキーを設けるというのはいかがでしょうか？
    これは Windows のツールバーの仕様により、ラベルありとラベルなしのボタンを混在させることができないので、マクロごとにラベルのオン・オフを指定することができないのです。

    > 2.7.8 の仕様をベースにさらに各種設定パネルの仕様を変更するのと、どちらのほうが Kuro さん的にベターなのかは分かりませんが…。
    前提条件として、Windows のツールバーには以下の 2 つのタイプのどちらかを選択する必要があります。

    ・標準バーのようなラベル非表示の「ボタンモード」
    ・マクロバーのようなラベル表示の「リストモード」

    ボタンとリストを混在させることはできません。

    そこで、設定画面の仕様を変更するつもりはなく、[表示] メニューの [ツールバー] の中に [マクロのタイトル] といった項目を設けて、オンにすればマクロのラベル表示。オフにすればマクロのラベル非表示、と切り替える仕組みを想定しています。

    マクロのボタンごとではなく、マクロバー全体に対しての機能となります。

    > > (#title="-" で登録したらセパレータに化けるとか？)
    > ユーザーがセパレータ用にダミーファイルを用意して「マクロのカスタマイズ」で任意の位置に配置・登録するということでしょうか？
    なはは…、言ってみただけです ^^;

    > プレフィクスキーでセパレータに対応させるのでしたら、 #tittle="hoge|" （← hoge＋バーティカルバー）とか #title="",1 （← 追加引数）のようなかたちで任意のマクロの右側にセパレータを付加できるようにするというのは開発上むずかしいでしょうか？
    それはアリかもしれないですね。ちょっと裏技のような感じもありますが、Windows のメニューもセパレータはタイトルに "-" という文字を指定するわけですし、理にかなってるといえばそうかもしれないです。

    > ああ、見に行かないで済むようにと「引用」したというのに。
    そうだったのですね、お気遣いいただきありがとうございました。

    2019年6月15日 18:31  |  Kuro

87. ご返信、ありがとうございます。
    > 前提条件として、Windows のツールバーには以下の 2 つのタイプのどちらかを選択する必要があります。
    > ボタンとリストを混在させることはできません。
    以前ご説明いただいたので承知しています。

    最初のほうの提案は、前提として #label キー（仮）を新設することを想定したものでした。
    他の各種設定パネルもマクロの実体ファイルの #title キーを参照しているようですので、それらに影響する #title キー自体には手を付けないほうがよいのでは？ とおもったもので。
    2.7.8 でラベルを非表示化した機能のスイッチを #label キーに担わせるという発想で、#label=false キーがあるマクロでは「マクロバーでのみ #title="hoge" の読み込みをブロック」して、2.7.8 の更新内容の「#title=""」のときの挙動をさせるといえばよかったでしょうか。

    ・#title プレフィクスの行がないなら、従来どおりすべてのパネルで実体ファイル名をラベルとして表示
    ・#title="" にしたら単純に（2.7.7 以前と同様）にすべてのパネルでラベルなし（※要するに、いままで同様 #title="" にする意味はなく、非推奨）
    ・#label=false（あるいは #nolabel=true とか）プレフィクスがあれば、2.7.8 の #title="" の機能を引き継ぐかたちで「マクロバーのラベルのみ "" （アイコンの右に余白あり）」として、他の設定パネルでのラベルは #title キーを読み込む（※マクロバーのマクロがすべて #label=false のときにボタンで表示する → ラベルなし＆余白なし）

    2019年6月15日 20:19  |  sukemaru

88. > そこで、設定画面の仕様を変更するつもりはなく、[表示] メニューの [ツールバー] の中に [マクロのタイトル] といった項目を設けて、オンにすればマクロのラベル表示。オフにすればマクロのラベル非表示、と切り替える仕組みを想定しています。
    > マクロのボタンごとではなく、マクロバー全体に対しての機能となります。
    これならすべて解決。 :)
    既存のマクロを #title="" にする必要もなくなりますし、私の前レスや上の提案もまったく必要なしですね。
    そのさいは、マクロバーの右クリックメニュー内にも [✔マクロのタイトル] という項目を加えていただければとおもいます。
    ただ、セパレータを追加できない場合は 16px や 24px での表示ではアイコンの並びが窮屈になりそうかも…？

    > なはは…、言ってみただけです ^^;
    > それはアリかもしれないですね。ちょっと裏技のような感じもありますが、Windows のメニューもセパレータはタイトルに "-" という文字を指定するわけですし、理にかなってるといえばそうかもしれないです。
    ほかの設定パネルの仕様に影響しないようでしたら、#title="" のダミーファイル（？）の方法でも、既存のプレフィクスキーに要素を追加する方法でも、よいかとおもいます。
    ニーズの少ない（？）部分みたいですし、ほかのソフトでは前例のなさそうな試みのようですので、Kuro さんのご判断で実装しやすいかたちにしていただいて大丈夫だとおもいます。
    私個人としては、どんなややこしい形式であってもセパレータを追加できるなら「ドーンと来い！」なので。 :D

    そもそもご提案させていただいたのは、もしも実装方法で Kuro さんを悩ませているようなら、稚拙なものでも何らかのアイデアを出してそれを叩き台にしていただければ！ とおもっただけでして。
    やはり Kuro さんのひらめきにお任せするほうが間違いなさそうですね。 :)
    …将来の新規ユーザーさんから見てどういう形式が分かりやすいのか？ までは想像がつきません（既存のプレフィクスの形式自体も分かりやすいか？ といわれたら…）。 :P

    2019年6月15日 20:20  |  sukemaru

89. CSSの@font-faceのunicode-rangeのように、コードポインタを指定すれば、
    改善されると思いますが、どうでしょうか?

    @font-face {
    font-family : 'AntiEmoji';
    src : local('BIZ UDゴシック');
    unicode-range : U+30-39;
    }

    のようにです。

    2019年6月17日 8:10  |  疾風

90. >> sukemaru さん
    ご返信ありがとうございます。

    > 私個人としては、どんなややこしい形式であってもセパレータを追加できるなら「ドーンと来い！」なので。 :D
    ありがとうございます ^^
    いただいたアイデアを参考に良い感じの仕様が浮かびましたので、次のバージョンではセパレータを指定できる仕組みも実装してみようと思います。

    >> 疾風 さん
    コメントありがとうございます。
    ご意見は今後の開発の参考にさせていただきたいと思います。

    2019年6月17日 23:10  |  Kuro

91. 【お知らせ】

    みなさん、コメントありがとうございます。

    当サイトのコメント欄ですが、質問や要望などをコメント欄に投稿されることが増えており、最近ではコメント数が 100 近くに増えてしまって、問い合わせ内容の推移を追いかけるのが難しくなっている状態です。

    気軽に投稿できる雰囲気も面白いものではありますが、コメント欄の構造上、どの問題についてなのかが記載されないまま複数の返信が来てしまうと非常にわかりづらくなってしまいますので、質問や要望はフォーラムのほうに投稿していただけると内容を追いやすいですし回答もしやすいです。

    フォーラムの内容は検索インデックスに登録されますので、他のユーザさんも問題の回答を探しやすくなりますから、情報共有ということでフォーラムをご利用いただきますようご協力お願いします。

    つきましては、今週末 (6/21) をもちまして当サイトのコメント機能を終了させていただきます。

    質問や要望だけではなく、応援コメントをいただくこともあって開発のモチベーションにもなっていたので心苦しい限りですがご容赦ください。

    いままでコメントをくださったみなさん、ありがとうございました。

    2019年6月17日 23:18  |  Kuro

92. >> Kuro さん

    コメントが無くなるのは、一抹の寂しさもありますが、最近のコメントの伸びようはすごいですからね。丁寧に対応したいと思うほどキツくなるというジレンマがあったかと思います。

    疲れない程度にゆるーくやってくためには致し方なしかと思うので、良いご判断かと！

    2019年6月18日 8:13  |  yuko

93. わかりました～。

    （コメント欄は、プログラムとかよく分かってない人が書き込める場所、
    　ぐらいに思っていました)

    (（応援メッセージに特化したいのなら、「コメント」の文字を「応援コメント」などに変えて、「要望。質問・バグ報告などはフォーラムにお願いします」とした上で、　コメント欄の文字数を20字ぐらいに制限したらどうかなぁ？　応援メッセージならそれぐらいで足りると思うし、その程度のコメントなら返信コメント要らないだろうし。質問や要望・意見なんかは、それ以上の文字数必要だろうし……）)

    2019年6月19日 4:30  |  道化の真実

94. >> yuko さん
    コメントありがとうございます。

    それはありますねー。記事も長いしコメント欄も長い… ^^;

    当サイト始まって以来 10 年以上にわたり、いただいたコメントにはすべてレスをするというスタイルを通してきたのですが、文章を書くのが非常に遅いもので、コメントの多さと余暇時間的にもちょっと厳しくなってきちゃいました。

    >> 道化の真実 さん
    コメントありがとうございます。

    応援メッセージはありがたいですが、質問や要望をコメント欄に書かれてしまうと情報共有できないのと、これだけ記事もコメント欄も長くなると返信しづらいし探しづらいという問題のほうが大きいですね。

    コンテンツがソフトウェアという性質上、どうしてもコメント欄に書く内容と言ったら質問か要望になってしまいますから、そこにコメント欄がある限りこればっかりは仕方がないのだと思います。

    2019年6月21日 21:45  |  Kuro