domotion-svg 0.13.2 → 0.14.0

package/dist/animation/animator.js

@@ -273,6 +273,11 @@ export function generateAnimatedSvg(config) {
         const enterStartPct = entersViaOverlap
             ? pct(timeOffset - prevTransDur, totalDuration)
             : startPct;
+        // DM-1207: the last frame holds solid to 100% (no loop cross-dissolve)
+        // unless `loopFade` is set — same rule the crossfade/cut path applies via
+        // DM-1148 (see emitCrossfadeOrCutFrame). For the slide paths (push-left /
+        // scroll) this means: slide in, then hold (no slide-out / fade-out).
+        const holdLastFrame = i === frames.length - 1 && config.loopFade !== true;
         if (transType === "push-left") {
             // Push: slide in from right, slide out to left
             frameGroups.push(`  <g class="f f-${i}"><clipPath id="fc-${i}"><rect width="${width}" height="${height}" /></clipPath><g clip-path="url(#fc-${i})" class="fp fp-${i}">\n${frame.svgContent}\n  </g></g>`);
@@ -282,7 +287,7 @@ export function generateAnimatedSvg(config) {
             // Window is [enterStartPct .. transEndPct] (when the slide has fully
             // exited the viewBox); 0.01% pad on each side keeps the snap inside the
             // existing opacity:0 bookend.
-            keyframes.push(slideKeyframes(i, "X", width, entersViaPush, enterStartPct, startPct, holdEndPct, transEndPct, enterStartPct, transEndPct, totalSec));
+            keyframes.push(slideKeyframes(i, "X", width, entersViaPush, enterStartPct, startPct, holdEndPct, transEndPct, enterStartPct, transEndPct, totalSec, holdLastFrame));
         }
         else if (transType === "scroll") {
             // DM-609: `scroll` now means real geometric scroll between two frames
@@ -294,7 +299,7 @@ export function generateAnimatedSvg(config) {
             // `fd-${i}` display animation). (`entersViaScroll` is already computed in
             // the outer scope above — same value, no need to redeclare/shadow it.)
             frameGroups.push(`  <g class="f f-${i}"><clipPath id="fc-${i}"><rect width="${width}" height="${height}" /></clipPath><g clip-path="url(#fc-${i})" class="fp fp-${i}">\n${frame.svgContent}\n  </g></g>`);
-            keyframes.push(slideKeyframes(i, "Y", height, entersViaScroll, enterStartPct, startPct, holdEndPct, transEndPct, enterStartPct, transEndPct, totalSec));
+            keyframes.push(slideKeyframes(i, "Y", height, entersViaScroll, enterStartPct, startPct, holdEndPct, transEndPct, enterStartPct, transEndPct, totalSec, holdLastFrame));
         }
         else if (transType === "magic-move" && frame.magicMove != null) {
             // DM-898: magic-move. Frame i holds [start..holdEnd] then HARD-CUTS out;
@@ -444,6 +449,14 @@ function renderTypingOverlay(overlay, frameIdx, frameStart, frameEnd, totalDurat
     const speed = overlay.speed ?? 60;
     const fontSize = overlay.fontSize ?? 14;
     const charWidth = fontSize * 0.6; // monospace cell (overlay font is monospace)
+    // DM-1205: the typewriter reveal hides not-yet-typed text with a width-0 clip
+    // rect. Chrome renders a zero-area clip path as "clip everything" (text
+    // hidden, correct), but WebKit/Safari treats an EMPTY clip as "no clip" and
+    // paints the element in full — so on multi-line overlays every line past the
+    // first showed its whole text immediately (the shared text opacity is already
+    // 1 while the line waits its turn). Hiding with a tiny non-zero width keeps
+    // the clip non-empty so WebKit clips it too; 0.01px reveals no visible pixel.
+    const hiddenW = "0.01px";
     const lineHeight = Math.round(fontSize * 1.35);
     const color = overlay.color ?? "#e6edf3";
     const typeStartMs = frameStart + delay;
@@ -512,7 +525,7 @@ function renderTypingOverlay(overlay, frameIdx, frameStart, frameEnd, totalDurat
         const lineEndPct = pct(lineEndMs, totalDuration);
         lineTimings.push({ li, startMs: lineStartMs, endMs: lineEndMs, len: line.length });
         cumChars += line.length;
-        parts.push(`  <defs><clipPath id="${clipId}"><rect class="${id}-rev${li}" x="${overlay.x}" y="${lineY - fontSize}" width="0" height="${textHeight}" /></clipPath></defs>`);
+        parts.push(`  <defs><clipPath id="${clipId}"><rect class="${id}-rev${li}" x="${overlay.x}" y="${lineY - fontSize}" width="${hiddenW}" height="${textHeight}" /></clipPath></defs>`);
         parts.push(`  <text class="${id}-text" x="${overlay.x}" y="${lineY}" fill="${color}" font-size="${fontSize}" font-family="'SF Mono', Menlo, Monaco, monospace" clip-path="url(#${clipId})">${escapeHtml(line)}</text>`);
         // DM-1204: the reveal clip MUST sweep linearly so its right edge tracks the
         // caret (whose position track is `linear`). Without an explicit timing
@@ -520,8 +533,10 @@ function renderTypingOverlay(overlay, frameIdx, frameStart, frameEnd, totalDurat
         // through the sweep at the time-midpoint while the linear caret is only at
         // 50% — that desync read as the caret lagging ~10–20 chars behind the
         // revealed text mid-type, even though the endpoints (parked state) matched.
+        // DM-1205: the hidden state uses `hiddenW` (a tiny non-zero width), not 0,
+        // so WebKit's empty-clip-path fallback doesn't paint the whole line.
         cssRules.push(`
-    @keyframes ${id}-rev${li} { 0%, ${lineStartPct} { width: 0; } ${lineEndPct} { width: ${lineWidth}px; } ${holdEndPct} { width: ${lineWidth}px; } ${disappearPct}, 100% { width: 0; } }
+    @keyframes ${id}-rev${li} { 0%, ${lineStartPct} { width: ${hiddenW}; } ${lineEndPct} { width: ${lineWidth}px; } ${holdEndPct} { width: ${lineWidth}px; } ${disappearPct}, 100% { width: ${hiddenW}; } }
     .${id}-rev${li} { animation: ${id}-rev${li} ${totalSec.toFixed(2)}s linear infinite; }`);
     });
     // Whole-overlay visibility — shared by every line's <text>.
@@ -676,17 +691,39 @@ function buildDisplayKeyframes(name, visibleStartPct, visibleEndPct) {
  * exits to `-size`. 0.1% pads on each bookend keep the snap inside the
  * opacity:0 frame. Emits the fp/fv/fd keyframes + the `.f-`/`.fp-` rules.
  */
-function slideKeyframes(i, axis, size, entersSliding, enterStartPct, startPct, holdEndPct, transEndPct, visStart, visEnd, totalSec) {
+function slideKeyframes(i, axis, size, entersSliding, enterStartPct, startPct, holdEndPct, transEndPct, visStart, visEnd, totalSec, 
+/** DM-1207: the last frame, when the loop must NOT cross-dissolve, slides in
+ *  and then HOLDS solid (transform 0, opacity 1, visible) to 100% — no
+ *  slide-out / fade-out — and the loop hard-cuts back to frame 0. Mirrors the
+ *  crossfade/cut path's DM-1148 holdToEnd. Without it the slide-out keyframes
+ *  ramp the last frame to opacity 0 across its whole hold, washing it out. */
+holdToEnd = false) {
+    const enterBound = padBefore(parseFloat(enterStartPct), KEYFRAME_EPSILON.slide, 2);
+    if (holdToEnd) {
+        return `
+    @keyframes fp-${i} {
+      0%, ${enterBound}% { transform: translate${axis}(${entersSliding ? size : 0}px); }
+      ${startPct} { transform: translate${axis}(0); }
+      100% { transform: translate${axis}(0); }
+    }
+    @keyframes fv-${i} {
+      0%, ${enterBound}% { opacity: 0; }
+      ${enterStartPct} { opacity: 1; }
+      100% { opacity: 1; }
+    }${buildDisplayKeyframes(`fd-${i}`, visStart, "100")}
+    .f-${i} { animation: fv-${i} ${totalSec.toFixed(2)}s infinite, fd-${i} ${totalSec.toFixed(2)}s infinite step-end; }
+    .fp-${i} { animation: fp-${i} ${totalSec.toFixed(2)}s infinite; }`;
+    }
     return `
     @keyframes fp-${i} {
-      0%, ${padBefore(parseFloat(enterStartPct), KEYFRAME_EPSILON.slide, 2)}% { transform: translate${axis}(${entersSliding ? size : 0}px); }
+      0%, ${enterBound}% { transform: translate${axis}(${entersSliding ? size : 0}px); }
       ${startPct} { transform: translate${axis}(0); }
       ${holdEndPct} { transform: translate${axis}(0); }
       ${transEndPct} { transform: translate${axis}(-${size}px); }
       ${padAfter(parseFloat(transEndPct), KEYFRAME_EPSILON.slide, 2)}%, 100% { transform: translate${axis}(-${size}px); }
     }
     @keyframes fv-${i} {
-      0%, ${padBefore(parseFloat(enterStartPct), KEYFRAME_EPSILON.slide, 2)}% { opacity: 0; }
+      0%, ${enterBound}% { opacity: 0; }
       ${enterStartPct} { opacity: 1; }
       ${transEndPct} { opacity: 1; }
       ${padAfter(parseFloat(transEndPct), KEYFRAME_EPSILON.slide, 2)}%, 100% { opacity: 0; }

package/dist/capture/emoji.d.ts

@@ -17,6 +17,43 @@
  */
 import type { Page } from "@playwright/test";
 import type { CapturedElement } from "./types.js";
+/**
+ * Snap an Apple Color Emoji sbix bitmap to the SQUARE box Chrome actually
+ * paints it in.
+ *
+ * Chrome paints a color-emoji glyph as a square whose side equals the glyph
+ * ADVANCE — the captured `Range.getBoundingClientRect()` width, minus any
+ * letter-spacing Chrome appends to the right of the advance. Two facts make
+ * the advance (not the font size) the correct side:
+ *  - At small font sizes Chrome enforces a minimum emoji advance that exceeds
+ *    the font size — e.g. a 20px advance at font-size 16 (~1.25×). Sizing the
+ *    overlay to the font size painted the emoji ~20% too small (DM-1198: "our
+ *    emojis seem a lot smaller").
+ *  - The sbix PNG is a full square bitmap (the emoji fills a square em), so
+ *    drawing it into an advance × advance box reproduces both full-bleed emoji
+ *    and ones with transparent margins (e.g. 📈) without distortion.
+ *
+ * Geometry:
+ *  - Horizontal: the bitmap sits flush at the advance's left (`rect.x`); any
+ *    letter-spacing pads to the RIGHT, so no horizontal shift is applied
+ *    (DM-919 — the original DM-381 centering pass wrongly shifted it right
+ *    whenever letter-spacing > 0).
+ *  - Vertical: the square is centered in the captured rect's line box, which
+ *    matches Chrome within ~1px across sizes (DM-438 — a 20×17 rect extends
+ *    upward to a 20×20 square; DM-801 — a 56×63 rect with 8px letter-spacing
+ *    snaps to 48×48).
+ */
+export declare function emojiSquareRect(rect: {
+    x: number;
+    y: number;
+    width: number;
+    height: number;
+}, letterSpacing: number): {
+    x: number;
+    y: number;
+    width: number;
+    height: number;
+};
 /**
  * For every text segment CAPTURE_SCRIPT flagged with a rasterRect (contains a
  * color-bitmap glyph like U+2713 ✓ or an emoji), ask Playwright for a

package/dist/capture/emoji.js

@@ -97,6 +97,42 @@ function extractEmojiBitmap(codepoint, paintedWidthPx) {
     _sbixCache.set(cacheKey, result);
     return result;
 }
+/**
+ * Snap an Apple Color Emoji sbix bitmap to the SQUARE box Chrome actually
+ * paints it in.
+ *
+ * Chrome paints a color-emoji glyph as a square whose side equals the glyph
+ * ADVANCE — the captured `Range.getBoundingClientRect()` width, minus any
+ * letter-spacing Chrome appends to the right of the advance. Two facts make
+ * the advance (not the font size) the correct side:
+ *  - At small font sizes Chrome enforces a minimum emoji advance that exceeds
+ *    the font size — e.g. a 20px advance at font-size 16 (~1.25×). Sizing the
+ *    overlay to the font size painted the emoji ~20% too small (DM-1198: "our
+ *    emojis seem a lot smaller").
+ *  - The sbix PNG is a full square bitmap (the emoji fills a square em), so
+ *    drawing it into an advance × advance box reproduces both full-bleed emoji
+ *    and ones with transparent margins (e.g. 📈) without distortion.
+ *
+ * Geometry:
+ *  - Horizontal: the bitmap sits flush at the advance's left (`rect.x`); any
+ *    letter-spacing pads to the RIGHT, so no horizontal shift is applied
+ *    (DM-919 — the original DM-381 centering pass wrongly shifted it right
+ *    whenever letter-spacing > 0).
+ *  - Vertical: the square is centered in the captured rect's line box, which
+ *    matches Chrome within ~1px across sizes (DM-438 — a 20×17 rect extends
+ *    upward to a 20×20 square; DM-801 — a 56×63 rect with 8px letter-spacing
+ *    snaps to 48×48).
+ */
+export function emojiSquareRect(rect, letterSpacing) {
+    const ls = Math.max(0, letterSpacing) || 0;
+    const side = Math.max(1, rect.width - ls);
+    return {
+        x: rect.x,
+        y: rect.y + (rect.height - side) / 2,
+        width: side,
+        height: side,
+    };
+}
 /**
  * For every text segment CAPTURE_SCRIPT flagged with a rasterRect (contains a
  * color-bitmap glyph like U+2713 ✓ or an emoji), ask Playwright for a
@@ -178,28 +214,12 @@ export async function rasterizeBitmapGlyphs(page, tree, viewport) {
                                     // isn't carried on the segment (only the SVG path needs it,
                                     // not the existing screenshot path which already round-trips
                                     // a rectangular PNG).
-                                    const elFs = parseFloat(el.styles.fontSize ?? "") || 0;
-                                    const fs = seg.fontSize ?? (elFs > 0 ? elFs : Math.max(g.rect.width, g.rect.height));
-                                    // DM-919: Chrome's per-emoji paint origin = advance start
-                                    // (rect.x) when there's NO letter-spacing — the bitmap
-                                    // sits flush at the left of the advance. When letter-
-                                    // spacing > 0, Chrome ADDS the letter-spacing to the
-                                    // advance, which captures as a wider rect — the bitmap
-                                    // is still at rect.x (the spacing pads to the right).
-                                    // The original DM-381 centering pass mis-handled this:
-                                    // it shifted the bitmap by `(rect.width - fs) / 2`,
-                                    // moving the emoji right whenever letter-spacing >0.
-                                    // Pull out the captured letter-spacing and subtract it
-                                    // from rect.width FIRST, then center the bitmap inside
-                                    // the REAL advance — handles both the centered emoji-
-                                    // alone case (where rect.w ≈ fs) and the letter-spaced
-                                    // case (where rect.w = fs + letter-spacing).
                                     const ls = parseFloat(el.styles.letterSpacing ?? "") || 0;
-                                    const advanceW = Math.max(fs, g.rect.width - Math.max(0, ls));
-                                    g.rect.x += (advanceW - fs) / 2;
-                                    g.rect.y += (g.rect.height - fs) / 2;
-                                    g.rect.width = fs;
-                                    g.rect.height = fs;
+                                    const sq = emojiSquareRect(g.rect, ls);
+                                    g.rect.x = sq.x;
+                                    g.rect.y = sq.y;
+                                    g.rect.width = sq.width;
+                                    g.rect.height = sq.height;
                                     continue;
                                 }
                             }

package/dist/capture/script/dotted-circle-detect.js

@@ -57,13 +57,20 @@ export const createDottedCircleDetect = () => {
         }
         return { cnt, w: cnt > 0 ? (maxx - minx + 1) : 0 };
     };
-    // Does Chrome auto-insert a U+25CC before this lone mark in `font`?
+    // Does Chrome auto-insert a U+25CC before this lone mark/cluster-letter in
+    // `font`? Probes category M (combining marks), category Lo (some Brahmic
+    // cluster-initial LETTERS — e.g. Soyombo U+11A84) AND category Lm (modifier
+    // LETTERS the Universal Shaping Engine also circles when orphaned — e.g. Kirat
+    // Rai U+16D6B/6C, length / vowel modifiers that paint "◌ □" when stranded).
+    // The ink heuristic below is the real gate (a normal letter renders WITHOUT a
+    // circle, so bare ≠ comb → false), so including Lo / Lm only widens what's
+    // probed, never forces a false positive.
     const markGetsDottedCircle = (cp, ch, font) => {
         if (cp < 0x0900)
             return false;
         if (font == null || font === '')
             return false;
-        if (!/\p{M}/u.test(ch))
+        if (!/\p{M}|\p{Lo}|\p{Lm}/u.test(ch))
             return false;
         const key = cp + '|' + font;
         const hit = _cache.get(key);

package/dist/capture/script/emoji-detect.js

@@ -30,11 +30,20 @@ export const createEmojiDetect = () => {
         // painting as a dropped/empty path-mode glyph: ✅ ✊ ✋. Unconditional like
         // the ✨ ❌ ➡ family above — emoji presentation wins over the cascade.
         0x2705, 0x270A, 0x270B,
-        // DM-728: U+2B?? "Miscellaneous Symbols and Arrows" block with default
-        // emoji presentation per Unicode emoji-data — Chrome paints these as
-        // Apple Color Emoji glyphs without needing the U+FE0F variation
-        // selector. The fixture's ⭐ U+2B50 in `20-deep-font-palette.html` was
-        // painting as a hollow tofu before this list was extended.
+    ]);
+    // DM-1165: the Miscellaneous Symbols and Arrows (U+2B??) code points with
+    // default emoji presentation — ⬅⬆⬇ (2B05-07), ⬛⬜ (2B1B/1C), ⭐ (2B50),
+    // ⭕ (2B55). DM-728 added these to `rasterCps` unconditionally for the ⭐ in
+    // `20-deep-font-palette.html`, but Chrome's choice is actually CASCADE-
+    // DEPENDENT: when the element's font stack reaches a monochrome symbol/math
+    // font that covers them first, Chrome paints text, not color. Verified via
+    // `CSS.getPlatformFontsForNode` on the 2B00 fixture (cells lead with "Apple
+    // Symbols"): 2B05→Apple Symbols, 2B1B & 2B50→STIX Two Math — all MONOCHROME,
+    // so the unconditional raster was stamping blue emoji / a yellow star over
+    // Chrome's black arrows / hollow star. Probe per-element via `isColorGlyph`
+    // in `needsRaster` instead (color → raster, monochrome → path). A Set so the
+    // membership test in `needsRaster` is O(1).
+    const emojiPresentation2B = new Set([
         0x2B05, 0x2B06, 0x2B07, 0x2B1B, 0x2B1C, 0x2B50, 0x2B55,
     ]);
     // Codepoints in the U+2600-26FF Misc Symbols block with EmojiPresentation=Yes
@@ -200,6 +209,43 @@ export const createEmojiDetect = () => {
         // cascade DOES reach the color font still rasters correctly.
         if (cp >= 0x1F700 && cp <= 0x1F77F)
             return isColorGlyph(cp, font);
+        // DM-1168: the two Emoji_Presentation=Yes code points in the Enclosed CJK
+        // Letters and Months block (U+3200-32FF) — ㊗ U+3297 CIRCLED IDEOGRAPH
+        // CONGRATULATION and ㊙ U+3299 CIRCLED IDEOGRAPH SECRET. Chrome paints them
+        // as Apple Color Emoji by default (the fixture cells show the red circled
+        // ideographs). But several macOS text fonts (Hiragino, Arial Unicode) also
+        // cover them with a MONOCHROME glyph, so a `lang=ja` cascade that reaches
+        // Hiragino first paints text, not color. Probe Chrome's actual per-element
+        // choice via the canvas (color → raster, monochrome → path), exactly like
+        // the DM-1025 emojiPresentation26 / DM-1125 alchemical branches.
+        if (cp === 0x3297 || cp === 0x3299)
+            return isColorGlyph(cp, font);
+        // DM-1173: 〽 U+303D PART ALTERNATION MARK (CJK Symbols and Punctuation,
+        // U+3000-303F). Emoji=Yes but text-default presentation, so Chrome paints
+        // the color glyph only when the cascade reaches Apple Color Emoji and no
+        // text font covers it first (many do — Hiragino, M+ 1p, Shippori Mincho).
+        // The fixture cell paints the orange color mark, so probe per-element font
+        // (color → raster, monochrome → path) like the branches above.
+        if (cp === 0x303D)
+            return isColorGlyph(cp, font);
+        // DM-1165: the U+2B?? emoji-presentation symbols (arrows ⬅⬆⬇, squares ⬛⬜,
+        // ⭐, ⭕). Cascade-dependent — Chrome paints text when the stack reaches a
+        // monochrome symbol/math font first (Apple Symbols / STIX Two Math), color
+        // otherwise. See `emojiPresentation2B` above.
+        if (emojiPresentation2B.has(cp))
+            return isColorGlyph(cp, font);
+        // DM-1167: the ONLY two codepoints in the Misc Symbols & Pictographs block
+        // (U+1F300-1F5FF) that a macOS text font also covers monochrome are
+        // 🌐 U+1F310 (GLOBE WITH MERIDIANS) and 🎤 U+1F3A4 (MICROPHONE) — Apple
+        // Symbols carries both. When the element's cascade leads with Apple Symbols
+        // (the html-test `.f1` cells do; CSS.getPlatformFontsForNode confirms),
+        // Chrome paints the MONOCHROME path glyph, not the color emoji. Probe
+        // Chrome's actual per-element choice (color → raster, monochrome → path)
+        // exactly like the DM-1125 Alchemical / DM-1168 ㊗㊙ branches, instead of
+        // unconditionally stamping the Apple Color Emoji bitmap over Chrome's text
+        // glyph. The common Apple-Color-Emoji-first cell still rasters (probe → true).
+        if (cp === 0x1F310 || cp === 0x1F3A4)
+            return isColorGlyph(cp, font);
         // Main emoji blocks: Misc Symbols & Pictographs, Emoticons, Transport &
         // Map, Alchemical, Supplemental Symbols & Pictographs, Pictographs
         // Extended-A, Symbols & Pictographs Extended-B.