Home » Uncategorized » Status update on LibreOffice / Apache OpenOffice

Status update on LibreOffice / Apache OpenOffice

Michael Meeks has posted a status update on LibreOffice versus Apache OpenOffice. It is worth reading, but there are some points I’d like to add and emphasize.

The first is that the Apache OpenOffice project went public about a year ago. And in the meanwhile, all they’ve done is make a build with a small amount of new features:

2012 04 25 ooo comparison

Most of the new features they will announce are features done by Sun / Oracle, but never debugged / shipped. Only a handful of features have been achieved by this new organization. In other words, while Apache are now making a release under the OpenOffice brand, it is not a version moves things forward very much. It should be a concern that the value of the OpenOffice name is decreasing. How many would still be running Firefox if it didn’t make major improvements for 2 years? What is the point of a brand if you aren’t building the best product to represent it? It is cheapest if the brand is handed over to LibreOffice, though primarily IBM stands in the way.  In the meanwhile, explaining to as many people as possible that LibreOffice is a better OpenOffice is helpful. I am happy several people mentioned LibreOffice in my movie interviews.

The Apache incubation started because IBM didn’t understand that LibreOffice had just build everything they would need and that copyleft is considered a good thing by many. IBM are convincing a few handfuls of naive contributors to use lax license with a primary benefit that allows IBM to use but not give back. I don’t recommend these people play poker.

The biggest point from that chart is that it documents how Apache OpenOffice is behind and will never be able to catch up with LibreOffice, especially considering their license prevents them from incorporating LO code. It should have been possible to predict these results a year ago, and now we have the evidence. I don’t expect these facts to make it into the skulls of smart but stubborn people at IBM, but it is a good reminder of the situation. There will surely be some announcements of their first release coming soon, and which will ask the community to try it out and help. Fortunately, the Linux community is already clued in to what is going on. LibreOffice is one of the most important communities to enable more people to run Linux on a full-time basis. There are many ways for people to help out.


