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

arXiv cs.CL Papers

Summary

EditPPT introduces a multi-agent framework for accurate and faithful slide editing in long decks, using structured tool-using and dual-modal validators, and presents the DeckEdit-Bench benchmark.

arXiv:2608.20381v1 Announce Type: new Abstract: 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/
Original Article
View Cached Full Text

Cached at: 08/24/26, 04:16 AM

# Faithful Long-Deck Slide Editing via Structured Tool-Using Multi-Agent with Dual-Modal Validators
Source: [https://arxiv.org/html/2608.20381](https://arxiv.org/html/2608.20381)
###### Abstract

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 introduceEditPPT, a multi\-agent framework that reformulates slide editing as aconstrained tool\-selection problem\. By executing localized shape\-level operations through the native PowerPoint COM interface,EditPPTnarrows 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 presentDeckEdit\-Bench, a benchmark with 28 human\-authored decks, 582 slides, and 183 editing prompts across short, medium, and long deck tiers\. Experiments show thatEditPPTachieves 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[here](https://anonymous.4open.science/r/EditPPT-0E27/)\.

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

Jiheon Kim1Kyudan Jung2Jaegul Choo2KAIST AI\{ben8169, kyudan, jchoo\}@kaist\.ac\.kr

## 1Introduction

Slide decks are a ubiquitous medium for organizing and communicating information across business, academic, and professional contexts\(Shiet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib10)\)\. Naturally, automating slide workflows has emerged as a high\-value task\. Recent systems have made rapid progress in presentation generation from natural\-language instructions, source documents, and user preferences\(Geet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib58); Zhenget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib7); Yanget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib59); Zenget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib60); Zhenget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib9); Wuet al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib3)\); however, reliable slideeditingremains a significant challenge\(Junget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib11); Ofengendenet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib5); Janget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib2)\)\. Unlike generation, slide editing is strictly bound by three simultaneous constraints: modification accuracy, preservation fidelity, and robustness to deck length\. An editing system must execute a requested modification while leaving unrelated content and formatting untouched\. Crucially, this preservation behavior must remain stable as the presentation grows in length and complexity, since unintended shifts in fonts, layouts, or shapes can render an entire deck unusable\.

![Refer to caption](https://arxiv.org/html/2608.20381v1/x1.png)Figure 1:EditPPTmaintains strong editing across deck lengths while preserving unrequested objects\.![Refer to caption](https://arxiv.org/html/2608.20381v1/x2.png)Figure 2:\(a\) The Planner translates the user’s high\-level intent into a specification targeting specific slides\. \(b\) The Parser converts target slides into structured JSON; images are captioned by a VLM\. \(c\) The Multi\-Agent Dispatcher routes each slide element to the appropriate sub\-agent\. \(d\) Each sub\-agent invokes tools with task\-specific parameters\. \(e\) The tools execute edits via COM\. \(f\) The LLM Validator re\-parses the edited slides, compares pre\- and post\-edit states, and verifies task completion\. Once passed, a VLM checks for visual defects\.A central obstacle is the mismatch between idealized editing representations and native`\.pptx`files\. Many LLM\-based pipelines operate on regularized HTML, code, or structured markup representations where layers, coordinates, and object boundaries are explicit\(Geet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib58); Zhenget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib7); Yanget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib59); Janget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib2)\)\. User\-authored presentations rarely satisfy these assumptions because they include grouped objects, implicit formatting, inconsistent layouts, and artifacts whose semantic role differs from their file\-level type\(Wuet al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib3); Panet al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib6)\)\. Direct manipulation of native files through code generation or OOXML editing avoids some representational loss, but it requires the LLM to synthesize brittle stateful programs or edit a complex schema where small targeting errors can propagate across slides\(Anthropic,[2026d](https://arxiv.org/html/2608.20381#bib.bib4); Junget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib11); Ofengendenet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib5)\)\. These failure modes become more pronounced in long, dense decks, yet existing benchmarks still emphasize relatively short, generated, HTML\-based, or modular editing settings\.

Our key observation is that practical edits are more regular than the files that contain them\. Although native decks are structurally irregular, most user requests decompose into bounded operations over recurring object types, including text frames, tables, charts, shapes, and images\. This motivatesEditPPT, a length\-robust, layout\-aware framework that formulates slide editing as aconstrained tool\-selection problem: the LLM interprets the instruction and selects typed operations, while execution is handled by deterministic shape\-level tools through the COM interface\.EditPPTcombines a COM\-based parser, specialist edit agents with narrow tool scopes, and a modality\-decoupled validator that checks both instruction fulfillment and visual layout anomalies, thereby reducing the cascading errors caused by open\-ended program synthesis or raw file\-structure modification\.

To evaluate this setting, we introduceDeckEdit\-Bench, a depth\-oriented benchmark with 28 human\-authored decks, 582 slides, and 183 natural\-language editing prompts across short \(≤\\leq10 slides\), medium \(11 to 30 slides\), and long \(\>\>30 slides\) tiers\. As summarized in Figure[1](https://arxiv.org/html/2608.20381#S1.F1),EditPPTcompletes 99\.5% of benchmark instances and achieves 88\.7% slide\-targeting F1, 82\.5% instruction following, and 91\.5% object preservation overall; qualitative comparisons in Figure[3](https://arxiv.org/html/2608.20381#S1.F3)further illustrate its ability to apply requested edits while preserving unrelated slide content\. On long decks, it maintains 90\.5% slide F1, 86\.6% instruction following, and 91\.7% preservation, while PPTPilot and Talk\-to\-Your\-Slides show stronger instruction\-following degradation as deck length increases\. These results indicate that native, constrained tool execution mitigates length\-induced error cascades in practical slide editing\.

![Refer to caption](https://arxiv.org/html/2608.20381v1/x3.png)Figure 3:Qualitative comparison of presentation\-editing strategies\.EditPPTconstrains execution to typed shape\-level tools, reducing accidental edits to unrelated slide content\.#### Contributions\.

Our main contributions are summarized as follows:

- •We proposeEditPPT, a tool\-augmented multi\-agent framework that reformulates slide editing as a constrained tool\-selection problem, executing shape\-level operations via the native PowerPoint COM interface\.
- •We releaseDeckEdit\-Bench, a depth\-oriented benchmark with 28 human\-authored decks and 183 prompts that capture the structural complexity and length diversity of real\-world presentation workflows\.
- •We empirically demonstrate thatEditPPTsignificantly outperforms existing code\-generation and structure\-editing baselines while exhibiting strong stability against deck\-length scaling\.

## 2Related Work

#### Presentation automation\.

A broad line of work has studied automated presentation construction, including instruction\-driven slide synthesis, academic paper\-to\-slide generation, and interactive deck authoring systems\(Geet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib58); Zhenget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib7); Yanget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib59); Zenget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib60); Zhenget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib9); Wuet al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib3)\)\. These systems typically operate in regularized representation spaces, such as HTML, structured markup, or generated code, which are effective when the system controls the layout from the beginning but are less suited to editing user\-authored`\.pptx`files with grouped objects, inconsistent layers, implicit formatting, and semantic\-structural mismatches\. Our work therefore focuses on a distinct setting: instruction\-driven editing of native PowerPoint decks, where the system must identify the intended targets, apply local modifications, and preserve unrelated content and formatting in the original file\.

#### Presentation editing benchmarks\.

Recent benchmarks have begun to evaluate presentation editing as a first\-class agentic task\. Talk\-to\-Your\-Slides introduces TSBench for efficient object\-model\-based slide editing\(Junget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib11)\), PPTArena evaluates in\-place PowerPoint edits over real slides with structural and visual judging\(Ofengendenet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib5)\), and DECKBench studies multi\-turn academic slide generation and editing in a multi\-agent HTML workflow\(Janget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib2)\)\. These efforts establish the importance of instruction following, locality, and visual quality for slide editing\.DeckEdit\-Benchcomplements them by emphasizing length scaling over native, human\-authored decks with heterogeneous PowerPoint objects and layout artifacts\.

StageInputOutputPlanningUser instructionSlide\-level tasksParsingTarget slidesShape JSON statesDispatchTasks and shapesSpecialist callsExecutionTyped argumentsCOM editsText ValidationBefore/after statesAccept or recoverVision ValidationAfter slide CaptureAccept or visual\-fixer call

Table 1:TheEditPPTpipeline keeps each step grounded in PowerPoint\-resolved objects, from planning to validation\.

## 3Method

### 3\.1Overview and Design Rationale

