PaperlayerView exact revision on arXiv

Source-linked AI summary

EditPPT: Faithful Long-Deck Slide Editing via Structured Tool-Using Multi-Agent with Dual-Modal Validators

Jiheon Kim, Kyudan Jung, Jaegul Choo

arXiv:2608.20381v1cs.CLcs.AIcs.HC

TL;DR

Reliable slide editing requires accurate modification, preservation of unrelated content, and robustness to deck length, but native .pptx files challenge idealized representations and open-ended code generation. EditPPT addresses this with constrained shape-level tool execution over PowerPoint-resolved objects, specialist agents, and dual-modal validation, evaluated on a benchmark of human-authored decks. It achieves strong overall results and maintains strong performance on long decks, while retaining deployment and scope limitations.

  • Problem

    Slide editing must simultaneously provide modification accuracy, preservation fidelity, and robustness to deck length, despite native .pptx files containing irregular structures that challenge existing representations and editing pipelines.

  • Method

    EditPPT reformulates slide editing as constrained tool selection over PowerPoint-resolved objects, using specialist agents, COM-based shape-level operations, and separate structural and visual validators.

  • Results

    99.5% execution, 88.7% slide-targeting F1, 82.5% instruction following, and 91.5% object preservation were achieved overall, with strong performance on long decks.

  • Takeaways & Limitations

    EditPPT provides a length-robust approach for editing human-authored PowerPoint decks while preserving unrelated slide content.

  • Takeaways & Limitations

    The framework depends on desktop PowerPoint COM automation, is optimized for concrete edits over existing objects, and has imperfect visual judging for subtle aesthetic regressions.

Abstract

from arXiv · show

Automating slide editing requires simultaneously satisfying modification accuracy, preservation fidelity, and robustness to deck length. Existing LLM-based systems often fail on real-world presentation files because they rely on idealized intermediate representations or open-ended code generation, which are prone to cascading errors in long decks. We introduce EditPPT, a multi-agent framework that reformulates slide editing as a constrained tool-selection problem. By executing localized shape-level operations through the native PowerPoint COM interface, EditPPT narrows the LLM action space while preserving the application-resolved structure of user-authored decks. By separating validation across modalities, our dual-modal validation provides more robust assessment of both instruction fidelity and visual quality. We also present DeckEdit-Bench, a benchmark with 28 human-authored decks, 582 slides, and 183 editing prompts across short, medium, and long deck tiers. Experiments show that EditPPT achieves a 99.5% execution rate, 88.7% slide-targeting F1, 82.5% instruction following, and 91.5% object preservation overall, while maintaining strong performance on long decks. Our code and benchmark are available at https://anonymous.4open.science/r/EditPPT-0E27/

1 Introduction

Reliable slide editing must modify requested content accurately, preserve unrelated objects and formatting, and remain robust as decks grow longer and more complex. EditPPT addresses this by combining constrained shape-level tools, native PowerPoint state, and dual-modal validation, achieving strong benchmark performance across deck lengths.

  • Motivation: Reliable slide editing must satisfy modification accuracy, preservation fidelity, and robustness to increasing deck length and complexity.Unintended changes to fonts, layouts, or shapes can render an entire deck unusable.
  • Motivation: User-authored .pptx files contain grouped objects, implicit formatting, inconsistent layouts, and artifacts that challenge idealized editing representations.Direct code or OOXML manipulation can require brittle stateful programs, allowing small targeting errors to propagate across slides.
  • Approach: EDITPPT combines a COM-based parser, specialist edit agents, and modality-decoupled validation for instruction fulfillment and visual layout anomalies.The pipeline first checks structural task completion and then uses visual validation to identify defects.
  • Evaluation: DECKEDIT-BENCH contains 28 human-authored decks, 582 slides, and 183 editing prompts spanning short, medium, and long deck tiers.The benchmark emphasizes structural complexity and length diversity in real-world presentation workflows.
  • Evaluation: 99.5% execution, 88.7% slide-targeting F1, 82.5% instruction following, and 91.5% object preservation were achieved overall, with strong performance on long decks.On long decks, EDITPPT maintained 90.5% slide F1, 86.6% instruction following, and 91.7% preservation.
  • Approach: EDITPPT reformulates slide editing as constrained tool selection, with typed shape-level operations executed through the native PowerPoint COM interface.The framework uses specialist agents with narrow tool scopes and aligns execution with PowerPoint-resolved object state.

