I'd be thrilled if this could lead to higher fidelity print and Save-to-PDF functionality in browsers.
Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
31–40 of 43 posts
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#32Just adding, since I don't see it mentioned in the readme, that its written in Typescript. That's what makes this interesting. I imagine Pandoc can do this but its not Typescript (its Haskell).
pandoc purportedly can run as wasm: https://github.com/haskell-wasm/pandoc-wasm
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#33Good work on the effort to the author. And every time y'all, how absurd is it that this still has to exist? It never stops being wild to me.
it could be worse and be completely closed source like google docs
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#34I'd be thrilled if this could lead to higher fidelity print and Save-to-PDF functionality in browsers.
Broken printing is a failure/intention of website developers. It’s very easy to define print styles with a `@media print {…}` CSS query. Few sites use it.
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#35Earlier quoted context omitted.
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?
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.
Ok, I dug into the Red Hat doc. It’s a great example and it uncovered a few real shortcomings.
A couple of things about this scenario:
First, the page relies on stylesheets, so you need styleSource: "computed", either Playwright on Node, or run in the browser with the content already rendered.
Second, dom-docx doesn’t fetch remote images itself. The caller supplies an imageResolver (e.g. a fetch callback), which keeps security, timeouts, host allowlists, etc. under caller control: https://dom-docx.com/learn#image-resolver
I fixed a few bugs from this (in 0.1.8):
- wide headings inside flex containers getting clipped
- oversized images not scaling down to the printable page width
- OS dark theme (prefers-color-scheme: dark) leaking near-white computed text colors into Word on the browser path
I also added an ad-hoc repo script that loads a live URL, takes a CSS selector, and converts with Playwright (tools/try-url.ts). I used it on the RHEL page and got a pretty decent 200+ page doc. Some tables still look wrong — I’ll dig into those next.
Script: https://github.com/floodtide/dom-docx/blob/main/tools/try-ur...
Example usage from a clone: npx tsx tools/try-url.ts \ "https://docs.redhat.com/en/documentation/red_hat_enterprise_..." \ ".docs-content-container" \ rhel-storage.docx
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#36Hey 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…
This is very cool and thanks for sharing the workflow, buuuuuut... Could you please rewrite the README in your own words? If not for this comment, I would have just flagged this submission without looking into it further, because no matter how useful the premise is, it feels like one of the millions “I’ve burnt a bunch of tokens and thrown the result on GitHub” kinda projects you see nowadays. Clearly that’s not the case here, but an LLM-generated README really does your project a disservice.
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#37Hey 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…
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.
I spent two days last week trying to figure out why a docx file I was generating with python-docx looked fine in libreoffice but would not open in word. it was just some text with a circle overlaid on it, but word is a lot fussier about the xml structure of the document than libreoffice is. finally had to create the same structure directly in msword and have claude examine the two files for differences.
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#38Hey 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…
[flagged]
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#39Hey 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…
Very interesting approach. I am having trouble with page breaks (documentation says they work, but demo pages dont) etc. For the invoicing example this would require table breaks/overflows into subsequent pages in a real application and I am currently evaluating going with model->PDF or model->DOCX
Do you have any approach in this regard that works ?
Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)
#40Earlier quoted context omitted.
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?
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.
Thanks for following up. I don't understand why your post has been flagged.