EditPPT: Structured Execution and Evaluation for Reliable Slide Editing

Jiheon Kim; Kyudan Jung; Jaegul Choo

cs.CLJun 29, 2026

EditPPT: Structured Execution and Evaluation for Reliable Slide Editing

Authors: Jiheon Kim, Kyudan Jung, Jaegul Choo

Organizations: KAIST AI

Abstract

Reliable slide editing requires precise modifications to intended objects while preserving the rest of the presentation. We argue that slide editing is a problem of structured, constrained modification rather than open-ended code generation. Despite the complexity of real presentations, editing requests can largely be decomposed into the objects to change, the operations to apply, and the state to preserve. This perspective guides both evaluation and execution. For evaluation, we introduce DeckEdit-Bench, 183 editing tasks on 28 human-authored decks whose target and preserved objects are annotated at the shape level, so that intended and unintended changes are scored mostly by deterministic rules. For execution, we present EditPPT, a multi-agent framework that resolves targets before editing, restricts each specialist to a subset of 37 predefined tools, and validates each edit for instruction fulfillment and preservation, correcting or rolling back failed ones. Across five backbone models, EditPPT reaches 66.7-74.9% Task Success while keeping Preservation above 97%. Even with an open 27B model and no task-specific fine-tuning, it approaches Claude Code with Sonnet 5 in Task Success while better preserving the original deck. These results suggest that constraining how edits are executed, not only model scale, makes slide editing more reliable.

Figures & tables

Figure 1: Overview of EditPPT . (a) The parser converts each slide into compact JSON through COM. (b) The planner reasons over the deck outline and splits the request into slide-level tasks. (c) The dispatcher resolves the target shapes and routes subtasks to specialists. (d) Specialists edit only through (e) the tools of their own domain. (f) The text validator checks object-level changes and triggers an incremental fix or a rollback. (g) The vision validator runs only when enabled and checks the rendered slide for visual defects.

Source decks

Per task

Ground truth & scoring

Benchmark

PPTX

Decks / slides

Sl./deck (med.)

Sh./sl. (mean/med.)

Pic./sl. (% sl.)

Eq. decks

Multiling. slides

Tgt sl. (mean/med.)

\geq

10 /

\geq

20 sl.

Cand. (mean/med.)

\geq

100 cand.

Obj.

Pres.

Scoring

PPTBench

✗

–

0 / 0%

–

\triangle

\triangle

DECKBench

✗

–

✗

S, L

TSBench

✓

56 / 72

4.3 / 3.5

0.72 (54%)

1.4%

\leq

0 / 0%

\leq

✗

PPTArena

✓

100 / 999

9.3 / 4

1.10 (46%)

1.2%

6.6 / 4

22 / 9%

55 / 17

18%

✗

\triangle

L, V

PPT-Eval

✓

12 / 404

30.5

13.1 / 4

0.70 (30%)

2.9 / 1 †

4 / 4%

34 / 4 †

\triangle

\triangle

R, V

Table 1: Comparison of slide-editing benchmarks. Corpus statistics are recomputed from the released source decks with one counting rule (Appendix B ). Sh./sl. and Pic./sl. count leaf shapes and pictures per slide, with the share of slides containing a picture. Multiling. counts slides that mix English with a non-Latin script. Tgt sl. counts target slides per task and Cand. all shapes on them, a proxy for the target-search space, and columns with

\geq

give the share of tasks at or above each threshold. Obj. and Pres. mark object-level target annotation and preservation scoring. Scoring uses R ules, L LM, V LM, or S imilarity to a reference, and DeckEdit-Bench uses model judgments, in parentheses, for only 26 of its 183 tasks.

\triangle

denotes partial support. † Estimated from prompt wording.

Figure 2: An acceptable annotation in practice, for “Translate every slide’s text into Korean” on one slide of a survey deck. Left: the original slide with its 11 target shapes and three avatar initials, which are design badges that may be translated or kept. Middle and right: EditPPT keeps the initials while TTYS translates them, and both translate every target and succeed on this slide. Without the acceptable category, translating the initials would count as damage.

System	Model	Modified	TS $\uparrow$	Slide $\uparrow$	IF $\uparrow$	Over-edit $\downarrow$	Pres $\uparrow$	Cost/task $\downarrow$	Time/task	In / Out tok
PPTPilot	gpt-6-sol	147/183	51.4	69.1	83.3	0.68	98.3	$0.298	1.7 min	148k / 4.3k
	gpt-6-luna	137/183	43.2	59.0	73.6	0.68	96.3	$0.017	1.6 min	153k / 5.0k
	Qwen3.8-27B	150/183	50.3	47.3	53.2	0.42	93.1	–	10.2 min	122k / 17.8k