2 Related Work

Presentation automation has largely focused on generation or editing in regularized representations, while newer benchmarks assess agentic editing, instruction following, locality, and visual quality. DECKEDIT-BENCH complements this work by emphasizing length scaling in native, human-authored decks with heterogeneous PowerPoint objects.

  • Presentation automation: Presentation-construction systems commonly use HTML, structured markup, or generated code, which suit layout-controlled generation better than editing user-authored .pptx files.These representations are less suited to grouped objects and heterogeneous artifacts in existing decks.
  • Presentation editing benchmarks: Recent presentation-editing benchmarks evaluate editing as an agentic task involving instruction following, locality, and visual quality.TSBench, PPTArena, and DECKBench study object-model editing, in-place PowerPoint edits, or multi-agent HTML workflows.
  • Presentation editing benchmarks: DECKEDIT-BENCH emphasizes length scaling over native, human-authored decks containing heterogeneous PowerPoint objects and layout artifacts.Its focus complements benchmarks centered on shorter, generated, modular, or HTML-based editing settings.

3 Method

EditPPT uses a five-stage, COM-centered pipeline that grounds bounded shape-level edits in PowerPoint-resolved structure and validates both semantic completion and visual quality.

  • Pipeline: The five-stage pipeline parses relevant slides, decomposes instructions, dispatches specialist agents, executes COM tools, and validates the edited result.Structural and visual validators operate before the result is accepted.
  • Design rationale: COM provides a shared application interface for parsing and editing, exposing PowerPoint-resolved object state while avoiding fragmented OOXML manipulation.The representation preserves editable object state and reduces package-level XML redundancy.
  • Planning and targeted parsing: The planner converts high-level scope into slide-level tasks and then refines each request into shape-level targets and actions.Only the slides needed for execution are parsed before task refinement.
  • Planning and targeted parsing: The parser represents native objects and properties, including geometry, text, formatting, tables, charts, images, and slide-level elements.Image captions help agents identify visual content that is otherwise difficult to resolve from presentation structure.
  • Planning and targeted parsing: Reconstruction procedures address COM gaps in rich-text runs, paragraph segmentation, and merged table cells, enabling more precise downstream edits.These procedures preserve local formatting and expose logical table cells for tool use.
  • Execution and validation: The dispatcher routes relevant shapes to type-specific specialist agents, while dual-modal validation checks intended changes, unrelated objects, and rendered visual defects.The system re-parses the edited deck and compares it with the original state and edit plan before visual inspection.

4 DECKEDIT-BENCH

DECKEDIT-BENCH evaluates realistic editing of heterogeneous, human-authored PowerPoint decks using natural-language prompts that require target inference across multiple deck lengths and scopes.

  • Benchmark scope: DECKEDIT-BENCH contains 28 human-authored PowerPoint decks, 582 slides, and 183 natural-language editing prompts.The source files retain heterogeneous layouts, grouped objects, images, tables, charts, shapes, backgrounds, and slide-level properties.
  • Benchmark scope: The corpus draws from research, teaching, and professional materials in Korean and English, with most decks directly written and used by people.A small number began with generation assistance before manual editing into realistic presentations.
  • Deck length tiers: Decks are stratified by length into short decks of at most 10 slides, medium decks of 11–30 slides, and long decks exceeding 30 slides.The tiers measure length rather than intrinsic difficulty.
  • Prompt design: Prompts conceal internal shape identifiers, XML paths, object indices, and implementation handles, requiring systems to infer the target slide, object, and operation.This setup tests editing from user-facing instructions rather than system-specific references.
  • Prompt design: The benchmark spans local and presentation-scale edits, with four categories combining explicit or pattern-based targeting and simple or compound operations.Pattern prompts identify recurring targets across slides, while compound prompts coordinate multiple edits.

5 Experiments

