There are really two, almost entirely separate, points there - one is about missing interpretability of LibreOffice, and the other is about the author's inability to install Microsoft Office on Linux.
I'd like to articulate a case why supporting the the author's use cases is likely uneconomical.
With respect to the LibreOffice interoperability with Microsoft Office: the author works in publishing, which requires almost pixel-perfect equivalence between how a document is displayed between them and their collaborators. Faithfully reproducing almost 40 years of evolution in the layout engine (some of which co-evolution with the Windows OS and the font system) necessitates a development program of mind-boggling proportions. It is absolutely no surprise to me that no entity, either commercial or open source can finance such an endeavor. (Even Microsoft does not exhibit 100% interop between the native Office and the cloud Office 365)
A similar argument applies to being able to install Office on Linux, with the added nuance that the major driving force behind Wine etc are game distributors, whereas Office compatibility is not a major priority, especially given the VM and Office 365 alternatives.
gregopet 6 minutes ago [-]
Microsoft really doesn't want anyone to reliably copy their formats. Their standard is purposefully complicated and convoluted, it was almost rejected by ISO for this reason and it took heavy lobbying before it passed (I know of this personally as the ISO vote went through national ISO bodies).
I've worked with the Java implementation for writing Office files, the Apache POI. The internal package names for these classes are "hssf", "hwpf" and so on. It's not very obvious why until you Google it and, well, "hwpf" stands for "horrible word processor format", "hssf" is "horrible spreadsheet format" and so on. Implementing these things is often difficult for good reason, and sometimes for not so good reasons, but this is the first time I've encountered developers expressing such direct hostility towards what they were trying to implement.
yuriks 2 hours 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 1 hours 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.
raincole 1 hours 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 38 minutes 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.
ryukoposting 18 minutes ago [-]
Lots of things that just don't smell right here. First of all, every experience I've had trying to get GDocs to play ball with DOCX has led to the same misery that comes with LibreOffice. It works fine until you use an unsupported font, or tables, or precise image layouts, etc etc etc.
DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Also, for what it's worth... you know what GDocs and Word won't open? A document written in WordStar on a TRS-80 in 1983. You know what will open that document? LibreOffice. LibreOffice checks all the boxes for my spreadsheet/document writing needs, and it has also been an irreplacable tool in my data archival efforts.
lordofgibbons 5 minutes ago [-]
What's everyone's opinion on OnlyOffice? It seems to have a much more polished UI than LibreOffice.
In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
That said, I'd really like to see an office suite put together out of the various opensource tools which try to approach documents/graphics in new and striking ways:
- LyX --- a "What You See Is What You Mean" document processor, it can offer quite professional capabilities (when I was doing STEM composition, the book which came in as LaTeX exported from LyX was the cleanest and most straight-forward manuscript I ever worked on)
- PySpread --- (or maybe Flexisheet if someone can get it to a usable state) Way more than most folks need, this Pythonic spreadsheet where every cell can be either a Python program or the output of a Python program could revolutionize what folks do w/ spreadsheets and data
- Jupyter Notebooks --- almost a de facto standard, getting wider adoption would be a good thing
- ipe --- https://ipe.otfried.org/ --- this, or TikzEdit or maybe xasy for Asymptote would be more drawing tool than most users would ever want, and able to make anything anyone really needs
GeneralMaximus 37 minutes ago [-]
> In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
Because your publisher, professor, employer, collaborators, and book club members all want an Office file. Full stop. They will not accept anything else, and they will refuse to work with you unless you have the clout to force them to use your new format. And then they will be unhappy.
That’s what this article is getting at. If you want to replace Office, you need to have full compatibility with Office files. There’s no way around it. Most people don’t want more open, faster, more features, or better. They want Office (or increasingly, Google Docs).
linguae 2 hours ago [-]
I remember how promising AbiWord (https://en.wikipedia.org/wiki/AbiWord) and GNUmeric (http://www.gnumeric.org/) were 20 years ago when I first started using Linux and FreeBSD. Back in 2004, OpenOffice was slow on my hand-me-down PC running a 475MHz AMD K6-2 processor and with only 64MB RAM, but AbiWord ran well; it was a nice, lightweight word processor that was decently compatible with Microsoft Word for my needs as a high school student who needed to turn in essays and other reports. I've never tried GNUmeric, but I remember people singing its praises back in 2004.
I haven't heard anything about AbiWord and GNUmeric in recent years, though. I haven't kept up with them since my college days.
maeil 49 minutes ago [-]
> A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
This kind of thinking in tech is why Office doesn't have any serious competitors. It's insufficient for what most business users need, and they're the reason the whole world runs on Office.
jlarocco 23 minutes ago [-]
It's kind of crazy how half-assed and terrible the web app competitors to Office are.
It's been 30 years, and Office 95 was objectively better and more full featured than Google Docs in 2024. Even Microsoft Works would blow Google Docs out of the water in a feature-by-feature comparison.
alsetmusic 1 hours ago [-]
Different apps render Markdown differently. The syntax may be standardized (though extended in different ways), but the layout will be wildly different if you open the same document in several different apps. This doesn’t resolve the author’s stated issue of not having a true wysiwyg document when shared with a third party.
airstrike 2 hours ago [-]
Business users don't want .md files
immibis 1 hours ago [-]
.md is a terrible format for serious work. It only supports a few opinionated types of formatting. This is reasonable when you want to directly write one (the intended use of the format). For interchange you want at least RTF or XHTML.
2 hours ago [-]
xvilka 48 minutes ago [-]
One of the biggest blockers is the stubbornness of Apache Foundation that fails to admit that OpenOffice is effectively dead and simply redirect to the LibreOffice site, along with the announcement that OpenOffice is deprecated.
raverbashing 30 minutes ago [-]
Please, it's not like LibreOffice was significantly better or more popular
Them both being written in a memory unsafe language[1][2] isn't helping matters
Also, while digging up those links I noticed the last release of OO was in Dec 2023 which is a lot of time for all the components they bundle to acquire vulns. But at least they're consistent about it since the release before that was in Feb 2023
The big point that the article is trying to make is bookended by these quotes: "... there's a standard, things ought to be simple. So you could, theoretically and perhaps even practically, use non-Microsoft software to get the job done!". "... it[LibreOffice] stubbornly refused to that, for ideological reasons."
This feels at odds with my experience of the LibreOffice community and maintainers in general, and also appears to misunderstand the detail of the OOXML standard. I think the blockers to full pixel-level replication of Office documents have more to do with the sheer complexity of the formats involved and the obscure way some of the features are described, which AFAIK often involves just saying "do this the way Word does it" instead of describing the behaviour in a completely implementation agnostic way. As a Mac user, I am very familiar with the minor differences in rendering between Mac and Windows version of Office 365. Most people will know there are differences in rendering between the web versions and the desktop versions, too. And these implementations were written by the same organisation with people who presumably had access not only to the specification but also the actual source code and libraries that were used for the "primary" Windows implementation.
For me to agree with this article's premise, I'd need to see an example of even one implementation of OOXML support that meets the author's standards.
sys_64738 1 hours ago [-]
If people want to use it then they can use it. If they don't want to then leave them alone. This is what's great about FLOSS. You use what you want to.
chris_wot 6 minutes ago [-]
I’m not sure what this guys point is. He first says that he can’t stand on ideology, he Needs to Het Things Done. Then he says LO needs to implement OOXML fully.
Which is cute, because not even Microsoft implement OOXML fully.
LO is an incremental development model. Every point release increases compatibility. Case in point: EMF+ files had massive gaps. A guy called Bartovs has now implemented a huge chunk of functionality now.
Now we have implemented Smart Art. Floating tables. You name it, it gets improved every point release.
But what I don’t see is him writing quality bug reports. Fit to start somewhere.
dangus 49 minutes ago [-]
The biggest blocker to LibreOffice adoption is that the general purpose office suite is dying a slow death.
When you think about it, unless you’re working at a very small business or on home stuff, most things you do with it should live elsewhere.
If you’re writing up some documentation for a business process, that should live in a system designed for that purpose where documents can be linked together and integrate with other systems. Examples include Confluence or Notion.
If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
If you’re doing HR stuff like performance reviews you need a system that can enforce tight read permissions and enforce a workflow.
The list goes on and on. The general business office suite only exists to catch general purpose processes that fall through the cracks where a better solution doesn’t exist, and every day that goes by eliminates another one of those use cases.
The second biggest blocker is that LibreOffice isn’t in your browser. It’s a slow-installing slow-loading clunky old desktop application.
The third biggest blocker to LibreOffice adoption is the dogshit ancient-looking UI. It looks nothing like a native application on any platform which constantly reminds you you’re using the knockoff of the Real McCoy.
And the final hurdle is that it has a dorky name.
cosmic_cheese 9 minutes ago [-]
I don’t think that LibreOffice not being in the browser is necessarily a blocker in itself. For something like an advanced office suite, where you don’t want to have browser toolbars/tabs/etc eating up valuable screen space that could be going to app palettes and such instead, not being chained to a browser is a boon.
Besides that, when software serves a purpose well, people do not hesitate to download and install it. If need to install an app causes significant user dropoff, I’d say that’s an indictment of the app’s functionality/UX/etc. It basically means that the value the app provides isn’t worth an extremely minor one-time inconvenience, which is a pretty low bar to clear.
maeil 46 minutes ago [-]
> If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
This greatly underestimates the importance of Excel for anything to do with physical goods, which is all of the world outside of the tiny SV/HN SaaS bubble. Excel files are the API that glues every factory, supplier, vendor and system together. Good luck replacing that and forcing all of the involved parties to switch to this replacement.
GeneralMaximus 33 minutes ago [-]
Yep. I’m currently working for a client who build software for the insurance industry, and we have a whole pipeline to parse and generate Excel files. The industry mostly runs on Excel and email. Without support for parsing those spreadsheets, my client would never have been able to convince their customers to use the rest of their software.
2Gkashmiri 2 hours ago [-]
I dont know.
I am a "heavy" calc and writer user. I use them daily in my office job.
I dont need much macros (the ones I created for excel do with for calc) so it works.
I do get formatting issues with files every often but with next release, its usually fixed.
I have been using of before it was libreoffice so I know.
Yes, it does crash sometimes but that is getting less and less obvious now.
I encourage you to give it a spin. Its not half as bad as it sounds
tech234a 2 hours ago [-]
(2023)
andrewstuart 2 hours ago [-]
Macintosh apps have great compatibility as do Google.
Rendered at 04:51:59 GMT+0000 (Coordinated Universal Time) with Vercel.
I'd like to articulate a case why supporting the the author's use cases is likely uneconomical.
With respect to the LibreOffice interoperability with Microsoft Office: the author works in publishing, which requires almost pixel-perfect equivalence between how a document is displayed between them and their collaborators. Faithfully reproducing almost 40 years of evolution in the layout engine (some of which co-evolution with the Windows OS and the font system) necessitates a development program of mind-boggling proportions. It is absolutely no surprise to me that no entity, either commercial or open source can finance such an endeavor. (Even Microsoft does not exhibit 100% interop between the native Office and the cloud Office 365)
A similar argument applies to being able to install Office on Linux, with the added nuance that the major driving force behind Wine etc are game distributors, whereas Office compatibility is not a major priority, especially given the VM and Office 365 alternatives.
I've worked with the Java implementation for writing Office files, the Apache POI. The internal package names for these classes are "hssf", "hwpf" and so on. It's not very obvious why until you Google it and, well, "hwpf" stands for "horrible word processor format", "hssf" is "horrible spreadsheet format" and so on. Implementing these things is often difficult for good reason, and sometimes for not so good reasons, but this is the first time I've encountered developers expressing such direct hostility towards what they were trying to implement.
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."
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.
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.
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.
DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Also, for what it's worth... you know what GDocs and Word won't open? A document written in WordStar on a TRS-80 in 1983. You know what will open that document? LibreOffice. LibreOffice checks all the boxes for my spreadsheet/document writing needs, and it has also been an irreplacable tool in my data archival efforts.
https://github.com/ONLYOFFICE/DesktopEditors
A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
That said, I'd really like to see an office suite put together out of the various opensource tools which try to approach documents/graphics in new and striking ways:
- LyX --- a "What You See Is What You Mean" document processor, it can offer quite professional capabilities (when I was doing STEM composition, the book which came in as LaTeX exported from LyX was the cleanest and most straight-forward manuscript I ever worked on)
- PySpread --- (or maybe Flexisheet if someone can get it to a usable state) Way more than most folks need, this Pythonic spreadsheet where every cell can be either a Python program or the output of a Python program could revolutionize what folks do w/ spreadsheets and data
- Jupyter Notebooks --- almost a de facto standard, getting wider adoption would be a good thing
- ipe --- https://ipe.otfried.org/ --- this, or TikzEdit or maybe xasy for Asymptote would be more drawing tool than most users would ever want, and able to make anything anyone really needs
Because your publisher, professor, employer, collaborators, and book club members all want an Office file. Full stop. They will not accept anything else, and they will refuse to work with you unless you have the clout to force them to use your new format. And then they will be unhappy.
That’s what this article is getting at. If you want to replace Office, you need to have full compatibility with Office files. There’s no way around it. Most people don’t want more open, faster, more features, or better. They want Office (or increasingly, Google Docs).
I haven't heard anything about AbiWord and GNUmeric in recent years, though. I haven't kept up with them since my college days.
This kind of thinking in tech is why Office doesn't have any serious competitors. It's insufficient for what most business users need, and they're the reason the whole world runs on Office.
It's been 30 years, and Office 95 was objectively better and more full featured than Google Docs in 2024. Even Microsoft Works would blow Google Docs out of the water in a feature-by-feature comparison.
Them both being written in a memory unsafe language[1][2] isn't helping matters
Also, while digging up those links I noticed the last release of OO was in Dec 2023 which is a lot of time for all the components they bundle to acquire vulns. But at least they're consistent about it since the release before that was in Feb 2023
1: https://github.com/apache/openoffice/tree/AOO4115-GA/main/ba...
2: https://cgit.freedesktop.org/libreoffice/core/tree/basic/sou...
This feels at odds with my experience of the LibreOffice community and maintainers in general, and also appears to misunderstand the detail of the OOXML standard. I think the blockers to full pixel-level replication of Office documents have more to do with the sheer complexity of the formats involved and the obscure way some of the features are described, which AFAIK often involves just saying "do this the way Word does it" instead of describing the behaviour in a completely implementation agnostic way. As a Mac user, I am very familiar with the minor differences in rendering between Mac and Windows version of Office 365. Most people will know there are differences in rendering between the web versions and the desktop versions, too. And these implementations were written by the same organisation with people who presumably had access not only to the specification but also the actual source code and libraries that were used for the "primary" Windows implementation.
For me to agree with this article's premise, I'd need to see an example of even one implementation of OOXML support that meets the author's standards.
Which is cute, because not even Microsoft implement OOXML fully.
LO is an incremental development model. Every point release increases compatibility. Case in point: EMF+ files had massive gaps. A guy called Bartovs has now implemented a huge chunk of functionality now.
Now we have implemented Smart Art. Floating tables. You name it, it gets improved every point release.
But what I don’t see is him writing quality bug reports. Fit to start somewhere.
When you think about it, unless you’re working at a very small business or on home stuff, most things you do with it should live elsewhere.
If you’re writing up some documentation for a business process, that should live in a system designed for that purpose where documents can be linked together and integrate with other systems. Examples include Confluence or Notion.
If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
If you’re doing HR stuff like performance reviews you need a system that can enforce tight read permissions and enforce a workflow.
The list goes on and on. The general business office suite only exists to catch general purpose processes that fall through the cracks where a better solution doesn’t exist, and every day that goes by eliminates another one of those use cases.
The second biggest blocker is that LibreOffice isn’t in your browser. It’s a slow-installing slow-loading clunky old desktop application.
The third biggest blocker to LibreOffice adoption is the dogshit ancient-looking UI. It looks nothing like a native application on any platform which constantly reminds you you’re using the knockoff of the Real McCoy.
And the final hurdle is that it has a dorky name.
Besides that, when software serves a purpose well, people do not hesitate to download and install it. If need to install an app causes significant user dropoff, I’d say that’s an indictment of the app’s functionality/UX/etc. It basically means that the value the app provides isn’t worth an extremely minor one-time inconvenience, which is a pretty low bar to clear.
This greatly underestimates the importance of Excel for anything to do with physical goods, which is all of the world outside of the tiny SV/HN SaaS bubble. Excel files are the API that glues every factory, supplier, vendor and system together. Good luck replacing that and forcing all of the involved parties to switch to this replacement.
I am a "heavy" calc and writer user. I use them daily in my office job.
I dont need much macros (the ones I created for excel do with for calc) so it works.
I do get formatting issues with files every often but with next release, its usually fixed.
I have been using of before it was libreoffice so I know.
Yes, it does crash sometimes but that is getting less and less obvious now.
I encourage you to give it a spin. Its not half as bad as it sounds