Since all my eBook projects are version controlled via Git, I was thinking of creating a custom tool to serialize/deserialize .hepx project files, by unpacking them in the repository so that only the text files and images are tracked, but not the .hepx files. My tool would then handle updating the unserialized folder or the .hepx file, depending on which one has the most recent changes.
Another advantage of this approach is that it allows to convert absolute path in projects settings to relative paths in the unpacked data, restoring it to an absolute path when rebuilding the .hepx file, effectively making HTMLExecutable project files “portable” (e.g. when accessing the repository from different machines, or when collaboratively editing a book project).
Most of my eBook projects are private, hosted on a local Git server, but I’ll soon also be working on some open source eBook projects on GitHub, in which case I’d be sharing publicly the unserialized .hepx project files.
Since the unpacked contents of a .hepx files often contain default images and CSS stylesheets that ship with HTMLExecutable, I was wondering if publicly sharing the .hepx project files (packed or otherwise) would constitute a problem because of these assets. My understanding is that HTMLExe users have the right to reuse them in their own projects, but sharing the raw assets is another thing (even though it’s in the context of a legitimate HTMLExe book project), so I thought about asking before sharing anything.
In case these images (mostly icons, e.g. for the TOC, or button images for the navbars) and/or CSS is not allowed, the only solution I can think of is to fingerprint all the default images so they can be ignored by Git and excluded from the unpacked data — the tool can always retrieve them locally, since they are shipped with the application.
That was my main question, regarding the legal aspects of sharing of the default assets which are included in .hepx project files.
As a side consideration, it would be nice to have an alternative way to save HTMLExe projects, using plaintext files (XML, JSON, YAML, etc.) instead of a packed binary. For my books and documentation projects I strongly rely on automation, Continuos Integration services, and command line tools to integrate the various tools in the pipeline. HTMLExecutable is only one of the tools involved in generating the final documents, along with other tools for generating static websites, ePub, CHM, PDF, etc., via AsciiDoc.
In these kind of contexts, which usually involve collaborative editing and version control, settings stored in binary format and absolute paths are problematic, but if the settings are stored in plaintext they can at least be manipulated so that when the project is checked out locally they are converted back to absolute paths.