Templated-PPT-Master/references/visual-design.md

# Page mockups and visual materials

Reuse the user's settled template, theme, route and page workflow. Receive the current page's title/message, evidence, content groups and notes through [content handoff](content-handoff.md), then define its layout, asset roles and required native objects before generating its mockup. Establish a minimal page brief if none is supplied. Follow the confirmed [execution choices](execution-and-review.md), including ImageGen scope/budget and selected alternatives. Review only consequential decisions that remain open; do not restart settled outline, style or tool choices. A request to review one page does not authorize a full-deck generation run.

When extracting style from an existing presentation or PDF, render representative pages and inspect the actual images. XML/object counts alone cannot establish density, hierarchy, ornament or spacing. Keep style references separate from strict source assets. Use existing accepted references; a rejected mockup does not remain a design baseline.

## Rough layouts and confirmed preferences

For page-by-page work with ImageGen enabled, use an actual visual or actual render from the selected template and theme as the reference. Inspect it before generation. Make a rough layout with the main content elements approximately in their intended regions, retaining the fixed page UI as a reference; focus on grouping, hierarchy, reading order and the contribution-to-evidence relationship. Do not spend the layout-draft budget on fine detail or claim pixel correspondence with the final PPT.

Let the user review the current layout at the agreed granularity, incorporate feedback, then implement the authorized page. Later authorized pages reuse the confirmed ImageGen choice and budget; seeing each new layout is page review, not a repeated permission question. If ImageGen is declined or unavailable, use only the user's selected alternative or resolve that pending choice before dependent work. Do not silently switch to another generator, Agent arrangement or text-only plan.

Record confirmed feedback in existing project/page notes or review material: the preference, user confirmation, applicable page/report scope and reference image/source revision. Reuse it within that scope on subsequent authorized pages. A local change does not become a global rule; an ongoing preference needs explicit support. Do not create another preference database or write global memory. Keep rejected drafts distinguishable from accepted references.

