fishbone
9 hours ago
Hey HN, author here.
I do a lot of backend document (docx file) generation work, and updating our templates and backend code is one of my least favorite development tasks. Cryptic errors, minute-plus rebuild loops. I’d much prefer building these reports in JS rendered HTML (e.g., Vue or React), but existing HTML-to-docx libraries in the OSS ecosystem don't produce output that's actually valid, editable Word structure.
I'd had good luck applying Karpathy's Autoresearch pattern (agent runs iterations against an objective score, keeps what improves, discards what doesn't) to a couple of other problems, and figured OOXML fidelity was a good fit.
The Autoresearch process goes like this: render HTML and take a screenshot, use dom-docx to convert to docx, rasterize the docx file with LibreOffice and take another screenshot, score the browser HTML screenshot vs LibreOffice screenshot and measure layout fidelity + editability + speed as a quality metric, feed score back in, and repeat to drive higher fidelity within the constraints of editability and performance. It’s a beautiful thing to watch.
Burned some tokens and ran that loop against 37 real-world HTML patterns such as nested lists, tables, flex layouts and blockquotes (stuff that often breaks converters) and "brute forced" my way to what I hope is a high-fidelity HTML to docx converter.
A few things about where it landed:
- Native OOXML output, real Word structure, not a screenshot or a 1x1 table pretending to be a document - Works in Node, in the browser (no Playwright needed for the default path), and as a CLI (npx dom-docx input.html -o output.docx) - MIT licensed - Full benchmark methodology + results vs the established OSS alternatives: https://github.com/floodtide/dom-docx/blob/main/docs/BENCHMA...
Live demo if you want to test HTML conversion in the browser: https://dom-docx.com
Happy to answer anything about the scoring loop or anything else.
PS: This is the first thing I've open sourced and I'm excited to see where it leads!
exceptione
7 hours ago
Sounds to good to be true, but it works for the given examples! What is the scope though? It produces garbage with larger documents with tables and figures. For example this large document, even with removed menu and headings: https://docs.redhat.com/en/documentation/red_hat_enterprise_...
Could it be it has only been fed small documents?
fishbone
6 hours ago
All of the suite test cases are small fragments of HTML to test specific things, so I probably do need a way to test bigger documents. Thanks for the feedback. I’ll add that to the to-do list.
I’ll try the red hat example later this evening.
Octoth0rpe
8 hours ago
That's an interesting approach. I'm concerned about the use of LibreOffice as your source of truth. Would it be possible to swap out LibreOffice for actual MS Word in this workflow? This also could reveal some libreoffice rendering bugs/edge cases that are worth filing bugs over.
cgyvbunji
4 hours ago
In my experience a docx that looks good in libreoffice usually looks good in word, it's the other way around that is usually more of a problem.
fishbone
8 hours ago
I don’t have MS word installed on my development machine, so I haven’t done much testing with Word, but that does sound like a good idea to run the suite using Word. For what it’s worth I did not notice any issues with LibreOffice, even after running many iterations and tests.
m_w_
7 hours ago
I would add a +1 for testing w/ Word - the official Office suite runs some validation where only Word will show a "broken file" popup, even when nothing else does.
In our case, clients use only real Word, so any machine-generated/mutated files (excel/ppt as well) need a pass through the real office executable.
fishbone
7 hours ago
Thanks for the feedback, I’ll add Word validation to my todo list.
rickette
6 hours ago
Interesting but how is an "autoresearch loop" different than creating a spec and X number of testcases and letting an agent run against these testcases and the spec?
fishbone
6 hours ago
Scoring would probably be the big difference because the outcome is to optimize performance or optimize a score or a metric versus just a pass fail.