Support ThreadedComments

[Elite-stay]

reference

[aral-matrix]

My apologies but if you don't show the minimal effort in writing a proper feature request, I won't invest time in looking at your links.

[Elite-stay]

I apologize for my previous actions. This is about a new class for describing annotations for Office 2019 versions and above. Attached is a new table I created. I did some research and found that the new reading method has modified the original author information, pointing it to a new person.xml. Annotations are pointed to by xr:uid to new threadedComment.xml. vmlDrawing seems to be different as well, but I can't compare the modified parts from the old version, so I can't provide much information on this. The reference link is about an openxml document, but generally, it's difficult to use in C++. As far as I know, this library is the most comprehensive and is still being maintained. If there's anything offensive, I apologize again for my previous actions.

test.xlsx

[aral-matrix]

That's better - we already invest a lot of time in researching OOXML peculiarities, I am not willing to go guessing/puzzling together what a user wants. I'll reopen as a feature request but seeing as though it appears to be a much later addition to the OOXML format, this will remain low priority for now. There's a bunch of other things that have to be done first - most notably pushing a restructured CMake configuration with a bunch of patches into master.

[Elite-stay]

If you plan to refactor the CMake configuration, I recommend considering xmake as an alternative. xmake comes with built-in package management functionality, so there's no need to embed pugixml and boost.nowide directly into the repository (I also found this library in the official repository). Additionally, xmake's scripts are more user-friendly, and the installation process doesn't require manual definition. Although the scripts are written in Lua, even if you're not familiar with Lua, you can still use them easily. Typically, you only need to define the header files, include paths, source files, macro definitions, and necessary options required by the caller. Of course, in terms of current popularity, xmake may still not be as well-known as CMake, but it offers more convenient solutions in many aspects.

[aral-matrix]

Thank you for the suggestion of an alternative build tool. Unfortunately, xmake appears to be not yet included in any major linux distribution, and I am still hoping to package OpenXLSX for debian in the next months. And our main priority when updating the build configuration is not to break user configurations...

Btw - if you look at the development-aral branch, you will see that we already restructured the codebase to exclude the pugixml and zip (miniz, libz) & boost::nowide dependencies & link them in dynamically. As a matter of fact, that is what made the CMake configuration so complex that I can't trivially fix it at the moment :/

[Elite-stay]

You pointed out that xmake is not available on mainstream Linux releases, but in fact xmake is available on Arch Linux/Alpine/ubuntu/debian/fedora, and even if it is not, it can be downloaded and installed with a single command. But it's true that the C++ community is quite dependent on CMake, and it takes a lot of courage to go directly from CMake to xmake...

As for package management, xmake only needs to add_requires("pugixml"), which will be handled automatically at install. If I have time, I may help you put together an xmake script so you can decide if it's worth it. Thank you again for your efforts.

[aral-matrix]

I made a point to say "appears to be" because I didn't do more than a quick glance at the search results ;) I was mostly interested in who is behind xmake, and I wasn't immediately able to find any "about" page with names or organizations on it, sadly.
The latest development-aral-ktb branch actually has a CMake script (admittedly a very complicated one, sadly also requiring the latest version of CMake) that has a similar function to add a dependency (with some more information, e.g. the "fallback" source code repository in case a package is not available on the host system).

Whatever we end up doing, I want to have a master commit with all the fixes from my development-aral branch that contains a consolidated updated CMake configuration, before any further changes. So thank you for the offer, but I'll ask you to have some patience with us for now.

This would all be much easier if there was a single proper build system out there that was well documented and capable of the major functions: adding dependencies from the host OS if installed, with a fallback git repository, and being able to build a shared, static and (ideally) a monolithic static library.

Unfortunately, this seems highly complex in CMake, and CMake documentation is atrocious. In GNU Make I wouldn't know how to do the pulling in of dependencies, especially if those dependencies themselves need to be configured via CMake.