うむ。ここで一回、「いま確定しているもの」「まだ決めてないもの」「実装で試してから決めるもの」まで分けて書き出そう★
将来案をうっかり現行仕様へ混ぜないように、Free / Standardまでを対象にする。
Kaia PDF — Free / Standard 仕様草案
Draft 0.1 / 2026-09-01
1. 製品の基本位置づけ
Kaia PDFは、Web上で紙面をデザイン・Previewし、FINAL時に確定した発行情報からPDFを生成する独立コンポーネント。
Counterの付属機能ではない。
PDFのグレードはCounter等のグレードから独立して選択できる。
現行開発対象：
Free → Standard
Creative / Advancedは将来拡張。
現段階では将来拡張を妨げない構造のみ考慮し、機能そのものは実装しない。
Registry：
- PDF parent：
KS-0018-CNT-18 - PDF Free：
KS-0028-CNT-18 - PDF Standard：
KS-0029-CNT-18
2. 対応用紙
Free / Standard共通。
- A4 Portrait
- A4 Landscape
- A5 Portrait
- A5 Landscape
現時点ではこの4種類。
用紙サイズをグレード制限にはしない。
3. 編集画面
基本構成：
[ Parts Panel ] [ Canvas / Preview ]
Parts Panel＝部品箱。
Canvas＝紙面編集領域兼Preview。
ExcelでText Boxや画像を挿入するような感覚を基本とする。
Workspace左右交換
編集画面に、
⇄ Swap Panels
相当の操作を用意する。
通常：
[ Parts ][ Canvas ]
交換後：
[ Canvas ][ Parts ]
これは左利き専用モードとはしない。
ユーザーが好きな作業机配置を選択するWorkspace機能とする。
重要：
左右交換によって、
- Canvas内部座標
- BOX位置
- Designデータ
- PDF出力
を変更してはならない。
可能なら選択状態を編集者のWorkspace設定として保存する。
4. Zoom
Canvas表示倍率はスライダー方式。
概念：
－ ━━━━━●━━ ＋ [ Fit ]
Zoomは画面表示だけに作用する。
作品内部の、
- 座標
- サイズ
- 画像サイズ
- 文字サイズ
等には影響しない。
Fit
Fit = 現在利用可能なWorkspace内へ、用紙全体が見える倍率に自動調整する。
固定100%へ戻す機能ではない。
Panel左右交換や画面サイズ変更後も、その時点の利用可能領域に合わせて再計算する。
5. Canvas / 紙外作業領域
Canvasは「紙そのもの」ではなく、
広い作業領域の中にA4/A5の完成範囲が存在する
構造とする。
イメージ：
┌───────────────────────────┐
│ hidden workspace │
│ │
│ ┌───────────────┐ │
│ │ │ │
│ │ A4 / A5 │ │
│ │ FINAL AREA │ │
│ │ │ │
│ └───────────────┘ │
│ │
│ hidden workspace │
└───────────────────────────┘ユーザー感覚としては、
「紙をくり抜いて、その後ろで部品を自由に動かす」
に近い。
紙外への移動
オブジェクトは紙外へ移動可能。
紙外へ出ても、
- Cropしない
- Deleteしない
- 元画像を破壊しない
- 隠れた部分の位置情報を保持する
後から紙面内へ戻せば、隠れていた部分が再び表示される。
FINAL PDFへ出力されるのは紙面境界内のみ。
つまり、
編集データは非破壊保持
→ FINAL出力時だけ紙面境界でクリップ
とする。
作業領域サイズ
無限Canvasにはしない。
実装事故を起こさない範囲で、紙外へ十分逃がせる有限領域を用意する。
必要以上に巨大化させない。
実装負担が大きくなる場合は既存制作ツールの一般的な挙動を参考にして簡略化する。
6. Design / Operation分離
初期構造から分離する。
Design
紙面の見た目。
例：
- 用紙サイズ / 向き
- 背景
- Page Frame
- BOX位置
- BOXサイズ
- フォント
- 文字サイズ
- 色
- 画像
- Image Frame
- Ornament
- 回転
- レイヤー順
Operation
発行時の動作・流し込み情報。
例：
- runtime
N - Counter ON/OFF
- Timestamp ON/OFF
- Serial ON/OFF
- Fixed Text
- User Name等の入力
- 発行時取得値
将来のDesign FormatやProject複製を考慮しても、この境界を最初から崩さない。
ただし、それらの将来機能自体は現段階では作らない。
7. Runtime連携
関連コンポーネントは共通runtime N で接続する。
例：
管理用Registry IDとruntime Nを混同しない。
PDFはFINAL時の最終点呼役。
8. Parts
Parts Panelには、少なくとも以下のデータ部品を持つ。
- Counter
- Timestamp
- Date
- Time
- Serial
- User Name
- Fixed Text
- Image
- Page Frame
- Image Frame
- Ornament（Standard）
紙面Designには生のショートコード文字列ではなく、内部的な安全なPart Typeを保存する。
9. 接続コンポーネントが存在しない場合
Counter / Timestamp / Serial等が存在しないからといって、対応PartそのものをUIから消さない。
グレーアウトして理由を表示する。
例：
Grayed-out features require an additional component.
これによりユーザーは「機能自体が存在しない」のか「現在使えない」のかを区別できる。
SerialにはFree製品は存在しない。
10. Timestamp / Date / Time
同一の確定Timestampから必要な表示を派生させる。
例：
2026.08.27 22:22:22
なら、
Timestamp
2026.08.27 22:22:22
Date
2026.08.27
Time
22:22:22
PDF独自の「発行日」を勝手に生成しない。
11. Preview
Previewは完成レイアウト確認に使えるだけの精度を持たせる。
名前や日付を伏字にする旧案は採用しない。
Previewでは、
- User Name
- Timestamp
- Date
- Time
- Counter
- Fixed Text
- その他確定済み入力
を実際の値で表示可能。
ただしSerialだけはFINAL前には存在しない。
そのためPreview専用Placeholderを使用する。
Previewによって本物のSerialを消費してはならない。
12. SAMPLE
Previewスクリーンショットを完成発行物として利用されることを防ぐため、
透過PNG SAMPLE Mask
をPreview最前面へ強制表示する。
SAMPLEは通常のDesign Layerではない。
ユーザーが、
- Bring to Front
- Layer変更
- Design編集
等を行ってもSAMPLEより上へ出ることはできない。
また、ブラウザ側でSAMPLE表示を除去するだけで正式PDF相当物を取得できる構造にはしない。
13. FINAL
FINALは不可逆発行境界。
概念フロー：
入力確定
↓
Preview確認済みDesign / 値を確定
↓
FINAL
↓
Counter発行確定
↓
Timestamp取得
↓
Serial使用時は実Serial発行
↓
同一issuance eventとして確認
↓
最終値を紙面へ投入
↓
SAMPLEなしでレンダリング
↓
PDF生成
PreviewとFINALの間で勝手に再翻訳・再解釈・値変更を行わない。
必要情報が、
- 欠落
- Overflow
- 取得失敗
- 発行条件不成立
なら、推測してPDFを生成せず停止する。
14. Preview / FINAL描画原則
二つの別レイアウトシステムを作らない。
同じDesign定義からPreviewとFINALを生成する。
違いは主に、
Preview：
- SAMPLEあり
- Serial Placeholder
FINAL：
- SAMPLEなし
- 実Serial
- 確定発行値
とする。
Web上で見えたレイアウトとFINAL PDFのズレを最小化する。
15. Font
サイトテーマのFontを自動取得する方式にはしない。
TCD等、特定テーマにも依存しない。
Kaia PDF側が、
Web PreviewとFINAL PDFの両方で正常出力できることを確認したFontだけ
選択肢として提供する。
ユーザーには内部方式を意識させない。
通常文字向けに、一般用途を十分満たすFont群を用意する。
具体的なFont一覧は技術試験後に決定。
16. Undo / Redo
可能な限り、
↶ Undo / ↷ Redo
を提供する。
ただし初版で巨大な履歴管理システムは作らない。
実装負担が軽い方式を優先する。
候補：
Design State Snapshot方式
Undo対象候補：
- 移動
- サイズ変更
- 回転
- 追加
- 削除
- 色変更
- Text変更
- Ornament変更
具体的な履歴数等は技術試験後に決定。
Undo/Redoのために初版Editorを巨大化させない。
17. Layer
紙面部品には重なり順を持たせる。
最低限、
- Bring Forward
- Send Backward
相当の操作を可能にする方向。
SAMPLE Layerはこの通常Layer管理とは独立する。
18. PDF Free
Free単体で実用品として完成したPDFを発行可能。
StandardはFreeを「使えるようにする」ための解除キーではない。
Background
背景色を設定可能。
現時点ではKaia側から完成背景画像・完成台紙ライブラリを提供しない。
Page Frame
シンプルな線による額装。
候補：
- Single
- Double
- Dotted
- Dashed
- Line thickness
- Line color
実際にWeb/PDF双方で安定するものから採用する。
Text / Data BOX
PartsからText/Data BOXを紙面へ配置可能。
具体的なBOX上限数は未確定。
19. PDF Standard
Freeの全機能を含む。
Standardは主に紙面制作の自由度を拡張するグレード。
Standardへ上げても、Freeで作ったシンプルなDesignをそのまま使える。
20. Standard Image Allowance
Standardでは画像利用量を以下の二択とする。
1 image × 最大1/2 paper
または
2 images × 最大1/4 paper each
混在して上限を超える組み合わせは不可。
例：
1/2 × 1 + 1/4 × 1
は不可。
制限計算はシステム側で行い、ユーザーに残量計算させない。
「1/2」「1/4」の厳密な技術定義は実装前に確定する。
21. Standard Ornament / Beads
Standardでは大量の完成額縁画像を配ることを基本方式にしない。
Kaia PDFが安全性・Web/PDF出力を確認したglyph / shape等を、
Ornament Beads
として提供する。
ユーザーはビーズを並べて一つのOrnamentを作れる。
例：
❧ ✦ ◆ ✦ ❧
操作候補：
- Bead選択
- 並べ替え
- 追加
- 削除
- Spacer
- Size
- Color
Spacerは可能なら単なる文字スペースではなく、構造化された間隔部品とする。
22. Ornament安全性
任意Unicodeを自由入力してOrnament化する方式にはしない。
Kaia PDFがPreview → FINAL PDFまで正常出力を確認したものだけPaletteへ入れる。
Font / SVG / その他の内部実装方式はユーザーへ露出しない。
つまり、
ビーズ箱に入っているものは全部使える★
を保証する方向。
23. Built-in Ornament Presets
Standardには、Kaia側で作った完成済みOrnament Presetを少数用意する。
基本操作：
Presetを選ぶ
→ 色を選ぶ
→ 完成
より細かく編集したい場合：
Copy to Custom
PresetのBead構成をCustom Ornamentへ複製。
そこから、
- Bead交換
- 並べ替え
- Spacer変更
- 色変更
等が可能。
Built-in Presetそのものは破壊・上書きしない。
24. Page Frame Link
額縁の対称配置はシステム側で補助する。
基本的なLink Group候補：
- Four Corners
- Top / Bottom
- Left / Right
- All appropriate linked parts
Link状態では一つの代表Partを編集し、対応箇所へ自動的に、
- Rotate
- Reflect
- Mirror
等を適用して展開する。
ユーザーが必要な場合はLinkを解除して個別編集できる。
対称作業は機械にやらせる。
非対称にしたい時だけ人間が触る。
形状LinkとColor Linkを別管理できる構造は考慮するが、初版UIでどこまで公開するかは未確定。
25. Image Frame
画像に適用できる装飾/形状枠。
ユーザー向け名称は現時点で、
Image Frame
を採用候補とする。
基本候補：
- None
- Oval
- Diamond
- Polygon
Noneは必須。
ユーザー自身が画像へ装飾枠を描き込んでいる場合、Kaia側のFrameを重ねずそのまま使用できる。
26. Image Frame Position
現時点では6位置方式。
Upper Left / Upper Center / Upper Right
Lower Left / Lower Center / Lower Right
Image Frameは完全自由配置ではなく、この指定位置を基本とする。
サイズも自由無制限にはしない。
27. Polygon Image Frame
Polygonは最低3 sides。
最大値はまだ固定しない。
数学的に全side数を提供する必要はない。
実際の紙面上で、
- 見栄えが良い
- 画像が成立する
- 操作しやすい
形状だけ採用する。
漫画的な宝石シルエット程度まで細かくできれば十分。
操作イメージ：
Sides ◀ 6 ▶
Image FrameはRotation可能。
形状変更・回転によって見た目サイズが大きく変わらないよう、Shapeごとに内部補正を行う方向。
数学的完全同面積より、
視覚的な占有感の統一
を優先する。
28. Standardの基本UX
Standardは二段階で使える。
簡単に使う人
Presetを選ぶ → 色を選ぶ → 完成
遊びたい人
Copy to Custom → Beadsを編集
つまり、
簡単な入口は残すが、奥ではかなり遊べる。
29. 初版で作らないもの
少なくとも現段階では以下をFree / Standardへ先回り実装しない。
- 完成台紙画像による全面置換
- ユーザー独自の高度な装飾素材システム
- Project Duplicate
- Design Format保存 / 再利用
- Enterprise機能
- 完全スマートフォン制作環境
- 無限Canvas
- 巨大な履歴管理UI
将来機能を邪魔しないデータ構造は考慮する。
30. 技術試験が必要なもの
ここは仕様未決定ではなく、実物を殴って決める領域。
A. Web → PDF描画
極小試作で、
Text
→ Font
→ Image
→ glyph/Ornament
→ Color
→ Rotation
→ Reflection
→ SAMPLE
→ FINAL PDF
まで通す。
Web PreviewとPDFの一致度を見る。
ここが最大の先行試験。
B. Font / Ornament Palette
候補を実際にWeb/PDF双方へ出し、
PASSしたものだけ商品Paletteへ採用。
C. Undo / Redo
軽量Snapshot等で十分成立するか試す。
重ければ初版仕様を縮小する。
D. Hidden Workspace
紙外作業領域をどの程度まで広げても安全か実測する。
無理に広げない。
31. 現在まだ決めていないこと
ここは俺が勝手に埋めない。
① Free / StandardのText/Data BOX上限
まだ数字を決めていない。
② 画像1/2・1/4の厳密な定義
見た目上の意図は決まっているが、計算方式は未決定。
③ Freeの画像仕様
ここは俺が前の草案で「Free＝画像1枚1/4」と書いたが、今回までの確定情報として十分な裏取りが取れていないので、一旦未確定へ戻す。
Standardの 1×1/2 or 2×1/4 は確定。
④ Image PartとImage Frameの関係
「画像をImage Frameへ入れる」のか、「通常ImageとImage Frame付きImageが別Part」なのか、6固定位置との関係を含めて一度整理する。
⑤ Page Frame Link UIの細かさ
内部的な拡張余地は残すが、初版でColor Link等まで露出するか未定。
⑥ Polygonの具体的採用side数
実物を見て決める。
⑦ Undo履歴数
技術試験後。
⑧ Font一覧 / Ornament Beads一覧
実出力PASS後。
32. 事故防止ルール
実装に入る前の赤札。
PreviewとFINALを別々に作らない。
SAMPLE除去だけで正式成果物を取得できる構造にしない。
PreviewでSerialを発行しない。
Workspace左右交換・ZoomをDesign座標へ混ぜない。
紙外へ出たオブジェクトを破壊しない。
テーマ依存Fontを勝手に拾わない。
野良UnicodeをOrnament Paletteへ入れない。
Registry IDとruntime Nを混ぜない。
Creative / Advancedを「ついでに」作らない。
Undoを作るためにEditor全体を巨大化させない。
無限Canvasを作らない。
そして実装直前にもう一回、
「ところで俺、何を作るために走るんだっけ？★」
をやるｗｗｗ
これなら俺はかなり安心。
そして今回書き出して良かった。Freeの画像1/4を俺が確定事項みたいに書いていたところは、ちゃんと赤ペンで未確定へ戻した。 こういう小さい「たぶんそうだった」を残したままコードへ行くのが一番危ない。
残りも全部一気に決めなくていい。
次に一個だけ詰めるなら、俺は ④ Image と Image Frameの関係 を先にやりたい。ここが決まるとStandardの画像制限とParts Panelの構造が一緒に綺麗になる。
今はまだ**仕様書Draft 0.1。靴紐を床に並べ終わったところ★**ｗｗｗ
No comments yet.