Talk to Your Slides	gpt-6-sol	176/183	35.5	64.8	76.6	6.23	93.6	$0.625	7.4 min	105k / 41.7k
Talk to Your Slides	gpt-6-luna	169/183	29.0	41.3	49.3	5.63	95.5	$0.027	6.7 min	84k / 36.5k
Claude Code + PPTX skill	Sonnet 5	183/183	73.8	81.5	97.8	0.88	93.9	$0.387	1.6 min	577k / 11.0k

Table 2: Results on all 183 tasks of DeckEdit-Bench . Modified counts tasks for which the system returned a deck that differs from the input, and all other tasks count as failures. TS, Slide, IF, and Pres denote Task Success, Slide Success, Instruction Following, and Preservation (Section 4.3 ). Cost is the mean list price per task, unavailable for the locally served Qwen (–). Input tokens include cached prompt tokens. Best value per quality metric in bold, second underlined.

System	Backbone	Short	Medium	Long
PPTPilot	gpt-6-sol	55.6	58.0	35.4
	gpt-6-luna	40.7	50.6	33.3
	Qwen3.8-27B	61.1	59.3	22.9
TTYS	gpt-6-sol	50.0	33.3	22.9
TTYS	gpt-6-luna	44.4	27.2	14.6
Claude Code	Sonnet 5	74.1	84.0	56.2

Table 3: Task Success by deck length: short (

\leq

10 slides, 54 tasks), medium (11–30, 81), long (

>

30, 48). Best per column in bold, second underlined.

Variant	TS $\uparrow$	Slide $\uparrow$	IF $\uparrow$	Over-edit $\downarrow$	Pres $\uparrow$	Cost/task
All 183 tasks
Full system	73.8	88.5	95.5	0.54	98.9	$0.036
Single agent	61.7	82.4	93.3	5.59	98.7	$0.048
No validation	70.5	86.3	94.8	0.48	96.8	–
57 tasks in which the loop triggered a retry
Full system	38.6	79.3	94.7	0.81	97.7	$0.092

Table 4: Ablations of EditPPT with gpt-6-luna. Single agent replaces the dispatcher and specialists with one agent that can use all 37 tools. No validation re-runs only the 57 tasks in which validation triggered a retry and reuses the other 126 results, so its cost over all 183 tasks is not reported. Best value per block in bold, second underlined.

Appendix figures & tables35 assets

Supplementary material from the paper’s appendix.

Appendix

Panel of Figure 3 — Figure 3: The equation slide of a translation task. The earlier version turns the equation into plain characters and repeats the inline symbols, while the current framework keeps both intact.

Figure 4: The two forms in which PowerPoint shows an equation. New equations are inserted in the linear form and then converted to the built-up professional form.

Input representation	Tokens	Est. cost	Efficiency
EditPPT parser	2.14M	$4.27	3.63 $\times$
Raw XML, slide part only	7.61M	$15.22	1.02 $\times$
Raw XML, full scope	7.74M	$15.49	1.00 $\times$

Appendix

Table 5: Token and cost comparison between the EditPPT parser output and raw OOXML over 570 parsed slides. Full scope adds the slide’s relationship file and the chart and diagram parts it references to the slide XML. Estimated cost assumes gpt-6-sol input pricing ($2.00 per million tokens) without caching. Efficiency is relative to full-scope raw XML; higher is better.

	Code route		XML route
Backbone	$\leq$ 30k	$>$ 30k	$\leq$ 30k	$>$ 30k
gpt-6-sol	31/45	31/63	28/41	4/34
gpt-6-luna	23/44	32/64	22/42	2/33
Qwen3.8-27B	27/45	28/65	31/41	6/30

Appendix

Table 6: PPTPilot tasks completed out of tasks routed, split by route and by whether any target slide exceeds 30,000 characters of XML. Two Qwen3.8-27B tasks ended before routing.

Specialist	Tools	Operations
Text and style	7	Character formatting, inserting, deleting, replacing, and rewriting text, paragraph alignment, bullets
Table	3	Cell text style, cell text replacement, table layout and borders
Chart	6	Categories, series, chart structure, axes, colors, a new chart from data
Shape layout	15	Moving and resizing, aligning and distributing, reordering items into slots, creating text boxes, placeholders, and shapes, deleting, duplicating, and copying shapes, visual styles and gradient fills, inserting, replacing, and editing pictures
Slide	6	Adding, deleting, duplicating, and moving slides, transitions, backgrounds

