Hacker News new | comments | show | ask | jobs | submit login
LibreOffice 5.4 released with new features for Writer, Calc and Impress (documentfoundation.org)
178 points by mksaunders 10 months ago | hide | past | web | favorite | 63 comments

Love LibreOffice - I've used it and OpenOffice for over 15 years. I've been heartbroken by recent releases, however - the keyboard shortcuts in Calc (and other components) have changed.

This is like breaking my fingers - I'm so much slower now. It's not just that there's a difference - I can adapt to that. It's that they've re-labeled menu entries with duplicate index keys. You can't do some things quickly now (e.g. optimize column widths with Alt-O-M-O, which worked for years).

There's a reason why MS Excel has keyboard shortcuts that make no sense - they match to menu entries from old versions, and they've kept them in so people who have been using it for decades don't have a reason to switch.

Please, LibreOffice developers, make your menu shortcuts sensible again!

It's nice to hear that somebody else feels this way, too.

I'm running an older LibreOffice release simply because I won't put up with the hit on my productivity in Calc. I'm not going to waste my effort learning new keyboard shortcuts, particularly when they're key shortcuts that also work in Excel and have kept working there from Excel 2003 - 2016.

An idealistic part of me would love to spend the time to figure out how to stand up a build environment for LibreOffice to fix this myself, but I've got a lot better stuff to do.

Why not use the in application customization to set the shortcuts?

Obviously in general not wanting to bother is a perfectly valid reason, I'm asking in comparison to setting up a build environment.

They could offer keyboard shortcut sets/bundles/profiles/themes that you could switch and revert all at once.

That strikes me as so obvious that I don't understand why this is the case. Could anyone with more knowledge on the matter elaborate?

Because there isn't really many known profile in that field with each a pool of experienced users wanting it, like there is eg in code editor (where most major editor offer a set to mimic vim, emacs, visual studio, ...).

There is only "the norm" and "other random stuff nobody asked for". The norm being the ones used since forever in office and copied by every other office suite since.

And frankly your average office user (John from accounting, Denise from marketing, ...) does not have as much will to learn new shortcuts as devs do. So if devs insist on keeping theirs, it's obviously not even a question for the others.

Really weird move there by libreoffice.

That there aren't many commonly used profiles only makes it easier to ship the few that are used. I guess that 'whatever Libreffice used before' and 'Excel' would cover 90+% of demand.

There even is a precedent: Word used to (maybe still does) ship with optional keybindings for WordPerfect compatibility. I also vaguely remember excel having a set of Lotus-123 keybindings.

Oh wow, blast from the past. I vaguely recall that being able to use WP keybindings was a key reason why my dad's company eventually switched to MOFT Word, despite constantly complaining about it at the same time.

I was pretty young then, so I never completely understood or cared why they went from WordPerfect to MS Office. It had something to do with the Windows version of WP being shit, but Word missing the 'underwater screen', among other things.

All I remember is that after initially being impressed by the full-color fancy pen on the loading screen, I was mostly annoyed at how slow and unstable everything had become with Word. That feeling stayed with me until probably at least Windows XP.

I find it interesting how many of the discussions I have these days really boil down to the same issues that I feel were central to the WP/Word fued: control vs convenience, following the trends vs doing what seems logically optimal (convention over configuration?), as well as the huge shift from keyboard/command-line type interfaces to mouse/windowed environments.

I'll have to pull down this release and look at that option. My recollection from the last time I looked (over a year ago) was that the changes I wanted, mostly which involved changing the pull-down menus and accelerator keys therein, wasn't able to be customized. I'm not using "keyboard shortcuts" so much as operating the pull-down menus very quickly with multi-keypress muscle memory sequences (which Microsoft handled very well as Excel moved to the "Ribbon" interface).

>There's a reason why MS Excel has keyboard shortcuts that make no sense - they match to menu entries from old versions, and they've kept them in so people who have been using it for decades don't have a reason to switch.

Yep. I've been typing "/edr" to delete a row in a spreadsheet for 25 years, and I'm not going to stop now. :-)

That doesn't seem to work in Excel 12.29 for MacOS. Is it a Windows only keystroke?

Just for your info, no better in MS-land, Microsoft broke most shortcuts between Office 2003 and Office 2007, a few got reverted with 2010. Still it's mind blowing how bad shortcuts are nowadays. Instead of Ctrl+<char> one has to type Alt+<char>+<char> and other nonsense for many shortcuts. (Sure system wide shortcuts and a few ones like Ctrl+C still work) But try to paste a text as plain unformatted text, good luck with that.

Interesting observation. I've had the opposite experience. Perhaps it is sbecause I'm not using "shortcuts" but rather am operating the pull-down menus with accelerator keys via muscle-memory. Inserting columns, rows, formatting cells, and many other functions continued to work with the various ALT-x-x combinations that I was used to. I never used any of the CTRL-x variants, except for cut/copy/paste.

