Soft edge effect on objects in LibreOffice

After implementing glow effect recently, we at Collabora Productivity also implemented soft edge effect for objects in Draw and Impress. And again, that was done thanks to SUSE who made it possible.

The relevant bug report‘s duplicate contains a sample that I use here for illustration. First, take a look at how it was before:

How it was in LibreOffice 6.4

Now let’s see what it looks like now:

How it looks in LibreOffice 7.0

And finally here is the reference look of the slide:


This will be available in the upcoming LibreOffice 7.0.

Glow effect on objects in LibreOffice

Thanks to SUSE who made this possible, now we have glow effect on objects in upcoming LibreOffice 7.0. Collabora Productivity engineers Tam√°s Bunth and myself together have implemented it for shapes and pictures.

Below are some screenshots of a PPTX slide with glow samples collected from the relevant bug report:

How it was in 6.4
How it looks like in master towards 7.0
Reference look

What puzzles me is why fontworks’ (right bottom) glow is not shown in the reference, although the effect is present in its properties. Somehow now LibreOffice seems to support glow in fontworks better ūüėČ

Glow on pictures is only implemented in Impress and Draw. Glow on shapes is available in all modules.

When Legacy Justifies Errors

Since forever, Basic in had a bug: it didn’t properly check closing parentheses in expressions like

FirstUpper = UCase( Left( sString, 1 ) + LCase( Mid( sString, 2 ) )

(example taken from this AskLibO question). Note the mismatch between opening and closing parentheses: four opening, and only three closing. The author missed one to close UCase function after Left( sString, 1 ), and any compiler would naturally point out to this common mistake – any but StarBasic in OOo and derivatives.

What StarBasic did was auto-closing the expression in the end when compiling. It would only complain if the result of such auto-closing would be ill-formed; sometimes (as in the example above), the result would be syntactically correct – but not necessarily semantically correct: the example above compiled with StarBasic did not what author expected (a text with first character capitalized, and the rest of the text in lowercase), but returned text in all caps instead. For some similar cases, such errors could be not easy to find in the absence of compiler check, especially in a large project.

This has been reported to LibreOffice bug tracker as tdf#80731 back in 2014; and it was addressed in 5.4 development cycle, with the fix backported into 5.3.1. A nice and correct fix, isn’t it?

Well, not actually. It turned out, that over the years, the amount of existing and actually used legacy code having the error has become so big, that it was unrealistic to make sure that all of it is checked and fixed. Of course, some errors were found in the code bundled with LibreOffice itself – and naturally, it was fixed. Some third-party extensions – quite a number of them – also happened to have it; and all authors who could be contacted, had released updated releases with the mistake corrected; thank you! But it wasn’t possible to test any extension out there; and besides publicly available and supported extensions, there were also unsupported (but still used, and useful) ones; and private ones (used by those who developed/paid for their development); and also uncountable macros outside of any extensions, and all of them having the error, that happily worked before, suddenly stopped working for their users … so after some time, the fix was reverted both from 5.3.3, and from still developing 5.4 (tdf#106529). By the way, I was enjoying reading “AltSearch extension put a bugfix release 1.4.2 to work around this bug” there, as if pointing to syntax error was actually a LibreOffice’s bug, not a mistake in the extension’s code.

So LibreOffice kept silently allowing the wrong syntax ever after 5.3.3, until now. Today I have reinstated the original fix by Pierre Lepage from 5.4, with one modification: the check is only active when compiling the code from within Basic IDE. What does it mean? It means, that for anyone writing a new code in the Basic IDE, the syntax error will be properly found and shown. When one opens an existing module in the IDE, and makes a modification (which would of course trigger recompilation), the existing errors in the same module (even in different routines) would be found, too. But if the code is compiled not from the IDE (as when a macro is executed from an event handler; or when an extension runs its code), the old permissive handling is kept, and the code with errors will continue working as before.

I consider this an acceptable compromise, which would both allow existing users of legacy code to keep using their code, and still prevent creation of new buggy code (and also help gradually cleaning up the existing errors in supported Basic programs).

The change will appear in coming version 6.4. It’s still to be seen if this change will survive, or will it also uncover a different can of worms, and be eventually reverted, as its predecessor ūüėä

XLSX interoperability: pivot tables-related improvements

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!

Proper console mode for LibreOffice on Windows

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,, 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¬†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!

Auto-hiding empty mail merge fields

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.

Even easier configuration of AD integration for LibreOffice

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.

Configuring LibreOffice using GPO to take user data from Active Directory

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.