So I have to say I don't see a point in this product... though I suspect there is actually a market for it.
HTML help files were the only way I had to really discover the hidden features in any of the software I had. I dove deep into those manuals and read every section, sometimes more than once, just to familiarize myself with what was possible. If I couldn't figure something out, the option to "just Google it" wasn't on the table; the help feature built into the program was the best shot at finding the solution. It was also relatively standard: just about every bit of software, even lots of games, used the same format and had the same basic UI to navigate and search the text.
Maybe times are different now, and internet-based help really is the way to go, but for a long while they were the next best thing to a paper manual: easy to ignore, but incredibly handy when required.
I still stand by my observation - very few people read help _files_. Printed manuals - yes, those were read and they were undoubtedly useful, but not the electronic versions. They are usually bloated with so much filler and so cumbersome to use that people just don't bother.
Not saying they're perfect or solve everything, but I'm thankful to the author for making this tool.
Generally the developer doc was much better when we got MSDN on a CDROM as opposed to todays crap where links eventually become 404 because the MS web team decided to shuffle things around.
Sadly, it's all gotten lost in the shuffle over time, and 1.) Nobody writes comprehensive documentation anymore and 2.) Nobody knows the capabilities that are built in for desktop software to take advantage of.
You know, back when there were modems, and before the Eternal September spread to the rest of the world (1993 ... 2000)
When I was contracting I'd carry a disc or two of CHMs - basically the bookshelf back home, to avoid carting actual books.
And destroy it with outsourced writers. MSDN 2001 is the last piece of readable documentation about windows that is still available in some form.
(Of course moved on to ircii, bitchx, etc.)
reverse engineered chm spec and the complexity boggles my mind: https://www.nongnu.org/chmspec/latest/
These days I think I would have used Kaitai Struct to create a declarative specification and generated library code and a human-readable specification from that.
The reverse engineering of the CHM format was pretty rewarding though, it felt good to bring CHM access to the Linux community. I never got as far as scratching my original itch of having a CHM compiler that runs on Linux, instead I got distracted by open source and just ditched the proprietary world entirely.
If anyone feels the need to get involved in open source but isn't sure how or where, reverse engineering proprietary formats, drivers and firmware is needed now more than ever and is very rewarding both intellectually and for enabling the community.
I wish Microsoft had used an existing standard container format like ZIP instead of inventing yet another container format. They have created lots of different container formats over the years; OLE, ITSF, istorage from back then and probably more in recent times.
Everybody knows how to author html, if xml is some specific new set of rules, what is the advantage of that approach?
If it is xml, what makes it different from the epub format? Is epub format the subset? What were the advantages of it not being the subset?
I think you can convert CHM to ePub using Calibre, then convert from ePub to whatever you want using pandoc, then import that into Zeal?