The position of CTRL on the keyboard is ideal for shortcuts. CTRL+x is short and can be used with one hand. I guess you started with 2007 or 2010. For me the ribbon related shortcuts are inefficient.

I started w/ Office 95 (well, standalone Excel 4.0, actually). To insert cells I'd type "ALT-E-I". To delete cells "ALT-E-D". Aside from cut/copy/paste and simple text formatting (bold, underline, italic) I've never used the CTRL-x shortcuts. I've always just operated the pull-down menus with their accelerator keys very quickly.

Edit: Ahh-- I re-read your comment. I'm not using the ribbon ALT-x shortcuts. I'm using the accelerator keys from the old pull-down menus. No-- those ribbon "shortcuts" are frustrating to me.

try to paste a text as plain unformatted text, good luck with that.

CTRL-V, release. Press & release the CTRL key, then press T

Or just ctrl+shift+v. Works in most applications but few people are aware of it.

Hmm, doesn't work for me in Office 2016.

It was when they brought that idiotic ribbon in and it was apparently more important to meet the engineering need for implementation elegance (consistent shortcut keys across all the office suite that matched the ribbon click path) than to let users continue to work efficiently. Insert row went from alt->I->R to something I can't even remember now. I hope someone in product management got flogged for that.

I understand you. I loathe the Microsoft Windows guy who translated the shortcuts of MS Office. Ctrl-S does not save my Excel file. I've already lost a lot of work due to this poor soul.

> Inspired by Leonardo da Vinci’s “simplicity is the ultimate sophistication”, LibreOffce developers have focused on fle simplicity as the ultimate document interoperability sophistication. This makes ODF and OOXML fles written by the free offce suite more robust and easier to exchange with other users than the same documents generated by other offce suites.

So, two notes here:

1) Microsoft Office and Google Docs at least have figured out how to make their web versions so that when I copy-and-paste from them, any i following an f doesn't disappear because of whatever they're doing to kern letters.

2) "Shorter XML output" is about 978th on the list of things that LibreOffice needs to do to improve interoperability, and the fact that it's a focus is deeply weird.

You are probably not aware of the issues related to Microsoft Office files, which are intentionally bloated with useless XML contents to make interoperability almost impossible. A cleaner XML improves interoperability, even if you do not think it helps. The reality is that until people will consider Microsoft Office files as a reference, anything else will fail WRT interoperability because those files are developed to kill interoperability.

> which are intentionally bloated with useless XML contents to make interoperability almost impossible.

That's just a conspiracy theory. The reason they're "bloated" is because Microsoft Office is optimizing for interoperability with its largest competitor: older versions of Microsoft Office.

Maybe Microsoft Office having "cleaner" XML would improve interoperability. But as long as Office is the standard, the ability to consume messy XML is worth more than the ability to emit clean XML.

> That's just a conspiracy theory.

The "conspiracy" is exceedingly well documented, as others have already noted.

The motherlode is these pages of contemporary documents at Groklaw:



A good starting document is "Can Other Vendors Implement Microsoft's Office Open XML?" http://web.archive.org/web/20070912014933/http://www.hollowa...

> A good starting document is "Can Other Vendors Implement Microsoft's Office Open XML?" http://web.archive.org/web/20070912014933/http://www.hollowa....

Then let's start there! Let's start with the first section about Word Processing, in fact:

``` 1.1. Historical Compatibility

OOXML contains compatibility markers to describe older legacy documents, their quirks and processing models. These compatibility features mark behaviours that software must implement to correctly display and process the majority of documents in existence.

The "Compability Settings" WordProcessingML4 section within OOXML does not provide for repeatable practices. While it provides Microsoft the ability to store information related to various behaviors in their legacy file formats, the specification merely lists the names of these settings without proper definitions. An OOXML-consuming application, presented with a document using these attributes, will be unable to interpret them properly and render the page in a high-fidelity manner. Further, since these attributes are merely listed but not defined, the ability to practice the benefit of being “fully compatible with the large existing investments in Microsoft Office documents” (the goal of OOXML according to its authors) is consequently reserved for Microsoft alone.

These behaviours such as “autoSpaceLikeWord95” , “useWord97LineBreakRules” and “useWord2002TableStyleRules” are not defined. As OOXML repeatedly states, [t]o faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard.

These processing hints in the proposed standard depend on undisclosed information, and therefore other vendors cannot correctly process historical documents using OOXML. This lack of specification has significant implications for the New Zealand public sector organisations operating under the Public Records Act who are seeking to preserve documents of their records in a readable electronic form. ```

I think that rather supports the claim that backwards compatibility is a problem for OOXML. I see no claim in there about any deliberate obfuscation.

> These behaviours such as “autoSpaceLikeWord95” , “useWord97LineBreakRules” and “useWord2002TableStyleRules” are not defined.

