Pen Lettering

This Pen captures the current understanding of the letter-based message display system for Intake. It is not the final renderer. It is the present doctrine: the observed control model, the intended object hierarchy, and the first practical rendering strategy.

Purpose

The message displayer is treated as a transparent, parent-bound lettering layer that lives above a moving video base. Each displayed character is not ordinary text. Each character is a visual object that samples the moving image beneath it and expresses a sense of buriedness through opacity and masking.

Core Observations

• The displayer should bind to window, parent, and especially Parental as its exchange anchor.
• It should not depend on Parentop for normal message-display authority.
• The child learns its identity through the fvent lane using Parental.qaram and Parental.dommand.
• The root display object is a named branch such as Parental.DispA.
• Ordinal character objects such as Parental.DispA09 hold character-specific rendering properties.
• The whole message string belongs at the group root, for example Parental.DispA.text.
• Group-level influences such as opacity belong at the group root, for example Parental.DispA.opacity.

Identity Binding

The parent establishes a one-to-one relationship with the displayer through the fvent lane. The child drains that lane and learns which named branch of Parental belongs to it.

Parental.qaram = "DispA";
Parental.dommand = "Start";

var cmd = Parental("fvent");
if (cmd === "Start" && Parental.qaram === "DispA") {
  myId = "DispA";
}

Once the displayer knows it is DispA, it understands that its root branch is Parental.DispA and its ordinated children will be Parental.DispA01, Parental.DispA02, and so on.

Hierarchical Control Model

The root object carries the truth of the whole message. The ordinal children specialize individual letters. This keeps shared concerns at the group level and character-specific concerns at the leaf level.

Parental.DispA = {
  id: "DispA",
  text: "WELCOME HOME",
  opacity: 0.62,
  state: "Active",
  count: 12
};

Parental.DispA09 = {
  index: 9,
  text: "H",
  mode: "bitmap",
  font: "WeatheredRomanA",
  opacityLocal: 0.88
};

Letter Object Model

Each visible character is a composite object with two principal visual layers:

• a bitmap glyph image, usually a weathered or artist-designed raster source
• a canvas overlay above the image, used to sample and clip moving video content

<div class="glyph">
  <img id="MsgD09" src="glyphs/H.png" alt="" />
  <canvas id="MsgC09"></canvas>
</div>

The image defines the visible glyph form. The canvas receives copied video pixels and is clipped to the glyph fill. The opacity of that canvas is used as the depth or buriedness signal.

Video Mixing Strategy

The parent page carries the base video layer. The displayer iframe remains transparent and occupies only the message region. Each glyph canvas samples the shared base video and applies a clipping operation so that moving content is visible only inside the bounds of the glyph.

ctx.drawImage(video, sx, sy, sw, sh, 0, 0, cw, ch);
ctx.globalCompositeOperation = "destination-in";
ctx.drawImage(glyphImage, 0, 0, cw, ch);
canvas.style.opacity = effectiveOpacity;

For a first test, direct access to the parent video element through parent.document is the most practical route. Later versions may publish crop metadata or frame state through Parental.

Transparency and Overlap

The iframe background should remain transparent. The message region can be a rectangular overlay that sits above the normal beach/video layer. Glyph objects may overlap slightly according to simple bitmap kerning rules.

.message-root {
  position: absolute;
  inset: 0;
  background: transparent;
}

.glyph {
  position: absolute;
}

.glyph img,
.glyph canvas {
  position: absolute;
  inset: 0;
}

Kerning and Ordination

The first implementation should use normal, restrained kerning. Each letter uses a two-digit ordinal suffix, which is sufficient for a 10 to 15 character message. Ordination is part of the control strategy, not just a display convenience.

Parental.DispA01
Parental.DispA02
Parental.DispA03
...
Parental.DispA09
Parental.DispA10

Width can come from the glyph image itself. Position can be determined by cumulative advance plus an optional local adjustment field such as xAdjust.

Effective Opacity Model

Group-level and letter-level control should multiply cleanly so that the whole message can be softened or buried together while still permitting local variation.

effectiveOpacity =
  (Parental.DispA.opacity ?? 1) *
  (Parental.DispA09.opacityLocal ?? 1);

Short Test Display

The best first proof is a short word rather than a full sentence. A word such as WELCOME, INTAKE, or ASHORE is enough to prove:

• identity binding through fvent
• transparent iframe behavior
• ordinal child control
• video sampling inside glyphs
• buriedness through opacity

Current Strategy

• treat the displayer as a child state machine bound to Parental
• use a named root object such as DispA for the whole message
• use ordinated child objects for letter-specific control
• render letters as bitmap image plus canvas overlay
• sample parent video into each canvas and clip to glyph fill
• keep the first test small, transparent, and explicit

Scope Boundary

• the Reggie layer is not finalized here
• full stage choreography is not finalized here
• artist-scanned alphabet intake remains future work
• this is a doctrine Pen, not a production renderer

It does establish the current doctrine clearly enough for follow-on conversations to reason from the same anchor.