Appendix

Table 7: Tools available to each specialist.

Procedure	What it does
Parsing
Run reconstruction	Compares formatting character by character and starts a run wherever it changes, avoiding mixed-state and empty values that COM returns over ranges
Paragraph records	Records alignment, indent, spacing, and bullet labels per paragraph and assigns each paragraph the runs inside it
Merged cells	Groups table cells with the same position and size into one cell with row and column spans
Group expansion	Parses group children recursively with the same fields as top-level shapes
Placeholder index	Maps placeholder types to shapes, and treats a picture placeholder as a picture

Appendix

Table 8: Supporting procedures for parsing and target resolution.

Procedure	What it does
Execution
Style mapper	Carries the formatting of the original runs over to rewritten or translated text
Paragraph reconciliation	Rebuilds the mapper’s output when it returns a different number of paragraphs
Paragraph assignment	Writes each paragraph in one assignment so that its paragraph format survives
Conditional writes	Writes a formatting value only when it differs, keeping inherited formatting inherited
Unrequested arguments	Drops style arguments that the request does not mention

Appendix

Table 9: Supporting procedures for execution, validation, and recovery, continuing Table 8 .

	Short	Medium	Long	All
Decks	9	12	7	28
Slides	46	241	295	582
Tasks	54	81	48	183
Slides per deck, median	5	21	43	18
Shapes per slide	14.3	8.5	21.8	15.7
Pictures per slide	1.09	1.47	3.23	2.34

Appendix

Table 10: Benchmark statistics by deck length: short decks have at most 10 slides, medium decks 11–30, and long decks more than 30. Counts follow the rules of Table 1 . Per-task values are mean / median. The targeted share is the mean fraction of a deck’s slides that a task targets.

Kind	Instruction	Deck	Targets
Role across the deck	Change every slide’s title color to green.	Short	9
Body text across the deck	Change every slide’s body font to Times New Roman.	Medium	22
Condition on content	On every slide that mentions ‘MingTok-Audio’, bold every occurrence of the term.	Medium	10
Condition and addition	For every slide whose title starts with ‘DEMO’, change the title color to dark red and add a small textbox ‘Phase 2 Demo’ at the top-right corner of the slide.	Short	4
Cross-slide reference	On slides 6-15, adjust each shape’s position and size to match slide 5’s layout.	Medium	10
Selective translation	Translate every Vietnamese-language passage in the deck into Korean. Leave English-only slides unchanged.	Medium	6

Appendix

Table 11: Example instructions from DeckEdit-Bench , exactly as given to every system. Deck is the length tier of the source deck, and Targets is the number of annotated target slides.

Category	Types	Tasks	What the checks verify
Text content	8	33	Text matches a pattern, a rewrite rule applied to the original text, numbering prefixes, no characters of the source language left after translation
Character style	7	33	Bold, italic, underline, font, or size on whole shapes or on selected terms, and emphasis patterns or fonts kept through a rewrite
Color and fill	8	29	Text or fill color within a named range, recoloring from one range to another, distinct or ordered colors across shapes
Objects and pictures	5	37	Shapes added in a region with given text, shapes removed, pictures scaled, recolored, or replaced
Geometry and arrangement	6	8	Alignment, even spacing, equal size, matching another shape’s geometry, reordering or swapping items
Tables	11	12	Header and row styles, alternating row colors, column colors, cell text, merged cells, added columns

Appendix

Table 12: The 69 check types grouped by what they inspect. A task can use types from several categories, so task counts do not add up to 183.

System	Model	Shape Success	Shape IF
PPTPilot	gpt-6-sol	73.4	82.7
	gpt-6-luna	54.3	70.0
	Qwen3.8-27B	36.2	37.5
TTYS	gpt-6-sol	71.7	79.0
TTYS	gpt-6-luna	38.9	42.4
Claude Code	Sonnet 5	89.1	96.1

Appendix

Table 13: Shape-level scores on all 183 tasks, over the 3,388 target shapes on judged target slides. Best value per column in bold, second underlined.

		Task Success			Slide Success			Preservation
System	Model	Released	Strict	Required	Released	Strict	Required	Released	Strict	Required
PPTPilot	gpt-6-sol	51.4	49.7	49.7	69.1	64.7	66.2	98.3	91.8	98.2
	gpt-6-luna	43.2	41.5	42.6	59.0	57.4	57.6	96.3	94.2	96.2
	Qwen3.8-27B	50.3	48.6	49.7	47.3	46.1	46.7	93.1	90.8	93.1
TTYS	gpt-6-sol	35.5	33.9	33.9	64.8	63.1	60.7	93.6	91.0	93.8
TTYS	gpt-6-luna	29.0	27.3	27.9	41.3	40.4	39.5	95.5	92.9	95.4

Appendix

Table 14: Results under the released annotation and the two extreme readings of the acceptable category, on all 183 tasks. Only the 32 tasks with acceptable annotations are rescored. Best value per column in bold, second underlined.

Role	gpt-6	Qwen3.8-27B	Claude Code
Planner	high	thinking on	high
Dispatcher	high	thinking on	high
Specialists	none	thinking off	low
Style mapper	high	thinking off	low
Text validator	none	thinking off	low
Picture captions	none	thinking off	low

Appendix

Table 15: Reasoning setting of each role by backbone family.

Model	Input	Cached input	Output
gpt-6-sol	2.00	0.20	10.00
gpt-6-luna	0.10	0.01	0.50
gemini-3-pro-image-preview	2.00	–	120.00

Appendix

Table 16: List prices used for cost, in USD per million tokens. The gpt-6 prices are from the provider’s pricing page on 2026-09-27. Costs for the Claude backbones are those reported by Claude Code.

System	Model	Modified	TS $\uparrow$	Slide $\uparrow$	IF $\uparrow$	Over-edit $\downarrow$	Pres $\uparrow$
PPTPilot	gpt-6-sol	126/152	54.6	70.2	86.7	0.87	98.3
	gpt-6-luna	119/152	46.7	66.0	81.2	0.90	95.0
	Qwen3.8-27B	131/152	53.9	51.3	58.6	0.43	94.4
TTYS	gpt-6-sol	145/152	36.8	61.8	73.1	7.16	93.4
	gpt-6-luna	140/152	32.2	39.7	47.2	6.57	97.3
	Qwen3.8-27B	105/152	16.4	18.6	21.9	10.31	92.0

Appendix

Table 17: All systems on the 152 tasks that TTYS with Qwen3.8-27B ran. The 31 tasks left out come from five long decks. Columns as in Table 2 . Best value per quality metric in bold, second underlined.

System	Model	TS $\uparrow$	Slide $\uparrow$	IF $\uparrow$	Over-edit $\downarrow$	Pres $\uparrow$
PPTPilot	gpt-6-sol	51.4 [42.5, 60.1]	69.1 [62.9, 76.6]	83.3 [76.9, 90.3]	0.68 [0.19, 1.26]	98.3 [97.4, 99.1]
	gpt-6-luna	43.2 [35.1, 50.6]	59.0 [50.4, 66.4]	73.6 [65.5, 81.5]	0.68 [0.21, 1.41]	96.3 [92.0, 98.9]
	Qwen3.8-27B	50.3 [38.9, 61.0]	47.3 [30.2, 67.0]	53.2 [34.4, 74.9]	0.42 [0.00, 1.07]	93.1 [87.4, 97.3]
Talk to Your Slides	gpt-6-sol	35.5 [28.2, 43.4]	64.8 [58.0, 72.2]	76.6 [70.0, 83.3]	6.23 [4.37, 8.44]	93.6 [89.3, 97.4]
Talk to Your Slides	gpt-6-luna	29.0 [20.9, 38.2]	41.3 [33.1, 50.4]	49.3 [40.5, 58.5]	5.63 [3.54, 8.16]	95.5 [92.7, 97.7]
Claude Code + PPTX skill	Sonnet 5	73.8 [66.3, 80.7]	81.5 [75.5, 87.9]	97.8 [95.5, 99.6]	0.88 [0.40, 1.38]	93.9 [89.5, 97.4]

Appendix

Table 18: The quality metrics of Table 2 with 95% deck-cluster bootstrap intervals (28 decks, 10,000 resamples). Best value per column in bold, second underlined, as in Table 2 .

A	B	A/B only	$p$	$p_{\text{Holm}}$	$\Delta$ TS	$\Delta$ Slide	$\Delta$ IF	$\Delta$ Over-edit	$\Delta$ Pres
EditPPT sol	PPTPilot sol	55/12	$<$ 0.001	$<$ 0.001	+23.5 [15.1, 31.9]	+19.9 [11.5, 27.1]	+12.4 [3.1, 20.3]	$-$ 0.26 [ $-$ 0.62, 0.07]	$-$ 0.2 [ $-$ 1.7, 1.2]
	PPTPilot luna	66/8	$<$ 0.001	$<$ 0.001	+31.7 [23.2, 40.3]	+30.1 [21.2, 39.3]	+22.1 [12.6, 30.7]	$-$ 0.26 [ $-$ 0.99, 0.25]	+1.9 [ $-$ 1.1, 6.1]
	PPTPilot Qwen	56/11	$<$ 0.001	$<$ 0.001	+24.6 [14.4, 35.6]	+41.7 [21.7, 59.3]	+42.5 [20.7, 62.1]	0.00 [ $-$ 0.54, 0.43]	+5.0 [0.9, 10.7]
	TTYS sol	77/5	$<$ 0.001	$<$ 0.001	+39.3 [31.8, 47.0]	+24.2 [17.3, 30.9]	+19.1 [12.5, 26.2]	$-$ 5.81 [ $-$ 8.07, $-$ 3.97]	+4.6 [0.4, 8.9]
	TTYS luna	87/3	$<$ 0.001	$<$ 0.001	+45.9 [38.1, 54.0]	+47.7 [37.6, 57.0]	+46.4 [36.2, 56.3]	$-$ 5.21 [ $-$ 7.81, $-$ 3.05]	+2.7 [ $-$ 0.2, 5.6]
	Claude Code Sonnet	20/18	0.87	1.00	+1.1 [ $-$ 5.6, 8.3]	+7.5 [0.4, 14.7]	$-$ 2.1 [ $-$ 6.5, 1.0]	$-$ 0.46 [ $-$ 0.73, $-$ 0.19]	+4.3 [0.7, 8.3]

Appendix

Table 19: Each EditPPT backbone against each baseline on the 183 tasks. Differences are A

-

B in percentage points with 95% deck-cluster bootstrap intervals. A/B only counts the tasks that only A or only B completes.

p

is an exact two-sided McNemar test on Task Success, and

p_{\text{Holm}}

applies the Holm correction over all 66 pairs in this table and Table 20 . Model names are shortened to sol, luna, Qwen, Sonnet, and Haiku.

A	B	A/B only	$p$	$p_{\text{Holm}}$	$\Delta$ TS	$\Delta$ Slide	$\Delta$ IF	$\Delta$ Over-edit	$\Delta$ Pres
EditPPT sol	EditPPT luna	16/14	0.86	1.00	+1.1 [ $-$ 5.9, 8.1]	+0.5 [ $-$ 2.3, 2.8]	+0.2 [ $-$ 1.2, 1.3]	$-$ 0.12 [ $-$ 0.66, 0.35]	$-$ 0.8 [ $-$ 2.3, 0.3]
	EditPPT Qwen	18/13	0.47	1.00	+2.7 [ $-$ 3.2, 8.4]	+1.6 [ $-$ 3.6, 5.4]	$-$ 0.1 [ $-$ 4.8, 3.0]	+0.06 [ $-$ 0.35, 0.49]	+0.8 [ $-$ 1.4, 3.0]
	EditPPT Sonnet	18/17	1.00	1.00	+0.5 [ $-$ 6.7, 7.9]	+0.2 [ $-$ 3.8, 3.9]	$-$ 1.3 [ $-$ 4.6, 1.5]	+0.12 [ $-$ 0.22, 0.51]	+0.6 [ $-$ 1.6, 2.4]
	EditPPT Haiku	25/10	0.02	0.38	+8.2 [0.5, 16.3]	+5.2 [0.3, 10.6]	+2.4 [ $-$ 0.7, 6.5]	$-$ 0.13 [ $-$ 0.69, 0.42]	+0.2 [ $-$ 1.8, 2.0]
EditPPT luna	EditPPT Qwen	16/13	0.71	1.00	+1.6 [ $-$ 3.2, 6.5]	+1.0 [ $-$ 3.3, 4.4]	$-$ 0.3 [ $-$ 4.6, 2.5]	+0.18 [ $-$ 0.19, 0.64]	+1.5 [ $-$ 0.2, 3.8]
	EditPPT Sonnet	13/14	1.00	1.00	$-$ 0.5 [ $-$ 4.8, 4.4]	$-$ 0.3 [ $-$ 3.2, 2.4]	$-$ 1.5 [ $-$ 4.5, 1.2]	+0.24 [ $-$ 0.05, 0.65]	+1.4 [ $-$ 0.2, 3.0]

Appendix

Table 20: Pairwise comparisons among the EditPPT backbones (top) and among the baselines (bottom), in the format of Table 19 .

Variant	Tasks	$\Delta$ TS	$\Delta$ Slide	$\Delta$ IF	$\Delta$ Over-edit	$\Delta$ Pres	Full / variant only	$p$
Single agent	183	$-$ 12.0 [ $-$ 17.4, $-$ 6.9]	$-$ 6.0 [ $-$ 10.0, $-$ 2.7]	$-$ 2.2 [ $-$ 5.3, 0.4]	+5.05 [2.17, 8.19]	$-$ 0.2 [ $-$ 0.9, 0.5]	27/5	$<$ 0.001
No validation	183	$-$ 3.3 [ $-$ 6.7, 0.0]	$-$ 2.2 [ $-$ 5.5, 0.6]	$-$ 0.6 [ $-$ 2.3, 0.6]	$-$ 0.06 [ $-$ 0.41, 0.15]	$-$ 2.1 [ $-$ 5.0, $-$ 0.1]	9/3	0.15
No validation, retried tasks	57	$-$ 10.5 [ $-$ 21.4, 0.0]	$-$ 4.9 [ $-$ 11.8, 1.4]	$-$ 1.5 [ $-$ 4.7, 1.5]	$-$ 0.14 [ $-$ 0.92, 0.37]	$-$ 4.7 [ $-$ 10.4, $-$ 0.1]	9/3	0.15

Appendix

Table 21: Ablations of EditPPT with gpt-6-luna: each variant minus the full system, in points, with 95% deck-cluster bootstrap intervals. Full / variant only counts the tasks completed only by the full system or only by the variant, and

p

is an exact two-sided McNemar test on Task Success. The 183-task no-validation row reuses the results of the 126 tasks in which the loop never triggered a retry.

System	Backbone	1	2–5	6–19	$\geq$ 20
PPTPilot	gpt-6-sol	45.1	53.8	69.2	44.4
	gpt-6-luna	37.8	38.5	53.8	47.2
	Qwen3.8-27B	50.0	57.7	61.5	33.3
TTYS	gpt-6-sol	56.1	34.6	12.8	13.9
TTYS	gpt-6-luna	52.4	15.4	12.8	2.8
Claude Code	Sonnet 5	80.5	73.1	82.1	50.0

Appendix

Table 22: Task Success by the number of target slides per task, with 82 tasks on one slide, 26 on 2–5, 39 on 6–19, and 36 on 20 or more. Best per column in bold, second underlined.

		Cost per task (USD)				Time per task (min)
System	Model	Mean	SD	Median	Max	Mean	SD	Median	Max
PPTPilot	gpt-6-sol	$0.298	0.341	0.154	1.705	1.7	1.5	1.1	8.2
	gpt-6-luna	$0.017	0.017	0.009	0.091	1.6	1.3	1.1	7.7
	Qwen3.8-27B	–	–	–	–	10.2	9.6	6.9	56.6
Talk to Your Slides	gpt-6-sol	$0.625	0.909	0.195	4.363	7.4	10.2	2.4	44.4
Talk to Your Slides	gpt-6-luna	$0.027	0.035	0.010	0.188	6.7	8.3	2.8	33.5

Appendix

Table 23: Per-task cost at list prices and wall-clock time over every task each system ran (183 per system; 181 with a recorded time for PPTPilot with Qwen3.8-27B). SD is the sample standard deviation. Qwen runs on local GPUs and has no list price (–).

Validator path	Slides	Pass	Partial	Fail	Damage	Wrong	Pass rate
Accepted at first attempt	1525	1398	56	55	9	7	91.7%
Rejected, then accepted	101	77	18	4	2	0	76.2%
Rejected, best attempt kept	74	31	30	6	6	1	41.9%
Rejected, slide restored	13	5	0	7	1	0	38.5%

Appendix

Table 24: Text validator verdicts against the evaluator for EditPPT with gpt-6-luna, over the slides the agents edited. Damage : the requested change was graded but a non-target shape on the slide also changed. Wrong : a non-target slide. Slides that are neither target nor wrong-target slides are excluded. Best pass rate in bold, second underlined.

Panel of Figure 6 — Figure 6: A table before and after the request “On slide 15’s table, merge adjacent cells that contain the same text, ignoring letter case. If a cell could be merged either horizontally or vertically, merge it horizontally.”

Panel of Figure 7 — Figure 7: All 49 slides of a deck before and after the request “Translate every Korean passage in the deck into English.” Slides are numbered in order, and slide 44, which has no Korean text, is not a target.

Panel of Figure 8 — Figure 8: A table before and after the request “On slide 29, add a new column at the right end of the table with the header ‘Status’.” Names in the table are placeholders from the source deck.

Figure 10: A low-contrast defect found in the audit, shown before and after the edit with the changed region magnified below. After EditPPT with gpt-6-luna changed the body font of every slide to Calibri, the white text in the dark box turned black, and the annotator noted that it is hard to see on the dark background.

Figure 12: Review page for training pairs. Each row shows the slide before an edit, after it, and after the proposed repair, with the request, the defect category, the diagnosis, and the proposed tool calls. The reviewer accepts, rejects, or questions a pair with the buttons at the bottom and enters corrections with the buttons on the right. In the second row no single change repairs the slide, so the repair column is empty and the reviewer has asked for a move to the right and down. The interface labels are in Korean. Slides from “Creep Characterization of Refractory Materials at High Temperatures Using the Integrated Digital Image Correlation Technique” by L. Breder Teixeira, J. Gillibert, E. Blond, and T. Sayet and “Development of a second order dynamic stall model” by N.C. Adema, M. Kloosterman, and J.G. Schepers, both CC BY 4.0, edited.

#	Task, slide (run)	Defect noted in the audit	Repair by the validator	Outcome
1	01_OverseasNews-04, s. 10 (luna)	Added page number overlaps the body text.	adjust_layout : shape 2, left 886, top 525	Resolved
2	01_OverseasNews-04, s. 17 (luna)	Added page number overlaps the body text.	adjust_layout : shape 6, left 878, top 495	Resolved
3	01_OverseasNews-04, s. 27 (luna)	Added page number overlaps the body text.	adjust_layout : shape 3, left 894, top 523	Resolved
4	01_Transformer-01, s. 24 (luna)	A graphic overlaps the text.	set_shape_font_size : shape 5, 20 pt	Resolved
5	01_Transformer-01, s. 29 (luna)	A graphic overlaps the text.	set_shape_font_size : shape 5, 20 pt	Resolved
6	01_Transformer-01, s. 30 (luna)	A graphic overlaps the text.	set_shape_font_size : shape 5, 20 pt	Resolved

Appendix

Table 25: The 40 judged repairs of the vision validator, grouped by outcome. Notes are the auditor’s, shortened and translated where needed. Each repair is one tool call on one shape, identified by its ID on the slide. set_shape_font_size sets the font size, and adjust_layout sets the position in points from the top-left corner of the slide. Each repair is shown in Figures 13 – 15 .

Panel of Figure 13 — Figure 13: Repairs that resolved the defect (1 of 2). Left: the slide after the edit, with the defect. Right: the same slide after the validator’s repair. Numbers refer to Table 25 , and names of people on the slides are masked.

Panel of Figure 14 — Figure 14: Repairs that resolved the defect (2 of 2) or partly resolved it, shown as in Figure 13 .

Panel of Figure 15 — Figure 15: Repairs that did not resolve the defect, and repairs on clean slides that the validator flagged by mistake, shown as in Figure 13 .

Implementation	PowerPoint	OOXML	Google Slides
Native, full	58	51	38
Native, partial	0	4	4
Emulated	0	1	5
Not representable	0	2	11

Appendix

Table 26: The 58 executor operations by how each platform implements them. Partial operations cover only some cases, such as solid backgrounds on Google Slides. Emulated operations reach the same effect another way, such as rendering slides through LibreOffice. Operations that cannot be represented include text measurement on both new platforms and chart editing, shadows, gradients, and transitions on Google Slides.

Platform	Decks re-saved	Shapes changed
OOXML executor	28 / 28	0%
LibreOffice 24.2	28 / 28	4.5%
Google Slides	19 / 28	19.4%

Appendix

Table 27: Changes caused by opening and saving a deck without any edit. Shapes changed is the median share per deck.

	OOXML	Google Slides
Tasks (decks)	183 (28)	117 (19)
Recorded tool calls	4,595	1,692
Calls executed	92.5%	84.7%
Same effect, PowerPoint’s sizes	92.6%	76.1%
Same effect, sizes reset	87.5%	74.4%
Text identical	97.9%	97.0%

Appendix

Table 28: Replay of recorded PowerPoint tool calls on the other executors. Shape-level values are shares of the shapes PowerPoint changed. Text and style values use the variant with sizes reset.

LLM Agents