EditPPTprocesses an editing request through a five\-stage pipeline \(Figure[2](https://arxiv.org/html/2608.20381#S1.F2)\)\. Given a user\-supplied`\.pptx`deck and a natural\-language instruction, the system \(i\) parses the relevant slides into structured representations of native PowerPoint objects, augmented with selective visual metadata, \(ii\) decomposes the instruction into a per\-slide task list, \(iii\) dispatches each task to a specialist agent, \(iv\) executes deterministic shape\-level operations through the PowerPoint COM interface, and \(v\) validates the result using complementary structural and visual validators before either accepting the edit or triggering recovery\. The pipeline runs sequentially against a single PowerPoint application instance, with slide\-level checkpoints used to support recovery\. Table[9](https://arxiv.org/html/2608.20381#A4.T9)summarizes the input and output of each stage\.

SystemDeck LengthPerformanceEfficiencyExecutionRate↑\\uparrowSlide F1↑\\uparrowInstructionFollowing↑\\uparrowPreserv\.↑\\uparrowVisual Quality↑\\uparrowAvg\. Time\(s/slide\)↓\\downarrowAvg\. Cost\(×10−2\\times 10^\{\-2\}$/slide\)↓\\downarrowPPTPilotShort66\.7%80\.8%69\.7%83\.8%84\.8%24\.94\.93Medium86\.4%83\.2%68\.1%78\.5%90\.0%8\.93\.03Long85\.4%69\.8%52\.6%88\.2%84\.7%11\.54\.38Overall80\.3%76\.8%60\.6%83\.6%87\.3%11\.33\.75Talk\-to\-Your\-SlidesShort64\.8%75\.9%52\.1%72\.6%76\.3%122\.33\.24Medium39\.5%61\.3%39\.6%85\.6%82\.6%109\.30\.63Long50\.0%57\.7%34\.9%93\.2%73\.7%89\.20\.47Overall49\.7%60\.7%38\.1%88\.6%77\.8%100\.90\.79Claude Code \+ PPTX SkillShort100\.0%93\.8%83\.3%81\.8%94\.6%83\.826\.85Medium100\.0%95\.6%92\.8%86\.2%91\.6%27\.38\.94Long100\.0%95\.2%95\.4%82\.0%84\.7%26\.07\.09Overall100\.0%95\.3%93\.4%83\.8%88\.2%30\.49\.20EditPPTShort100\.0%86\.6%76\.8%93\.7%92\.7%69\.69\.45Medium100\.0%87\.0%78\.7%90\.9%93\.4%36\.55\.60Long97\.9%90\.5%86\.6%91\.7%86\.7%40\.79\.36Overall99\.5%88\.7%82\.5%91\.5%89\.9%40\.87\.74

Table 2:Overall and length\-wise comparison onDeckEdit\-Bench\. Each evaluation instance corresponds to one deck\-prompt pair\. Slide F1 denotes slide\-targeting F1\. Instruction Following is measured as the full\-or\-partial editing success rate on successfully targeted slides\. Preserv\. denotes Object Preservation Rate, reflecting shape\-level preservation capability\. Average time and cost are reported per slide, where cost is in units of10−210^\{\-2\}USD\. Bold values indicate the best result, andunderlinedvalues indicate the second\-best result among Overall results\.The key design choice is to use the running PowerPoint application as a shared interface for both parsing and editing, following recent evidence that object\-model\-based slide manipulation can be more efficient and style\-preserving than pixel\-level GUI control for structured slide edits\(Junget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib11)\)\. Static libraries such aspython\-pptxexpose only a partial view of the application\-resolved slide state, making conditional edits difficult\. Direct OOXML editing111Office Open XML \(OOXML\) is the XML\-based package format underlying modern Microsoft Office files, including\.pptx\. A PowerPoint deck is stored as a ZIP package containing XML parts, relationship files, and media assets\. Because XML encodes hierarchy and metadata through explicit tags and attributes, serialized OOXML tends to be verbose and token\-inefficient for LLM\-based processing\.requires manipulating fragmented low\-level XML structures, making LLM\-based editing both costly and brittle\.EditPPT, by contrast, uses COM to query and modify the live PowerPoint application, recovering PowerPoint\-resolved object state for parsing and applying bounded shape\-level operations for editing within the same application context\.

This distinction is especially important for Claude\-style PPTX editing workflows that inspect or modify serialized OOXML directly\. As shown in Figure[4](https://arxiv.org/html/2608.20381#S3.F4), theEditPPTparser is not merely a different serialization of the same file contents, but a compact application\-resolved representation that removes package\-level XML redundancy while preserving editable object state\. Across 2,313 parsed slides, this reduces input size from 36\.48M raw\-XML tokens to 8\.45M parser tokens, a 76\.8% reduction, and lowers the estimated input cost by 4\.32×\\times\(Table[5](https://arxiv.org/html/2608.20381#S6.T5)\)\. The advantage is larger on complex slides because raw OOXML repeats style, coordinate, relationship, and object metadata across many XML parts, whereasEditPPTexposes the objects that an editing agent can actually act on\.

This representation and execution alignment reduces ambiguity throughout the pipeline\. The parser exposes editable objects as PowerPoint resolves them, specialist agents select only type\-compatible tools, and validators check both semantic completion and visual layout integrity\. As a result, local editing failures are less likely to propagate across long, content\-dense decks\.

### 3\.2Planning and Targeted Parsing

EditPPTfirst converts a user instruction into slide\-level editing tasks and then parses only the slides needed to execute those tasks\. The planner operates in two stages\. First, it interprets the high\-level scope of the instruction, such as whether the edit applies to a specific slide, a subset of slides, or the entire presentation\. For example, instructions such as “change the title on slide 3” specify an explicit target slide, whereas instructions such as “remove the logo from all slides” induce a deck\-wide scope\. Second, after the relevant slides are parsed, the planner refines the request into shape\-level subtasks that specify the target slide, target object, and intended action\.

#### Structure\-first grounding\.

For each target slide, our method uses a structure\-first slide representation augmented with selective visual information\. Vision\-based GUI agents and screen parsers have made progress in grounding actions from screenshots\(Xieet al\.,[2024](https://arxiv.org/html/2608.20381#bib.bib69); Luet al\.,[2024](https://arxiv.org/html/2608.20381#bib.bib70)\), but applying them across long decks is costly and does not expose the fine\-grained editable state needed for precise modification, such as font attributes, shape colors, table structure, chart data, or object identifiers\. We therefore use a COM\-based slide parser as the primary representation\. Visual signals are used selectively, with image captions extracted during parsing and rendered slide images generated only on demand for visual validation\.

Slide\-level TargetingObject\-level IFSystemCorr↑\\uparrowMiss↓\\downarrowWrng↓\\downarrowSucc↑\\uparrowPart↑\\uparrowFail↓\\downarrowPPTPilot 65\.1%24\.2%10\.7%39\.0%21\.4%39\.6%T2S 42\.5%50\.0%7\.5%24\.6%13\.4%62\.1%Claude Code 94\.7%4\.7%0\.6%83\.8%9\.4%6\.8%EditPPT 79\.4%13\.5%7\.1%65\.7%16\.8%17\.5%

Table 3:Breakdown of modification accuracy\. T2S denotes Talk\-to\-Your\-Slides\. Slide\-level targeting is reported as Correct \(Corr\), Missing \(Miss\), and Wrong \(Wrng\) rates\. Object\-level instruction following \(IF\) is reported as Success \(Succ\), Partial \(Part\), and Fail rates\. Bold values indicate the best value, andunderlinedvalues indicate the second\-best value\.The parser produces a JSON object enumerating native PowerPoint objects and their properties, including object type, geometry, text and font attributes, table and chart contents, image metadata, and slide\-level elements\. Each parsed shape is associated with aShape\_Id, which serves as the addressing handle for downstream tool calls\. For embedded images, the parser stores short captions as image\-level metadata, allowing agents to identify images by visual content when users refer to them explicitly, e\.g\., “delete the dog photo\.” This also helps resolve non\-textual slide content such as diagrams or table screenshots that would otherwise be invisible in the`\.pptx`structure\.

Although COM exposes PowerPoint\-resolved object state, its raw interface is insufficient for reliable agentic editing\. We observed three gaps: native COM properties and methods often lack granularity for rich\-text editing, default paragraph segmentation often misaligns with instruction\-level semantic units, and merged\-cell structures in tables are exposed implicitly rather than as addressable logical cells\. We therefore add reconstruction procedures for run\-level formatting, paragraph\-level segmentation, and merged table cells\.

For text, the parser reconstructs formatting runs and logical paragraph units so that mixed\-format text and paragraph\-like spans can be edited without collapsing local style\. For tables, it infers merged\-cell structure geometrically, allowing downstream agents to address logical cells rather than raw grid positions\. Full algorithmic details and edge cases are provided in Appendices[E\.1](https://arxiv.org/html/2608.20381#A5.SS1)and[E\.2](https://arxiv.org/html/2608.20381#A5.SS2)\.

The resulting slide\-wise shape\-level tasks are grounded in PowerPoint\-resolved object state and passed to the dispatcher and specialist agents for bounded tool execution\.

### 3\.3Specialist Agents and Tool Execution

After planning and targeted parsing, each slide\-level editing task is paired with the JSON representation of its target slide\. The dispatcher inspects the parsed shape inventory, selects the shapes relevant to the task, and routes each selected shape to a specialist agent according to its object type and intended edit\. The specialist then receives the resulting shape\-level task and target shape metadata and invokes the corresponding COM tool\.

### 3\.4Dual\-modal validation

After executing an edit,EditPPTvalidates the result through dual\-modal validation, separating instruction\-level verification from visual\-quality assessment for more robust evaluation\. It re\-parses the edited deck and compares it with the original state and edit plan to ensure that the intended slide object was correctly modified while unrelated elements remain unchanged; additionally, the edited slide is rendered and checked by a VLM\-based validator to detect visual design issues such as overlap, clipping, or unintended layout shifts\.

![Refer to caption](https://arxiv.org/html/2608.20381v1/x4.png)Figure 4:Token efficiency of the EditPPT XML parser\. \(a\) The parser reduces the token footprint and removes the extreme long tail of raw XML, which is used in Claude code and Claude PPT\. \(b\) Compression becomes more effective as slide complexity increases, using shape count as a proxy for complexity\.

## 4DeckEdit\-Bench

To evaluate realistic slide editing over existing presentations, we introduceDeckEdit\-Bench, a benchmark of 28 human\-authored PowerPoint decks, 582 slides, and 183 natural\-language editing prompts\. Unlike slide generation or isolated slide modification, practical presentation editing requires a system to locate the correct target inside an existing deck, apply the requested change, and preserve unrelated content, formatting, and layout\. The benchmark therefore keeps source decks as native`\.pptx`files with heterogeneous layouts, grouped objects, embedded images, tables, charts, shapes, backgrounds, and slide\-level properties\.

### 4\.1Deck Collection and Length Tiers

The deck corpus is curated to reflect presentations that people actually use, drawing from research, teaching, and professional materials in both Korean and English\. Most decks were directly written and used by human authors, while a small number were first drafted with generation assistance and then manually edited into realistic, usable presentations\.

We stratify the corpus by deck length into three tiers: short decks with at most 10 slides, medium decks with 11 to 30 slides, and long decks with more than 30 slides\. The tiers are defined by length rather than difficulty, so short decks may still contain dense, visually rich slides, while long decks stress target selection, preservation, and execution over larger presentation contexts\. Detailed tier statistics are provided in Appendix[B\.1](https://arxiv.org/html/2608.20381#A2.SS1)\.

### 4\.2Editing Prompt Design

For the 28 decks, we create 183 natural\-language editing prompts that reflect user\-facing presentation editing requests\. The prompts do not expose internal shape identifiers, XML paths, object indices, or implementation\-specific handles; therefore, a system must infer the target slide, target object, and intended operation from the instruction and the presentation content\.

The prompts cover both local and presentation\-scale edits, ranging from specified single\-slide modifications to repeated\-target edits across a deck\. We vary both target scope and instruction complexity, yielding four prompt categories: Explicit\-Simple, Explicit\-Compound, Pattern\-Simple, and Pattern\-Compound\. Explicit prompts specify the relevant slide directly, while pattern prompts require identifying recurring targets across multiple slides\. Simple prompts involve a single target or operation, whereas compound prompts require multiple coordinated edits within a single instruction\.

Detailed deck metadata, prompt templates, action labels, target categories, and capability groupings are provided in Appendix[B](https://arxiv.org/html/2608.20381#A2)\.

## 5Experiments

We evaluate reliable slide editing along three criteria: modification accuracy, preservation fidelity, and robustness to deck length\. Accuracy and preservation are measured at both the slide level, where we evaluate whether the system edits only the requested slides, and the object level, where we evaluate whether the requested edit is fulfilled without changing out\-of\-scope objects\. Length robustness is measured by reporting the same metrics across short, medium, and long decks\.

### 5\.1Experimental Setup

All systems are evaluated on the fullDeckEdit\-Benchbenchmark, consisting of 183 deck\-prompt instances across 28 decks\. Each instance starts from a fresh copy of the source deck, so edits do not accumulate across prompts\. A run is considered executable if the system produces an edited`\.pptx`file without runtime failure or unrecoverable file corruption\. We record execution status, output files, logs, API cost, and runtime for each run\.

#### Baselines\.

We compare our method with three baselines\.Talk\-to\-Your\-Slidesis a COM\-based code\-generation baseline for natural\-language presentation editing\.PPTPilotis the editing agent from PPTArena, which alternates betweenpython\-pptxoperations and direct XML manipulation depending on the required edit\.Claude Code \+ PPTX Skillis a strong general\-purpose coding\-agent baseline equipped with PowerPoint editing capability\. All systems receive the same source deck and user instruction and are required to produce an edited`\.pptx`file\.

#### Configuration\.

We use OpenAI GPT\-4\.1 as the backbone language model for all text\-only components of our framework, including the planner, dispatcher, specialist agents, structural validator, and recovery planner\(OpenAI,[2025](https://arxiv.org/html/2608.20381#bib.bib73)\)\. For image\-related processing, we use Gemini 2\.5 Flash\-Lite to generate image captions during parsing and Gemini 2\.5 Pro to judge visual layout defects during validation\(Google,[2026](https://arxiv.org/html/2608.20381#bib.bib74)\)\. Talk\-to\-Your\-Slides and PPTPilot are also evaluated with GPT\-4\.1 under their default tool configurations\(Junget al\.,[2026](https://arxiv.org/html/2608.20381#bib.bib11); Ofengendenet al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib5)\)\. Claude Code \+ PPTX Skill is run with Claude Sonnet 4\.6 and the official PPTX Skill\(Anthropic,[2026b](https://arxiv.org/html/2608.20381#bib.bib76),[c](https://arxiv.org/html/2608.20381#bib.bib78)\)\. For the repeated\-trial variability study, we separately evaluate Claude Sonnet 4\.6 and Claude Opus 4\.7 on the same long\-deck translation task\(Anthropic,[2026b](https://arxiv.org/html/2608.20381#bib.bib76),[a](https://arxiv.org/html/2608.20381#bib.bib77)\)\.

MetricClaudeSonnet 4\.6ClaudeOpus 4\.7EditPPTCost \(full deck\)Avg\. cost$14\.87$43\.18$4\.91Cost SD$11\.08$24\.04$0\.27Avg\. cost / slide$0\.304$0\.881$0\.100Cost / slide SD$0\.226$0\.491$0\.006End\-to\-End Runtime \(full deck\)Avg\. runtime34\.3 min48\.5 min40\.2 minRuntime SD9\.2 min24\.3 min2\.1 minAvg\. runtime / slide42\.0s59\.4s49\.2sRuntime / slide SD11\.3s29\.7s2\.6s

Table 4:Repeated\-trial variability under identical conditions\. Each system was run seven times on the same 49\-page deck with the identical “Translate to English” instruction\.Boldvalues indicate the best result for each metric, whileunderlinedvalues indicate the second\-best result\.

### 5\.2Evaluation

We evaluate edited decks in two stages to separate slide selection from object\-level editing quality\. All LLM and VLM judges use GPT\-5\.5OpenAI \([2026](https://arxiv.org/html/2608.20381#bib.bib79)\), OpenAI’s latest frontier model\.

#### Stage 1\. Slide\-level targeting\.

We first identify which slides were edited\. Each slide is labeled ascorrectly\_targetedif it was requested and edited,missing\_targetif it was requested but unchanged, andwrong\_targetif it was edited despite being outside the requested scope\. Slides that are neither requested nor edited are treated as correctly unchanged and excluded from precision, recall, and F1\. This stage measures slide\-level modification accuracy and slide\-level preservation by LLM Judge\.

#### Stage 2\. Object\-level instruction following\.

On correctly targeted slides, we evaluate whether the requested edit was fulfilled and whether unrelated objects were preserved\. The target edit is labeled assuccess,partial, orfail, wherepartialindicates incomplete fulfillment or minor formatting deviations\. We separately mark apreservation\_errorwhen any object outside the requested edit scope is unintentionally modified\. We also render the before\-and\-after decks and use a VLM judge to assess visual defects and layout changes\.

#### Metrics\.

We report slide\-targeting F1, Instruction Following, Object Preservation Rate, and defect\-complement visual quality, with the main metrics broken down by deck length\.

## 6Results

#### Overall performance\.

Table[2](https://arxiv.org/html/2608.20381#S3.T2)summarizes the overall and length\-wise results onDeckEdit\-Bench\. Our method completes 99\.5% of editing instances and achieves 88\.7% Slide F1, 82\.5% Instruction Following, and 91\.5% object\-level preservation overall\. These results show that the system not only produces valid edited decks reliably, but also selects the intended slides, applies the requested edits, and preserves out\-of\-scope objects with high accuracy\. Table[3](https://arxiv.org/html/2608.20381#S3.T3)further decomposes these scores into slide\-level targeting and object\-level instruction following\. Although Claude Code leads on both stages, our framework outperforms the other native\-edit baselines\.

#### Robustness to deck length\.

As shown in Table[2](https://arxiv.org/html/2608.20381#S3.T2), performance remains stable across deck lengths\. Long decks achieve 90\.5% Slide F1, 86\.6% Instruction Following, and 91\.7% object\-level preservation, improving over the corresponding short\-deck instruction\-following score while staying close to the short\-deck preservation score\. PPTPilot and Talk\-to\-Your\-Slides, by contrast, show clear instruction\-following degradation from short to long decks, suggesting constrained native execution helps reduce length\-induced failure cascades\.

Input representationTokensEst\. costEfficiencyEditPPT Parser8\.45M$16\.894\.3×\\timesRaw XML, full scope36\.48M$72\.971\.0×\\timesTable 5:Token and cost comparison between the EditPPT parser representation and raw XML over 2,313 parsed slides\. Full scope includes both slide XML files and their associated relationship files\. Estimated cost assumes GPT\-4\.1 input pricing without caching\. Efficiency is measured relative to raw XML, where higher is better\.
#### Repeatability\.

Table[4](https://arxiv.org/html/2608.20381#S5.T4)evaluates repeated runs on the same long\-deck translation task\.EditPPThas the lowest average cost and the smallest cost variation, with $4\.91 average cost and $0\.27 standard deviation, compared with $14\.87±\\pm$11\.08 for Claude Sonnet 4\.6 and $43\.18±\\pm$24\.04 for Claude Opus 4\.7\. It also has the lowest runtime variation, 2\.1 minutes across trials, indicating more predictable resource usage under repeated execution\.

#### Additional analyses\.

Appendix[C](https://arxiv.org/html/2608.20381#A3)reports additional result analyses, including modification and preservation breakdowns, qualitative examples, and validation details, while Appendix[D](https://arxiv.org/html/2608.20381#A4)reports parser token efficiency\.

### 6\.1Ablation Study

We ablate two core design choices of our framework, the multi\-agent system and the dual\-modal validator\. Detailed results are reported in Table[6](https://arxiv.org/html/2608.20381#S6.T6)\.

#### Multi\-agent dispatch\.

Replacing the type\-specialized dispatcher with a single general\-purpose agent yields modest accuracy gains, but at substantial efficiency cost: per\-slide cost rises by26\.626\.6% and runtime by10\.010\.0%\. The single agent must reason over the full tool inventory at every step, inflating prompt context and reasoning length\. Object Preservation is unchanged \(91\.591\.5%\), indicating that locality is governed by tool design rather than agent decomposition\. Multi\-agent dispatch therefore offers a favorable accuracy–efficiency trade\-off, with the efficiency advantage compounding on long, content\-dense decks\.

#### Dual\-modal validation\.

Replacing the dual\-modal validator with a single VLM judge — provided with both the rendered slide and the parsed structural state — causes severe regressions across every quality metric, with Instruction Following collapsing by over 37 points and Object Preservation by nearly 32 points\. We attribute this collapse to two likely factors\. First, cognitive overload, as the VLM must judge structure and visuals simultaneously\. Second, modality grounding bias, as it tends to trust visual cues over the structural state\. These findings suggest that relying on a VLM alone to validate slide edits is risky, and that separating structural verification via re\-parsing from visual layout checking is a precondition for reliable validation\.

The specialist architecture operationalizes the action\-space reduction introduced in Section[3\.1](https://arxiv.org/html/2608.20381#S3.SS1)by decomposing slide\-level plans into type\-compatible shape\-level tool calls\. This reduces cross\-object tool misuse before validation and recovery\.

MetricEditPPTEditPPT\+ Single AgentUnifiedVLMPerformanceExec\. Rate99\.5%100\.0%100\.0%Slide F188\.7%90\.6%82\.6%Instr\. Follow\.82\.5%86\.1%44\.7%Preserv\.91\.5%91\.5%59\.6%EfficiencyAvg\. Cost \(×10−2\\times 10^\{\-2\}$/slide\)7\.7410\.059\.71Avg\. Time \(s/slide\)40\.846\.170\.9

Table 6:Ablation study comparing the multi\-agent system with a single\-agent variant and a unified VLM baseline using the same tool set\.

## 7Conclusion

EditPPTreframes presentation editing as constrained tool selection over native PowerPoint objects, rather than as open\-ended code generation or raw file\-structure manipulation\. This design aligns parsing, execution, and validation around the same COM\-resolved object state, allowing agents to perform localized edits while preserving unrelated slide content\. Our parser removes the redundancy of raw OOXML and yields more efficient, repeatable execution across runs, while a dual\-modal validator separates structural verification from visual layout assessment, enabling more robust judgment along each modality\. ThroughDeckEdit\-Bench, we evaluate this setting on human\-authored decks across length tiers and show thatEditPPTmaintains strong execution reliability, slide targeting, instruction following, and object preservation, including on long decks where conventional baselines degrade\. These findings suggest that robust document editing agents should expose less arbitrary executable freedom to LLMs and instead provide typed interfaces that match the native structure of the target application\.

## Limitations

EditPPTcurrently relies on the PowerPoint COM interface, which is tied to the desktop PowerPoint runtime and is effectively single\-threaded for many operations\. This limits straightforward parallelism and makes deployment dependent on environments where PowerPoint automation is available\. The framework is also optimized for concrete editing requests over existing objects, so highly abstract instructions that require extensive design reasoning, content rewriting, or global narrative restructuring may still require stronger planning modules or human review\. Finally, while our validators reduce silent failures, visual judging remains imperfect, especially for subtle aesthetic regressions or domain\-specific formatting conventions\.

## Ethical Considerations

This work aims to improve the reliability of presentation editing tools and can reduce repetitive manual labor in document workflows\. Because the system modifies user\-authored decks, deployments should preserve source files, expose edit logs, and avoid overwriting user content without confirmation\. The benchmark includes human\-authored presentation materials\. All decks inDeckEdit\-Benchwere contributed by the authors or by colleagues who were fully informed of the research purpose and gave consent for their decks to be used in a publicly released benchmark\. We removed or anonymized any sensitive or personally identifying content prior to release, respected source licenses, and avoided exposing private organizational content\. More broadly, automated editing can be used to alter persuasive or educational material at scale, which makes provenance, review, and user control important safeguards\.

#### Use of AI Assistants

We used AI coding assistants for parts of the implementation and AI writing assistants for language polishing of this manuscript\. All technical claims, experimental results, and conclusions were independently verified by the authors\.

## References

- Anthropic \(2026a\)Claude Opus 4\.7\.Note:[https://www\.anthropic\.com/claude/opus](https://www.anthropic.com/claude/opus)Accessed: 2026\-05\-25Cited by:[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- Anthropic \(2026b\)Claude Sonnet 4\.6\.Note:[https://www\.anthropic\.com/claude/sonnet](https://www.anthropic.com/claude/sonnet)Accessed: 2026\-05\-25Cited by:[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- Anthropic \(2026c\)PPTX Skill\.Note:[https://github\.com/anthropics/skills/blob/main/skills/pptx/SKILL\.md](https://github.com/anthropics/skills/blob/main/skills/pptx/SKILL.md)Accessed: 2026\-05\-25Cited by:[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- Anthropic \(2026d\)Using Claude for PowerPoint\.Note:[https://support\.claude\.com/ko/articles/13521390\-powerpoint%EC%9A%A9\-claude\-%EC%82%AC%EC%9A%A9](https://support.claude.com/ko/articles/13521390-powerpoint%EC%9A%A9-claude-%EC%82%AC%EC%9A%A9)Accessed: May 23, 2026Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p2.1)\.
- J\. Ge, Z\. Z\. Wang, X\. Zhou, Y\. Peng, S\. Subramanian, Q\. Tan, M\. Sap, A\. Suhr, D\. Fried, G\. Neubig, and T\. Darrell \(2025\)AutoPresent: designing structured visuals from scratch\.InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition \(CVPR\),External Links:[Link](https://arxiv.org/abs/2501.00912)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- Google \(2026\)Gemini API Models\.Note:[https://ai\.google\.dev/gemini\-api/docs/models](https://ai.google.dev/gemini-api/docs/models)Accessed: 2026\-05\-25Cited by:[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- Z\. Gou, Z\. Shao, Y\. Gong, Y\. Shen, Y\. Yang, N\. Duan, and W\. Chen \(2024\)CRITIC: large language models can self\-correct with tool\-interactive critiquing\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2305.11738)Cited by:[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.SSS0.Px1.p1.1),[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.p1.1)\.
- D\. Jang, M\. L\. Heisler, L\. Xing, Y\. Li, E\. Wang, Y\. Xiong, Y\. Zhang, and Z\. Fan \(2026\)DECKBench: benchmarking multi\-agent frameworks for academic slide generation and editing\.External Links:2602\.13318,[Link](https://arxiv.org/abs/2602.13318)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px2.p1.1)\.
- K\. Jung, H\. Cho, J\. Yun, S\. Yang, J\. Jang, and J\. Choo \(2026\)Talk to your slides: high\-efficiency slide editing via language\-driven structured data manipulation\.External Links:2505\.11604,[Link](https://arxiv.org/abs/2505.11604)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px2.p1.1),[§3\.1](https://arxiv.org/html/2608.20381#S3.SS1.p2.1),[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- H\. Kang, E\. Bao, and A\. Goswami \(2025\)VLM\-slideeval: evaluating vlms on structured comprehension and perturbation sensitivity in ppt\.External Links:2510\.22045,[Link](https://arxiv.org/abs/2510.22045)Cited by:[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.p1.1)\.
- Y\. Liu, D\. Iter, Y\. Xu, S\. Wang, R\. Xu, and C\. Zhu \(2023\)G\-Eval: NLG evaluation using GPT\-4 with better human alignment\.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,External Links:[Link](https://arxiv.org/abs/2303.16634)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px2.p1.1)\.
- Y\. Lu, J\. Yang, Y\. Shen, and A\. Awadallah \(2024\)OmniParser for pure vision based gui agent\.External Links:2408\.00203,[Link](https://arxiv.org/abs/2408.00203)Cited by:[§3\.2](https://arxiv.org/html/2608.20381#S3.SS2.SSS0.Px1.p1.1)\.
- A\. Madaan, N\. Tandon, P\. Gupta, S\. Hallinan, L\. Gao, S\. Wiegreffe, U\. Alon, N\. Dziri, S\. Prabhumoye, Y\. Yang, S\. Gupta, B\. P\. Majumder, K\. Hermann, S\. Welleck, A\. Yazdanbakhsh, and P\. Clark \(2023\)Self\-refine: iterative refinement with self\-feedback\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2303.17651)Cited by:[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.SSS0.Px1.p1.1),[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.p1.1)\.
- M\. Ofengenden, Y\. Man, Z\. Pang, and Y\. Wang \(2025\)PPTArena: a benchmark for agentic powerpoint editing\.External Links:2512\.03042,[Link](https://arxiv.org/abs/2512.03042)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px2.p1.1),[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- OpenAI \(2025\)GPT\-4\.1 Model\.Note:[https://developers\.openai\.com/api/docs/models/gpt\-4\.1](https://developers.openai.com/api/docs/models/gpt-4.1)Accessed: 2026\-05\-25Cited by:[§5\.1](https://arxiv.org/html/2608.20381#S5.SS1.SSS0.Px2.p1.1)\.
- OpenAI \(2026\)GPT\-5\.5 technical report\.Note:[https://www\.openai\.com](https://www.openai.com/)Accessed: 2026Cited by:[§5\.2](https://arxiv.org/html/2608.20381#S5.SS2.p1.1)\.
- Y\. Pan, C\. Hu, X\. Huang, C\. Huang, M\. Zhao, Y\. Bi, X\. Zhang, A\. Zeng, and L\. Hu \(2026\)AeSlides: incentivizing aesthetic layout in llm\-based slide generation via verifiable rewards\.External Links:2604\.22840,[Link](https://arxiv.org/abs/2604.22840)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p2.1)\.
- S\. G\. Patil, T\. Zhang, X\. Wang, and J\. E\. Gonzalez \(2023\)Gorilla: large language model connected with massive apis\.External Links:2305\.15334,[Link](https://arxiv.org/abs/2305.15334)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px1.p1.1)\.
- Y\. Qin, S\. Liang, Y\. Ye, K\. Zhu, L\. Yan, Y\. Lu, Y\. Lin, X\. Cong, X\. Tang, B\. Qian, S\. Zhao, L\. Hong, R\. Tian, R\. Xie, J\. Zhou, M\. Gerstein, D\. Li, Z\. Liu, and M\. Sun \(2024\)ToolLLM: facilitating large language models to master 16000\+ real\-world apis\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2307.16789)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px1.p1.1)\.
- T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, E\. Hambro, L\. Zettlemoyer, N\. Cancedda, and T\. Scialom \(2023\)Toolformer: language models can teach themselves to use tools\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2302.04761)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px1.p1.1)\.
- Z\. Shi, Y\. Chen, H\. Li, W\. Sun, S\. Ni, Y\. Lyu, R\. Fan, B\. Jin, Y\. Weng, M\. Zhu, Q\. Xie, X\. Guo, Q\. Yang, J\. Wu, J\. Zhao, X\. Tang, X\. Ma, C\. Wang, J\. Mao, Q\. Ai, J\. Huang, W\. Wang, Y\. Zhang, Y\. Yang, Z\. Tu, and Z\. Ren \(2025\)Deep research: a systematic survey\.External Links:2512\.02038,[Link](https://arxiv.org/abs/2512.02038)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1)\.
- N\. Shinn, F\. Cassano, A\. Gopinath, K\. Narasimhan, and S\. Yao \(2023\)Reflexion: language agents with verbal reinforcement learning\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2303.11366)Cited by:[§C\.4](https://arxiv.org/html/2608.20381#A3.SS4.SSS0.Px1.p1.1)\.
- Q\. Wu, G\. Bansal, J\. Zhang, Y\. Wu, B\. Li, E\. Zhu, L\. Jiang, X\. Zhang, S\. Zhang, J\. Liu, A\. H\. Awadallah, R\. W\. White, D\. Burger, and C\. Wang \(2023\)AutoGen: enabling next\-gen llm applications via multi\-agent conversation\.External Links:2308\.08155,[Link](https://arxiv.org/abs/2308.08155)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px1.p1.1)\.
- W\. Wu, Z\. Xu, Z\. Zhang, Y\. Zhao, and H\. Tang \(2026\)PresentAgent\-2: towards generalist multimodal presentation agents\.External Links:2605\.11363,[Link](https://arxiv.org/abs/2605.11363)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- T\. Xie, D\. Zhang, J\. Chen, X\. Li, S\. Zhao, R\. Cao, T\. J\. Hua, Z\. Cheng, D\. Shin, F\. Lei, Y\. Liu, Y\. Xu, S\. Zhou, S\. Savarese, C\. Xiong, V\. Zhong, and T\. Yu \(2024\)OSWorld: benchmarking multimodal agents for open\-ended tasks in real computer environments\.External Links:2404\.07972,[Link](https://arxiv.org/abs/2404.07972)Cited by:[§3\.2](https://arxiv.org/html/2608.20381#S3.SS2.SSS0.Px1.p1.1)\.
- Y\. Yang, W\. Jiang, Y\. Wang, Y\. Wang, and C\. Zhang \(2025\)Auto\-Slides: an interactive multi\-agent system for creating and customizing research presentations\.External Links:2509\.11062,[Link](https://arxiv.org/abs/2509.11062)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. Cao \(2023\)ReAct: synergizing reasoning and acting in language models\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2210.03629)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px1.p1.1)\.
- W\. Zeng, M\. Ouyang, L\. Cui, and H\. T\. Ng \(2025\)SlideTailor: personalized presentation slide generation for scientific papers\.External Links:2512\.20292,[Link](https://arxiv.org/abs/2512.20292)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- H\. Zheng, X\. Guan, H\. Kong, W\. Zhang, J\. Zheng, W\. Zhou, H\. Lin, Y\. Lu, X\. Han, and L\. Sun \(2025\)PPTAgent: generating and evaluating presentations beyond text\-to\-slides\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,C\. Christodoulopoulos, T\. Chakraborty, C\. Rose, and V\. Peng \(Eds\.\),Suzhou, China,pp\. 14402–14418\.External Links:[Link](https://aclanthology.org/2025.emnlp-main.728/),[Document](https://dx.doi.org/10.18653/v1/2025.emnlp-main.728),ISBN 979\-8\-89176\-332\-6Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§1](https://arxiv.org/html/2608.20381#S1.p2.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- H\. Zheng, G\. Mo, X\. Yan, Q\. Yuan, W\. Zhang, X\. Chen, Y\. Lu, H\. Lin, X\. Han, and L\. Sun \(2026\)DeepPresenter: environment\-grounded reflection for agentic presentation generation\.External Links:2602\.22839,[Link](https://arxiv.org/abs/2602.22839)Cited by:[§1](https://arxiv.org/html/2608.20381#S1.p1.1),[§2](https://arxiv.org/html/2608.20381#S2.SS0.SSS0.Px1.p1.1)\.
- L\. Zheng, W\. Chiang, Y\. Sheng, S\. Zhuang, Z\. Wu, Y\. Zhuang, Z\. Lin, Z\. Li, D\. Li, E\. P\. Xing, H\. Zhang, J\. E\. Gonzalez, and I\. Stoica \(2023\)Judging LLM\-as\-a\-judge with MT\-Bench and chatbot arena\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2306.05685)Cited by:[Appendix A](https://arxiv.org/html/2608.20381#A1.SS0.SSS0.Px2.p1.1)\.

## Appendix ARelated Works \(continued\)

#### Tool\-augmented and multi\-agent LLM systems\.

Tool\-augmented LLMs extend language models by enabling them to invoke external tools, APIs, and executable functions during reasoning and task execution\(Schicket al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib61); Yaoet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib62); Qinet al\.,[2024](https://arxiv.org/html/2608.20381#bib.bib63); Patilet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib64)\)\. Multi\-agent frameworks further decompose complex tasks into specialized roles, improving modularity across planning, execution, and verification\(Wuet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib65)\)\. Building on this paradigm, our solution adapts tool\-augmented execution to native presentation editing through constrained specialist agents, each restricted to a narrow, type\-consistent subset of deterministic shape\-level tools\. This restriction reduces the effective action space exposed to each agent and mitigates cross\-object tool misuse, thereby improving the reliability of structured slide editing\.

#### LLM\- and VLM\-based validation\.

LLM\-as\-judge methods have been widely used to evaluate open\-ended model outputs, including instruction following, response quality, and task completion\(Zhenget al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib66); Liuet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib67)\)\. Recent work has also extended this paradigm to multimodal settings, where VLMs assess visual outputs or detect layout\-level defects\. In slide editing, such evaluators are useful because success requires both semantic instruction fulfillment and visual layout integrity, but most judge\-based protocols are used primarily as post\-hoc evaluation mechanisms\. In contrast,EditPPTincorporates modality\-decoupled validation into the editing loop: a structural validator checks instruction fulfillment and unintended object\-level changes from parsed slide states, while a visual validator detects newly introduced layout defects from rendered slides\. These validators provide recovery signals for replanning and repair, rather than serving only as final evaluators\.

## Appendix BAdditional Benchmark Details

DeckEdit\-Benchincludes prompt metadata for target scope, action type, object category, and instruction complexity\. Explicit prompts name a target slide, while pattern prompts require locating recurring or conditional targets, and compound prompts require multiple coordinated object\-level edits within a single instruction\.

### B\.1DeckEdit\-BenchStatistics

Table[7](https://arxiv.org/html/2608.20381#A2.T7)reports the detailed corpus statistics by deck\-length tier\. Tiers are defined by slide count rather than by intrinsic difficulty or slide simplicity, and all tiers contain native PowerPoint objects and heterogeneous layouts\.

TierSlide range\# Decks\# Slides\# Prompts\# ShapesShapes / SlideShort≤\\leq109465450510\.98Medium11 to 3012241811,7587\.29Long\>\>307295484,49415\.23TotalAll285821836,75711\.61

Table 7:Statistics ofDeckEdit\-Bench\. Tiers are defined by deck length, but all tiers contain structurally rich slides with native PowerPoint objects\.
### B\.2Examples fromDeckEdit\-Bench

Figure[5](https://arxiv.org/html/2608.20381#A2.F5)shows representative examples fromDeckEdit\-Bench\. Each example is paired with its pristine target slide\.

![Refer to caption](https://arxiv.org/html/2608.20381v1/x5.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x6.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x7.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x8.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x9.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x10.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x11.png)

![Refer to caption](https://arxiv.org/html/2608.20381v1/x12.png)

Figure 5:Representative editing instructions fromDeckEdit\-Bench, each paired with its pristine target slide\. Explicit prompts directly specify the target slide or object, whereas pattern prompts require the system to infer recurring targets across the deck\. Simple prompts involve a single operation, while compound prompts require multiple coordinated edits\. Pattern examples show one representative slide containing the recurring target\.

## Appendix CAdditional Result Analyses

### C\.1Modification Breakdown

Remaining failures are concentrated in target selection rather than local tool execution\. Pattern\-Compound tasks are the most difficult because they require conditional slide selection across a deck, while ADD operations are the easiest and reach near\-perfect instruction following once the target is found\.

### C\.2Detailed Preservation Results

The detailed preservation breakdown shows thatEditPPT’s strongest advantage is object preservation: it reaches 91\.5% overall preservation and remains above 90% in every length tier\. Its remaining preservation errors mainly arise from pattern\-based instructions, where the system must infer recurring targets across multiple slides, rather than from explicit single\-slide edits\.

SystemBreakdownCategoryInst\.Slide\-levelObject\-levelWrong Slide Edits↓\\downarrowObject Preserv\.↑\\uparrowPPTPilotTask typeExplicit\-Single1361\.8%76\.9%Explicit\-Compound3963\.4%58\.8%Pattern\-Single778\.0%61\.1%Pattern\-Compound1815\.1%87\.6%Action typeADD1515\.2%77\.7%REPLACE10514\.6%57\.6%DELETE153\.8%73\.2%SLIDE70\.0%58\.3%Talk\-to\-Your\-SlidesTask typeExplicit\-Single170\.0%76\.5%Explicit\-Compound570\.0%60\.0%Pattern\-Single6510\.7%73\.6%Pattern\-Compound2115\.0%81\.5%Action typeADD120\.0%89\.4%REPLACE12111\.6%75\.5%DELETE1333\.3%65\.0%SLIDE90\.0%56\.2%Claude Code \+ PPTX SkillTask typeExplicit\-Single170\.0%93\.8%Explicit\-Compound570\.0%92\.6%Pattern\-Single870\.4%76\.2%Pattern\-Compound221\.5%88\.7%Action typeADD180\.0%84\.1%REPLACE1320\.5%73\.8%DELETE170\.9%79\.6%SLIDE110\.0%100\.0%EditPPTTask typeExplicit\-Single170\.0%93\.8%Explicit\-Compound570\.0%84\.0%Pattern\-Single866\.2%89\.8%Pattern\-Compound2215\.1%93\.7%Action typeADD180\.0%87\.5%REPLACE1317\.5%89\.9%DELETE1720\.1%94\.5%SLIDE116\.7%92\.4%Table 8:Detailed preservation fidelity analysis by system, task type, and action type\. Slide\-level preservation is measured by Wrong Slide Edits, the proportion of slide\-level targeting outcomes labeled aswrong\_target, indicating edits to slides outside the requested scope\. Object\-level preservation is measured by Object Preserv\., the proportion of correctly targeted slides withoutpreservation\_error\.
### C\.3Qualitative Comparison

Figure[3](https://arxiv.org/html/2608.20381#S1.F3)compares representative presentation\-editing strategies\. The qualitative examples show that open\-ended code or structure\-level editing can satisfy the requested operation while still introducing unintended changes to neighboring content, whereasEditPPTlocalizes execution through typed shape\-level tools and therefore better preserves unrelated slide elements\.

### C\.4Validation and Recovery Details

A successful COM call does not necessarily imply a successful edit: the operation may execute without error while failing to satisfy the user instruction or introducing a layout defect\. This mirrors recent findings that external feedback and critic\-in\-the\-loop refinement can improve agent reliability, but that VLM\-based slide assessment remains imperfect and benefits from calibration\(Madaanet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib71); Gouet al\.,[2024](https://arxiv.org/html/2608.20381#bib.bib72); Kanget al\.,[2025](https://arxiv.org/html/2608.20381#bib.bib8)\)\.EditPPTtherefore validates each edited slide with two complementary modules\. A structural validator checks instruction fulfillment from the before/after parsed slide state, while a visual validator inspects the rendered slide for layout errors introduced during editing\.

#### Structural validation\.

The structural validator receives the user instruction, the slide\-level task, and the difference between the parsed slide JSON before and after editing\. It checks whether the intended edit was applied to the correct target without unintended changes to unrelated objects or parsed properties\. For severe failures, such as incorrect target selection or a missing edit,EditPPTrestores the slide\-level checkpoint and retries the specialist with validator feedback, following verbal self\-reflection and iterative feedback\-based refinement\(Shinnet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib68); Madaanet al\.,[2023](https://arxiv.org/html/2608.20381#bib.bib71); Gouet al\.,[2024](https://arxiv.org/html/2608.20381#bib.bib72)\)\. For partially correct edits, the validator instead produces an incremental correction plan so that the specialist can complete only the remaining local modification\.

## Appendix DParser Efficiency

### D\.1XML\-Parser Token Efficiency

To quantify the benefit of our parser, we compare the token footprint of EditPPT parser output against raw XML input\. As shown in Table[5](https://arxiv.org/html/2608.20381#S6.T5), the parser reduces total input tokens from 36\.48M to 8\.45M, a 76\.8% reduction\. This also lowers the estimated input cost from $72\.97 to $16\.89, corresponding to a 4\.32×\\timesreduction\.

Figure[4](https://arxiv.org/html/2608.20381#S3.F4)\(a\) further shows that the reduction is not limited to aggregate cost\. Raw XML exhibits a heavy\-tailed token distribution, reaching up to 1\.1M tokens for a single slide, while the parser output is capped at 31K tokens in this set\. Thus, the parser improves both efficiency and robustness by reducing average input size as well as extreme context\-length outliers\.

We also find that the parser becomes more effective as slide complexity increases\. Figure[4](https://arxiv.org/html/2608.20381#S3.F4)\(b\) plots compression efficiency against the number of shapes per slide, using shape count as a proxy for slide complexity\. Slides with more shapes tend to contain more repeated style, coordinate, relationship, and object\-level metadata in raw XML\. The parser removes much of this redundant low\-level structure and represents the slide in a compact semantic form, leading to larger relative token savings on more complex slides\.

StageInputOutputPlanningUser instructionSlide\-level tasksParsingTarget slidesShape JSON statesDispatchTasks and shapesSpecialist callsExecutionTyped argumentsCOM editsValidationBefore/after statesAccept or recover

Table 9:TheEditPPTpipeline keeps each step grounded in PowerPoint\-resolved objects, from planning to validation\.COM gapReconstructionEditing benefitMixed text styleRun\-level spansPreserves formattingParagraph mismatchLogical segmentsTargets bullets and subtitlesMerged table cellsGeometric groupingEdits logical cellsImage\-only contentCaption metadataGrounds visual references

Table 10:Parser augmentations used to convert raw COM state into editable units that better match natural\-language slide\-editing instructions\.

## Appendix ETechnical Implementation Details

#### Parser\.

The Parser converts all objects on each slide, including text, tables, charts, images, and shapes, into a JSON structure via the PowerPoint COM API\. To avoid redundant work, it caches per\-slide parse results indatabase\[page\_number\]\. When a retry is needed after an edit, the parser bypasses the cache withforce=Trueso that the latest slide state is parsed, and edit history is stored as snapshots inedit\_history\.

#### JSON structure:

1\{

2"Objects\_Detail":\[

3\{

4"Shape\_Id":2,

5"Name":"Title1",

6"Type":"TextBox",

7"More\_detail":\{

8"TextFrame":\{

9"Runs":\[

10\{"Text":"Hello","Font":\{"Name":"MalgunGothic","Size":24,"Bold":true\}\}

11\]

12\}

13\}

14\},

15\{

16"Shape\_Id":5,

17"Name":"Table1",

18"Type":"Table",

19"More\_detail":\{

20"Table":\{

21"Cells":\{

22"1,1":\{"Text":"Item","Runs":\[\.\.\.\]\},

23"1,2":\{"Text":"Value","Runs":\[\.\.\.\]\}

24\}

25\}

26\}

27\}

28\]

29\}

#### Planner\.

Table 11:Planner ModesModeDescriptionExample UsageexplicitSpecifies individual tasks for each slide“Change the title on page 1 to red, and highlight the table header on slide 4 in blue\.”patternTemplate\-based repetitive tasks \(page number substituted via\{i\}\)“Change the body font to Arial on all slides”
#### Task plan JSON:

1\{

2"understanding":"Theuserwantstochangethetitleonslide1toredandhighlightthetableheaderonslide4inblue\.",

3"tasks":\[

4\{

5"page\_number":1,

6"description":"Changethefontcolorofthetitletexttored",

7"action":"changefontcolortored",

8"target":"title",

9"contents":\{"color":"\#FF0000"\}

10\},

11\{

12"page\_number":4,

13"description":"Changethefontcolorofthetableheadertoblue",

14"action":"changetableheadercelltoblue",

15"target":"tableheader",

16"contents":\{"color":"\#0000FF"\}

17\}

18\]

19\}

#### Dispatcher\.

DispatcherAgent routes tasks to specialized agents\. When parsed slide data is available, the LLM performs multi\-dispatch by classifying relevant shapes and grouping them by agent type\. Slide\-level operations such as adding or deleting slides are routed directly to the slide agent, while classification failures fall back to thetext\_styleagent\.

1FALLBACK\_AGENT="text\_style"

2

3classDispatcherAgent:

4defdispatch\(self,task,slide\_objects=None\):

5ifnotslide\_objects:

6returnself\.\_dispatch\_single\(task\)

7shape\_summary=\[

8\{"Shape\_Id":obj\["Shape\_Id"\],"Name":obj\["Name"\],"Type":obj\["Type"\]\}

9forobjinslide\_objects

10\]

11response=call\_llm\(

12model=self\.model,

13messages=\[

14\{"role":"system","content":system\_prompt\},

15\{"role":"user","content":user\_prompt\},

16\],

17\)

#### Specialist Agents : 5 types\.

Table 12:Agent RegistryAgentDescriptionNo\. of ToolsTool Listtext\_styleText content and formatting edits7set\_text\_style, edit\_text\_insert, edit\_text\_delete, edit\_text\_replace, edit\_text\_rewrite, set\_paragraph\_alignment, manage\_bullet\_pointstableTable structure and cell editing3cell\_text\_style, replace\_table\_text, table\_layout\_stylechartChart data and style modification5update\_chart\_categories, update\_chart\_series, update\_chart\_structure, update\_chart\_axes, update\_chart\_colorsshape\_layoutShape placement, creation, and image insertion13adjust\_layout, distribute\_shapes, align\_shapes, create\_textbox, create\_placeholder, create\_shape, delete\_shape, duplicate\_shape, duplicate\_shape\_within\_slide, apply\_visual\_style, apply\_gradient\_fill, insert\_image, edit\_imageslideSlide\-level operations5add\_slide, delete\_slide, duplicate\_slide, set\_slide\_transition, set\_slide\_background1@dataclass

2classAgentSpec:

3agent\_type:str

4tool\_names:List\[str\]

5system\_prompt\_builder:Callable\[\[str\],str\]

6description:str

7

8AGENT\_REGISTRY:dict\[str,AgentSpec\]=\{\}

9

10register\_agent\(AgentSpec\(

11agent\_type="text\_style",

12tool\_names=\[

13"set\_text\_style","edit\_text\_insert","edit\_text\_delete",

14"edit\_text\_replace","edit\_text\_rewrite",

15"set\_paragraph\_alignment","manage\_bullet\_points",

16\],

17system\_prompt\_builder=create\_text\_style\_agent\_system\_prompt,

18description="Textcontentandformatting\.\.\.",

19\)\)

#### BaseEditAgent : retry \+ rollback\.

BaseEditAgent executes each edit as a bounded retry\-and\-rollback loop\. It first parses the slide withparser\.process\(\), usingforce=Trueon retries to bypass cached state, and filters the parsed JSON to theshape\_idsselected by the dispatcher\. The agent then constructs a specialist prompt from the system prompt, target slide JSON, and user request, calls the LLM to select a tool and arguments through function calling, and injects required runtime fields such asslide\_jsonandagent\_requestaccording toToolMeta\. After COM execution, text tools callclamp\_text\_to\_slide\(\)and other tools callclamp\_shapes\_to\_slide\(\)\. The result is checked by the text validator and, when enabled, the vision validator, after which the runtime either saves the edit, restores a checkpoint and retries, or keeps the current state and applies an incremental correction\.

#### Tools : 33 tools\.

#### Text Editing \(7 tools\):

set\_text\_style, edit\_text\_insert, edit\_text\_delete, edit\_text\_replace, edit\_text\_rewrite, set\_paragraph\_alignment, manage\_bullet\_points

#### Table Editing \(3 tools\):

cell\_text\_style, replace\_table\_text, table\_layout\_style

#### Chart Editing \(5 tools\):

update\_chart\_categories, update\_chart\_series, update\_chart\_structure, update\_chart\_axes, update\_chart\_colors

#### Shape/Layout \(13 tools\):

adjust\_layout, distribute\_shapes, align\_shapes, create\_textbox, create\_placeholder, create\_shape, delete\_shape, duplicate\_shape, duplicate\_shape\_within\_slide, apply\_visual\_style, apply\_gradient\_fill, insert\_image, edit\_image

#### Slide Management \(5 tools\):

add\_slide, delete\_slide, duplicate\_slide, set\_slide\_transition, set\_slide\_background

1@dataclass

2classToolMeta:

3needs\_slide\_json:bool=False

4needs\_agent\_request:bool=False

5needs\_container:bool=False

6cleanup\_false\_args:list\|None=None

7

8meta=TOOL\_METADATA\.get\(function\_name\)

9ifmeta:

10ifmeta\.needs\_slide\_json:

11function\_args\["slide\_json"\]=contents

12ifmeta\.needs\_agent\_request:

13function\_args\["agent\_request"\]=agent\_request

#### Validator\.

#### Text Validator \(required\):

Validates editing results by comparing old\_parse and new\_parse using an LLM\.

1defupdate\_after\_edit\(self,text\_validation,model,page\_number,

2description,action,detailed\_contents,used\_tools\):

3old\_parse=self\.database\[page\_number\]

4new\_parse=parse\_active\_slide\_objects\(

5page\_number,self\.container\.prs,self\.container\.ppt\_app

6\)

7response=call\_llm\(

8model=model,

9messages=\[

10\{"role":"system","content":create\_text\_validator\_agent\_system\_prompt\(\.\.\.\)\},

11\{"role":"user","content":create\_text\_validator\_agent\_user\_prompt\(

12old\_parse,new\_parse,used\_tools

13\)\},

14\],

15\)

16return\(valid,reason,strategy,new\_parse\)

#### Vision Validator \(in development\):

Exports the slide as a PNG and performs visual validation using Gemini 2\.5 Pro\.

1classVisionValidatorAgent:

2@classmethod

3defcreate\(cls,activate\_valid=False,container=None,model=None\):

4returncls\(activate\_valid,container,model\)

5

6defprocess\(self,page\_number,agent\_request,parsed\_contents,used\_tools\):

7slide\.Export\(str\(screenshot\_path\),"PNG"\)

8response=call\_llm\(model=self\.model,messages=\[\.\.\.\]\)

9return\(valid,reason\)

#### Bounds Clamping\.

Table 13:Bounds Clamping TargetsTarget ToolsClamping FunctionBehaviorText tools \(edit\_text\_rewrite, edit\_text\_replace, edit\_text\_insert, replace\_table\_text, set\_text\_style, manage\_bullet\_points\)clamp\_text\_to\_slide\(\)Proportionally reduces font size at the Run level to fit text within the shape \(up to 5 passes\)Other toolsclamp\_shapes\_to\_slide\(\)Repositions or resizes shapes that have moved outside the slide boundary1\_TEXT\_CLAMP\_TOOLS=\{

2"edit\_text\_rewrite","edit\_text\_replace","edit\_text\_insert",

3"replace\_table\_text","set\_text\_style","manage\_bullet\_points",

4\}

5

6def\_execute\_tool\(self,name,args\):

7result=FUNCTION\_MAP\[name\]\(\*\*args\)

8ifnamein\_TEXT\_CLAMP\_TOOLS:

9clamp\_text\_to\_slide\(prs,slide\_number,shape\_id\)

10else:

11clamp\_shapes\_to\_slide\(prs,slide\_number\)

#### Pipeline Summary\.

Table 14:Pipeline SummaryStepComponentRoleOn Failure1PlannerNatural language→\\rightarrowstructured task listUp to 3 LLM retries2ParserSlide→\\rightarrowJSON databaseInvalidate cache and re\-parse3DispatcherTask→\\rightarrowspecialized agent routingFallback to text\_style4Specialist AgentLLM Tool Calling→\\rightarrowCOM executionRollback \+ up to 3 retries5ValidatorValidate editing results \(text/vision\)Strategy\-based branching \(incremental/rollback\)6Bounds ClampingPrevent shapes from exceeding slide boundsAdaptive font reduction / position adjustment
### E\.1In\-House Algorithms

#### Run\-Level Parsing\.

#### Problem:

The PowerPoint COMTextFrame2\.TextRange\.RunsAPI does not return Run boundaries accurately in a dynamic dispatch environment\.

#### Solution:

Character\-level font snapshot comparison

#### Step 1 : snap\(\)\.

1defsnap\(font\):

2iffontisNone:

3return\(None,0\.0,False,False,False,None,False,False,False\)

4return\(

5safe\(font,"Name"\),

6round\(float\(safe\(font,"Size",0\)\),1\),

7bool\(safe\(font,"Bold",0\)\),

8bool\(safe\(font,"Italic",0\)\),

9bool\(safe\(font,"Underline",0\)\),

10rgb\_of\(font\),

11bool\(safe\(font,"Strikethrough",0\)\),

12bool\(safe\(font,"Subscript",0\)\),

13bool\(safe\(font,"Superscript",0\)\),

14\)

#### Step 2 : parse\_text\_frame\_debug\(\)\.

1defparse\_text\_frame\_debug\(text\_frame\):

2tr=text\_frame\.TextRange

3full=tr\.Text

4runs=\[\]

5n=safe\(tr,"Length",len\(full\)\)

6cur\_idx=1

7cur\_snap=snap\(safe\(tr\.Characters\(cur\_idx,1\),"Font"\)\)

8foriinrange\(2,n\+1\):

9nxt\_snap=snap\(safe\(tr\.Characters\(i,1\),"Font"\)\)

10ifnxt\_snap\!=cur\_snap:

11seg\_len=i\-cur\_idx

12runs\.append\(make\_run\_dict\(tr\.Characters\(cur\_idx,seg\_len\)\)\)

13cur\_idx=i

14cur\_snap=nxt\_snap

15runs\.append\(make\_run\_dict\(tr\.Characters\(cur\_idx,n\-cur\_idx\+1\)\)\)

16cp\_offset=0

17forruninruns:

18run\["Run\_Start\_Index"\]=cp\_offset

19cp\_offset\+=len\(run\.get\("Text",""\)\)

20return\{"HasText":True,"Text":full,"Runs":runs,

21"Paragraphs":parse\_paragraph\_bullets\(text\_frame\)\}

#### Step 3 : make\_run\_dict\(\)\.

1defmake\_run\_dict\(text\_range\_segment\):

2text=safe\(text\_range\_segment,"Text",""\)

3run=\{"Text":text\}

4f=safe\(text\_range\_segment,"Font"\)

5ifnotf:

6returnrun

7font\_dict=\{\}

8name=safe\(f,"Name"\)

9ifnameisnotNone:

10font\_dict\["Name"\]=name

11size=safe\(f,"Size"\)

12ifsizeisnotNone:

13font\_dict\["Size"\]=size

14ifsafe\(f,"Bold",0\):font\_dict\["Bold"\]=True

15ifsafe\(f,"Italic",0\):font\_dict\["Italic"\]=True

16ifsafe\(f,"Underline",0\):font\_dict\["Underline"\]=True

17ifsafe\(f,"Strikethrough",0\):font\_dict\["Strikethrough"\]=True

18ifsafe\(f,"Subscript",0\):font\_dict\["Subscript"\]=True

19ifsafe\(f,"Superscript",0\):font\_dict\["Superscript"\]=True

20rgb=rgb\_of\(f\)

21ifrgbisnotNone:

22font\_dict\["Color"\]=rgb

23iffont\_dict:

24run\["Font"\]=font\_dict

25returnrun

#### Key Issues and Resolutions:

Table 15:Run\-Level Parsing IssuesIssueResolutionCOM uses UTF\-16 indexing while Python uses code point indexingIterate usingtr\.Length\(UTF\-16\); storeRun\_Start\_Indexin code point unitshasattr\(\)misbehaves under COM dynamic dispatchWrap all attribute access with asafe\(\)helper usingtry/exceptCOM RGB uses BGR byte orderInrgb\_of\(\):bgr & 0xFF→\\rightarrowR,\(bgr \>\> 8\) & 0xFF→\\rightarrowG,\(bgr \>\> 16\) & 0xFF→\\rightarrowB
#### Table Merged Cell Tracking\.

#### Problem:

The PowerPoint COM API does not directly expose merged cell information for tables\.

#### Solution:

Geometric bounding box comparison

1defparse\_table\(table\):

2rows=table\.Rows\.Count

3cols=table\.Columns\.Count

4result=\{"Dimensions":\{"Rows":rows,"Columns":cols\},"Cells":\{\}\}

5visited=\{\}

6forrinrange\(1,rows\+1\):

7forcinrange\(1,cols\+1\):

8cell=table\.Cell\(r,c\)

9shape=cell\.Shape

10geom\_key=\(

11round\(shape\.Left,2\),

12round\(shape\.Top,2\),

13round\(shape\.Width,2\),

14round\(shape\.Height,2\),

15\)

16ifgeom\_keyinvisited:

17anchor\_r,anchor\_c=visited\[geom\_key\]

18key=f"\{anchor\_r\},\{anchor\_c\}"

19anchor\_cell=result\["Cells"\]\[key\]

20anchor\_cell\["\_RowSpan"\]=max\(

21anchor\_cell\["\_RowSpan"\],r\-anchor\_r\+1

22\)

23anchor\_cell\["\_ColSpan"\]=max\(

24anchor\_cell\["\_ColSpan"\],c\-anchor\_c\+1

25\)

26continue

27visited\[geom\_key\]=\(r,c\)

28tf\_detail=clean\_cell\_detail\(

29parse\_text\_frame\_debug\(shape\.TextFrame\)

30\)

31cell\_detail=\{

32"Text":tf\_detail\.get\("Text",""\),

33"Runs":tf\_detail\.get\("Runs",\[\]\),

34"\_RowSpan":1,

35"\_ColSpan":1,

36\}

37v\_anchor=safe\(shape\.TextFrame,"VerticalAnchor",None\)

38ifv\_anchorisnotNoneandv\_anchor\!=1:

39cell\_detail\["VerticalAlign"\]=\{3:"middle",4:"bottom"\}\.get\(v\_anchor\)

40if"Paragraphs"intf\_detail:

41cell\_detail\["Paragraphs"\]=tf\_detail\["Paragraphs"\]

42bg=get\_cell\_bg\_color\_hex\(shape\)

43ifbg:

44cell\_detail\["BgColor"\]=bg

45result\["Cells"\]\[f"\{r\},\{c\}"\]=cell\_detail

46forkey,cellinlist\(result\["Cells"\]\.items\(\)\):

47rs=cell\.pop\("\_RowSpan"\)

48cs=cell\.pop\("\_ColSpan"\)

49ifrs\>1orcs\>1:

50cell\["Merged"\]=True

51cell\["RowSpan"\]=rs

52cell\["ColSpan"\]=cs

53returnresult

#### Output Example:

1\{

2"Dimensions":\{"Rows":3,"Columns":3\},

3"Cells":\{

4"1,1":\{

5"Text":"MergedHeader",

6"Runs":\[\{"Text":"MergedHeader","Font":\{"Name":"MalgunGothic","Size":14,"Bold":true\}\}\],

7"Merged":true,

8"RowSpan":2,

9"ColSpan":2

10\},

11"1,3":\{"Text":"RegularCell","Runs":\[\.\.\.\]\},

12"2,3":\{"Text":"RegularCell","Runs":\[\.\.\.\]\},

13"3,1":\{"Text":"Bottom","Runs":\[\.\.\.\]\}

14\}

15\}

#### Textbox Autosizing\.

#### Problem:

After editing text, if the content becomes longer, it may overflow outside the shape or extend beyond the slide boundary\.

#### Solution:

Two\-tier adaptive font reduction system

#### Tier 1 : Inside edit\_text\_rewrite\.

1ifnotis\_auto\_sizeandauto\_resize:

2new\_tr=tf\.TextRange

3shape\.Width=original\_width

4current\_size=new\_tr\.Font\.Sizeifnew\_tr\.Font\.Sizeelse12\.0

5ifold\_base\_font\_size:

6current\_size=min\(current\_size,old\_base\_font\_size\)

7whilenew\_tr\.BoundHeight\>original\_heightandcurrent\_size\>9\.0:

8current\_size\-=0\.5

9new\_tr\.Font\.Size=current\_size

10ifnew\_tr\.Font\.Sizeandcurrent\_size\!=new\_tr\.Font\.Size:

11scale=current\_size/new\_tr\.Font\.Size

12foriinrange\(1,new\_tr\.Length\+1\):

13ch=new\_tr\.Characters\(i,1\)

14ifch\.Font\.Size:

15ch\.Font\.Size\*=scale

Table 16:Tier 1 BehaviorPhaseTargetBehaviorLower BoundUniform reductionEntire textRepeatFont\.Size \-= 0\.59\.0ptProportional scalingPer characterch\.Font\.Size \*= scalePreserves original ratio
#### Tier 2 : clamp\_text\_to\_slide\.

1defclamp\_text\_to\_slide\(prs,slide\_number,shape\_id\):

2slide\_w=prs\.PageSetup\.SlideWidth

3slide\_h=prs\.PageSetup\.SlideHeight

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5ifnotshape\.HasTextFrame:

6return

7def\_overflow\(\):

8over\_r=\(shape\.Left\+shape\.Width\)\-slide\_w

9over\_b=\(shape\.Top\+shape\.Height\)\-slide\_h

10returnmax\(0,over\_r,over\_b\)

11if\_overflow\(\)<=1:

12return

13run\_info=\[\]

14tr=shape\.TextFrame\.TextRange

15forpiinrange\(1,tr\.Paragraphs\(\)\.Count\+1\):

16para=tr\.Paragraphs\(pi\)

17rc=para\.Runs\(\)\.Count

18ifrc==0:

19size=para\.Font\.Sizeifpara\.Font\.Sizeandpara\.Font\.Size\>0else12\.0

20run\_info\.append\(\(para,size\)\)

21else:

22forriinrange\(1,rc\+1\):

23run=para\.Runs\(ri\)

24size=run\.Font\.Sizeifrun\.Font\.Sizeandrun\.Font\.Size\>0else12\.0

25run\_info\.append\(\(run,size\)\)

26max\_orig=max\(sfor\_,sinrun\_info\)

27min\_allowed=max\(6\.0,max\_orig\*0\.5\)

28def\_apply\_scale\(scale\_factor\):

29forrun\_obj,originrun\_info:

30new\_s=max\(min\_allowed,round\(orig\*scale\_factor\*2\)/2\)

31run\_obj\.Font\.Size=new\_s

32shape\_dim=max\(shape\.Width,shape\.Height,1\)

33scale=max\(0\.5,1\.0\-\_overflow\(\)/shape\_dim\)

34\_apply\_scale\(scale\)

35for\_inrange\(4\):

36ovf=\_overflow\(\)

37ifovf<=1:

38break

39scale\*=max\(0\.7,1\.0\-ovf/shape\_dim\)

40scale=max\(0\.5,scale\)

41\_apply\_scale\(scale\)

#### Algorithm Properties:

Table 17:Textbox Autosizing Algorithm PropertiesPropertyDetailRun\-level processingSignificantly fewer COM calls compared to per\-character accessAdaptive initial estimateFirst scale computed as1\.0 \- overflow / shape\_dimensionIterative fine\-tuningUp to 4 additional correction passes after initial estimate \(based on residual overflow\)Proportional reductionEach Run is reduced proportionally to its original size→\\rightarrowpreserves mixed size ratios0\.5pt snappingAligned to 0\.5pt increments viaround\(size \* 2\) / 2\(rendering consistency\)Lower boundMinimummax\(6\.0, max\_original\_size×\\times0\.5\)→\\rightarrowensures readabilityConvergence conditionStops when overflow≤\\leq1pt

### E\.2Win32COM Limitations

Win32COM provides the most faithful access to PowerPoint’s application\-resolved object state, but it also introduces practical constraints\. It does not natively support parallel execution, so processing many slides can become a runtime bottleneck\. The API also exposes overlappingTextFrameandTextFrame2interfaces whose behavior is not always interchangeable, and equation objects require special handling because Office Math structures are not exposed in the same way as ordinary text ranges\. Figure[6](https://arxiv.org/html/2608.20381#A5.F6)and Figure[7](https://arxiv.org/html/2608.20381#A5.F7)illustrate representative equation\-handling cases\.

![Refer to caption](https://arxiv.org/html/2608.20381v1/figures/tech_equation_handling_1.png)Figure 6:Equation Handling Issue![Refer to caption](https://arxiv.org/html/2608.20381v1/figures/tech_equation_form_1.png)Figure 7:Equation FormPowerPoint paragraph ranges can become unreliable when a text box contains carriage returns, soft line breaks, or mixed run\-level formatting, so paragraph\-level deletion and insertion may break the intended grouping or drop style information\. The implementation avoids relying on visual paragraph boundaries and instead reconstructs the full paragraph text from mapped runs before writing the resolved text back\.

The current paragraph update strategy replaces direct paragraph mutation with full\-text reconstruction:

1

2paragraph\.Text=""

3paragraph\.InsertAfter\("newtext"\)

4

5full\_text=""\.join\(mapped\_run\_texts\)

6paragraph\.Text=full\_text

### E\.3Claude PPT Editing Limitations

The current Claude PPT workflow reads and modifies OOXML directly across slides, which increases token cost and processing time even for simple repetitive edits\. This full\-package representation is especially inefficient when the intended operation touches only a small number of objects\. It can also make run\-level text editing brittle because finely separated formatting spans are exposed verbatim, which increases the chance of hallucinated edits and observed artifacts such as broken spacing\.

### E\.4Full Tool Reference

#### A\. Common Helpers\.

#### \_find\_shape\_by\_id\.

1def\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\):

2slide=prs\.Slides\(slide\_number\)

3forshapeinslide\.Shapes:

4ifshape\.Id==shape\_id:

5returnshape

6raiseValueError\(f"Shape\{shape\_id\}notfoundonslide\{slide\_number\}"\)

#### \_hex\_to\_rgb\_int\.

1def\_hex\_to\_rgb\_int\(hex\_color\):

2hex\_color=hex\_color\.lstrip\("\#"\)

3r,g,b=int\(hex\_color\[0:2\],16\),int\(hex\_color\[2:4\],16\),int\(hex\_color\[4:6\],16\)

4returnr\+\(g<<8\)\+\(b<<16\)

#### \_apply\_font\_snapshot\.

1def\_apply\_font\_snapshot\(font,snapshot\):

2ifsnapshot\.get\("Name"\):font\.Name=snapshot\["Name"\]

3ifsnapshot\.get\("Size"\):font\.Size=snapshot\["Size"\]

4ifsnapshot\.get\("Bold"\)isnotNone:font\.Bold=snapshot\["Bold"\]

5ifsnapshot\.get\("Italic"\)isnotNone:font\.Italic=snapshot\["Italic"\]

6ifsnapshot\.get\("Underline"\)isnotNone:font\.Underline=snapshot\["Underline"\]

7ifsnapshot\.get\("Color"\):

8font\.Color\.RGB=\_hex\_to\_rgb\_int\(snapshot\["Color"\]\)

#### \_apply\_overrides\.

1def\_apply\_overrides\(font,overrides\):

2forkey,valueinoverrides\.items\(\):

3ifkey=="Name":font\.Name=value

4elifkey=="Size":font\.Size=value

5elifkey=="Bold":font\.Bold=value

6elifkey=="Italic":font\.Italic=value

7elifkey=="Underline":font\.Underline=value

8elifkey=="Color":font\.Color\.RGB=\_hex\_to\_rgb\_int\(value\)

9elifkey=="Strikethrough":font\.Strikethrough=value

#### \_normalize\_char\_range\.

1def\_normalize\_char\_range\(text\_range,start,end\):

2total=text\_range\.Length

3ifstartisNone:start=0

4ifendisNone:end=total

5start=max\(0,min\(start,total\)\)

6end=max\(start,min\(end,total\)\)

7returnstart,end

#### \_resolve\_insert\_position\.

1def\_resolve\_insert\_position\(text\_range,position\):

2ifposition=="start":return0

3ifposition=="end":returntext\_range\.Length

4ifisinstance\(position,int\):

5returnmax\(0,min\(position,text\_range\.Length\)\)

6returntext\_range\.Length

#### B\. Text Editing \(7 tools\)\.

#### B\.1 set\_text\_style\.

1defset\_text\_style\(prs,slide\_number,shape\_id,style\_changes,

2char\_start=None,char\_end=None,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4tr=shape\.TextFrame\.TextRange

5start,end=\_normalize\_char\_range\(tr,char\_start,char\_end\)

6target=tr\.Characters\(start\+1,end\-start\)

7\_apply\_overrides\(target\.Font,style\_changes\)

8returnf"Appliedstyletocharacters\{start\}\-\{end\}"

#### B\.2 edit\_text\_insert\.

1defedit\_text\_insert\(prs,slide\_number,shape\_id,text,position="end",

2font\_overrides=None,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4tr=shape\.TextFrame\.TextRange

5pos=\_resolve\_insert\_position\(tr,position\)

6tr\.Characters\(pos\+1,0\)\.InsertBefore\(text\)

7iffont\_overrides:

8inserted=tr\.Characters\(pos\+1,len\(text\)\)

9\_apply\_overrides\(inserted\.Font,font\_overrides\)

10returnf"Insertedtextatposition\{pos\}"

#### B\.3 edit\_text\_delete\.

1defedit\_text\_delete\(prs,slide\_number,shape\_id,

2char\_start,char\_end,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4tr=shape\.TextFrame\.TextRange

5start,end=\_normalize\_char\_range\(tr,char\_start,char\_end\)

6tr\.Characters\(start\+1,end\-start\)\.Delete\(\)

7returnf"Deletedcharacters\{start\}\-\{end\}"

#### B\.4 edit\_text\_replace\.

1defedit\_text\_replace\(prs,slide\_number,shape\_id,

2old\_text,new\_text,font\_overrides=None,

3slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5tr=shape\.TextFrame\.TextRange

6full=tr\.Text

7idx=full\.find\(old\_text\)

8ifidx==\-1:

9returnf"Text’\{old\_text\}’notfound"

10start=idx\+1

11length=len\(old\_text\)

12target=tr\.Characters\(start,length\)

13target\.Text=new\_text

14iffont\_overrides:

15replaced=tr\.Characters\(start,len\(new\_text\)\)

16\_apply\_overrides\(replaced\.Font,font\_overrides\)

17returnf"Replaced’\{old\_text\}’with’\{new\_text\}’"

#### B\.5 edit\_text\_rewrite\.

1defedit\_text\_rewrite\(prs,slide\_number,shape\_id,runs,

2auto\_resize=True,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4tf=shape\.TextFrame

5original\_width=shape\.Width

6original\_height=shape\.Height

7is\_auto\_size=tf\.AutoSize\!=0

8old\_base\_font\_size=None

9try:

10old\_base\_font\_size=tf\.TextRange\.Font\.Size

11except:

12pass

13tf\.TextRange\.Text=""

14tr=tf\.TextRange

15offset=0

16forruninruns:

17text=run\["Text"\]

18tr\.InsertAfter\(text\)

19segment=tr\.Characters\(offset\+1,len\(text\)\)

20if"Font"inrun:

21\_apply\_font\_snapshot\(segment\.Font,run\["Font"\]\)

22offset\+=len\(text\)

23ifnotis\_auto\_sizeandauto\_resize:

24new\_tr=tf\.TextRange

25shape\.Width=original\_width

26current\_size=new\_tr\.Font\.Sizeifnew\_tr\.Font\.Sizeelse12\.0

27ifold\_base\_font\_size:

28current\_size=min\(current\_size,old\_base\_font\_size\)

29whilenew\_tr\.BoundHeight\>original\_heightandcurrent\_size\>9\.0:

30current\_size\-=0\.5

31new\_tr\.Font\.Size=current\_size

32ifnew\_tr\.Font\.Sizeandcurrent\_size\!=new\_tr\.Font\.Size:

33scale=current\_size/new\_tr\.Font\.Size

34foriinrange\(1,new\_tr\.Length\+1\):

35ch=new\_tr\.Characters\(i,1\)

36ifch\.Font\.Size:

37ch\.Font\.Size\*=scale

38return"Textrewritten"

#### B\.6 set\_paragraph\_alignment\.

1defset\_paragraph\_alignment\(prs,slide\_number,shape\_id,

2alignment,paragraph\_index=None,

3slide\_json=None\):

4ALIGN\_MAP=\{"left":1,"center":2,"right":3,"justify":4\}

5shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

6tr=shape\.TextFrame\.TextRange

7ifparagraph\_indexisnotNone:

8para=tr\.Paragraphs\(paragraph\_index\+1\)

9para\.ParagraphFormat\.Alignment=ALIGN\_MAP\.get\(alignment,1\)

10else:

11foriinrange\(1,tr\.Paragraphs\(\)\.Count\+1\):

12tr\.Paragraphs\(i\)\.ParagraphFormat\.Alignment=ALIGN\_MAP\.get\(alignment,1\)

13returnf"Setalignmentto\{alignment\}"

#### B\.7 manage\_bullet\_points\.

1defmanage\_bullet\_points\(prs,slide\_number,shape\_id,

2action,paragraph\_index=None,

3bullet\_char=None,indent\_level=0,

4slide\_json=None\):

5shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

6tr=shape\.TextFrame\.TextRange

7ifparagraph\_indexisnotNone:

8paragraphs=\[tr\.Paragraphs\(paragraph\_index\+1\)\]

9else:

10paragraphs=\[tr\.Paragraphs\(i\)foriinrange\(1,tr\.Paragraphs\(\)\.Count\+1\)\]

11forparainparagraphs:

12pf=para\.ParagraphFormat

13ifaction=="add":

14pf\.Bullet\.Type=1

15ifbullet\_char:

16pf\.Bullet\.Character=ord\(bullet\_char\)

17pf\.IndentLevel=indent\_level

18elifaction=="remove":

19pf\.Bullet\.Type=0

20elifaction=="set\_level":

21pf\.IndentLevel=indent\_level

22returnf"Bullet\{action\}applied"

#### C\. Table Editing \(3 tools\)\.

#### C\.1 cell\_text\_style\.

1defcell\_text\_style\(prs,slide\_number,shape\_id,

2row,col,style\_changes,

3char\_start=None,char\_end=None,

4slide\_json=None\):

5shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

6cell=shape\.Table\.Cell\(row,col\)

7tr=cell\.Shape\.TextFrame\.TextRange

8start,end=\_normalize\_char\_range\(tr,char\_start,char\_end\)

9target=tr\.Characters\(start\+1,end\-start\)

10\_apply\_overrides\(target\.Font,style\_changes\)

11returnf"Appliedstyletocell\(\{row\},\{col\}\)"

#### C\.2 replace\_table\_text\.

1defreplace\_table\_text\(prs,slide\_number,shape\_id,

2row,col,runs,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4cell=shape\.Table\.Cell\(row,col\)

5tf=cell\.Shape\.TextFrame

6tf\.TextRange\.Text=""

7tr=tf\.TextRange

8offset=0

9forruninruns:

10text=run\["Text"\]

11tr\.InsertAfter\(text\)

12segment=tr\.Characters\(offset\+1,len\(text\)\)

13if"Font"inrun:

14\_apply\_font\_snapshot\(segment\.Font,run\["Font"\]\)

15offset\+=len\(text\)

16returnf"Replacedtextincell\(\{row\},\{col\}\)"

#### C\.3 table\_layout\_style\.

1deftable\_layout\_style\(prs,slide\_number,shape\_id,

2row=None,col=None,

3width=None,height=None,

4bg\_color=None,border\_color=None,

5border\_width=None,

6vertical\_align=None,

7slide\_json=None\):

8shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

9table=shape\.Table

10ifwidthandcol:

11table\.Columns\(col\)\.Width=width

12ifheightandrow:

13table\.Rows\(row\)\.Height=height

14ifrowandcol:

15cell=table\.Cell\(row,col\)

16ifbg\_color:

17cell\.Shape\.Fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(bg\_color\)

18ifvertical\_align:

19VA\_MAP=\{"top":1,"middle":3,"bottom":4\}

20cell\.Shape\.TextFrame\.VerticalAnchor=VA\_MAP\.get\(vertical\_align,1\)

21return"Tablelayoutupdated"

#### D\. Chart Editing \(5 tools\)\.

#### D\.1 update\_chart\_categories\.

1defupdate\_chart\_categories\(prs,slide\_number,shape\_id,

2categories,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4chart=shape\.Chart

5wb=chart\.ChartData\.Workbook

6ws=wb\.Worksheets\(1\)

7fori,catinenumerate\(categories\):

8ws\.Cells\(i\+2,1\)\.Value=cat

9chart\.Refresh\(\)

10wb\.Close\(False\)

11returnf"Updated\{len\(categories\)\}categories"

#### D\.2 update\_chart\_series\.

1defupdate\_chart\_series\(prs,slide\_number,shape\_id,

2series\_index,values,name=None,

3slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5chart=shape\.Chart

6wb=chart\.ChartData\.Workbook

7ws=wb\.Worksheets\(1\)

8col=series\_index\+1

9ifname:

10ws\.Cells\(1,col\)\.Value=name

11fori,valinenumerate\(values\):

12ws\.Cells\(i\+2,col\)\.Value=val

13chart\.Refresh\(\)

14wb\.Close\(False\)

15returnf"Updatedseries\{series\_index\}"

#### D\.3 update\_chart\_structure\.

1defupdate\_chart\_structure\(prs,slide\_number,shape\_id,

2chart\_type=None,has\_legend=None,

3has\_title=None,title\_text=None,

4slide\_json=None\):

5CHART\_TYPES=\{

6"column":51,"bar":57,"line":4,"pie":5,

7"area":1,"scatter":\-4169,"doughnut":\-4120,

8\}

9shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

10chart=shape\.Chart

11ifchart\_typeandchart\_typeinCHART\_TYPES:

12chart\.ChartType=CHART\_TYPES\[chart\_type\]

13ifhas\_legendisnotNone:

14chart\.HasLegend=has\_legend

15ifhas\_titleisnotNone:

16chart\.HasTitle=has\_title

17iftitle\_textandchart\.HasTitle:

18chart\.ChartTitle\.Text=title\_text

19return"Chartstructureupdated"

#### D\.4 update\_chart\_axes\.

1defupdate\_chart\_axes\(prs,slide\_number,shape\_id,

2axis\_type="value",

3min\_value=None,max\_value=None,

4title=None,number\_format=None,

5slide\_json=None\):

6AXIS\_MAP=\{"category":1,"value":2\}

7shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

8chart=shape\.Chart

9axis=chart\.Axes\(AXIS\_MAP\.get\(axis\_type,2\)\)

10ifmin\_valueisnotNone:axis\.MinimumScale=min\_value

11ifmax\_valueisnotNone:axis\.MaximumScale=max\_value

12iftitle:

13axis\.HasTitle=True

14axis\.AxisTitle\.Text=title

15ifnumber\_format:

16axis\.TickLabels\.NumberFormat=number\_format

17returnf"Updated\{axis\_type\}axis"

#### D\.5 update\_chart\_colors\.

1defupdate\_chart\_colors\(prs,slide\_number,shape\_id,

2series\_colors=None,slide\_json=None\):

3shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

4chart=shape\.Chart

5ifseries\_colors:

6foridx,colorinseries\_colors\.items\(\):

7series=chart\.SeriesCollection\(int\(idx\)\)

8series\.Format\.Fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(color\)

9return"Chartcolorsupdated"

#### E\. Shape/Layout \(13 tools\)\.

#### E\.1 adjust\_layout\.

1defadjust\_layout\(prs,slide\_number,shape\_id,

2left=None,top=None,width=None,height=None,

3rotation=None,slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5ifleftisnotNone:shape\.Left=left

6iftopisnotNone:shape\.Top=top

7ifwidthisnotNone:shape\.Width=width

8ifheightisnotNone:shape\.Height=height

9ifrotationisnotNone:shape\.Rotation=rotation

10returnf"Layoutadjustedforshape\{shape\_id\}"

#### E\.2 distribute\_shapes\.

1defdistribute\_shapes\(prs,slide\_number,shape\_ids,

2direction="horizontal",spacing=None,

3slide\_json=None\):

4shapes=\[\_find\_shape\_by\_id\(prs,slide\_number,sid\)forsidinshape\_ids\]

5ifdirection=="horizontal":

6shapes\.sort\(key=lambdas:s\.Left\)

7ifspacingisNone:

8total\_w=sum\(s\.Widthforsinshapes\)

9slide\_w=prs\.PageSetup\.SlideWidth

10spacing=\(slide\_w\-total\_w\)/\(len\(shapes\)\+1\)

11x=spacing

12forsinshapes:

13s\.Left=x

14x\+=s\.Width\+spacing

15else:

16shapes\.sort\(key=lambdas:s\.Top\)

17ifspacingisNone:

18total\_h=sum\(s\.Heightforsinshapes\)

19slide\_h=prs\.PageSetup\.SlideHeight

20spacing=\(slide\_h\-total\_h\)/\(len\(shapes\)\+1\)

21y=spacing

22forsinshapes:

23s\.Top=y

24y\+=s\.Height\+spacing

25returnf"Distributed\{len\(shapes\)\}shapes\{direction\}ly"

#### E\.3 align\_shapes\.

1defalign\_shapes\(prs,slide\_number,shape\_ids,

2alignment="center",slide\_json=None\):

3shapes=\[\_find\_shape\_by\_id\(prs,slide\_number,sid\)forsidinshape\_ids\]

4ifalignment=="left":

5min\_left=min\(s\.Leftforsinshapes\)

6forsinshapes:s\.Left=min\_left

7elifalignment=="right":

8max\_right=max\(s\.Left\+s\.Widthforsinshapes\)

9forsinshapes:s\.Left=max\_right\-s\.Width

10elifalignment=="center":

11cx=sum\(s\.Left\+s\.Width/2forsinshapes\)/len\(shapes\)

12forsinshapes:s\.Left=cx\-s\.Width/2

13elifalignment=="top":

14min\_top=min\(s\.Topforsinshapes\)

15forsinshapes:s\.Top=min\_top

16elifalignment=="bottom":

17max\_bottom=max\(s\.Top\+s\.Heightforsinshapes\)

18forsinshapes:s\.Top=max\_bottom\-s\.Height

19elifalignment=="middle":

20cy=sum\(s\.Top\+s\.Height/2forsinshapes\)/len\(shapes\)

21forsinshapes:s\.Top=cy\-s\.Height/2

22returnf"Aligned\{len\(shapes\)\}shapesto\{alignment\}"

#### E\.4 create\_textbox\.

1defcreate\_textbox\(prs,slide\_number,left,top,width,height,

2text="",font\_overrides=None,slide\_json=None\):

3slide=prs\.Slides\(slide\_number\)

4shape=slide\.Shapes\.AddTextbox\(1,left,top,width,height\)

5shape\.TextFrame\.TextRange\.Text=text

6iffont\_overrides:

7\_apply\_overrides\(shape\.TextFrame\.TextRange\.Font,font\_overrides\)

8returnf"Createdtextboxonslide\{slide\_number\}"

#### E\.5 create\_placeholder\.

1defcreate\_placeholder\(prs,slide\_number,layout\_index,

2placeholder\_type,left,top,width,height,

3slide\_json=None\):

4slide=prs\.Slides\(slide\_number\)

5layout=prs\.SlideMaster\.CustomLayouts\(layout\_index\)

6ph=layout\.Placeholders\.Add\(placeholder\_type,left,top,width,height\)

7returnf"Createdplaceholderonslide\{slide\_number\}"

#### E\.6 create\_shape\.

1defcreate\_shape\(prs,slide\_number,shape\_type,

2left,top,width,height,

3fill\_color=None,line\_color=None,

4text=None,slide\_json=None\):

5SHAPE\_TYPES=\{

6"rectangle":1,"rounded\_rectangle":5,

7"ellipse":9,"triangle":7,

8"right\_arrow":33,"star":92,

9\}

10slide=prs\.Slides\(slide\_number\)

11auto\_type=SHAPE\_TYPES\.get\(shape\_type,1\)

12shape=slide\.Shapes\.AddShape\(auto\_type,left,top,width,height\)

13iffill\_color:

14shape\.Fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(fill\_color\)

15ifline\_color:

16shape\.Line\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(line\_color\)

17iftext:

18shape\.TextFrame\.TextRange\.Text=text

19returnf"Created\{shape\_type\}onslide\{slide\_number\}"

#### E\.7 delete\_shape\.

1defdelete\_shape\(prs,slide\_number,shape\_id,slide\_json=None\):

2shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

3shape\.Delete\(\)

4returnf"Deletedshape\{shape\_id\}fromslide\{slide\_number\}"

#### E\.8 duplicate\_shape\.

1defduplicate\_shape\(prs,slide\_number,shape\_id,

2target\_slide,offset\_left=0,offset\_top=0,

3slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5shape\.Copy\(\)

6target=prs\.Slides\(target\_slide\)

7target\.Shapes\.Paste\(\)

8new\_shape=target\.Shapes\(target\.Shapes\.Count\)

9new\_shape\.Left=shape\.Left\+offset\_left

10new\_shape\.Top=shape\.Top\+offset\_top

11returnf"Duplicatedshape\{shape\_id\}toslide\{target\_slide\}"

#### E\.9 duplicate\_shape\_within\_slide\.

1defduplicate\_shape\_within\_slide\(prs,slide\_number,shape\_id,

2offset\_left=72,offset\_top=0,

3slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5shape\.Copy\(\)

6slide=prs\.Slides\(slide\_number\)

7slide\.Shapes\.Paste\(\)

8new\_shape=slide\.Shapes\(slide\.Shapes\.Count\)

9new\_shape\.Left=shape\.Left\+offset\_left

10new\_shape\.Top=shape\.Top\+offset\_top

11returnf"Duplicatedshape\{shape\_id\}withinslide\{slide\_number\}"

#### E\.10 apply\_visual\_style\.

1defapply\_visual\_style\(prs,slide\_number,shape\_id,

2fill\_color=None,line\_color=None,

3line\_width=None,opacity=None,

4shadow=None,slide\_json=None\):

5shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

6iffill\_color:

7shape\.Fill\.Solid\(\)

8shape\.Fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(fill\_color\)

9ifline\_color:

10shape\.Line\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(line\_color\)

11ifline\_widthisnotNone:

12shape\.Line\.Weight=line\_width

13ifopacityisnotNone:

14shape\.Fill\.Transparency=1\.0\-opacity

15ifshadowisnotNone:

16shape\.Shadow\.Visible=shadow

17returnf"Visualstyleappliedtoshape\{shape\_id\}"

#### E\.11 apply\_gradient\_fill\.

1defapply\_gradient\_fill\(prs,slide\_number,shape\_id,

2color1,color2,angle=0,

3slide\_json=None\):

4shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

5shape\.Fill\.TwoColorGradient\(1,1\)

6shape\.Fill\.GradientAngle=angle

7shape\.Fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(color1\)

8shape\.Fill\.BackColor\.RGB=\_hex\_to\_rgb\_int\(color2\)

9returnf"Gradientfillappliedtoshape\{shape\_id\}"

#### E\.12 insert\_image\.

1definsert\_image\(prs,slide\_number,image\_path,

2left,top,width=None,height=None,

3slide\_json=None\):

4slide=prs\.Slides\(slide\_number\)

5ifwidthandheight:

6shape=slide\.Shapes\.AddPicture\(

7image\_path,False,True,left,top,width,height

8\)

9else:

10shape=slide\.Shapes\.AddPicture\(

11image\_path,False,True,left,top

12\)

13returnf"Insertedimageonslide\{slide\_number\}"

#### E\.13 edit\_image\.

1defedit\_image\(prs,slide\_number,shape\_id,

2new\_image\_path=None,crop=None,

3brightness=None,contrast=None,

4slide\_json=None\):

5shape=\_find\_shape\_by\_id\(prs,slide\_number,shape\_id\)

6ifnew\_image\_path:

7left,top,w,h=shape\.Left,shape\.Top,shape\.Width,shape\.Height

8shape\.Delete\(\)

9slide=prs\.Slides\(slide\_number\)

10new\_shape=slide\.Shapes\.AddPicture\(

11new\_image\_path,False,True,left,top,w,h

12\)

13else:

14ifcrop:

15pf=shape\.PictureFormat

16if"left"incrop:pf\.CropLeft=crop\["left"\]

17if"right"incrop:pf\.CropRight=crop\["right"\]

18if"top"incrop:pf\.CropTop=crop\["top"\]

19if"bottom"incrop:pf\.CropBottom=crop\["bottom"\]

20ifbrightnessisnotNone:

21shape\.PictureFormat\.Brightness=brightness

22ifcontrastisnotNone:

23shape\.PictureFormat\.Contrast=contrast

24returnf"Editedimageshape\{shape\_id\}"

#### F\. Slide Management \(5 tools\)\.

#### F\.1 add\_slide\.

1defadd\_slide\(prs,layout\_index=1,position=None,

2slide\_json=None,agent\_request=None\):

3layout=prs\.SlideMaster\.CustomLayouts\(layout\_index\)

4ifposition:

5slide=prs\.Slides\.AddSlide\(position,layout\)

6else:

7slide=prs\.Slides\.AddSlide\(prs\.Slides\.Count\+1,layout\)

8returnf"Addedslideatposition\{slide\.SlideIndex\}"

#### F\.2 delete\_slide\.

1defdelete\_slide\(prs,slide\_number,

2slide\_json=None,agent\_request=None\):

3prs\.Slides\(slide\_number\)\.Delete\(\)

4returnf"Deletedslide\{slide\_number\}"

#### F\.3 duplicate\_slide\.

1defduplicate\_slide\(prs,slide\_number,target\_position=None,

2slide\_json=None,agent\_request=None\):

3prs\.Slides\(slide\_number\)\.Duplicate\(\)

4iftarget\_position:

5new\_slide=prs\.Slides\(slide\_number\+1\)

6new\_slide\.MoveTo\(target\_position\)

7returnf"Duplicatedslide\{slide\_number\}"

#### F\.4 set\_slide\_transition\.

1defset\_slide\_transition\(prs,slide\_number,

2transition\_type=None,duration=None,

3advance\_on\_click=None,advance\_time=None,

4slide\_json=None,agent\_request=None\):

5slide=prs\.Slides\(slide\_number\)

6sst=slide\.SlideShowTransition

7iftransition\_typeisnotNone:

8sst\.EntryEffect=transition\_type

9ifdurationisnotNone:

10sst\.Duration=duration

11ifadvance\_on\_clickisnotNone:

12sst\.AdvanceOnClick=advance\_on\_click

13ifadvance\_timeisnotNone:

14sst\.AdvanceOnTime=True

15sst\.AdvanceTime=advance\_time

16returnf"Transitionsetforslide\{slide\_number\}"

#### F\.5 set\_slide\_background\.

1defset\_slide\_background\(prs,slide\_number,

2bg\_color=None,image\_path=None,

3gradient=None,

4slide\_json=None,agent\_request=None\):

5slide=prs\.Slides\(slide\_number\)

6bg=slide\.Background

7fill=bg\.Fill

8ifbg\_color:

9fill\.Solid\(\)

10fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(bg\_color\)

11elifimage\_path:

12fill\.UserPicture\(image\_path\)

13elifgradient:

14fill\.TwoColorGradient\(1,1\)

15fill\.ForeColor\.RGB=\_hex\_to\_rgb\_int\(gradient\["color1"\]\)

16fill\.BackColor\.RGB=\_hex\_to\_rgb\_int\(gradient\["color2"\]\)

17if"angle"ingradient:

18fill\.GradientAngle=gradient\["angle"\]

19returnf"Backgroundsetforslide\{slide\_number\}"

Similar Articles

Narrative-Driven Paper-to-Slide Generation via ArcDeck

Hugging Face Daily Papers

ArcDeck is a multi-agent framework that generates presentation slides from academic papers by modeling logical flow through discourse trees and iterative agent refinement, outperforming direct summarization methods. The paper introduces ArcBench, a new benchmark for evaluating paper-to-slide generation with emphasis on narrative coherence and logical structure.

DeepSlide: From Artifacts to Presentation Delivery

arXiv cs.AI

DeepSlide is a human-in-the-loop multi-agent system for the full presentation process, from requirement elicitation and time-budgeted narrative planning to evidence-grounded slide-script generation and rehearsal support. It introduces a dual-scoreboard benchmark separating static artifact quality from dynamic delivery excellence, and achieves gains in narrative flow, pacing precision, and slide-script synergy.

Deckwise

Product Hunt

Deckwise is an AI presentation agent that helps users create and edit presentation decks.