Skill detail

slide-craft

The design law of a slide page — canvas geometry, the text height table, the type scale, contrast pairs, spacing rhythm, and which element type carries which content. Load it when patching slide elements one at a time, when a fix is about colour or contrast, when text has to grow or shrink inside a box, when a page feels crowded or empty, or when replacement content needs real rich-text structure. It is the standard `page-clone` and `pro-editing` edit against, not a procedure of its own — those two decide which pages to touch and in what order, this one decides what a good page looks like when

Why we recommend it: Design law for slide pages covering canvas geometry, text height tables, type scale, contrast, spacing rhythm, and element-to-content mapping.

MatchDirectRecommended for HTML Presentation
SourceTHU-MAIC/​OpenMAICExternal source
Reported installsNot reportedPopularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: slide-craft
title: "页面设计"
description: The design law of a slide page — canvas geometry, the text height table, the type scale, contrast pairs, spacing rhythm, and which element type carries which content. Load it when patching slide elements one at a time, when a fix is about colour or contrast, when text has to grow or shrink inside a box, when a page feels crowded or empty, or when replacement content needs real rich-text structure. It is the standard `page-clone` and `pro-editing` edit against, not a procedure of its own — those two decide which pages to touch and in what order, this one decides what a good page looks like when you put it back.
---

# The design law of a slide page

Every slide in this runtime was drawn under a long set of rules — the canvas,
the height table, the type scale, the spacing standards. The generator that
drew the page had all of them in front of it. When you patch one element, you
have the page's numbers and nothing else, and the rules are the only way to
tell a repair from a dent.

This is that rule set, restated for editing. It is about the page, not the
process: which numbers a change has to stay consistent with, and which fields
actually reach the screen.

## The canvas you are editing inside

The canvas is **1000 × 562.5**. All elements respect a **50px margin**, so the
live area is `left ∈ [50, 950]`, `top ∈ [50, 512.5]`, and an element's right
edge (`left + width`) stays ≤ 950, its bottom edge ≤ 512.5.

The page's own alignment grid, which existing elements are already on:

- Left-aligned content sits at `left = 60` or `left = 80`.
- Centred content is `left = (1000 - width) / 2` — recomputed, never guessed.
- Right-aligned content is `left = 1000 - width - 60`.

Changing `width` on centred content changes `left` too, and they are two separate
writes. Read the neighbours' boxes first and land on the column they are already
using; a lone element 8px off the shared left edge reads as a mistake even though
nothing overflows.

**There is no alignment operation.** Every position is an explicit number you
write to that element's own `left` / `top` / `width` / `height`, one path per call,
computed from the neighbours you read. Aligning a row means giving each element the
number the row already uses — not asking the page to tidy itself.

## Text is sized by table, not by eye

A text element has **10px padding on all four sides**, so its usable area is
`(width - 20) × (height - 20)`, and heights come from one table
(line-height 1.5, padding included):

| Font size | 1 line | 2 lines | 3 lines | 4 lines | 5 lines |
| --------- | ------ | ------- | ------- | ------- | ------- |
| 14px      | 43     | 64      | 85      | 106     | 127     |
| 16px      | 46     | 70      | 94      | 118     | 142     |
| 18px      | 49     | 76      | 103     | 130     | 157     |
| 20px      | 52     | 82      | 112     | 142     | 172     |
| 24px      | 58     | 94      | 130     | 166     | 202     |
| 28px      | 64     | 106     | 148     | 190     | 232     |
| 32px      | 70     | 118     | 166     | 214     | 262     |
| 36px      | 76     | 130     | 184     | 238     | 292     |

When you replace an element's words, re-derive its height instead of keeping
the old one:

1. `characters_per_line = (width - 20) / font_size`. Keep the longest line at
   **≤ 75%** of that; past 100% the text wraps and takes a row you did not
   budget.
2. Count the lines your new content needs — one per `<p>`, plus a wrap for
   every paragraph over `characters_per_line` — then add ~0.8 of a line of
   slack and round up.
3. Look the height up against the **largest font size present in the
   content**, not the average.

Height is a container, not a clamp: overflowing text spills past the box
rather than shrinking, and the page shows the spill. The fix order is
**shorten the words, then step to the next table row, then widen the box** —
in that order, because a slide that needs a bigger box usually needs fewer
words.
Read the full source on GitHub (opens external page)
Context

Related work