From 13df64f6ff79662d4e0a6c62670dc3841934a8b8 Mon Sep 17 00:00:00 2001 From: EwdErna Date: Sat, 19 Sep 2026 11:14:43 +0900 Subject: [PATCH] =?UTF-8?q?PHY:=20KLE=E5=9B=BA=E6=9C=89=E3=81=AE=E5=BD=A2?= =?UTF-8?q?=E7=8A=B6=E3=83=BB=E5=B1=9E=E6=80=A7=E3=81=AE=E5=8F=97=E3=81=91?= =?UTF-8?q?=E6=AD=A2=E3=82=81=E5=85=88=E3=82=92=E6=B1=BA=E3=82=81=E3=82=8B?= =?UTF-8?q?(P-4=E8=A7=A3=E6=B6=88)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 長方形でないキーは Size に x2, y2, w2, h2 を加えて持つ - デカール・ゴーストはキーとして持ち、フラグで区別する - ラベルは参考情報として持つ(取り込み時の照合に使う) - 見た目の属性はKLEへ書き戻せるよう保持する。保持する層は未決 未決部分は P-5〜P-8 に分離。空の見出し「何かある？」も削除。 Journal: journal/2026-09-19-kle-key-attributes.md Co-Authored-By: Claude Opus 5 --- PHYレイヤー.md | 58 +++++++++++++++++++----- journal/2026-09-19-kle-key-attributes.md | 26 +++++++++++ 2 files changed, 73 insertions(+), 11 deletions(-) create mode 100644 journal/2026-09-19-kle-key-attributes.md diff --git a/PHYレイヤー.md b/PHYレイヤー.md index dfa5615..dc4cead 100644 --- a/PHYレイヤー.md +++ b/PHYレイヤー.md @@ -44,6 +44,17 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した 0.25U単位でスナップするが正規化しない。 サイズはローカルの値であり、親の変換を受けない。 +ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(x2, y2, w2, h2)を加えて表す。 +2つ目の矩形の位置は、キーのローカル原点からの相対値とする。 + +### デカールとゴースト + +デカールとゴーストはキーとして扱い、フラグで区別する。KLEの d, g に対応する。 + +### ラベル + +キーはラベルを参考情報として持つ。KLE JSONの取り込みでは照合に使う。 + ### グルーピング 複数のキーを「クラスター」としてまとめて運用することができる。 @@ -61,12 +72,12 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した - クラスター構造はBeyond KLEのデータにのみ存在する。外部形式へは階層を畳んだキー配置だけを出力する -### 何かある？ - ## 保存形式 各ノードは親から見た変換を持つ。キーとクラスターを混在させた木構造として保持する。 +`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels)にまだ追従していない。 + ```ts type Transform = { x: number, // 親座標系での位置 @@ -75,12 +86,19 @@ type Transform = { } type Size = { w: number, // ローカル値。親の変換を受けない - h: number + h: number, + x2?: number, // 長方形でないキーの2つ目の矩形。ローカル原点からの相対値 + y2?: number, + w2?: number, + h2?: number } type Key = { transform: Transform, size: Size, - profile: Profile + profile: Profile, + decal?: boolean, + ghost?: boolean, + labels?: string[] // 参考情報 } type Cluster = { transform: Transform, @@ -153,12 +171,15 @@ const kleData = (ConfigObject | KeyLabel)[][] KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り込む。元の rx, ry は保持しない。 +見た目の属性(c, t, p, a, f, f2, fa, l, n)は、KLE JSONへ書き戻せるように保持する。どの層で持つかは決まっていない。 + ## 検討済み・非採用 - キーごとの絶対座標保持 (journal/2026-09-18-phy-coordinate-model.md) - 相対座標と絶対座標の併記 (journal/2026-09-18-phy-coordinate-model.md) - ノードごとの回転中心パラメータ (journal/2026-09-18-phy-coordinate-model.md) - KLE JSONへの識別・構造情報の埋め込み(labelのID、`_beyondkle` メタデータ、ゴーストキー) (journal/2026-09-18-kle-roundtrip.md) +- KLEのデカール・ゴースト・見た目属性を取り込み時に捨てる (journal/2026-09-19-kle-key-attributes.md) ## 未確認事項 @@ -181,11 +202,26 @@ KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り - 現状の認識: 採用しない可能性が高い。ただし代わりに欲しい機能があり、それを思い出すきっかけとして残している - 格上げ条件: 代わりの機能を定義し、この推定を採るか捨てるかをユーザーが決める -### P-4 KLE固有の形状と属性の受け止め先 +### P-5 キャップ形状とスイッチ位置の関係 -- 位置づけ: 本文「過去のKLE JSONは読み込めなければならない」を満たすために必要な未解決の問い -- 現状の認識: 現在の Key 型(transform, size, profile)では次を受け止められない - - 長方形でないキー(x2, y2, w2, h2。ISO Enterなど)。受け止められないとISO配列が読めない。ローカルの値なので Size の拡張で相対座標モデルに収まる見込み - - デカールとゴースト(d, g)。PHYで持つか、取り込み時に捨てるか - - 見た目の属性(ラベル、c, t, p, f系, l, n)。落としてよいか、別の層で保持するか。ラベルは照合にも使う -- 格上げ条件: 各項目について、PHYで持つ・他の層で持つ・捨てるのいずれかをユーザーが決め、Key 型に反映する +- 位置づけ: 本文「キャップの位置・サイズからスイッチ座標を特定する」と食い違う事実がある +- 現状の認識: Stepped Caps Lockのように、スイッチ位置がキャップ中心からずれるキーがある。一方でステップキー(KLEの l)なら必ずずれるわけではない(昔のXFERなど)。キャップ形状だけではスイッチ位置が決まらない +- 格上げ条件: キャップに対するスイッチ位置の表し方(オフセットを持つか等)を決め、本文と Key 型を改める + +### P-6 キーキャップの見た目情報を持つ層 + +- 位置づけ: 本文「見た目の属性は保持する。どの層で持つかは決まっていない」の未解決部分 +- 現状の認識: c, t, p, a, f系に加え、l, n もキーキャップの見た目属性であり、PHYとは別の層が要りそう。そもそもキーキャップは設計時に決める必要が薄く、カスタムキーボードの文脈に属するため、Beyond KLEの扱う範囲かどうかも未定。ファイル単位の backcolor, radii, background, css も同じ問いに含まれる +- 格上げ条件: キーキャップの情報をBeyond KLEの範囲に含めるかをユーザーが決め、保持する層を決める + +### P-7 スイッチ種別の保持先 + +- 位置づけ: 未解決の問い。KLEの sm, sb, st(ファイル単位では switchMount, switchBrand, switchType)の扱い +- 現状の認識: PCB設計に使う情報なのでPHYで持つ候補。一部のキーだけ別のスイッチを使う前提のキーボードもあるため、キーごとの上書きが必要になりうる +- 格上げ条件: PHYで持つかを決め、持つ場合はファイル単位の既定値とキーごとの上書きの形を決める + +### P-8 ラベルをMAPに適用するか + +- 位置づけ: 未解決の問い。本文ではラベルを参考情報として持つことだけを決めている +- 現状の認識: どのラベルがMAPに適用できるかは、おそらく機械的には判断できない。自動で適用してユーザーが不要なものを落とす方式も考えられる +- 格上げ条件: 適用するか、する場合は自動適用とユーザーによる取捨の流れをユーザーが決める diff --git a/journal/2026-09-19-kle-key-attributes.md b/journal/2026-09-19-kle-key-attributes.md new file mode 100644 index 0000000..9d932f2 --- /dev/null +++ b/journal/2026-09-19-kle-key-attributes.md @@ -0,0 +1,26 @@ +# KLE固有の形状と属性の受け止め先 (旧 PHY P-4) + +## 結論 + +- 長方形でないキー(x2, y2, w2, h2): Size の拡張で持つ。ローカル値なので相対座標モデルに収まる +- デカール・ゴースト(d, g): キーとして持ち、フラグで区別する +- ラベル: 参考情報としてPHYで持つ。取り込み時の照合(P-2)にも使う。MAPへの適用は未決(P-8) +- 見た目の属性(c, t, p, a, f系, l, n): KLEへ書き戻せるよう保持する。保持する層は未決(P-6) +- スイッチ種別(sm, sb, st): 未決(P-7) + +## 案の比較 + +| 項目 | 案 | 採否 | +|---|---|---| +| d, g | PHYでキーとして持つ / 取り込み時に捨てる | 持つ | +| 見た目属性 | 捨てる / 解釈せず保持して書き出し時に戻す | 保持。KLEをビュワーに使うとき色などが戻る方が実用的 | +| ラベル | 捨てる / 参考情報として持つ | 持つ。照合に必要 | + +## ユーザーから得た事実・所感 + +- l(ステップキー)にはスイッチ位置がずれるものがある(Stepped Caps Lockが典型)。ただし l なら必ずずれるわけではない(昔のXFERなど) + → 「キャップの位置・サイズからスイッチ座標を特定する」という本文と食い違う。P-5として分離 +- l, n はキーキャップの見た目属性であり、PHYとは別の層が要りそう。キーキャップは設計時に決める必要が薄く、 + カスタムキーボードの文脈に属する。Beyond KLEの範囲かは結論なし +- 一部のキーだけ違うスイッチを使うキーボードもあるので、スイッチ種別はキーごとの上書きが要るかもしれない。PCB用なのでPHYに要るか +- ラベルのうちどれがMAPに適用できるかは判断できない見込み。自動で適用してユーザーが落とす案もある