Why I spent months building an offline document converter because floating textboxes kept ruining my files

If you've ever used a "free" online PDF to Word converter, you know that exact moment your heart drops:

You open the converted .docx file in Microsoft Word, try to fix a single spelling error or delete a word, and the entire layout explodes.

That's because 95% of converters out there don't actually reconstruct document structure. They take the shortcut: they wrap every single line of text in an absolute-positioned floating textbox (w:txbx). The document looks visually identical to the PDF until you touch it—then boxes overlap, line wraps break, and editing becomes impossible.

And that's not even getting into the privacy issue: why should anyone have to upload bank statements, tax returns, medical bills, or confidential client agreements to a random cloud server just to edit a table?

A few months ago, I decided to scratch my own itch and build an on-device, offline layout reconstruction engine for Android. The goal was simple:

1. Zero Cloud / 100% On-Device: Everything runs directly on your phone's processor. No remote servers, no cloud queues, no telemetry.
2. Real Flowing Layout: Native Word paragraphs (w:p) and real tables (w:tbl), so when you add or delete words, the text reflows naturally just like an author typed it.
3. Preserve High-Fidelity Objects: Stamps, signatures, logos, and letterheads stay intact as selectable/movable objects.

The Struggles Nobody Warns You About

Building this was a humbling experience:

• Mobile Memory Constraints: When processing a high-res 300 DPI multi-page document, keeping raw bitmaps in memory will trigger Android's low-memory killer instantly on budget devices. We had to implement streaming memory pooling so the app never spikes past 180MB RAM.
• The "Invisible Table" Problem: Distinguishing multi-column editorial text from borderless tabular data without relying on heavy cloud GPUs took weeks of iterative testing across hundreds of real-world sample documents.
• Google Play's 20-Tester Gauntlet: Surviving the mandatory 14-day 20-tester closed testing requirement without paying shady bot farms was grueling. We relied entirely on mutual testing with fellow indie developers, getting real crash logs and fixing edge cases before production.

Where We Are Today

We recently pushed v1.2.3 live on Google Play under PDF Retype.

It is completely free to try. I'm not here to sell anything—I genuinely want feedback from developers and power users.

Throw your messiest, most complex PDF or scanned invoice at it, and tell me where it breaks. What layouts did we fail on? What features would make your document workflow smoother?

P.S. If you're building local-first Android apps or dealing with document formatting, I'd love to discuss trade-offs and lessons learned in the comments!