Convert PPT to ODP

The reader here almost never has one deck. It is a department’s teaching material, a decade of committee presentations, an induction pack, a research group’s conference talks — dozens or hundreds of files sitting on a shared drive, produced by people who have moved on, in a format that the organisation has decided to stop depending on. The decision was usually made for a reason that has nothing to do with slides: a licence renewal, an open-formats policy, a move to Linux desktops, a budget.

That changes what a good outcome looks like. For one deck you can fix whatever the conversion got wrong in ten minutes. For two hundred you cannot, so the useful question is not "is this deck perfect" but "what kind of thing goes wrong, and how often". The answer is encouraging: text, tables, photographs and simple shapes are reliable, and the losses cluster in features that were fashionable in 2003 and are rarely load-bearing. Convert a representative sample first and look at what breaks before committing to the whole drive.

The registry gives ODP a vendor of OASIS, a date of 2005 and the standard ISO/IEC 26300. That last field is the whole reason institutions write it into policy: an ISO standard can be implemented by anyone, so a document deposited today can be read in thirty years by software nobody has written yet. The binary PowerPoint format is marked `documented` rather than `open` — Microsoft published the specification, which is genuinely useful and is not the same as a standard maintained by a body with a process.

The practical form of that is the number of independent implementations. ODP is read and written by LibreOffice Impress, by Microsoft PowerPoint, by Google Slides, by Apple Keynote and by a long tail of smaller tools. If any one of them disappears the files remain readable. That is the property being bought, and it is worth more to an archive or a public body than any feature comparison between the two formats.

It is honest to point out that this conversion asks more of the engine than most. LibreOffice has to read a compound binary file laid out for PowerPoint 97 and express it in OpenDocument’s model, and the two were designed fifteen years and one vendor apart. Every construct that does not have a direct counterpart is mapped to the nearest thing that does.

The good news is where the difficulty falls. Text, bullet levels, tables, images, shape geometry, fills, lines, slide dimensions and speaker notes all have clean equivalents and cross reliably. What is approximated is the 2003 decorative layer: gradient and bevel effects on autoshapes, the colour-scheme mechanism of that era, WordArt, and clip art drawn as vectors by a specific version of a specific program. Those arrive close rather than identical, and on a teaching deck they are almost never the content.

A 2003 deck typically has one master and a handful of built-in layouts chosen per slide, which is a simpler arrangement than either modern format uses. OpenDocument organises the same idea as master pages with presentation styles attached, so the mapping is not one-to-one and Impress will create what it needs to represent what the deck was doing.

The practical consequence is that placeholder positions can shift slightly, particularly on slides where somebody dragged a title box away from where the master put it. That is worth checking on a sample rather than fearing across the board. It is also an opportunity: a migration is the one moment when redoing the master is cheap, because every deck is being touched anyway. A department moving two hundred decks is usually better served by converting them and then applying one clean new master than by trying to preserve a 2003 house style nobody likes.

The binary format could embed a live object from another Microsoft program, and those embeddings are the oldest thing in most legacy decks: a chart from Excel 97, an equation from Microsoft Equation 3.0, an organisation chart from the Office 2000 tool, a Word table. Equation 3.0 was removed from Office entirely in 2018, so even a PowerPoint user cannot edit those any more.

They come across as pictures. The slide looks right and the object is no longer editable in place, which for a migration is usually the correct trade — you are moving away from the software that owned them, so nothing was going to edit them again anyway. Equations are the exception worth auditing: a formula rendered at the wrong size or with substituted symbols is a real defect in teaching material, and a science or engineering department should check those slides specifically rather than sampling at random.

Simple effects survive because both formats express the same basic ideas: an object appears, fades, wipes, flies in, and the slide transitions between one and the next. If the deck uses animation the way most teaching decks do — to reveal bullet points one at a time — expect it to work.

Elaborate custom animation from the 2003 timeline is where the mapping thins out: motion paths, chained sequences with precise delays, effects applied to individual chart series or table rows. Expect simplification rather than breakage. The way to test it is to present the deck rather than to look at it, which takes as long as the deck takes and is the only check that exercises the part that fails. On a migration, do this for the decks that will actually be delivered and skip it for the ones going into the archive.

This is the risk that migrations underestimate, because it compounds. An old deck names the faces that shipped with Office in its day; the destination is a Linux desktop or a machine without Microsoft software, which has none of them. The converter carries metric-compatible substitutes for Arial, Times New Roman, Courier New, Calibri and Cambria, so those hold their character widths and the layout survives.

Anything else is substituted with whatever is available, and a slide punishes that far more than a document does. A document reflows and gets a page longer; a slide title that grows by one line runs off the edge of its box, over an image, or off the slide. Since the whole point of the migration is that these decks will be opened on machines without the original fonts, the sensible move is to standardise the typography as part of the project — pick two faces that exist everywhere and apply them through the master.

On our server, not in your browser. Reading a binary PowerPoint file and writing OpenDocument needs a real office engine, and this page says so plainly rather than implying that everything on this site runs on your own device. The file travels over an encrypted connection to a container running LibreOffice headless, and that container has no outbound internet access of its own.

Each job gets its own scratch directory and its own LibreOffice profile — two `soffice` processes sharing one profile corrupt it, and the symptom is a conversion that never returns rather than an error — and the directory is deleted when the job ends regardless of the outcome. Anything still running after sixty seconds is terminated, which matters for legacy binaries: LibreOffice tends to stop rather than fail on a malformed old file. The free tier accepts 25 MB per uploaded file.

Pick five decks that between them use everything the collection uses — one dense with equations, one with charts, one that is mostly photographs, one with heavy animation, one from the oldest year available — and convert those first. What breaks in those is what will break in all of them, and an hour spent there tells you whether the migration is a bulk job or a project with manual work in it.

Then keep the `.ppt` originals for at least a full teaching or reporting cycle after the migration, on a drive somebody can find. Not because the conversion is unsafe, but because the defects it produces are the quiet kind — a formula that renders slightly wrong, an animation that reveals everything at once — and they are found by the person delivering the deck rather than by whoever converted it. Once a deck has been presented from its ODP without complaint, the original has done its job.