14 Comments

  1. Since you are on the topic of LibreOffice,
    any idea what is stopping them from embedding fonts into LibreOffice documents?

    • It doesn’t really make sense to embed fonts. They should be delivered out of band. There are license issues, security issues, issues with updates, etc. PDF just embeds the geometry of the characters that are used in the document, which is often much less than an entire font and all of its metadata, which is what LibreOffice would need. The smallest document templates would become 10s of megabytes.

      • Without the ability to embed fonts, does it mean that there’s a chance that document generate at one machine may not be 100% viewable on another machine?

        E.g.

        1. My kid’s homework/presentation done in Debian + LibreOffice may not look the same when opened in a classroom environment where MS is still the norm.

        2. ODF from one office (client/supplier) may not look simliar (especially symbols?) when opened at another. Definitely a show stopper for corporations where top management want to the reports to look nice 🙂

        Or do I have the understanding all wrong?

        May not fully agreed with this link but an interesting viewpoint nevertheless (http://fuckubuntu.blogspot.com/2011/06/open-office-office-libre-font-embedding.html)

        • Your cure is worse than the disease. Now every document would get bloated by 10s of megabytes. A company could have 10 employees and 1,000 documents. You recommend replicating the font 1,000 times instead of 10? Keep in mind fonts are much bigger than bitmaps and logos or the other little things people actually care about when making standard templates.

          There are out of band solutions to your scenarios. There is even a w3c web fonts standard that LO could support. In that case, the font is embedded, but it is storing a URL rather than an entire font. That gives a partial solution without the massive bloat problems. Note that it only really works when other apps support this feature, but it is the same way with yours. Anyway, embedding fonts in ODT is a bad idea, even though it is a great idea for PDF, so don’t waste your time hoping for it.

          • I will call you on that.

            I say what you are saying is completel bullshit. It’s typical “Open Sores” appologist drible.

            Almost everyone is using Microsoft, and their office suite, and hardly anyone is using Libre or Open Office, and MS embeds all the fonts into all the documents, and Libre and Open Office don’t.

            And it’s not “the office suite” that is bears the responsibility for this, it’s the morons who program it.

            Given that Libre Office and The Document Foundation are composed of the same incestiouly intertwined committee members, and the appologists for them, say “Oh we don’t think that font embedding is in the Open Document Standards”… so Libre Office doesn’t include them… because….

            “Hello Moron Mania – as much as I utterly HATE the people in Microsoft for almost everything I can possibly think of – I want software that helps me to get my job done, not bullshit that is built by fuckwits.”

            • You are wrong, MS doesn’t typically embed their fonts in documents either. They just store the font name.

              There are challenges in LibreOffice, as Sun managed the community so poorly for many years, but things are improving.

          • I gather from your (otherwise excellent) book’s layout that you don’t give much weight to typography. Your loss really, fonts give face and emotion to words.

            I have to tell you that the whole document bloat argument is a cheap one. Fonts are insignificantly large, in tens of kilobytes usually, and embedding them would solve many issues for many users. Having fonts online is fine for you or me, but just as Linux distros’ over-reliance to ubiquity of internet is a big barrier to it’s entry in less fortunate parts of the world (which is why before massive broadband SuSE always ruled eastern europe sovereignly with it’s massive yet carefully chosen DVD package set) so would this be.

            Bottom line: embedding font is really a basic requirement of every software that uses fonts, just like embedding images is a basic requirement of every software that uses images. Images are typically larger and typically add more bloat to documents that embed both (say, PDF). LO and OO both fulfill this requirement when it comes to image embedding. There is no sane reason not to do the same with fonts.

            • Just because I don’t want to ship fonts with every document doesn’t mean I don’t care about typography. That is illogical. We simply disagree about how to distribute them. I believe fonts should be delivered out of band.

              You are wrong about fonts being tens of kilobytes. I just looked up DejaVu, one of the main fonts I used in my book, and it 3MB for the core, and 7MB for the extras. You are off by a factor of 1000.

              Embedding fonts is not like embedding bitmaps. With fonts, you need the whole thing, even if the user uses one character, because they might type more later. It doesn’t obey the “only pay for what you use rule of engineering.” With a bitmap, you know if it is big or small, and you can control it. With fonts, it would be this massive hidden tax, and it has versioning issues, security issues, etc. And again, it isn’t like embedding fonts in PDF, which only embeds the characters in use, and even then just the glyph geometry, not all the metadata.

          • Yet it is something every other office and publishing software one could possibly think of has as an option (unless one is so deeply in the subject that he can drop some esoteric names).

            The keyword here being “option”. 3MB is not that big of a deal nowadays, and I will agree that as an option it could (and should) be turned OFF unless explicitly required by the user to enable him to pack his work together with his layout and design without forcing his receivers to install the fonts (much as he is not requiring them to place his bitmaps in, say, their Pictures folder).

            The whole idea of fonts being something to install on the system and not just files is just a tradition, and comes predominantly from the fact that they are core system resource used by the UI, and licencing issues related to them. In the context of document publishing they are a file resource much like bitmaps.

            Also, how are you not embedding the whole bitmap, even if usually you are embedding even the stuff that is cropped off to maintain editability? It’s the same. I’m also confused on versioning and security issues you mention.

            OO.o, AOO and LO together with derivatives like Symphony make for the definite second most popular office suite globally (proprietary or free). I for one object to the GNOME-like mentality of “I personally find no use of it so who cares if users want it as an option”. I believe that “open” should really extend to open to feedback. And with behemoths like the office suite it should also mean “we will put a lot of effort to lower barrier to entry” but that’s an entirely different subject somewhat tackled by the LO community in contrast to OO.o.

            Don’t take this personally, it’s what I see constantly happening in promising FLOSS communities. The paranoid fear of bloat is clouding the judgement of people that forget that the point of software is to be made for users, and from features they want, not the other way around.

            I find that “Fuck Ubuntu” blog a fun read, I guess it’s a cultural thing, here in the Balkans it’s an accepted satirical tradition to raise valid points with dick jokes.

            • I learned about a number of text engines at Microsoft, and none of them had this feature at the time I was there. They referenced fonts by name in the file format, and didn’t include them.

              The point about bitmaps is that you know if it is big or small, and so the size versus resolution is something you have control over. With fonts, you type 1 character, and suddenly you need 10 MB. As for the versioning issues: fonts improve over time. Unicode evolves and adds more characters, and fonts sometimes start with support for just a few character sets and grow over time if it becomes popular. So this makes distributing them with files problematic.

        • It is a stupid feature with little historical precedence in word processing software, but if enough people want it, then so be it. I don’t read every article in Wikipedia 😉

  2. “ … especially considering their license prevents them from incorporating LO code.”

    Well … this seems to going to change as Michael Meeks himself suggested :

    “Interestingly, there is perhaps a middle ground in the category b license.”

    “Interestingly, Apache OpenOffice Incubating already has a heavy dependence on code under this license; LibreOffice plans to move wholesale to the category-b Mozilla Public License (MPLv2).”

    I accept I am somehow surprised regarding this change … I didn’t expect something like this …

    If I haven’t misunderstand this stuff, when LO will change to MPLv2 , Apache guys would be able to pick the whole software and ship it as Apache OpenOffice … which means … picking the better SW, wrap it with the most popular NAME … and come back to business (while LibreOffice will stand on the background) … … … sincerely … I don’t understand it … maybe I am having a bad day …

    Regards.

    • It is an interesting question. Apache made the point many times that they won’t be able to take LibreOffice’s code, and they were basically proud of that fact, so if LO can switch to MPL which is apparently acceptable to Apache, that could shake things up. Of course a license change doesn’t change the way these teams work. That is what we have to look for.

Leave a Reply to Cae Cancel reply

Your email address will not be published. Required fields are marked *