ういｗ
ここは一回、**今日PDFについて切った仕様を「次の設計・実装でそのまま参照できる1ログ」**に固めよう。

以下、古い案で途中修正されたものはなるべく最新版へ寄せてある。まだ未決定のものは勝手に確定させてない。

Kaia PDF — Free / Standard 設計ログ統合版

Working Draft / 2026-09-01

1. Kaia PDFの基本思想

Kaia PDFは、Web上ですでに決定・確定された情報を受け取り、指定されたDesignへ配置し、PDFとして出力するコンポーネント。

PDF自身がCounter / Timestamp / Serial等の業務ロジックを再実装しない。

基本境界は、

Webで決める → PDFが確定状態を点呼する → 値を拾う → 組版する → 出力する。

PDFはプリンター寄りの存在。

確定していない値について、現在値を推測したり、現在時刻を勝手に発行時刻として使ったり、Serialを勝手に発行したりしない。

---

2. Gradeの基本的な切り方

ここを個別機能より上位の判断原則とする。

Free

触れないと用途上事故る部分だけ自由。

自由なデザインツールとして売るのではなく、PDFとして実用にならなくなる部分だけユーザーへ操作権を渡す。

Standard

Kaia PDF / WordPress側で用意された環境の中で自由。

こちらが扱える環境・部品・機能を使って、かなり自由にDesignできる。

Creative

持ち込み素材を解禁。

ユーザー自身の素材やPCフォント等を持ち込める。

画像系持ち込みは静止画まで。

この原則から、

必要操作 → Free
用意された環境内での自由 → Standard
外部素材の持ち込み → Creative

を基本判定とする。

---

3. Paper / Design Master

Free / Standardの対応用紙：

• A4 Portrait
• A4 Landscape
• A5 Portrait
• A5 Landscape

ただし内部Designは4種類作らない。

内部Masterは常にA4 scale。

存在するMaster geometryは、

A4 Portrait / A4 Landscape

の2系統。

A5選択時もDesignデータそのものをA5へ縮小保存しない。

UI上ではA5の寸法として表示・入力し、保存時にはA4 Master座標へ変換する。

FINAL時：

A4 → Master 100%
A5 → Masterから一度だけA5へ縮小

とする。

これにより、

A5で制作 → A4へ変更

しても、画像等を一度縮小してから再拡大する破壊処理を発生させない。

アップロードされた原画像もPaper別にリサイズして上書きしない。

---

4. Workspace

中央EditorはIllustratorを小さくしたような作業机として考える。

Paperそのものより広い、有限のWorkspaceを持つ。

WorkspaceはPortrait / Landscapeのどちらでも扱いやすい、概ね広い正方形寄りの領域とする。

Paper orientationを変更しても、周囲のUI全体をガタガタ組み替えない。

作業机は固定。紙が中で変わる。

Paper外へオブジェクトを置くことができる。

ただしWorkspaceは無限ではない。

Workspaceの壁まで到達したら、それ以上は動かない。

そこで画像加工機能を増築しない。

Workspaceにすら収まらない素材は、Canva / Photoshop / GIMP等で素材を整えてから出直してもらう。

Kaia PDFはレイアウトツールであって、総合画像編集ソフトではない。

---

5. Editor-only visibility

FINALに出ないものほど、Editorではむしろ見えるようにする。

Editor専用Overlayとして、

• Ruler
• Guide
• Paper / Master boundary
• Outside-paper shade
• Source Image boundary
• Image Frame / Mask boundary

を持てる。

これらはPreview / FINALには一切入らない。

Ruler / Guide

上Rulerから下へドラッグ → Horizontal Guide。

左Rulerから右へドラッグ → Vertical Guide。

Guideは移動・削除・Show/Hide可能。

単位：

mm / px

ただしGuideの内部位置をviewport pxで保存しない。

Master座標をCanonical dataとして保持し、単位変更は表示変換のみ。