The template/shared recipe supplies geometry, typography, fixed spacing and UI. For an approved mockup, the project may declare [controlled content-area adjustments](#controlled-adjustments-for-approved-mockups) rather than mechanically retain every preset number; fixed page UI and locked structures remain protected. Rebuild the actual page with supported native objects and check its reading order, capacity and visual evidence associations. Draft feedback does not establish final native rendering, editing or projection acceptance. Follow [review after revision](execution-and-review.md#review-after-revision) for the agreed independent check of substantive changes.

## Approved-mockup fidelity

An approved current-page mockup becomes the reconstruction reference. Rebuild it as faithfully as possible: preserve the accepted content, figure/image identities, graphics, relative arrangement, proportions, grouping, emphasis and relationships within the selected template's contracts. The draft's roughness permits necessary quality repair; it does not make its accepted elements optional.

As a rule, keep the established relative spatial relationships, visualization forms, icon identities and text styling. Preserve left/right and above/below order, proximity/grouping, connector endpoints, family intent, weight, color, emphasis, alignment and relative font-size hierarchy. Do not substitute a different chart/diagram form, redraw an icon in an unrelated style or move a label to another visual group for implementation convenience. Necessary fit and optical-alignment repairs below must retain these relationships and appearance; a substantive rearrangement or restyling needs the user's instruction.

Before reconstruction, inventory the accepted text and visual elements in existing page source/notes, including diagram nodes, links, arrows, braces, enclosures, legend items and labels. A shape that conveys grouping, containment, comparison, direction or a dependency is content. Do not drop it, replace it with an unrelated symbol or call it disposable decoration because native reconstruction is inconvenient. Preserve other accepted graphics too; an allowed picture exception must retain the element and disclose its object type.

Repair typography defects, verified-text spelling, wrapping, contrast, alignment, spacing, clipping and collisions as needed. Keep substantive text, values, groups and relationship meanings intact; do not solve a quality problem by removing an accepted paragraph, figure, graph element or connection. Keep the declared font families, with font sizes and shared content geometry adjusted under the rules below when useful; do not trace raster artifacts. If preserving the accepted content would require a substantive redesign or omission, present that specific change for the user's decision; ordinary quality repairs and these controlled adjustments need no repeated approval.

Compare the new full-page render with the approved sample and its inventory. Check for missing elements, changed endpoints, lost group boundaries and altered emphasis as well as appearance. Keep the accepted reference and relevant repairs in the project; do not replace the baseline with a later simplified draft without user instruction. Follow the agreed review assignment without creating a new review pipeline.

## Controlled adjustments for approved mockups

For faithful reconstruction of a user-approved mockup, adjust content-area font sizes, text/container dimensions, line/paragraph spacing, padding and necessary fit/alignment as needed for the actual native render. Template preset numbers are the starting point. Keep the accepted content, graphics, relationship-bearing shapes, relative spatial relationships, visualization forms, icon identities and text styling. Font-size adjustments serve accurate reconstruction and readable fit while retaining the sample's relative hierarchy; this is not a general redesign allowance. Fixed page UI, declared font families, brand assets and explicitly locked structures retain their contracts.

Use explicit units and regular discrete values for actively chosen design parameters. Prefer integers; where useful, select a consistent fixed step for each parameter class and unit, such as 0.5 pt or 0.25 pt. These are examples, not universal required steps. Font sizes and layout distances may use different steps. Apply the same rule to equivalent roles/components within the recorded scope; avoid unexplained multi-digit decimals and unrelated instance nudges. Derived equal distribution, proportional scaling, unit conversion, font metrics and curve/path calculations retain necessary precision. Evidence values and scientific geometry keep their source meaning and precision.

Keep adjusted roles/values in project-owned shared styles or layout recipes and make the real builder/renderers consume them. Record the approved reference, affected scope, units/steps and meaningful changes in existing project inputs/notes; include required style/recipe files in `build.inputs`, then lock and build. Keep the selected template snapshot, its lock and fixed UI intact. A shared content-area adjustment does not authorize editing installed or frozen template sources. Repeated containers use the same adjusted implementation; content callers still supply semantic content and whole-container placement, not internal spacing overrides. This is an authoring allowance, not a new automatically interpreted style-overlay schema: existing helpers keep their actual supported value types/modules and validation. Use a supported shared recipe and verify that its values are really applied.

After each typography or geometry adjustment, perform both levels of overflow review on the current rebuilt page:

| Level | Required checks |
|---|---|
| Text frame and content container | Verify measured/actual line widths and heights, wrapping, final lines, paragraph gaps and padding. All required text, formulas, labels, images and relationship shapes fit their intended usable bounds, with no clipping or unintended occlusion. A container remaining inside the page does not prove its contents fit. |
| Page and canvas | Verify complete visible groups, including container edges, arrowheads, connectors, image crops, strokes and effects, against the usable content region and page boundaries. Check collisions with fixed UI, neighboring groups and other content. A locally valid container does not prove the whole arrangement fits the page. |

Use source measurements and supported geometry/capacity checks, then inspect actual glyph/edge extents in the current full-page render at fit and normal presentation scale. Formula layout and native reflow may exceed nominal source boxes. Preserve explicitly intended crops or contacts, such as a template watermark, under their existing rules; do not count accidental content loss as intentional cropping. Repair the shared source/recipe, rebuild and inspect again, including affected pages when a shared style changes. Keep the accepted inventory and readable hierarchy; do not hide an overflow by deleting elements or shrinking substantive explanations into tiny text. Successful compilation or bounding-box equality alone does not complete this review. These checks use the existing page workflow and agreed review assignment without an extra approval round.

## Elements that need ImageGen

If an approved element is impractical or cumbersome to express faithfully with native components or SVG, use the host ImageGen tool to reconstruct that element as an independent material. Condition on the approved sample and relevant element references, preserving its visualization form, icon identity, style, proportions, details and relationship cues. Do not swap it for a simpler diagram, generic icon or different visual treatment. Native text, containers and connectors that are practical to reproduce remain separate; do not turn the whole page into a generated image.

Inspect local reference images before use. Give each input its actual role and constrain the edit/generation to the identified element. Request a transparent background and a monochrome or simple, clearly separated palette for generated materials, preserving the accepted shapes, details and style. Preserve real alpha, not a checkerboard or white matte. Compare the generated result to the accepted reference, checking missing parts, labels, endpoints, colors and style; repair the asset rather than accepting a simplified variant. Save the approved reference, prompt, generated original and consumed asset inside the project with provenance, and include them in the real build inputs. Follow current explicit tool choices; capability or budget limits do not authorize silently omitting the element.

Make recoloring explicit. For a single-color material, retain its alpha mask and the adjustable palette role; recoloring preserves alpha and the full silhouette/antialiased edges. For a few-color material, retain semantic layers or per-role alpha masks and a mapping of adjustable versus fixed colors; preserve holes, opacity and structural transparency. A small number of RGB values alone is not a semantic binding. Do not guess regions from matching colors or recolor fixed details indiscriminately. Use the available image-editing capability or an explicitly supported project binding to produce the intended palette, and inspect an actual recolored result at use size. Retain the required masks/mapping and recoloring inputs with the portable project. The existing SVG paint helper does not automatically recolor PNGs or read a new bitmap descriptor; only claim the mechanism that the project actually implements and verifies.

Keep exact supplied logos, screenshots, scientific evidence and source data authoritative, with their original backgrounds/colors where required. Reuse those originals instead of inventing replacements; ImageGen may reconstruct associated illustration/decorative material without fabricating evidence. Use verified source text for editable labels whenever practical and check any text retained in the asset. Disclose that a recolorable generated element is a picture, not independently editable internal geometry. Its bitmap color bindings do not turn it into an SVG paint-contract template icon; see [icon production](icon-production.md). Check its resolution, alpha edges, container/page overflow and placement relative to the other accepted elements in the actual rebuilt page.

## Page composition and HTML boundary

Every title, text, formula, label, visualization and meaningful decorative group must serve the page task and, through it, the section and report goals. Choose their arrangement from the current information relationship. Pure text can serve a short question, quotation or conclusion; a picture or icon needs a useful role. Do not mechanically reuse website hero sections, selling cards or dashboards as report layouts. The page's main meaning must be readable without scrolling, hovering or clicking.

Make conclusions and their supporting evidence visibly correspond through proximity, a shared heading, matching labels, annotations, highlighting or a necessary connector. Use only connections that express real relationships. Preserve exact premises and key reasoning/derivation steps where the audience needs them; check progression and information burden in the actual composition. Internal item counts, maintenance IDs and authoring decisions stay in process material unless the audience needs them for the report itself.

Do not use HTML/DOM/CSS to lay out report pages, including layouts later captured as screenshots, printed or converted to another format. HTML may contain a JavaScript visualization itself and its necessary runtime container. This exception does not cover surrounding titles, prose, columns or page UI; produce those through the permitted native/SVG route. A direct SVG diagram is allowed. Keep the selected route's editability claims accurate for any visualization asset.

## Mockup prompt inputs

For a requested raster page sample within the confirmed ImageGen scope, use the host image-generation tool directly. Supply:

- The selected canvas/aspect ratio, template palette, typography intent, grid and fixed content regions.
- The exact current-page text and moderate content density, with a declared hierarchy and clear content division.
- The intended page progression, necessary premises or key steps, and the association between conclusions and evidence.
- Approved representative images as style references, with the current layout allowed to differ.
- Supplied logos, figures and screenshots as strict identity/evidence assets. Preserve values, axes, labels, proportions and scientific meaning; do not synthesize substitute evidence.
- The editable reconstruction plan: decorative pictures may remain assets, while title/body, controls, separators and diagrams must later become independent native objects as required.

Inspect local reference images using the available image-viewing tool before editing or conditioning on them. Label each input's role in the prompt. Save prompt, tool result, source attribution and review status under the project. Show the current sample for the user's requested review and incorporate concrete corrections before native reconstruction.

Use generated text only as visual guidance. Native source text comes from verified content, with declared font families and the template's sizes or controlled project adjustments above; do not copy misspellings or typography defects from the raster sample. Preserve original evidence/identity assets independently so the final native page can use those files exactly.

Native paragraph lines must satisfy [punctuation and singleton rules](text-and-containers.md#paragraph-line-breaking-rules). Do not preserve a mockup's forbidden line-head/tail punctuation or a row containing only one character with optional punctuation; reflow the complete paragraph within the declared layout.

## Full-page hierarchy check

After completing each page, inspect its actual current render as a whole at a fitted full-page view and normal presentation scale. This check is required even for a single page or an authorized batch, and for both original authoring and mockup reconstruction. Inspect all visible text roles, including labels, chart text, captions, navigation and mathematical text, and the relationships between content containers.

| Dimension | Check across the whole page |
|---|---|
| Font size | Main title/message, section headings, body and supporting details are distinguishable and readable; no essential explanation is demoted to tiny text. Use the active declared template/project role sizes. |
| Font family | Each role uses its declared family, including math/monospace where relevant; substitutions and inconsistent families do not disrupt the hierarchy. |
| Font weight | Declared title/heading/body weights are realized correctly; emphasis helps the reader distinguish roles without inventing undeclared bold styles. |
| Spacing | Line spacing, paragraph gaps, internal padding and distances between groups follow the active shared recipe and visibly separate their intended levels. Check actual glyph/edge clearance. |
| Visual content groups | Proximity, alignment, containers, headings and meaningful connectors group related material and separate different groups, including across columns and boxes. The groups match the accepted content relationships. |

Judge their combined effect: can the reader identify the main message, then the sections, explanations and supporting details in the intended order? Merely assigning several font sizes, passing a bounding-box check or avoiding overlap is not a pass. Uniform styling or equal gaps can flatten the page even when every object is individually legible.

Repair the source and shared recipes as needed, preserve the approved elements, rebuild and inspect the new render before calling the page complete. Recheck affected pages when a shared recipe changes. Record meaningful findings/repairs briefly in existing page notes or review material; no new scoring schema or specialist review is required. Application editing and projection evidence remain separate under [PowerPoint checks](powerpoint-checks.md).

For adjusted mockup reconstruction, also complete the [container and page overflow review](#controlled-adjustments-for-approved-mockups). Hierarchy and overflow are separate acceptance conditions: a page can have clear hierarchy while content is clipped, or fit its bounds while all text roles appear flat.

## Material generation and transparent assets

For new bitmap illustrations, photos, textures or image edits, use the selected host image-generation capability. Request a transparent background when the final asset needs transparency. Preserve transparency on edits unless the user asks to change it. Use reference-image paths when all targets have paths, otherwise the smallest supported recent-image set that includes every target; do not silently omit a required target.

Ask for complete separated objects with consistent perspective, stroke and illumination. A material sheet can contain several non-overlapping assets with clear outer padding, but verify identity/count and edges after separation. Keep logos and strict evidence originals; generated approximations need explicit permission for that role. Repair small occlusions locally rather than redesigning an entire source background.

Check transparent edges against both light and dark backgrounds for halos, missing thin strokes and unintended holes. Avoid arbitrary color-key removal that erases matching subject colors. If an approved layered source or role mask exists, retain it with a clear mask-to-material contract; otherwise regenerate an unsuitable cutout through the image tool.

For an existing SVG icon system, use its vector source and declared paint contract rather than generating a new bitmap. Multiple independent color roles need stable element IDs and per-channel rules. Palette binding, fixed details, structural `none` and unlisted paint remain distinct. See [icon handoff](authoring-handoff.md#icon-material-handoff).

For new reusable adjustable icon sources use [icon production](icon-production.md): reuse, simple authored vectors, complex generated materials, then external supplements. Every reusable route finishes with compliant adjustable parts; raw generated or downloaded rasters are production inputs. For approved-mockup reconstruction preserve the accepted icon identity; [C28's independent picture exception](#elements-that-need-imagegen) remains a project asset and is not an adjustable template icon. Apply the source and evidence requirements in [production rules](production-rules.md).