I hated chm because the spec wasn't open. With only 1 reference implementation, it was user-hostile. Unless the spec for helpinator is open, I don't see myself using this.
Thanks for mentioning chmspec, I think it was a mistake for me to focus on writing it instead of writing an open source library that other tools could use to read the CHM format; several folks (xCHM etc) had to re-implement code instead of just depending on a library.
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.
Kaitai Looks interesting and rich. Thou I don’t get the license gpl3 for the compiler and MIT for the runtime, you can use the runtime without the compiler ? Why split them up licensing wise
I haven't used it but I think the idea is that if they want the tool to be used in proprietary software; the runtime needs to be license-compatible with anything, but the compiler can be any license, so may as well be one that ensures the compiler will always be open.
CHM was a replacement for an even weirder format (HLP, and its reader WINHELP) carried over from Windows 3.0. It was a gopher-like hierarchy of hypertext pages, but with RTF-based formatting as opposed to HTML, and a weird, proprietary container format. Given that context, CHM meant some progress.
Why XML? In the context of the CHM format I suspect because the answer to everything around that time was XML. If XML wasn't solving your problem you needed more of it.
When CHM arrived on the scene, ZIP was far from being treated like container format, and definitely not ubiquitous.
As for XML - it's ch easier to make a stable parser that is complete and fast for XML than it is for SGML-based HTML, and indeed the was a big push towards XML everywhere... Partially because of that reason.
Because technical writing is about structured authoring (e.g. using specialized content items like step-by-step guides, FAQs or Quizzes) and I follow this metaphor, avoiding excessive formatting options and concentrating on things that matter.
Epub suffers from the same flaws - only one language per file, freeform styling that makes company-wide style consistency problematic (and when we talk about a ERP system with thousands of users and a miriad supplementary tools created for it - it's a really big problem).
And it was not designed for context-sensitive help of desktop apps, while LiteHelp is.
Comments
I hated chm because the spec wasn't open. With only 1 reference implementation, it was user-hostile. Unless the spec for helpinator is open, I don't see myself using this.
reverse engineered chm spec and the complexity boggles my mind: https://www.nongnu.org/chmspec/latest/
Thanks for mentioning chmspec, I think it was a mistake for me to focus on writing it instead of writing an open source library that other tools could use to read the CHM format; several folks (xCHM etc) had to re-implement code instead of just depending on a library.
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.
https://kaitai.io/
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.
Kaitai Looks interesting and rich. Thou I don’t get the license gpl3 for the compiler and MIT for the runtime, you can use the runtime without the compiler ? Why split them up licensing wise
I haven't used it but I think the idea is that if they want the tool to be used in proprietary software; the runtime needs to be license-compatible with anything, but the compiler can be any license, so may as well be one that ensures the compiler will always be open.
CHM was a replacement for an even weirder format (HLP, and its reader WINHELP) carried over from Windows 3.0. It was a gopher-like hierarchy of hypertext pages, but with RTF-based formatting as opposed to HTML, and a weird, proprietary container format. Given that context, CHM meant some progress.
It's a folder with xml files, content is pretty self-explanatory, but I should write a description.
Why xml and not simply zipped htmls?
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?
Why XML? In the context of the CHM format I suspect because the answer to everything around that time was XML. If XML wasn't solving your problem you needed more of it.
I've thought what's shown here (and what I've asked about) is a new format that should replace CHM, and not the old "real" CHM?
When CHM arrived on the scene, ZIP was far from being treated like container format, and definitely not ubiquitous.
As for XML - it's ch easier to make a stable parser that is complete and fast for XML than it is for SGML-based HTML, and indeed the was a big push towards XML everywhere... Partially because of that reason.
Because technical writing is about structured authoring (e.g. using specialized content items like step-by-step guides, FAQs or Quizzes) and I follow this metaphor, avoiding excessive formatting options and concentrating on things that matter.
How does that differentiate it from ePub? Because "a compressed folder with XML files" is how I describe that format.
Epub suffers from the same flaws - only one language per file, freeform styling that makes company-wide style consistency problematic (and when we talk about a ERP system with thousands of users and a miriad supplementary tools created for it - it's a really big problem).
And it was not designed for context-sensitive help of desktop apps, while LiteHelp is.