{希哲16年12月18日の副日記}{小さく感じる}{越化参照化}{復活させた}{いったん無効化}{なくはなかった}{用合い上の問題}{反映されていた}{知番表示}{生成していた}...=}(253)

{希哲16年12月18日の開発 K#F85E/E74C-8AE4}

新生全知検索整備中間出振るい

領下手定め環境概ね問題なさそうだったため,新生全知検索整備中間出振るい踏み切った首尾良く完了し,大成功だった。これにより後縁最新の状態同期され自由自在開発体制取り戻した

21時30分出振るい作業開始断帯21時30分から約5分23時頃までには一通り点検不具合修正終えた

その後動作極めて安定しているdg_fnd() への輪数取得処理組み込み今回初出振るいとなるが,高速化効果は,毎回輪数計算必要になる場合検索数十ms求頼1回分短縮なので体感速度向上あまり期待していなかったしかし意外と検索時軽快感増している気がする最初はプラセボ効果近い開発者心理かと思ったが,自分の全知検索歴検索頻度考えれば感じ取れてもおかしくはない嬉しい誤算だった。

輪符知番輪結改良

安心して後縁手を入れられるようになったので,手始めに輪符生成する輪結で,第零番節付き知番そのまま輪結先などに反映されてしまう問題修正した

これにより,輪符知番K#9-XXXX/A-YYYY記述されていても,輪結先第零番節の削除をした /?fg=KNo.XXXX/YYYY/KNo.XXXX/YYYY となる。第二次知番改良経て司組生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符第零番節付き輪結生成していたため,クロール効率への悪影響懸念された出与え属性通して輪郭小窓知番表示にも反映されていたため,用合い上の問題なくはなかった

とりあえずは量が多い基本形輪符重い強調輪符でのみの対応

読み込み中...
=}
{希哲16年7月21日}{希哲16年6月}{開始する}{輪郭小窓実装}{最大の暗部}{手動開始}{無期限保留}{相性問題}{用者体験の向上}{払って}...=}(146)

{希哲16年7月21日の開発 K#F85E/E74C-7F30}

無番輪符改良完了した。これでデルン長年の課題だった輪郭間輪結における知番依存解消した作業中輪符補完機能についての閃きがあり,脳爆発始まった


輪郭選り手上での輪符補完機能は,省割キーあるいはカーソルのある輪括弧表示されるボタン押すことで開始することにした。省割キー仮に Ctrl + {想定しておく。

また,これを機にタッチ端末向け記号入力ボタン本格的に検討することにした。軽量標記言語中心とした用合い課題として記号入力煩雑さがあったため,その解決策兼ねる

ここでようやく輪符補完機能実装イメージまとまった最近のデライト開発では最大の暗部になっていた部分で,極めて大きな収穫言える


漠然と輪郭小窓実装含めていた輪符補完機能だが,ここだけ実装イメージまとまらなかった一時後回しにすることを考えていた理由だった。

原因は,輪符補完自動開始前提としていたことだった。自動開始となると入力中デラング正確に解釈する必要があるが,デラング複雑性考えると交度の肥大化避けられそうになかった深刻な保守性の低下請い手低速化懸念される

更に問題なのは,そこまでの実装コスト払っても,用者体験の向上繋がるとは限らないということだった。この手の挙動好き嫌いがかなり分かれる上に環境との相性問題大きい多くの人満足する水準にしようと思えばキリがない

読み込み中...
{希哲16年4月7日}{👍}{輪結}{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}{-webkit-tap-highlight-color}{妙な効果}...=}(75)

{希哲16年4月7日14歩 K#F85E/E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

=}
{希哲16年3月20日}{輪結}{Aejs 整備}{色付き}{有効時}{抜控機能実装}{下見タブ}{下書きタブ}{両立させる}{違和感がある}...=}(72)

{希哲16年3月20日の開発 K#F85E/E74C-0B0E}

{デラング}{続ける}{大雑把さ}{本筋}{トリッキー}{ウェブフォント}{閲覧環境}{半角約物}{Yaku Han JP}{letter-spacing}...=}(47)