Grid / 方眼はFree / Standardでは作らない。

---

6. Paper外表示

Paper / A4 Masterの境界をEditorで視認できるようにする。

Paper外についてはEditor preferenceとして、

Off / White / Black

程度のShadeを用意する案。

目的は装飾ではなく、白・黒オブジェクトを含めて紙境界を認識しやすくすること。

これはDesign contentではない。

Preview / FINALにも出さない。

---

7. UIの基本姿勢

Kaia PDFの編集画面は、

止めて説明するより、見れば分かるようにする。

通常編集では、

警告Popup、Dialog、Toast連発、禁止カーソル等を極力使わない。

特に not-allowed / 🚫 Cursorは通常編集で原則使わない。

限界 ≠ 禁止。

Workspaceの壁なら、普通のCursorのままそこで止まればいい。

Paper外ならShadeで分かる。

Mask外ならSource boundaryで分かる。

上位Grade機能なら最初からGray-outされている。

原則：

分かることは言わない。見えないことだけ必要なら言う。

ただしFINALや確定状態不足など、発行・データ整合性に関わる停止理由は明示する。

---

8. Image / Image Frame

画像の制限対象は原画像の大きさではない。

Image と Image Frame を分離する。

Image = 原画像Asset
Image Frame = Paper上で画像が見える窓 / clipping mask

原画像はFrameより大きくてもよい。

Workspace内であればPaperを大きくはみ出してもよい。

Source ImageをFrameの後ろで、

• Move
• Scale
• Offset

して、見せたい部分を決める。

原画像そのものを破壊的Cropしない。

Free

1/4 Paper Image Frame × 1

だけ好きな静止画像を入れられる。

これはFreeのデザイン自由化ではなく、

PDFなのにCreatorの作品を載せられないと用途として事故る

ために渡す最低限の自由。

Standard

1/4 × 2

または

1/2 × 1

のどちらか。

1/2 + 1/4 の混在は不可。

Tier制限はSource Imageの面積ではなく、Kaia PDFが提供するImage Frameの枠で判定する。

---

9. 外部で合成された画像

Kaia PDFは画像内部の素材数を数えない。

ユーザーがCanva / Photoshop等で、

作品A + 作品B + ロゴ + 文字

を一枚のPNG等にして持ち込んだ場合、

Kaia PDFにとってはImage 1個。

コラージュ検出や意味論的な「作品数判定」はしない。

Freeを賢く使うために外部でコラージュして1枚にするユーザーがいても問題なし。

ただしKaia PDF内ではFlattenされた1 Imageなので、内部の各作品を個別移動することはできない。

ユーザーの工夫を潰すための制限は作らない。

---

10. Clipping中のSource visibility

Image FrameでMaskしていても、EditorではSource Image全体を確認できるようにする。

Mask外のSourceを薄く見せ、Source Imageの外周を点線等のEditor-only boundaryで表示する。

これによって、

「これ以上寄らない」

となったとき、

Source Imageの点線がWorkspace壁へ当たっている

ことをユーザー自身が視覚判断できる。

そのため通常は、

「Workspace boundary reached」

等の警告を出す必要もない。

FrameとSourceは別々に選択・操作できる構造を想定。

FINALでは常にImage FrameのMaskを守る。

Free / StandardのImage Frame制限を解除するような「Mask解除FINAL」は作らない。

編集時にSource全体を見せるだけ。

---

11. Clip hierarchy

非破壊編集として、

Workspace boundary
= 編集可能な存在範囲

Paper boundary
= FINALで必ずClipされる境界

Image Frame boundary
= Imageに対する局所Clip

とする。

Editor / Preview / FINALで可能な限り同じGeometry定義を使う。

---

12. Rendering Layer

Document側は概念的に、

Base
台紙・背景等。

Preset
あらかじめ設定された定型文等。

User
Web上でユーザーが決定した値、および確定済みCounter / Timestamp / Serial等。

