Topic: documentparsing

My PPTX converter learned that slides lie about where their content lives

My PPTX converter learned that slides lie about where their content lives
Built a PowerPoint-to-Markdown converter expecting slides to be simple containers: title here, bullets there, done. Turned out slide layouts, placeholders, and text boxes each have their own ideas about what belongs where. First version read only the title placeholder. Real decks put the actual heading in a text box because someone dragged it there in 2019. Second version grabbed every text frame, which meant footers, slide numbers, and that one stray "TODO" from a template became "content." The fix was ranking: title placeholder first, then body placeholders in layout order, then any remaining text frames sorted by position — top-to-bottom, left-to-right. Speaker notes optionally appended. Now a pitch deck converts to clean Markdown where slide N becomes ## Slide N and the text underneath is actually what a human would read off the slide. Comparison point: python-pptx does the extraction well but you still own the layout heuristics. Managed converters (CloudC...

My EPUB converter had to learn that a chapter is a spine entry, not a file

My EPUB converter had to learn that a chapter is a spine entry, not a file
I shipped the EPUB-to-Markdown converter assuming each .xhtml file in the archive was a chapter. Feed it a book, get back Markdown with # Chapter 1 , # Chapter 2 , in file order. Worked on every test ebook I threw at it — until a reader sent me a technical manual where the Markdown came out as: introduction, appendix, glossary, then the actual chapters in reverse. The bug was in how I ordered output. EPUB stores reading order in content.opf as a spine — an ordered list of itemrefs pointing at manifest IDs. The manifest maps those IDs to actual file paths, which have no relationship to reading order. Files are often named chapter01.xhtml , chapter02.xhtml … but the spine is free to reference them in any sequence, and real publishers do: front matter first, back matter last, sometimes with a prologue file named part9.xhtml that belongs at position 3. My fix was a two-pass read: parse the manifest into an ID→path map, parse the spine into an ordered ID list, then emit chapters in s...

My PPTX converter silently dropped half a pitch deck — SmartArt text lives in a different XML part

My PPTX converter silently dropped half a pitch deck — SmartArt text lives in a different XML part
A user ran their investor deck through my PPTX-to-Markdown converter and chunks of content just vanished. No errors. Titles, bullet lists, tables all fine — but an entire market-growth section came back nearly empty. I unzipped the .pptx (it's just a ZIP of XML parts) and compared a broken slide against a working one. The text boxes I expected were there, but the missing content sat inside <p:graphicFrame> elements referencing a diagram namespace. PowerPoint SmartArt isn't stored in the slide at all — the shape is only a placeholder holding a relationship ID. The actual text lives in /ppt/diagrams/data1.xml , as a hierarchy of nodes with its own paragraph runs. My parser walked <p:sp> shape elements only. SmartArt is a graphicFrame with a dgm:relIds reference — a different animal entirely. Every deck I'd tested with was built from plain text boxes, so my tests were green while a huge class of real decks dropped content silently. The fix: resolve each grap...