Amazing that these things can be part of a standard, it even has the propietary names(Word97, Word2002), it's just pure malice to propose that horrible software functionality as a standard. I guess the 6k pages really made it hard to properly review it.

You are mistaken. The tricks they used to get OOXML standardized[1] leave no room for doubt that they have been intentionally making interoperability harder.

[1]: Wikipedia has an article about that: https://en.wikipedia.org/wiki/Standardization_of_Office_Open....

You've linked to Wikipedia but there is no evidence there supporting your claim. In fact the criticism section includes pro-ODF supporters claiming the exact opposite:

> The ODF Alliance UK Action Group has stated that [...] the Office Open XML file-format is heavily based on Microsoft's own Office applications and is thus not vendor-neutral

If you've ever seen the specs for the old, binary office formats (they can be obtained) then you'd know that they are very complex indeed and that their OOXML siblings are pretty much direct encodings of the same data structures with some adaptations for the limits of XML. There is no credit to the argument that Microsoft deliberately made the OOXML office formats complex compared with the existing binary formats.

It's true that Microsoft pushed hard to get OOXML through the ISO, but the reason for that is clear: they wanted an open standard that was 100% compatible with existing Office documents. Something like ODF which lacks many of the features of Office would not do. It also makes their developer's lives a lot easier if they can specify a standard which describes their software's current behaviour. This is exactly what what Adobe did with the PDF ISO standard (1000+ pages) and nobody complains about that.

You are replying to a claim I did not make, that OOXML was not based on Microsoft Office XML or that the XML formats were made more complex than the binary formats.

Anecdotally, Libreoffice has better compatibility with older versions of MS Office than current versions of MS Office, so I'm not sure you have any more evidence for "the reason" than the person you're replying to has for the "conspiracy theory."

I'm getting the macOS gatekeeper alert about "unidentified developer". Obviously this can be bypassed by right-clicking and choosing open, but don't the libreoffice developers code-sign LibreOffice.app (anymore) ?

I was confused by this, too. I could have sworn they were signing previous releases, but I'm not sure.

I did check the SHA-1 of my download, and it was correct.

previous one was definitely code signed. I installed the previous one yesterday and it was signed. So, surprised when today's wasn't.

Yep, the SHA-1 matched the one listed on the website for me too.

I just use the libreoffice in App Store. It's older but for my needs it suffices.

>Thanks to the efforts of developers, the XML description of a new document written by LibreOffice is 50% smaller in the case of ODF (ODT), and around 90% smaller in the case of OOXML (DOCX), in comparison with the same document generated by the leading proprietary office suite.

Given Microsoft's record in implemeting OpenDocument, this shouldn't be too hard to do.

I think they're saying they do .docx better (or at least smaller) than MS Word does .docx

DOCX files created by LibreOffice are not only smaller but simpler in term of XML structure, and easier to interoperate. A two-page file created from scratch is 1100 XML lines if written by LibreOffice and 11500 XML lines if written by Microsoft Office. The 10400 redundant XML lines are there to make it difficult to properly read the file. Also, they may contain non-standard elements which have been deprecated before the approval of the standard itself but are still there after 12 years.

I'm not sure that "to make it difficult" is true.

MS Office is very old, from their point of view compatibility will always have to mean it works as much as possible like the previous version.

So suppose you have a three-way condition clause in some code, each paragraph has either "Straight", "Fast" or "Thom Hopkins" formatting. Hmm. During XML standard writing you ask engineers to explain these options so you can write them up for the standard.

"Straight" and "Fast" turn out to each have six paragraph definitions. Great! Write those in the XML standard. The guy you asked to work out "Thom Hopkins" has gone on sick leave due to a mental breakdown, he has left a forty page document, which includes excerpts from several multi-page C++ classes, one of which seems to be a partial implementation of a bin packing solver and another involves regular expressions.

You find the supervisor of the guy who last worked on the original "Thom Hopkins" code. He explains it was developed over 15 years by a large team and was originally a core part of the document engine before the invention of the faster "Straight" paragraph mode sidelined it.

Now, you _could_ add all this crap to an appendix of the proposed XML document standard, and watch a committee vomit when they try to read it OR you could say "Thom Hopkins" is a special mode and shouldn't be used in standards compliant documents, even though it's actually used in millions of templates for your own popular office suite. And then people will say you did it just to spite them...

I mostly agree with you, I subscribe to "don't attribute malice where you could attribute incompetence or unforseen factors" but I keep wondering in the back of my head why they would keep all this cruft in the docx format. They hard forked their document format in 2007 and caused a LOT of headache back then, why not take the opportunity to streamline all this stuff, you know? Why not remove "Thom Hopkins" in the case of your story?

I'm looking forward to giving LibreOffice Online a test drive. Perhaps it can replace Google Docs for us with a nice self-hosted solution.