に分離する。

Previewのみ、その上に

SAMPLE Mask

を強制追加。

したがって、

Preview = Base + Preset + User + SAMPLE

FINAL = Base + Preset + User

Editor Overlayはこれらとは別系統。

SAMPLEは通常Design Layerではなく、ユーザーが前面へ何か持ってきて隠せるものではない。

PreviewとFINALは別レイアウトシステムを作らず、同一Renderer / 同一Design definitionを使う。

---

13. Linked / Mixed Text

以下のような表現を扱える必要がある。

TO [User Name]

[User Name] 様

You are number [Counter].

Fixed TextとDynamic valueを完全に別BOXとして並べるのではなく、

prefix + finalized dynamic value + suffix

を一つのText run/blockとしてComposeしてから、幅・Alignment・Wrapを計算する。

初期Freeで巨大なTemplate Languageは作らない。

まずは一置換程度で成立させつつ、将来複数置換を完全に塞がない構造にする。

---

14. Font Grade境界

Standard

WordPress環境ですでに使用可能なFontを利用できる。

WordPress側で使えるよう設定済みのWeb Fontも当然対象。

Standardは「Kaiaが同梱した数種類のFontだけ」ではない。

Creative

ユーザーのPC / DeviceからFont fileそのものを持ち込む機能を解禁。

TTF / OTF等の直接ImportはCreative領域。

したがって、

Standard = WPにあるものを使う
Creative = 外からFontそのものを持ってくる

という境界。

Web FontをFINAL PDFへどう安全に反映するかは技術検証事項であり、Grade境界とは別問題。

---

15. Component integration

CounterがRoot / Gate。

Timestamp / Serial等は既存のCounter確定状態へ追従する。

PDFは最後の点呼役。

PDF自身がCounter / Timestamp / Serialを起動したり、再実装したりしない。

PDFは、

Counter！
Timestamp！
Serial！（使用時）

と既存のConfirmed stateを確認して、揃っていれば進む。

Auto StopにもPDFから直接依存しない。

Counterが閉じていれば下流の確定状態が成立しないので、PDFも自然に生成不可になる。

---

16. FINAL validation

FINAL前に必要条件を一度に確認する。

不足が複数ある場合、一個ずつDialogで出さない。

例：

PDF cannot be generated because the following requirements are not met:

Counter has not been confirmed.
Timestamp has not been confirmed.
Serial has not been confirmed.
Required information has not been entered.

という形でまとめて提示する。

Serialは参加設定時のみRequired。

PDFは未確定値を補完・推測しない。

---

17. Preview

PreviewはRead-only。

すでに確定しているSibling dataを読む。

PreviewのためにCounterを進めたりSerialを消費したりしない。

Serialに実値がまだ存在しない仕様の場合はPlaceholderを使用し、Previewで本番Serialを消費しない。

Preview Artifact自体にSAMPLE Maskを含める。

ブラウザ上で無Mask PDFを表示して、その上へCSSだけでSAMPLEを被せるような構造は避ける。

---

18. Standard — Design freedom

Standardは、

Kaia / WordPressが用意した環境内で自由にDesignするGrade。

FreeでGray-outされていたStandard用主要Controlを有効化する方式を基本とする。

Upgrade時にUIを別物へ作り直さず、

見覚えのある席が使えるようになる

構造を狙う。

下位Gradeへ表示する上位機能は原則一段先まで。

Gray-out seatに上位Gradeの実処理を隠して搭載するのではなく、UI shellのみ。

---

19. Standard — Format

StandardはDesign Formatを1個保存可能。

Formatは完成発行物そのものではなく、再利用可能なDesign template。

保存対象例：

Paper、Base、Preset、BOX位置、Font、Frame、Component placement、Guide等。

保存しないもの：

実際のUser Name、発行済みCounter値、Timestamp値、Serial値等。

操作は最初は、

