4 ms·

> With a free price tag, it could easily do that. But, it first needs to provide the required functionality, and today, it stubbornly refused to that, for ideol

by yuriks 2y ago

> With a free price tag, it could easily do that. But, it first needs to provide the required functionality, and today, it stubbornly refused to that, for ideological reasons. Very confused by the article, even after re-reading it. The author keeps bringing up ideology throughout the article, but is there any arguments or evidence given that this is a factor? The simplest explanation to me is that OOXML is a de-facto proprietary format, and implementing full compatibility with it is simply a large technical undertaking that LibreOffice doesn't have the resources to effectively achieve right now. They even hint at that themselves: "From what I've been able to decipher, no non-Microsoft Office program implements the full specification and follows it to the letter."

linguae 2y ago
I agree with you. I disagree with the assertion from the author that LibreOffice refuses to implement the OOXML standard for ideological reasons; nothing was cited in the article supporting this assertion. If it were true that LibreOffice's developers only want to support open standards, then there wouldn't have been support for the pre-Office 2007 binary formats. Yes, I believe that imperfect compatibility with Microsoft Office is holding LibreOffice back, but perfect compatibility isn't going to happen without massive resources. It's immense work being 100% compatible with a proprietary, under-documented standard. Without an army of developers, it's going to take a very long time. Think of how long it took Wine and ReactOS to get to today's usability, and those projects still have much work to do. Think of how long it took the HaikuOS people to release release-candidate issues of their project.
- chris_wot 2y ago
  It’s absolutely not true that LO devs only want to support open standards. They are still supporting .doc compatibility! It’s difficult to be conpatible with a software product that claims to follow an open standard but that does not.
raincole 2y ago
The article's reasoning is ridiculous. I'm quite sure if it were easy to implement OOXML, LibreOffice would have done it. The first part of OOXML alone has more than 5,000 pages. Ideology or not, I highly doubt anyone would try to implement OOXML to the letter.
- DemocracyFTW2 2y ago
  > I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it I've lost this optimism a long time ago when I realized how much denialism and how little actual factual, detailed knowledge there is among vocal proponents for Linux and free software. For example, the entire font handling stack on Linux is a hot seething mess of horrible dysfunctionality, wrongly implemented and starting out from the wrong principles (IMHO), yet nobody is working to improve it because everyone keeps telling you it's a solved problem. More specifically, years ago ago I hacked together solutions to script LibreOffice from the 'outside' as it were because its macro system is such an utter painful failure in so many ways. Not only was a single website written in Japanese the only source for a reasonable rundown of LibreOffice's API, it also introduced me, indirectly, to the fact that the people who initially wrote OpenOffice were apparently not comfortable with Java being a strictly OOP language, so they did their best to write code that to a degree circumvents that, leading to a terrifyingly bad user experience and a hint of the convoluted horrors that might lurk in the source code. The glacial pace of LibreOffice's development where the appearance of the tiniest of innovations leads, every few years, to great public announcements and a new version number, has convinced me that the community has painted themselves in a corner with an unmanageable code base and devs that are, likely, in complete denial that the only way out would be a complete rewrite of the software, something that is, understandably, too hard to stomach.
  - chris_wot 2y ago
    I challenge you on each of these points: You make a big claim that font handling is a “hot seething mess”, but you do t explain why. Harfbuzz and ICU are hardly what you describe. LibreOffice’s API is extensively documented: * https://api.libreoffice.org/ https://api.libreoffice.org/ * the Developers Guide has been around for literally over a decade and is now located at https://wiki.documentfoundation.org/Documentation/DevGuide https://wiki.documentfoundation.org/Documentation/DevGuide LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation. LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly. I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings. I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.

by yuriks 2y ago

linguae 2y ago

I agree with you. I disagree with the assertion from the author that LibreOffice refuses to implement the OOXML standard for ideological reasons; nothing was cited in the article supporting this assertion. If it were true that LibreOffice's developers only want to support open standards, then there wouldn't have been support for the pre-Office 2007 binary formats. Yes, I believe that imperfect compatibility with Microsoft Office is holding LibreOffice back, but perfect compatibility isn't going to happen without massive resources. It's immense work being 100% compatible with a proprietary, under-documented standard. Without an army of developers, it's going to take a very long time. Think of how long it took Wine and ReactOS to get to today's usability, and those projects still have much work to do. Think of how long it took the HaikuOS people to release release-candidate issues of their project.

chris_wot 2y ago
It’s absolutely not true that LO devs only want to support open standards. They are still supporting .doc compatibility! It’s difficult to be conpatible with a software product that claims to follow an open standard but that does not.

raincole 2y ago

The article's reasoning is ridiculous. I'm quite sure if it were easy to implement OOXML, LibreOffice would have done it. The first part of OOXML alone has more than 5,000 pages. Ideology or not, I highly doubt anyone would try to implement OOXML to the letter.

DemocracyFTW2 2y ago
> I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it I've lost this optimism a long time ago when I realized how much denialism and how little actual factual, detailed knowledge there is among vocal proponents for Linux and free software. For example, the entire font handling stack on Linux is a hot seething mess of horrible dysfunctionality, wrongly implemented and starting out from the wrong principles (IMHO), yet nobody is working to improve it because everyone keeps telling you it's a solved problem. More specifically, years ago ago I hacked together solutions to script LibreOffice from the 'outside' as it were because its macro system is such an utter painful failure in so many ways. Not only was a single website written in Japanese the only source for a reasonable rundown of LibreOffice's API, it also introduced me, indirectly, to the fact that the people who initially wrote OpenOffice were apparently not comfortable with Java being a strictly OOP language, so they did their best to write code that to a degree circumvents that, leading to a terrifyingly bad user experience and a hint of the convoluted horrors that might lurk in the source code. The glacial pace of LibreOffice's development where the appearance of the tiniest of innovations leads, every few years, to great public announcements and a new version number, has convinced me that the community has painted themselves in a corner with an unmanageable code base and devs that are, likely, in complete denial that the only way out would be a complete rewrite of the software, something that is, understandably, too hard to stomach.
- chris_wot 2y ago
  I challenge you on each of these points: You make a big claim that font handling is a “hot seething mess”, but you do t explain why. Harfbuzz and ICU are hardly what you describe. LibreOffice’s API is extensively documented: * https://api.libreoffice.org/ https://api.libreoffice.org/ * the Developers Guide has been around for literally over a decade and is now located at https://wiki.documentfoundation.org/Documentation/DevGuide https://wiki.documentfoundation.org/Documentation/DevGuide LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation. LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly. I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings. I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.