Live data from Hacker News

Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

github.com

11–20 of 43 posts

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#11
post #5

Earlier quoted context omitted.

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 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.

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.

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#13
post #11
post #5

Earlier quoted context omitted.

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.

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.

Thanks for the feedback, I’ll add Word validation to my todo list.

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#15
post #2

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…

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?

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#16
post #12

The screenshot-to-docx scoring loop is a clever way to verify layout fidelity. Very useful for anyone generating reports from HTML.

Thanks, and just to mention, I’ve had awesome results using Autoresearch loops on other things like SQL performance.

Prompt example:

You are a SQL performance researcher. Run the following SQL query to establish a baseline, then come up with hypotheses to improve performance. Score each result and run 5 iterations. Avoid any regressions, each result must contain the exact same rows and columns.

See https://github.com/karpathy/autoresearch

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#18
post #12

The screenshot-to-docx scoring loop is a clever way to verify layout fidelity. Very useful for anyone generating reports from HTML.

Thanks, and just to mention, I’ve had awesome results using Autoresearch loops on other things like SQL performance. Prompt example: You are a SQL performance researcher. Run the following SQL query to establish a baseline, then come up with hypotheses to improve performance. Score each result and run 5 iterations. Avoid any regressions, each result must contain the exact same rows and columns. See https://github.com…

Also works wonderful for generating AI scripts, goal being increasing the elo rating after a tournament run. Also having deep and shallow tests save a lot of time. Deep tests are run sparingly while shallow tests are run after each change.

Re: Show HN: DOM-docx – HTML to native, editable Word docs (MIT)

#19
post #2

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…

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?
Post reply on HN