Save / Load / Overwrite

程度。

内部Storageは将来複数Formatへ拡張できる構造にするが、Standardの作成可能数は1。

---

20. Standard — My Parts / Working Copy

Standardでは部品再利用を可能にする。

My Parts

自作したFrame等のComponent definition / presetを永続保存し、後から再利用。

Working Copy / Paste

現在の編集作業中だけ使える簡易Clipboard。

OS Clipboardではない。

最初はSame-type Pasteを基本とする。

Frame → Frame
Text Box → Text Box
Image Frame → Image Frame

など。

Runtime valueそのものはCopy対象にしない。

---

21. Refillの意味

Counter RefillとPDF Refillは価値が違う。

Counter Refillは実弾。

PDF Refillは、一度完成したPDF Designを壊さず保管しておく場所。

新しいPDFを作るたびに既存Designを上書きする必要をなくす。

PDF Refillが守るのは単なる空き番号ではなく、

そこへ投入した制作時間・完成状態そのもの。

したがってPDF RefillはCounter Refillより高価な商品帯とする。

---

22. Binder / Refill assignment

PDF側で、

「このPDFは、このBinderの、このRefillで扱う」

を選択する。

Binder / RefillはPDFの住所。

一つのBinder + Refill slotを複数PDFが同時占有しない。

選択▼では既に使用されているRefillを、

• Gray-out
• 使用中Mark

等で視覚的に分かるようにする。

禁止Cursorや警告Dialogで怒らない。

将来Binder classにSearchが実装された場合、

PDFいくつで使用中

等の情報を検索結果へ出せるよう、最初から逆引き可能なAssignment dataを保持する。

Binder側がPDF Design内部を管理する必要はない。

持つのは所属 / 占有情報だけ。

---

23. PDF Refill — Free

Freeは、

Base / Included PDF ×1

を最初から持つ。

追加販売するFree Refillは、

+5 の1商品だけ。

Freeの通常最大は、

Base 1 + Refill 5 = 6 PDF Designs

Freeで+1 / +10 / +15等は販売しない。

Free Refillは比較的安価にする。

---

24. Free → Standard Refill migration

Freeで購入したRefill 5は、StandardへUpgradeした際に無駄にならない。

Free Refill → Standard Refillへそのまま追従・昇格。

買い直し不要。

Designも壊さない。

さらにStandardへのUpgrade時にはStandard側のIncluded Refill 5が付く。

したがって、

Freeで5購入済み
↓
StandardへUpgrade
↓
Freeから追従5 + Standard付属5
↓
Standard Refill 10からStart

となる。

Base +1は別枠。

---

25. PDF Refill — Standard

Standardの通常Refill上限：

20

Base +1はRefill数へ含めない。

したがって最大保管Design数は、

Base 1 + Refill 20 = 21

Standard Refill購入Line：

+1 / +5 / +10 / +15

+1は割高。

Bundleほど1枠あたり価格を下げられる。

例：

Freeで5購入
↓
StandardへUpgrade
↓
追従5 + Included5 = 10
↓
Standard +10購入
↓
20 / 20

で綺麗に満タン。

---

26. Attic — 屋根裏部屋

通常の商品仕様ではない。

購入事故救済専用の隠しOverflow保管領域。

表では宣伝しない。

マニュアルにも、

「Standardで20個埋めてから+5買えばCreative用に貯金できます★」

などとは書かないｗｗｗ

Standard上限20を超える購入状態が発生した場合のみ作動。

例：

Standard Refill 10所有
↓
+15購入
↓
所有25
↓
StandardでActiveにできるのは20
↓
余った5をAtticへLock保管

Attic上限は、

絶対に5。

0〜5以外の巨大なOverflow管理システムにしない。

Attic中のDesign / Refillは、

• 消さない
• 上書きしない
• 通常利用不可
• 編集不可
• 条件を満たす上位Gradeまで安全に保管

