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!
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.
Obviously in general not wanting to bother is a perfectly valid reason, I'm asking in comparison to setting up a build environment.
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.
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.
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.
Yep. I've been typing "/edr" to delete a row in a spreadsheet for 25 years, and I'm not going to stop now. :-)
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.
CTRL-V, release. Press & release the CTRL key, then press T
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.
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.
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...
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.
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.
: Wikipedia has an article about that: https://en.wikipedia.org/wiki/Standardization_of_Office_Open....
> 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.
I did check the SHA-1 of my download, and it was correct.
Given Microsoft's record in implemeting OpenDocument, this shouldn't be too hard to do.
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...
Are there any public demo instances available?
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.
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.
Looks like others are having this problem, too.
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:
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.