4.1 KiB
PowerPoint application evidence
Use the host's supported application UI tool, such as CUA, for PowerPoint operations. Initialize it with the documented app/browser entrypoint, read the returned documentation, and operate only through supported APIs. After a resumed computer-use summary, reload that tool's documentation before acting. Do not substitute shell scripting or hidden application automation for UI evidence.
Open the current generated file, verify the visible filename and page thumbnails, and inspect whether PowerPoint shows a repair/recovery warning. Work on task-owned copies and preserve the user's unrelated open presentations. Do not dismiss a repair prompt as successful opening; retain the diagnostic and repair the authored source.
Use the current output of the mandatory project build. Production corrections must be represented in project sources and rebuilt; edits made only in an application test copy do not become the deliverable. When the page follows an approved sample, compare it with that reference and its element inventory, preserving the accepted content and relationship-bearing shapes during repairs.
For rendered evidence, export this file to PDF through PowerPoint's own export dialog using the intended quality setting and a task-owned destination. Check the export exists and belongs to the current file, render its pages and inspect the images. Compare page geometry, text wrapping, typography, images, transparent edges, alignment and separators. Confirm actual PDF font identities when font rendering is disputed; a declared PowerPoint face alone does not prove which font the application rendered.
Use the text/container review: paragraph frame or justified logical-block fallback, no substantive statements in small muted notes, visible size/weight/color hierarchy within containers, one shared internal layout implementation per type/variant, compliant punctuation/singleton handling on every paragraph line, exact template-owned spacing and visible fixed paragraph gaps. Reject caller spacing overrides. Check actual glyphs/edges and visual rows, not only boxes, authored breaks or XML paragraphs. Review content/source and native objects as well as the render. A screenshot cannot prove a shared renderer or unified text source; grouping cannot prove native paragraph flow. Test fragment reflow in the application only when that editing behavior is part of the requested evidence.
For equations, inspect mc:Choice/a14:m and OMML structures separately from compatibility fallback text. Verify the declared math family on runs and operator/control properties, missing glyphs, fraction/radical/script/limit placement and clearance from adjacent prose. Actual equation editing requires selecting and changing the equation in a disposable copy; XML or a correctly shaped picture cannot establish that evidence. See math checks.
Every completed page also requires the full-page hierarchy check: sizes, families, weights, spacing and visual grouping across the whole rendered page. Component checks, a successful export or absence of overlap do not replace it. Repair issues and inspect the updated render; report application/projection evidence at its actual level.
Opening and exporting are distinct from actual editing. When editing evidence is requested, use a disposable task-owned copy: select a representative text/shape/placeholder, change it through the UI, save or export, and verify the resulting independent object/content change. Check an appropriate inherited object separately if template behavior is in scope. Do not alter the authoritative source project or a user's finished original merely to demonstrate editing.
Report the evidence actually obtained: source/reference validation, native structure and object types, current-page rendering, PowerPoint opening, actual object editing, or projection readability. A successful export cannot establish every later level. If the host application or UI capability is unavailable, deliver the validated source and PPTX with that specific unresolved application check.