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!
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.
What we had achieved previously
After we at Collabora Productivity had improved existing LDAP configuration backend to be relatively easily configurable for Windows clients in ActiveDirectory-based domain environment, we started to prepare a further improvement in this area, which purpose was to overcome the problems of LDAP-based backend. The said problems are caused by the fact that LDAP backend needs to have proper credentials for server connection explicitly configured, which leads to requirement to have a dedicated restricted service account which would have a fake password (which would be written in clear text on each configured workstation), and which only purpose is connecting to LDAP server and retrieving user information. The said approach hardly fits into Active Directory’s concept with single sign-on (SSO) in its heart. Of course, the preferable solution would be to have a configuration backend that could get user data from AD using current user’s credentials, without the need to have a service account for that.
Collabora makes the next step
In the past weeks, we have merged a brand new backend plugin (WinUserInfoBe), which uses the improvements in core made when working on LDAP backend, and which implements the said concept. It is, naturally, even easier to configure than LDAP backend (the only thing required is to set a user data field to be taken using the said plugin); neither server connection configuration, nor further LO data field to LDAP object property mapping is needed. And of course, we have made the necessary changes to our ADMX template to make this configurable using convenient GPO editor interface.
Upgrade and benefit
This change is immediately available in the released Collabora Office 5.3-49 for our customers – why not upgrade now and have a play? – and it will also be in the next major release of LibreOffice 6.1 due to be released in August 2018.
Introducing the problem
User data in LibreOffice (Options→LibreOffice→User Data) is used for a number of purposes; among them are setting authors of documents, comments and modifications (when in Change Tracking mode); and saving cursor position in documents (so that the authors would jump right to the place they worked at last time, while other readers would see the document from the beginning).
When the data is missing, collaborative work may suffer from e.g. anonymous changes or comments appearing in documents; that’s why it’s usually important for organizations to care that LibreOffice instances have this information filled in properly – and of course, the configuration should be centralized.
Pre-existing (awkward) solution
LibreOffice has always had ability to get user data using LDAP (a protocol to communicate with different directory services). Using that, it was already possible to setup LibreOffice to take user data (name, organization, address, etc.) from Active Directory (which is also accessible using LDAP) by doing some post-deployment steps: creating a custom .xcd file from a template (oo-ad-ldap.xcd.sample) shipped with LibreOffice, and deploying it to share\registry sub-folder of LibreOffice installation on client systems. However, this is not a “native” way to centrally configure Windows applications in an Active Directory domain; among other things, one needs to invent a mechanism to deploy the .xcd (e.g., using a .bat file at startup, or modifying MSIs used to install LibreOffice); debug it, and support (like when LibreOffice install path changes, as happened with LibreOffice 6.0, which now installs into LibreOffice – previously install path included major version number; and .bat script would need to account for that, and possibly also work in an environment where different LO versions exist on different systems).
A new shiny way to do this
Starting with Collabora Office 5.3-48, and coming with LibreOffice 6.1 in August, it is also possible to use a GPO Administrative Template that we at Collabora Productivity created for our partner Studio Storti, to setup this, which allows system administrators running Active Directory domains to perform the configuration conveniently using familiar tools and workflow. Please see the documentation file describing this in details, in the folder with the ADMX file.
Last week I had fixed a trivial bug (a leftover from a former change where a function’s return was changed, but one place of its usage managed to escape to be not converted to properly treat the changed return). It seems to simultaneously have fixed a number of other bugs (the discussion may be found in the bug tracker issue). The little (a few characters) bug turned out to create both performance issues, and clipping of characters, so it had big impact on LibreOffice on Windows (with DirectWrite, e.g. when OpenGL is used).
The problem became trivial both to find and fix, because of great bug report by Telesto, who not only filed the report, but also had provided every relevant piece of information, including terminal output accompanied the problem manifestation. I cannot emphasize enough the importance of this: the effort of the bug reporter makes a difference. Without the effort, some problems remain very difficult for developers to be tracked down and get fixed.
I write this to praise Telesto‘s great job, and urge every reporter of a bug to follow this great lead.