pdftoppm
}{譜類添付機能調整}{譜類添付機能}(116){希哲17年4月5日の開発 K#F85E/E74C-3148}
宇田川浩行譜類添付機能調整など。
細かい挙動の調整を終えてから PDF 埋め込み対応を完了,譜類添付機能も全体として完成形と言える状態になり,ようやくエクスポート機能実装に移れる。
3月24日の開発時点では,添付ボタンと埋め込み記法でラスター画像(JPEG, PNG, GIF, WebP)が扱える程度で機能実装の一段落としたが,SVG,動画,音声までの埋め込み含めての対応,その他主要文書譜類対応,添付代置子の導入,貼り付け・ドロップ対応,更に PDF 埋め込み対応と,現時点でやりたいことは一通りやってしまった。一段落とは言ったものの,中途半端感が残りいまいちすっきりせず,デライト公式での機能紹介も出来ていなかった。
PDF 埋め込み対応に関しては,PDF.js と pdftoppm
が優秀だったおかげで意外とあっさり実装出来た。特に PDF.js は viewer.html
の場筋と PDF 譜類の場筋を組み合わせて <iframe>
の src
属性に渡せばいいだけで,スクリプト側の対応も簡単だった。
最初のページを pdftoppm
で JPEG に,cwebp
で WebP に変換,その画像をクリックで縦サイズを合わせた <iframe>
に置換し viewer.html
を読み込む。読み込み中の進捗表示も viewer.html
が行ってくれるので,これだけで違和感なく軽快な PDF 埋め込みが実現出来た。一応,「(.pdf
添付ファイル)」の形で小書き輪結も添えるようにしておいた(PDF 埋め込みの様子)。
一つ,添付譜類の握接権限の課題は残した。現状,場筋が分かっていれば誰でも握接出来るが,デライトの性質上大きな問題ではない。エクスポート機能で譜類の握接制御を実装するのでそれを応用することにした。
{希哲17年4月1日10歩 K#F85E/E74C-F8BB}
宇田川浩行pdftoppm
}{PDF.js}{希哲17年3月31日の開発}{希哲17年3月31日の進捗}{希哲17年3月31日}{昔過ぎる}{実装出来そう}(47){希哲17年3月31日15歩 K#F85E/E74C-B816}
宇田川浩行{希哲17年2月21日5歩 K#F85E/E74C-5A3E}
宇田川浩行{希哲17年1月8日の開発 K#F85E/E74C-482E}
宇田川浩行CodePen 対応を含むデラング調整(6歩,7歩,8歩),課題だった KaTeX マクロ問題を含む不具合修正(9歩,12歩)。
やはり,知名欄・描写欄にマウスオーバーで捕活するようになったことで描出効率が大きく向上している。元々あった機能ではあるが,第二次用合い改良以後のデライトとの相性が非常に良い。
写し貼り時などの無駄なクリックが大きく減り,一度捕活解除した後に残った選択状態も判別しやすくなった。これは描写欄から引き入れ欄への写し貼りを繰り返す時に重要な点だ。
手元の舞覧(Linux 版 Firefox など)では,捕活が移ると選択状態が残っていても配灯が消える。クリックで捕活すると選択状態自体が消えてしまうので,前回の選択範囲が分からなくなる。その上,見えなくても選択状態は残っているので,新しく選択するつもりで前回の選択範囲の上からドラッグしてしまうと意図しない文字列ドラッグが発生する。マウスオーバーで捕活しなかった時期はこれがなかなかのストレスだった。
{希哲17年1月7日20歩 K#F85E/E74C-370E}
宇田川浩行知名欄・描写欄の捕活に関する仕様検討の結果,ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。
仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活・全選択,描写欄では捕活,という方針だった。これは,実用上の都合というのも大きく,こうでなければ単純に描出効率が悪かった。
昨年9月までの第二次用合い改良中の交度整理で,知名欄の捕活・全選択は機能しなくなっていた。これは確か,中景輪符の事象を改良したことで干渉の懸念があり,再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの,どの時点で機能しなくなっていたのかは曖昧だが,いずれにせよ,第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。
もしかしたら,これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率が重要な作業になると,クリックでの捕活はやはりまどろっこしく,鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。
懸念は,他要素・他機能との干渉や誤操作だったが,これは昨日の検討から急速に氷解した。今のデライトで,マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ,むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること,スクロールとの干渉も実際の舞覧では生じないこと,誤編集の問題については,そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており,更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した。
そこでまず,知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが,知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては,選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると,今度は選択状態が意図せず解除されやすくなる。もっと問題なのは,誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが,知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。
これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても,熟練用者向け過ぎて採用出来ない。
次に,知名欄の全選択機能を外し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら,編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。
どこまで普遍的な現象か分からないが,常用している Linux の Firefox では,<textarea>
の選択状態を残して捕活解除すると,再選択のつもりが(未捕活状態のせいで)意図しない文字列ドラッグが発生しやすいため,これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。
とにかく,第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。