{Yaku Han JP の導入について K#F85E/E74C-F3B3}

日本語の字詰めをデライト上で処理してほしい

ご要望・ご提案ありがとうございます。Yaku Han JP については全く知らなかったので,勉強になりました。約物隙間については確かに気になるところではありましたが,ご要望をきっかけに初めて本格的に検討してみました。

まず,Yaku Han JP導入については,少し時間をかけて検討続ける必要があるな,という印象です。

紙媒体と異なり,ウェブでは様々な閲覧環境配慮する必要があります。全ての閲覧環境,全ての場面で,全ての人がそれを望むか,という点で,Yaku Han JP万能解決策とはまだ確信出来ていないです。

Yaku Han JP例文を見た私の個人的な感想は,「それは詰まり過ぎじゃないか?」でした。見ようによっては,文章の構造が分かりにくいとも言えます。文字サイズを小さくするとよりその問題が大きくなると思います。紙媒体等では一文字ずつ調整するのでしょうが,一律自動でとなると難しいところです。

そもそも,最大手サイトから軒並隙間のあいた約物を見ているわけですから,「慣れ」もありますよね。もっと言えば,なぜ多くのフォント半角約物が採用されていないのか,という素朴な疑問もあります。それは,部分的に問題があるにしても全体としてそれが無難だからではないかな,という気もしています。特に紙媒体業界から来た人はウェブ大雑把さに厳しかったりしますが,実は全体最適化結果であるように思います。

それをウェブフォントで上書きする,というのは,良く言ってトリッキー,悪く言えば乱暴,という印象が拭えません。

また,軽量とはいえ,高速化を追求する上で外部リソース読み込みは紛れもなくコストです。利益天秤にかけて,とまで考えると厳しいところです。


そういった意味では,スクリプト解決してしまう方が正攻法かもしれません。特定パターンの文字列の letter-spacing調整する程度のことであれば,そこまで複雑なコードにも重たい処理にもならないはずです。

あるいは,デラング処理してしまうことも考えられます。

ただ,もし閲覧者が半角約物フォントで閲覧していたら,といったことまで考えると,そこまで積極的なことは出来ないかもしれません。


このような問題に対する本筋本命手段はやはり CSS だと思っています。カーニング関連の仕様充実してきているので,究極的にはそれを待つしかないかもしれません。

=}(1){あれ}
{知番}{用者}{進捗記録}{越える}{分かる}{希哲15年12月24日の開発}{導入しなかった}{完全に隠す}{繋がりうる}{知番の強み}...=}(116)

{希哲15年12月24日6歩 K#F85E/E74C-9D02}

自我知番の省略についての検討終了

昨日の開発から本格的に検討始めた自我知番の省略だが,描写内では輪郭自我知番全知検索などでは録入り中自我知番指す略記法として導入することを決めた

仕様として導入することに大きな問題はないが,難しいのは用合いにどう調和させるかで,これは今後の課題とする。

利点言うまでもなく文字列としての短縮性だが,変則性を一つ加えることで扱い難しくなる懸念もあった。省略有無混乱の元になる可能性もあるため,極力混同させないようにしつつ,ある程度は混同されることを想定した用合い提供する必要がある。この難しさは,これまで導入しなかった正しさでもある。

現状のように自我知番4桁収まっている間は,まだ略記法利点欠点拮抗するだろうが,そのうち8桁になれば流石に邪魔になってくるだろう。将来的に知番の長さ補う方法必要になってくるということは考えていたが,この課題解決策にもなることに気付いたことが決め手だった。

第零番節を除き輪郭知番8桁越えることは機械的な描出でもしない限り)考えにくいが,自我知番4桁なのはむしろ例外的な時期で,いずれ8桁標準になるし,遠い将来には12桁になることも考えておく必要がある。つまり,知番全体20桁まで長くなる現実的な可能性がある。

ここで自我知番の省略が出来れば,少なくとも自輪郭に関しては4桁から8桁輪郭知番だけ考えればいいので,十分な短縮性と言える。他輪郭なら20桁でも扱えなくはない

もっとも,自我知番12桁になるのは40億用者越えてからのことで,輪郭知番4桁もそう簡単には埋まらないので,現実には12桁から16桁知番模量層になるだろう。司組用者成熟度合わせて長くなっていくのが知番の強みだ。


考えている内に,自我知番の省略には無用な自我知番露出避けられる利点もあることに気付いた

テプラ機器知番ったりしているが,人目に触れる場所ではこれも個人情報流出繋がりうる自分だけ分かればいいなら自我知番表記しておく必要はないし,未公開にして完全に隠すことも出来る。

=}
{解決策}

{}