I am writing a PPTX parser for Object Explorer. So that I will be able to render Powerpoint files directly inside the tool.

The Object Explorer can already parse and render most of the common document formats, including Parquet, PDF, Markdown, CSV, JSON, etc.

Powerpoint file is a big missing piece. People share presentations all the time, While it's inconvenient at the moment to view a Powerpoint on the cloud, Users usually need to download the file (likely need to have multiple clicks) then open with Powerpoint. It's a quite bad experience, completely break the continuity of exploring.

But PPTX is a beast of its own. The format is complex, the spec is huge, and there are so many abbreviations that I can't keep track of them all.

Opened the OOXML spec. 5000+ pages. Started searching for "spTree". Found it buried somewhere in section 19. Okay, it's a shape tree. But what about all the other tags inside it? Back to searching.

I kept three things open at once: my code editor, the unzipped PPTX folder, and the spec PDF. Needed to understand how a slide worked, so I looked at slide1.xml. It referenced a layout through a relationship ID. Opened slide1.xml.rels to find which layout. Then opened that layout file. The layout referenced a master. Back to the rels file. Then the master file. Just to understand one slide.

This was going to take forever.

I threw together a quick web viewer. Drag a PPTX file in, unzip it with browser APIs, extract all the XML files. Put them in a tree on the left side. Click a section, see the XML on the right.

Added syntax highlighting so I could actually read the XML. The files come out as one giant line, so I wrote a formatter to indent everything properly. Now I could see the structure.

Started adding tooltips for the abbreviations. Hover over "p:sp" and see "Shape". Hover over "a:bodyPr" and see "Body Properties".

The tree navigation was huge. Instead of opening files in a folder, I could see everything organized: masters at the top, then layouts, then slides. Click to jump around. The relationship files show up right under each item, so I could see how things connect.

I broke down each slide into its parts. The background, the shape tree, individual shapes, text bodies. When I'm writing the parser and need to understand how text works, I just click on a text body section and see exactly what XML I need to handle.

Drag and drop made iteration fast. Working on the parser, hit an edge case, drag the problem file into the viewer, see what's different. The viewer saves everything to localStorage, so I can refresh and keep working with the same file.

With the viewer open, writing the parser got easier. I could see exactly what I was dealing with. Needed to extract slide titles? Looked at a few slides in the viewer, found the pattern in the XML, wrote the code.

The relationship files helped me understand the connections. A slide links to a layout, the layout links to a master. I could see it all laid out. When I wrote the code to traverse these relationships, I knew exactly what paths to follow.

The breakdown into sections made it clear what I needed to parse. Shapes are in the shape tree. Text is in text bodies. Backgrounds have their own element. I built my parser to match this structure because I could see it worked.

I still use the viewer when I'm stuck. Some PPTX file does something weird, I drop it in, see what's different. The parser handles most cases now, but when I add a new feature, I start by looking at examples in the viewer.

The tooltips still save me time. I forget what "nvSpPr" means every couple weeks. Hover, see "Non-Visual Shape Properties", remember, keep going.

It's a small tool, but it made this whole thing possible. Without it, I'd probably still be on page 500 of the spec.

Feel free to download and use it in your project. In case you interested to know how the pptx-raw-content-reader works or. Just like me, want to know how pptx works.