HN user

thisisjedr

69 karma

Engineer, founder, I ship code fast. https://j.blaszyk.me/

Posts2
Comments13
View on HN

Thanks! The hard here part is not typescript implementation but it's catching Word undocumented quirks.

The OOXML spec gets you far but doesn't cover 100% of how Word renders things. Community feedback has helped a lot here, users attach docs (in gh issues) that break rendering, we can reproduce against Word, fix the engine, and keep tightening fidelity.

I'm working on https://docx-editor.dev/, the open-source, mit licensed word editor library.

We are building this because we such library it in our core business, and a lot of other engineers seem to need it too. We have contributors showing up with bug reports and fixes, and real interest from people building apps around .docx docs.

My previous show hn post (https://news.ycombinator.com/item?id=46947229) got a lot of skepticism because we're developing heavily with AI, but with active community feedback and proper ai oversight (mostly me), I'm super proud of what we have now.

We don’t have a formal '% compatibility' metric yet, but it’s on our radar as a feedback loop mechanism for self-improvement.

For now, we mostly rely on testing with our own and customer docs. In practice, we were seeing solid results after a couple of days of keeping Claude working in the loop and giving lots of feedback: .docx files along with screenshots annotated to highlight what didn’t work.

Fair point, we know the editor isn't yet 1:1 with Word. When you built yours, was Word your source of truth (reverse-engineering sense), or did you stick to MS-OE376? And any recommended process for systematically uncovering those undocumented edge cases?