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 https://dashboard.documentfoundation.org.
> 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
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 <https://www.iso.org/standard/71691.html> 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: https://www.youtube.com/watch?v=WGWWVaEdHDE&t=2483s. 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
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
> <https://bugs.documentfoundation.org/show_bug.cgi?id=138923>) 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).
Italo Vignoli - LibreOffice Marketing & PR
mobile/signal +39.348.5653829 - email email@example.com
GPG Key ID - 0xAAB8D5C0
DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/marketing/
Impressum (Legal Info)
: 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