Date: prev next · Thread: first prev next last
2021 Archives by date, by thread · List index

Hi Raffaele,

Thanks for the message. Interoperability is definitely a topic worth of further efforts. I am adding some comments to your message, but the best option is probably to organize a chat after FOSDEM, the largest FOSS virtual event, planned for February 6/7 (too busy before).

On 1/26/21 7:25 PM, Raffaele Mancuso wrote:

> Unfortunately LibreOffice is unable to open them without breaking their
> layout (yes, I have all the Microsoft® fonts installed and configured
> through fontconfig).
You cannot legally use C-Fonts (Calibri, Cambria, Candara, Consolas, Constantia and Corbel). They are Microsoft proprietary, and their EULA does not allow to decouple them from Windows and Office. You should use Croscore fonts, and other fonts which emulate Microsoft fonts metrics.

You can find some suggestions here:

> I have submitted some bugs to the bug tracker so far, 3 of them
> regarding interoperability issues, but TDF is a small non-profit
> organization (11 people) and it's doing the best it could.
The Document Foundation has a staff of 11 people, but they are not developers. LibreOffice developers are way more than 11 (during the last quarter of 2020 they have been around 40 full time, plus volunteers, and some are working full time on OOXML interoperability).

You can have a better idea of the number of LibreOffice developers by looking at

> 7. Full compatibility seems to be achievable. For instance, I tried WPS®
> Office and did not have any compatibility problem so far (but I had
> compatibility issues with SoftMaker® Office 2021).
WPS is a Microsoft Office clone, reverse engineeered. They use OOXML as their default format (more on this format later), which makes their life easier but their files non interoperable (also, see later).

> I here propose to launch a crowdfunding campaign to implement full
> interoperability with Microsoft® Office formats. I can launch and manage
> the campaign if you wish.
There have already been specific projects about interoperability, funded by different entities. There is a team in Hungary working full time for OOXML interoperability.

So, the idea is not new, and launching a different project seems less obvious than supporting existing ones.

> 2.2. Document the Microsoft extensions to the OOXML(*) format (is the
> "plain" format fully-specified in ECMA-376
> <>,
> in ISO/IEC 29500 <> and also here
> <>?)
We know rather well the OOXML format, in all the available variants, which are all non standard and designed to kill interoperability. I have been personally involved in the standardization process at UNINFO back in 2006/2008, so I know rather well how the standard was accepted.

To be more precise, ECMA-376 has been rejected by ISO as a standard, because of the number of flaws, and this is the reason why Microsoft has developed OOXML, which has been approved after Geneva Ballot Resolution Meeting in two version: OOXML TRansitional, as a non standard bridge with legacy Office formats, and OOXML Strict, the real standard.

Strict was standardized based on Microsoft commitment to fully drop Transitional with Office 2010. The issue is that 100% of OOXML files generated by all versions of Office are still Transitional, as the format was never dropped, and is still the default format.

In addition, OOXML Transitional files are different according to the Office version, and change - without the changes being documented - on average every 3 months.

On the topic of standard formats you can have a look at this video in Italian: Is one of the most updated, although I am currently working at a presentation for CERN employees, specifically focused on interoperability between LibreOffice and Office.

By the way, the Italian law - if respected - prohibits the use of OOXML by Public Administrations, as it does not respect many standardization parametres.

The interoperability issue is rather complex. I use Linux Mint and exchange documents with Office users since 2006 (OpenOffice 2.0) with negligible issues. Of course, results vary according to several factors including the document complexity and how the document is generated.

> 3. I think we should handle font substitution better. For example, when
> we open a file and fonts are missing, LO should display a window with a
> list of missing fonts in the first column, the font that have been used
> as a substitute in the second column, and whether the font used as
> substitute is metric-compatible with the missing fonts (otherwise the
> layout will break, see here
> <>) in the
> third column. Moreover, LO should have a dataset of free
> metric-compatible fonts (like Carlito to substitute for Calibri).
LibreOffice has a font replacement table, which can be configured by the user, and ships with several fonts which are designed to be metrically compatible with Office fonts (for instance, the Liberation family).

Other metrically compatible fonts can be installed by the user (shipping all these fonts would dramatically increase the size of the installer).

Anyway, let's discuss your ideas after FOSDEM. Interoperability is a topic where we should definitely invest more time and efforts, and your ideas are worth a further investigation. I can give you some insights into the project, and we can start from there.

We can have a conversation in Italian (I am based just South of Milan, and according to the situation we could even meet face-to-face).

Ciao, Italo
Italo Vignoli - LibreOffice Marketing & PR
mobile/signal +39.348.5653829 - email
GPG Key ID - 0xAAB8D5C0
DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.