A major consideration for me was #indexing. Given the structure of what I’m working on, I need to index various parts or my writing in fairly complicated ways. The setting I’m working on is a fantasy-genre world, and there are several setting-level elements that I had specific indexing wants/needs for. Countries and their likely or expected “children” are a good example, I think:

Countries
   Country Name, #–#

Country Name, #–#
   City Name, #
   Organization Name, #

(#indexing continued)

Ultimately, this example is really focused on one thing: Providing cross-references in the index, so that someone looking for a country in the setting can look under “Countries” to find the name they’re looking for, then go find that name as a main entry in the index, and look for whatever was relevant under that.

(#LibreOffice continued)

Where LibreOffice Writer failed me was in its #indexing. The program does provide index capabilities, but they are really focused on single-term values. By that I mean that it’s easy enough to set up a single index entry for, say, the “Country Name” in my example above, but managing the “children” elements — the “City Name” and “Organization Name” in that example is… painful.

(#LibreOffice continued)

The UI for index entries is the main thing that I found painful and frustrating. I did make an effort to see if I could come up with a way to deal with indexing in LibreOffice using their “Concordance File” feature (https://help.libreoffice.org/latest/he/text/swriter/01/04120250.html), in combination with hidden-text blocks that it could (theoretically) latch on to. That was also painful, just in a different way.

(#LibreOffice continued)

Digging in to scripting and automation possibilities, while they exist, didn't help much. The UNO library that’s the backbone for those kinds of efforts seems cumbersome and clunky. Even that would’ve been manageable if there wasn’t something goofy going on in the document structure itself. I couldn't get a macro/script to reliably find those hidden text blocks.

(#LibreOffice continued)

Near as I can tell, the reason for that was that the inner workings of the program don’t make any effort to merge contiguous XML blocks of the same type. Any time I made a change to a hidden text block, it apparently stored that change by adding a new XML tag with my new text in the document’s data, even if that change was a single character, and the “new” tag was identical to the one the new text was being inserted into.

(#LibreOffice continued)

Over and above that, the supported version of #LibreOffice for my OS of choice, #LinuxMint, is at least one major version behind. While there’s a #flatpak available that’s much more current, that had its own issues, like having its own dedicated file-system location for things like macros. A flatpak installation for general use is probably fine, but the sort of power-user stuff I was concerned with made it untenable.

(#Nisus continued)

Unfortunately, though it’s still possible to use their website to download the program, and to buy a license for it, that license will never be delivered, apparently — as far as I can tell, #Nisus has gone out of business.

(I’m currently working with my credit-card company to get a refund for the $65 I spent making the attempt.)

(#QuarkXPress continued)

Here, my reluctance was simply based on the price — $700 isn’t bad for this kind of program, and there was a discount that took the “Perpetual License” cost down to $524 when I looked last — but I simply didn’t feel like dropping that kind of money, and tying myself to Apple hardware or a Windows OS in the process was also a non-starter for me.