Experiments assess execution, targeting, instruction following, preservation, and length robustness on the full benchmark, using staged structural and visual evaluation across systems.

  • Evaluation criteria: The evaluation measures modification accuracy, preservation fidelity, and robustness to deck length at both slide and object levels.Metrics are reported across short, medium, and long decks.
  • Experimental setup: The full benchmark contains 183 deck-prompt instances across 28 decks, with each instance starting from a fresh source-deck copy.Runs record execution status, output files, logs, API cost, and runtime.
  • Baselines: The study compares EditPPT with Talk-to-Your-Slides, PPTPilot, and Claude Code + PPTX Skill under shared source-deck and instruction conditions.The baselines use different editing approaches, including COM-based code generation, python-pptx, direct XML manipulation, and general-purpose coding-agent capabilities.
  • Configuration: All text-only components use GPT-4.1, image processing uses Gemini models, and LLM/VLM judges use GPT-5.5.The configuration applies GPT-4.1 to EditPPT components and the two principal baselines.
  • Evaluation procedure: Evaluation separates slide targeting from object-level editing quality, then combines structural judging with rendered-slide visual assessment.Targeting labels include correctly targeted, missing target, and wrong target; object edits are labeled success, partial, or fail.
  • Metrics: The reported metrics are Slide F1, Instruction Following, Object Preservation Rate, and defect-complement visual quality, broken down by deck length.Table 2 also reports average time and cost per slide.

6 Results

EditPPT performs reliably across deck lengths while preserving editing quality and offering efficiency advantages over less specialized variants. Ablations show that both multi-agent dispatch and separated structural and visual validation contribute to practical performance.

  • 99.5% of editing instances are completed, with 88.7% Slide F1, 82.5% Instruction Following, and 91.5% object-level preservation overall.
  • Robustness to deck length: 90.5% Slide F1, 86.6% Instruction Following, and 91.7% object-level preservation are maintained on long decks.
  • Repeatability: $4.91 average cost and $0.27 standard deviation are achieved across repeated long-deck runs, alongside 2.1 minutes of runtime variation.
  • Multi-agent dispatch: Replacing multi-agent dispatch raises per-slide cost by 26.6% and runtime by 10.0%, while Object Preservation remains 91.5%.The single agent reasons over the full tool inventory at every step.
  • Dual-modal validation: Instruction Following falls by over 37 points and Object Preservation by nearly 32 points when dual-modal validation is replaced by one VLM judge.The authors attribute the regression to cognitive overload and visual bias over structural state.
  • Type-specialized tool calls reduce cross-object tool misuse before validation and recovery.

7 Conclusion

EditPPT treats presentation editing as constrained tool selection over native PowerPoint objects rather than open-ended code generation. The framework aligns parsing, execution, and validation around PowerPoint-resolved state, while its scope remains bounded by deployment and task complexity constraints.

  • EditPPT uses native PowerPoint objects and localized shape-level operations to align parsing, execution, and validation.This alignment is intended to preserve unrelated slide content and support repeatable execution.
  • The framework improves reliability for concrete edits over existing objects but may require stronger planning or human review for abstract redesign and narrative-restructuring instructions.
  • PowerPoint COM dependence and effectively single-threaded operations limit straightforward parallelism and make deployment environment-dependent.
  • Visual judging remains imperfect for subtle aesthetic regressions and domain-specific formatting conventions.
  • Tool-augmented and multi-agent systems provide the broader paradigm for decomposing complex tasks across planning, execution, and verification.

B Additional Benchmark Details

DECKEDIT-BENCH organizes human-authored PowerPoint editing tasks by deck length and prompt complexity while retaining structurally rich native slides. Its difficult cases require conditional target selection and coordinated object-level edits.

  • DECKEDIT-BENCH includes prompt metadata for target scope, action type, object category, and instruction complexity.
  • Pattern prompts locate recurring or conditional targets, whereas compound prompts require multiple coordinated object-level edits within one instruction.
  • The benchmark tiers are defined by deck length, while all tiers contain native PowerPoint objects and heterogeneous layouts.
  • Pattern-Compound tasks are the most difficult because they require conditional slide selection across a deck.
  • ADD operations reach near-perfect instruction following once the target is found.

C.2 Detailed Preservation Results

EDITPPT’s strongest preservation results come from localized execution and remain above 90% across deck-length tiers. The validation pipeline checks structural instruction fulfillment separately from rendered visual quality, with recovery for severe targeting or missing-edit failures.

  • 91.5% overall object preservation is maintained above 90% in every length tier.Remaining preservation errors mainly arise from pattern-based instructions rather than explicit single-slide edits.
  • Localized typed shape-level tools better preserve unrelated slide elements than open-ended code or structure-level editing in representative comparisons.
  • Object-level preservation measures correctly targeted slides without preservation_error, while slide-level preservation measures wrong_target outcomes.
  • A successful COM call can still fail instruction fulfillment or introduce a layout defect, motivating complementary validation.
  • Dual-modal validation: Visual validation renders edited slides to detect overlap, clipping, and unintended layout shifts after structural checking.
  • Structural validation: Structural validation compares before-and-after parsed slide state against the instruction and task, checking intended edits and unrelated-object changes.Severe failures trigger checkpoint restoration and specialist retry with validator feedback.