Are there any public demo instances available?

Great. It works fine even on a tablet with touch. Sure, GoogleDocs is still better, but the power of the underlying LibreOffice will a lot more, and it's on-pare with iCloud and better than MS Word WebApp

Still looks more than a little rough around the edges. It doesn't like the styles can be edited at this stage?

I like LibreOffice as well. I find the whole suite useful: Writer, Calc, Impress and Draw. No heavy office person but I I use Calc several times a week.

It's funny that after so many years the tools still struggles getting traction even among Linux users. The built-in PDF was there years before MS Office which is why I wrote all my Resumes in the past with LibreOffice/OpenOffice. Google Docs might be more intuitive but it has less features than MS Works and I have little control over my privacy.

As much as I love LibreOffice -- and I prefer to use it whenever I can for several reasons -- the UI is just painfully awful.

My university and one of the journals I publish in require Word (docx) files for papers and other documents, so I'm required to use Office. No alternatives are allowed, not even LaTeX or sending in PDFs: their whole internal editing and typesetting system is based around Word. Still, while I disliked the ribbon in 2007, I've found the Word UI to have improved significantly over the years, with 2016 being remarkably decent and producing quite presentable documents. I would not object to there being a similar UI them in Writer.

I wanted to use Writer for several papers and my PhD thesis, but it has some difficulty importing my otherwise-not-very-complex Word 2016 files. While the text is imported more or less correctly, table widths and alignments get all screwy (which is a big deal), Word's internal cross-references (e.g. "See Figure X", where X is a number representing a specific figure and if that figure is re-ordered in the document, the number changes) get horribly broken, among other issues. Having Word export as ODT and opening that in Writer fixes some issues but creates more issues to the point where there's no real alternative for me than Word, at least for papers and other academic documents.

It really bugs me, and I blame Word for the interoperability issues. Even so, I have no alternatives due to the requirements of the journal. Bah.

I try to get into LibreOffice, but I just can't: on windows the ui is quite laggy, and the fonts just look... strange. It's like both the kerning and AA are off.

Warning to Windows users. I've just performed a clean install of the latest version, and I'm experiencing this problem:


Looks like others are having this problem, too.

Just found a solution, disabling OpenGL rendering. Not sure why this works, but it does:


I love seeing plain-text-related features appear every once in a while. Stuff like this[0] makes it much easier to use LO with my home-grown notetaking system which is kept in plain text.

[0] https://www.youtube.com/watch?v=lBNWOWJul4w&t=1m9s

I remember using OpenOffice torrents back in 2004 as the equivalent of `:CheckHealth` to see if users had problems with their network configuration, throttling, connection speed, etc because of how perpetually well-seeded they were.

I tried the torrent download just for kicks, and I was pleasantly surprised that was still the case: it downloaded at over 40MiB/s. (yes, MiB/s, not mbps).

Here's a magnet link if anyone wants:


How is the native Wayland support these days?

5.3 already runs perfectly for me on Wayland (native, not through Xwayland). So I guess 5.4 will be the same :)

That pleases me. Now if Firefox could catch up....

Forget features. Just make LO usable again. I had to revert to OpenOffice recently in the middle of pitching a client for a desktop db conversion from MS Access. On OS X Sierra LO has regressed.

I use calc all the time, and it does just fine, but one thing I'd like to know how to fix is the poor performance when having a filter applied on a long column...it crawls...

Have you submitted a bug report or looked for an existing one? https://bugs.documentfoundation.org/enter_bug.cgi?product=Li...?

Libreoffice is too slow with large documents.

At what size (in MB) of document have you noticed that it gets too slow? asking because I am planning to use it for a writing project.

I do course guides and question sets to support teaching in LibreOffice Writer (at home) and OpenOffice (at work). In the 60 page range, with lots of formulas, diagrams (drawn with drawing tools) and some bitmap images (scans of hand drawn graphs). I also copy in charts and graphs and more complex drawings from Calc/Impress as needed. No complex 'section' schemes or restyling though just writing straight through.

The size in Mb varies according to the number of scans - the drawings and diagrams themselves take little file space. A 100 page course guide comes in around 2Mb as an .odt with half a dozen scanned plots.

Seems sprightly enough on a core-duo laptop with 2Gb ram and KDE at home and the usual 'office PC' at work.

Interesting. Thanks for the info. Don't know a lot about the sizes of word processing docs, but slightly surprised that a 100 page doc would come in at as little as 2 MB. I would have thought it should be more. Maybe it is due to ODT format being compressed text/XML, which I think I read somewhere - need to look up the format spec.

Works for me. I have a 750-page .odt document which I just edited today with no speed problems.

I havent checked in a while, but have they given up on the pathetic attempt at an Access clone? It looked like someones weekend project accidentally got turned into a product.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact