python-pptx is the de facto Python library for generating PowerPoint files — MIT licensed, mature, used in production at thousands of companies. We use it internally at slideforge.dev. But over 18 months of shipping an API-first slide engine on top of it, we've hit a list of real limitations. This post is a catalog of the worst ones, with the specific code workarounds we ended up writing.
Nothing here is a critique of Steve Canny's work — python-pptx is doing exactly what it was designed for: low-level .pptx manipulation. These limitations only show up when you try to run it as a high-throughput production engine that generates consulting-grade output from structured data.
1. Merging decks silently loses embedded images
This was the first one that cost us a day of debugging. You have two decks — each has icons, logos, and maybe AI-generated images — and you want to concatenate them into one.
from pptx import Presentation
from copy import deepcopy
def merge_bad(files):
master = Presentation(files[0])
for f in files[1:]:
src = Presentation(f)
for slide in src.slides:
# Deep-copy the slide element into master — seems right
xml_slide = deepcopy(slide._element)
master.slides._sldIdLst.append(...) # etc
return masterThe output opens without errors. Text is intact. Charts are intact. But every Pictureshape points to a relationship ID that doesn't exist in the master deck — so when you open it in PowerPoint, the images are blank placeholders.
The fix: extract each picture's blob, re-add it via add_picture() in the new deck, then rewrite the XML reference. We wrote _copy_slide_with_pictures() that does this slide-by-slide. ~80 lines to get right. Every .pptx spec we produce now goes through this helper rather than a naive deep-copy.
2. Right-edge overflow on 16:9 canvas (the 13.33″ budget problem)
python-pptx lets you place any shape at any coordinate — including off the slide. There's no overflow: hidden, no canvas-bounds validator. If you add a 4-inch-wide text box at left=Inches(10), it extends past the slide's right edge and gets clipped when rendered.
For an AI-generated layout, this happens constantly. The model computes coordinates based on its understanding of the layout and doesn't always reconcile against the 13.33" × 7.5" canvas.
The fix: a static linter that runs before the sandbox executes the generated code. 46 heuristic rules check every shape: canvas bounds, text overlap via containment + stacking filters with a 15% threshold, contrast ratios, font size minimums, right-edge annotation budgets. When a violation is detected, the failure message is fed back into the LLM prompt and it retries. Adding the linter dropped our broken-slide rate from ~12% to under 1%.
3. No chart types beyond the basic six
python-pptx supports XL_CHART_TYPE.LINE, BAR_CLUSTERED, PIE, AREA, and a handful of variants. If you want waterfall, funnel, marimekko, radar, sunburst, treemap, bullet, heatmap, or Gantt — you're out of luck via native chart API.
These are exactly the charts consulting and finance teams want.
The fix:we build them as shape compositions, not native charts. A waterfall chart in slideforge.dev is a horizontal flex layout of rectangles with accent lines and value labels. Not a native PowerPoint chart — but a legitimate visual that's still editable shape-by-shape after download. 35 such composable components ship today (Metric, BarList, OrgChart, ThreeHorizons, MaturityModel, RAGScorecard, BurndownChart, CapTable, UnitEconomics, Heatmap, Gantt, Swimlane, Roadmap, etc.), and they compose — nest any component inside a SplitView or Card container for dashboards.
4. Can python-pptx add animations? No — here's what actually works
Short answer: python-pptx cannot add, edit, or remove animations. There is no animation API — no entrance/exit effects, no transitions, no motion paths. The feature request has been open since 2018 and isn't on the roadmap: PowerPoint animations live in the <p:timing> XML tree, whose structure (ECMA-376 §19.5) is large enough that every implementation attempt has stalled on edge cases.
Three workarounds actually work in practice, in order of how often we recommend them:
Option 1 — put the animations in the template (the reliable one). python-pptx preservesXML it doesn't understand, including the entire timing tree. So: author your animations once in PowerPoint — on the template slides or layouts — then use python-pptx only to fill and duplicate content. Every slide you touch keeps its animations through the round-trip. This is the only approach that survives arbitrary edits and never corrupts a file.
Option 2 — copy the <p:timing> element from a donor slide (the raw-XML one). Author the effect you want in PowerPoint on a one-slide donor deck, then transplant its timing tree with lxml:
from pptx import Presentation
import copy
donor = Presentation("donor_with_animation.pptx")
target = Presentation("generated.pptx")
donor_el = donor.slides[0]._element
timing = donor_el.find(
"{http://schemas.openxmlformats.org/presentationml/2006/main}timing"
)
target_el = target.slides[0]._element
target_el.append(copy.deepcopy(timing))
target.save("generated_animated.pptx")The catch: animation targets reference shapes by shape id (spid). The transplant only fires if the target slide's shape ids match what the timing tree points at — workable when you generate slides with a fixed structure, brittle everywhere else. Test in PowerPoint before shipping; a dangling spidmeans the effect silently doesn't play.
Option 3 — don't animate (what we ship). 100% of slideforge.dev output is animation-free by choice: our users' decks are board and client material, where builds are optional but a broken file never is. For slides that genuinely need motion, generate the deck, open it in PowerPoint, and add the animation manually — it survives any later python-pptx edit (see Option 1). We've since written this up in full, including the progressive-disclosure pattern with runnable code: python-pptx animations — what's supported, what survives, and what to do instead.
5. Font substitution when the template font isn't embedded
python-pptx will happily write tf.font.name = "Helvetica Neue" into the XML whether or not that font exists on the machine opening the file. PowerPoint silently substitutes with a local font, which usually changes line height, line breaks, and sometimes wraps text differently.
For consulting-grade decks where every pixel of typography matters, this is a failure mode we have to actively defend against.
The fix: theme resolution at render time. slideforge.dev ships three theme variants (modern sans, classic serif, monospace) with PowerPoint-safe font stacks (Calibri → Arial → Aptos, Times → Cambria → Georgia, etc.) and a theme override that lets users upload a corporate .pptxand inherit its exact font stack. We also embed fonts when the user's theme explicitly requests it.
6. Performance degrades past ~1,000 slides
Python-pptx holds the entire .pptx in memory as a parsed XML tree via lxml. For a 50-slide deck this is fine (~50MB). Past 500 slides it starts to hurt. At 1,000+ slides — common for report-generation use cases — memory gets heavy and save times climb non-linearly.
We hit this with a customer doing 323-slide sprint reports. RSS peaked at 1.7GB on a 2GB container, which is right at the OOM line.
The fix: for translation and read-only operations we built an lxml-only extractor that bypasses python-pptx's object model, operates on the XML stream directly, and stays under 300MB RSS even on 500-slide decks. For generation (where we typically produce 1 slide per API call anyway), we parallelize: 5 slides rendered concurrently via asyncio.Semaphore(3), then merged via our custom merge_presentations() (see #1).
7. “Insert Picture from URL” doesn't exist
slide.shapes.add_picture() requires a local filesystem path or a file-like object. If your image lives at https://..., you download it first.
The fix: an add_image() helper wrapped around add_picture() that accepts either a filesystem path or an HTTPS URL, downloads to a temp file, applies our crop-to-fit aspect-ratio logic via Pillow, and cleans up. Tiny workaround, but one more thing every downstream user had to write before we added it.
8. XML round-trips can drop slide master properties
If you open a customer-provided .pptxand iterate over slides, python-pptx re-serializes the XML on save. For simple decks this is lossless. For decks with uncommon features — e.g. slide masters with embedded videos, custom XML parts for interactive widgets, or SmartArt generated by PowerPoint's UI — the re-serialization strips what python-pptx doesn't understand.
The customer opens the output and finds their SmartArt is now a static image. Rare, but a failure mode when it happens.
The fix: we don't round-trip customer decks. For translation (translate_deck) we operate on the XML via lxml directly — no python-pptx parse step — and only rewrite text runs. For merging, we only merge slides we generated, which are always simple.
9. Chart data updates via the chart.replace_data() API are fragile
Updating a chart's underlying data is supposed to be easy: get the chart, call replace_data(CategoryChartData()). In practice, the shape of the existing chart (category axis, series count, data labels) has to match exactly or you get an exception. Some chart types don't support replace_data at all.
The fix: for most charts we regenerate from scratch rather than update in place. For the rare case a user wants to update an existing .pptx chart, we strongly recommend regenerating the slide.
10. No built-in PDF export
python-pptx produces .pptx files. It has no notion of PDF.
The fix: we shell out to libreoffice --headless --convert-to pdfin a subprocess sandbox. On Azure Container Apps with 1 CPU, a 10-slide deck converts in about 4–6 seconds. Not python-pptx's job, but worth noting because every production workflow needs it eventually.
11. No rendering slides to images — python-pptx writes XML, it doesn't draw
A question that comes up constantly (often from AI agents checking their own environment): can python-pptx render a slide to a PNG or JPEG? No. python-pptx is an OOXML writer — it builds the XML that describes a slide, but it contains no rendering engine. There is no slide.to_image(), and there never will be one in the library itself; rendering requires a layout engine, font shaping, and chart drawing that python-pptx deliberately doesn't implement.
The workarounds, in practice: (1) libreoffice --headless --convert-to png — works everywhere, but it's a ~400MB dependency and seconds per deck; (2) PowerPoint COM automation via win32com— highest fidelity, Windows-with-Office only, hostile to servers; (3) a rendering API. For slideforge.dev previews we ended up building a pure-Python PPTX→PNG renderer, because shipping LibreOffice inside an autoscaling container doubled the image size and the cold-start time — that's how far you have to go if you need fast previews without Office.
That renderer is now public: paste python-pptx code into the free python-pptx previewand see the rendered slide in about a second — no account, and it lints the output (overlaps, off-canvas shapes) while it's at it.
Related, because it's usually the same asker: is python-pptx safe to run on untrusted files? Largely yes — it parses XML and executes nothing; macros in a .pptm are inert data to it. The residual risks are the generic archive ones (a .pptx is a zip — decompression bombs, huge element counts), so cap file size and parse time if the input is hostile.
Bonus — things that python-pptx actually nails
To be fair, a lot of things python-pptx handles well:
- Text box API is excellent. Granular paragraph + run control. Font, color, alignment, hyperlinks, all exposed cleanly.
- Shape geometry. All auto-shapes, custom shapes, connectors — solid coverage.
- Table API. Cell-by-cell access with merged-cell support. Works.
- Picture basics. Add, crop, reposition — reliable.
- Slide layouts. Access to slide masters and layouts is ergonomic.
- XML escape hatch. You can always drop down to raw XML via
._elementwhen the Python API doesn't expose something.
For most projects, python-pptx is still the right choice. It's free, it's transparent, it works.
Where slideforge.dev fits
We built slideforge.devas a hosted API on top of python-pptx (and lxml for the performance-critical paths) with all eleven of the above workarounds baked in. You POST a brief or a structured intent, and the engine handles the canvas math, font stack, chart composition, picture re-embedding, visual QA, and PDF export automatically. If the ten workarounds above resonate with code you've written yourself, save the time — call our API for $0.05/slide or hit the MCP server from Claude Desktop.
But if you're doing something python-pptx already covers well and you don't need consulting-grade defaults, use python-pptx. It's genuinely a great library. We'd probably still be using it as-is if we weren't shipping a hosted service.