D.1 XML-Parser Token Efficiency

The EditPPT parser substantially reduces input size and cost compared with raw XML, while limiting extreme per-slide context lengths and improving savings on complex slides.

  • 76.8% reduction lowers parsed input from 36.48M raw-XML tokens to 8.45M parser tokens.Estimated input cost falls from $72.97 to $16.89, a 4.32× reduction.
  • 31K-token parser outputs replace raw-XML slides reaching up to 1.1M tokens.This reduces extreme context-length outliers in addition to average input size.
  • Compression savings increase with slide shape count because the parser removes repeated low-level metadata.The compact semantic representation preserves object-level information while eliminating redundant style, coordinate, relationship, and metadata structure.

E Technical Implementation Details

EditPPT combines COM-based parsing, specialized dispatch, deterministic typed tools, and structural or visual validation in a retry-capable implementation.

  • Parser: The parser converts native PowerPoint objects into structured JSON and caches per-slide results, bypassing the cache with force=True after retries.Edit history is stored as snapshots in edit_history.
  • Dispatch: The dispatcher classifies relevant shapes and routes tasks to specialized agents, with slide-level operations sent directly to the slide agent.Classification failures fall back to the text_style agent.
  • Execution control: Each edit runs through bounded retry and rollback, with runtime fields injected according to ToolMeta before COM execution.Post-execution clamping and validation determine whether the edit is saved, rolled back and retried, or incrementally corrected.
  • Tool execution: 33 typed tools cover text, tables, charts, shape/layout, and slide-management operations.The tool registry includes 7 text, 3 table, 5 chart, 13 shape/layout, and 5 slide-management tools.
  • Validation: Text validation compares old_parse and new_parse using an LLM, while the vision validator exports PNGs for visual checking with Gemini 2.5 Pro.The two validators assess structural text changes and rendered slide appearance through separate mechanisms.
  • Text parsing: Character-level font snapshots reconstruct run boundaries when PowerPoint’s dynamic TextFrame2.Runs API is unreliable.The parser compares per-character font properties and rebuilds runs with offsets and formatting metadata.
  • Table parsing: Table parsing records dimensions, cells, and merged-cell spans using geometric keys to identify repeated cell regions.Cells are traversed by row and column while duplicate geometries update row-span and column-span metadata.

E.2 Win32COM Limitations

Win32COM provides faithful access to PowerPoint’s resolved state but introduces concurrency, interface, equation, and paragraph-handling constraints.

  • Win32COM does not natively support parallel execution, making large-scale slide processing a runtime bottleneck.TextFrame and TextFrame2 behavior is also not always interchangeable, and equation objects require special handling.
  • Equation objects require special handling because Office Math structures are not exposed like ordinary text ranges.The paper illustrates representative equation-handling cases in Figures 6 and 7.
  • Paragraph ranges become unreliable with carriage returns, soft line breaks, or mixed run formatting, risking broken grouping or dropped style information.The implementation instead reconstructs full paragraph text from mapped runs before writing resolved text back.

E.3 Claude PPT Editing Limitations

The Claude PPT workflow’s direct OOXML approach is costly and brittle for localized edits because it exposes redundant package structure and finely separated formatting spans.

  • Direct OOXML processing increases token cost and processing time even for simple repetitive edits.The full-package representation is inefficient when an operation touches only a small number of objects.
  • Verbatim run-level formatting spans increase the chance of hallucinated edits and artifacts such as broken spacing.This brittleness arises from exposing finely separated formatting spans during editing.
  • Text and table operations: Text tools support styling, insertion, deletion, replacement, rewriting, paragraph alignment, and bullet management through PowerPoint text ranges.Table tools similarly modify cell text and layout properties such as dimensions, colors, borders, and vertical alignment.
  • Object-specific operations: Table and chart helpers expose localized edits to cells, dimensions, colors, alignment, chart categories, and refreshed chart data.These operations target individual table regions or chart categories rather than rewriting the entire package.
Loading 2608.20381v1…