Recently we at Collabora Productivity have made some substantial improvements to XLSX interoperability related to pivot tables, fixing many issues existed in Calc.
Personally I have committed these patches:
These changes allow our customers, and the whole LibreOffice user community, to enjoy better interoperability when using XLSX format. They will be available in LibreOffice version 6.3 later this summer; and they are immediately available for our customers in this week’s Collabora Office 6.0 update 28.
Thanks to our valuable customers who make these improvements possible funding the work!
Well – obviously. At least, their current actions tell that: they deprecated CRT MSMs (which is reiterated in VS 2019 RC2 release notes), a technology designed to allow MSI-based installers to install the CRT libraries in a centrally-managed manner; and the only recommended way now is using vcredist executable, which is not MSI-compatible.
What else, if not deprecation, might it mean, when an installer technology made unable to deploy applications created using vendor’s own flagship development tool?
Well – I thought: maybe that was an oversight? Why not inform them about the problem that MSI-only installers would be left without any viable option?
So I did. And I got the answer that to me was a clear confirmation:
Sorry that our current plan is like this, if there are a lot of customer complain about this new change, we will revisit this issue
So – “yes, our plan is to make it impossible for MSI; this is not a problem in our eyes; only if we will experience pressure, may we re-think about it”.
This is the title of a book I enjoyed reading, written by one of our valuable contributors – thank you RGB!
LibreOffice has always supported usage of command line switches that allow operations like conversion of documents to different file types, or batch-printing. Using LibreOffice CLI in various scripts is a very common scenario.
But until now, it had somewhat suboptimal support for this on Windows. The main executable module – soffice.bin – being a GUI subsystem application, it could not properly output its messages to the calling console, as well as return error codes to check ERRORLEVEL for success. The hacks used to redirect the output of the GUI application to the calling console were unreliable and didn’t work at all on some supported versions of Windows. Sometimes one could not even see why the entered command line was rejected as invalid.
I have just pushed a commit that changes the situation. Now LibreOffice has proper console mode on Windows. soffice.bin is now built for console subsystem, which allows using it in abovementioned scenarios, having the stdout and stderr output, as well as return code, properly sent to console (or redirected using normal means); in debug builds, the debug output is also visible on the console. To allow comfortable usage, a new console launcher executable is introduced, soffice.com, in LibreOffice installation’s program/ folder, alongside with familiar soffice.exe, which is retained for all GUI uses, as before. This allows to continue using command lines like
"c:\Program Files\LibreOffice\program\soffice" --convert-to odt file.doc
from cmd.exe command-line interpreter, without specifying the executable extension, and have the soffice.com launched to have proper console operation (subject to value of PATHEXT environment variable). The command properly “owns” the console (does not return to command prompt) until soffice finishes.
The change will be available in LibreOffice 6.3 scheduled for Summer 2019 (if testing does not reveal a major problem which would require to revert this). I hope this will make use of LibreOffice CLI more comfortable for Windows users, on par with other platforms. If you find any problems with the solution, please report bugs to our bug tracker. Early testing using daily builds is much appreciated!
Svyatoslav Razmyslov, a PVS-Studio developer, has performed an analysis of LibreOffice code using their static analysis tool, and provided the result to us (tdf#120703).
This is the second such analysis, first having been performed in 2015. I want to thank the PVS-Studio team for their efforts, that help us to improve the quality of LibreOffice code.
Managing empty fields: the status quo
When doing mail merge, it’s often (even usually) desirable that if a database field is empty for a recipient, then the corresponding line be hidden in the generated document. LibreOffice has always allowed doing this using special Hidden paragraph fields – which is very flexible, though not too user-friendly, because of its complexity in creation and support. E.g., one needs to remember to move the field along with the database field when one edits the document; or change the field’s conditions when renaming database fields or combining fields in a single paragraph.
There are situations when using Hidden paragraph fields is even impossible. Since the condition in the said field depends on a registered database name, it cannot be used when there’s no registered database (which happens when one wants to connect to data sources dynamically, when one is actually performing the merge).
Meet the convenience
Today we have released the new Collabora Office 5.3-49, which includes the improvement that we at Collabora Productivity have implemented: now database fields also hide paragraphs themselves when the field value is empty: now there’s no need to use separate fields for that. This allows for easier creation and management of the auto-hiding empty database values.
With the change, we are also more interoperable with other office suites that behave that way, including Microsoft Office.
This feature is controlled by a new compatibility option, which is enabled by default in all new documents. If one wants to return to old behaviour, however, one can easily do that using Writer’s compatibility options.
As usual, the improvement is also available in the next major release of LibreOffice, which is to be released in August.