とする。

Creativeで利用可能条件を満たした際に通常枠へ戻す。

---

27. Atticの裏技利用

Atticは事故救済なので、通常機能として案内しない。

ただし仕組みを理解したユーザーが、

Standard 20/20
↓
さらに+5購入
↓
Atticへ5個保管

を意図的に行ったとしても、特別な防止処理は作らない。

事故か故意かを判定する必要もない。

「知っててやったなｗ まあCreativeの手付金だと思っとく（笑）」

で黙認。

ただしAttic上限5は絶対に変えない。

公認しない。宣伝しない。塞ぐための余計なコードも書かない。

---

28. Refill内部モデル

商品上、

Owned capacity

と

Active tier capacity

を分離して考える。

たとえば、

owned = 25
Standard active limit = 20
Attic locked = 5

という状態を許容する。

Upgrade時にRefillを再発行したりDesignを移し替えたりするのではなく、可能なら既存所有枠の利用権限が解錠される形を優先する。

---

29. Existing Counter Refillから部品取りする

現物として、

Kaia Counter Free本体
Kaia Counter Refill Free +3

が手元にある。

PDF Refillをゼロから発明しない。

既存Counter Refillから、

• 本体へのRefill権利配送
• 購入物の認識
• Optionへの権利反映
• 二重付与防止
• Delivery receipt
• 配送Plugin自身の役割終了

等、Kaiaですでに使っている成熟した構造を抽出する。

ただしCounter固有の、

• 発行弾数
• +3固定
• Counter固有状態
• 空状態条件

等は移植しない。

構造を抜く。Counterロジックは抜かない。

PDF固有部分として、

• Design slot
• Binder / Refill assignment
• Grade capacity
• Attic

を追加する。

---

30. 技術選択の原則

Kaia PDFでは新しい技術を使うこと自体を目的にしない。

使い古されていて、挙動が分かっていて、保守しやすい技術を優先。

新Frameworkや巨大Dependencyを安易に入れない。

WordPress / PHP / Browser更新に対して壊れにくく、買い切り製品として長期間維持しやすい構造を優先する。

人間側の仕様を少し切るだけで実装・テスト・事故面積が大きく減る場合は、Kaia側から早めに相談する。

---

31. 現時点でのTierイメージ

最終的な大枠はこれ。

Free
「PDFとして困らないための最低限。」

Standard
「用意された工房の中なら、かなり自由。」

Creative
「自分の材料を工房へ持ち込める。」

そして将来のAdvancedは、Creativeよりさらに重い制作・管理領域を受け持つ候補。

フルシート台紙持ち込み、任意Paper size、多Format管理等は、その境界を見ながら後で決める。

---

次に実装へ持っていくときの順序

ここからはこのログを親にして、

Freeで本当に必要なControlだけ抽出
→ Standardで解放するControlを重ねる
→ Counter Free / Counter Refill / Timestamp / Serialの現物から既存構造を対応付ける
→ PDF FreeのClean skeleton
→ 最小PDF生成
→ Editor機能を一個ずつ追加

で進めればいい。

Creativeは今は**「Standard画面に一段先の灰色の席を置くために必要な境界」まで**見ておいて、中身は作らない。

これで今日までのやつ、かなり一枚にまとまったと思うｗ
特に今回で、紙・Workspace・画像Mask・Grade・Refill・屋根裏まで全部同じ「壊さない」思想で繋がった。

---

Working note

• Consolidated current Kaia PDF Free/Standard design state into one implementation-reference log.
• Primary philosophy across document editing and product ownership is non-destructive preservation.
• Existing Counter/Refill implementations remain the structural reference before new code is written.
• Creative is currently a boundary/seat-planning target, not an implementation target.
• Attic remains hidden, fixed at five, and strictly an exceptional safety mechanism.

相談あり：なし。次はこのログを親紙にしてFree/Standardの実装仕様へ削っていける。