Large language model agents use language models to plan, use tools, and act across multi-step tasks and environments.

See all 705 papers

Dec 2, 2025

PPTArena: A Benchmark for PowerPoint Editing

We introduce PPTArena, a benchmark for PowerPoint editing that evaluates how agents modify real slides from natural-language instructions. Unlike benchmarks that rely on image-PDF renderings or text-to-slide generation, PPTArena features 100 decks with over 1,300 human-curated edits across 2,125 slides, spanning text, charts, animations, and professional master styles. Each edit pairs a ground-truth deck with a target rubric and is scored by two Vision-Language Model (VLM) judges: one rates instruction following from structural diffs, the other visual quality from slide images. On top of this benchmark, we present PPTPilot, a structure-aware agent that plans semantic edit sequences, routes between programmatic tools and deterministic XML operations, and verifies each result in an iterative plan-edit-check loop. PPTPilot outperforms strong VLM-based agents by more than 10 percentage points on compound, layout-sensitive, and cross-slide edits, with large gains in visual fidelity and deck-wide consistency. Despite this, all agents still struggle on long-horizon, document-scale tasks, underscoring how hard reliable PowerPoint editing remains. We publicly release our code at https://github.com/michaelofengend/PPTArena .

Michael Ofengenden, Yunze Man, Ziqi Pang +2

University of Illinois Urbana-Champaign · University of California, Berkeley

LLM Agent Evaluation AI Agent Benchmarks Tool-Using Agents

Ask PDF

Sep 2, 2026

SLIDEFORGE: An LLM Agent for Controllable Editing of Slides as Structured Artifacts

Current AI agents compellingly describe slides. However, AI-assisted slide editing requires more than understanding: the output must retain layout, style, component structure, and native editability. Towards, AI-assisted slide editing, existing agents operate on screenshots or weak document representations and often fragment coherent visual units, rasterize editable content, or break layout. In contrast, for controllable slide editing, we introduce an agentic framework, SLIDEFORGE, which builds a Deck State Graph, an executable slide state that links visual decomposition, native pptx object structure, and perceptual organization. By recovering human-referable components while retaining fine-grained editable structure, SLIDEFORGE supports theme-preserving reconstruction through slide-native operations and rendered-state verification. We further introduce an evaluation paradigm for controllable slide transformation that jointly measures component recovery, preservation, restyling consistency, visual quality, and native editability. Experiments show that SLIDEFORGE outperforms direct prompting, screenshot-based agents, and generic code-agent baselines across these dimensions. Code is available at https://github.com/UIUC-MONET/SLIDEFORGE.

Haozhen Zheng, Fulin Wang, Tianhu Xiong +6

University of Illinois Urbana-Champaign · Meta

LLM Agents

Ask PDF

Oct 12, 2026

InfoVis: Unified Slide Image Generation and Editing

Generating and editing presentation slides requires models to combine accurate text rendering, instruction following, visual grounding, aesthetic design, and precise editing within one canvas. Existing work covers only subsets of these capabilities and lacks large-scale slide-native supervision and diagnostic evaluation. We formulate four slide-centric tasks and build a scalable data engine with over 13M continual-pretraining records and 1.9M supervised fine-tuning records. We also introduce VisSlideBench, a benchmark of 1,527 manually screened instances that covers all four tasks with task-specific, multidimensional evaluation. Its automatic rankings agree with blinded, dimension-wise human rankings. Using these resources, we train InfoVis, a unified 9B slide generation and editing model. On VisSlideBench, InfoVis leads every evaluated open-source model on all eleven metrics and scores 7.94 overall against 7.99 for Nano-Banana-2. Starting from FLUX.2-klein-base-9B, slide-specific post-training adds 1.6 points overall, with the largest generation gains in content faithfulness; the remaining gap to proprietary models is smallest in content faithfulness and largest in aesthetic quality. Built on InfoVis, our document-to-slide workflow achieves the second-highest Aesthetics score on the external SlidesGen-Bench. We will release the model, code, data, and benchmark.

Jiahao Wang, Xiyan Jiang, Chenyuan Wu +7

Institute of Automation, Chinese Academy of Sciences · Beijing Academy of Artificial Intelligence · Zhejiang University +1

Generative AI Evaluation

Ask PDF

Abstract

LLM Agents

Explore similar work

PPTArena: A Benchmark for PowerPoint Editing

SLIDEFORGE: An LLM Agent for Controllable Editing of Slides as Structured Artifacts

InfoVis: Unified Slide Image Generation and Editing