But most likely collaboration is now done via SharePoint and the cloud version where you can track changes live.
- There's no equivalent of "git blame" that I can find to see who/when a particular line/paragraph/section changed.
- I can't see if there's a way to view my changes separate from other edits to the document, or isolate changes by single authors generally.
- "diffing" via the "compare documents" action seems to want to generate a new document with track-changes edits for changes from old/new, but mangles the histories to present all changes as by the invoker of the diff, at that time, which isn't all that useful.
It's definitely better than nothing at all, but a long way short of where I'd hoped we'd be regarding collaborative document authoring at this point.
First of all, most developers can’t use git blame
Secondly, there hasn’t really been a good diffing / compare documents experience for complex documents, with images and tables. The experience we have with HTML occasionally breaks the document itself, it’s not suitable for an average office worker.
You have to keep in mind that the tools being complicated are a not just a training problem - every time I see a developer making a blog, they spend more time on the technology than on the content they want to write. That’s why I don’t host my blog, I need the tool to get out of the way so that I can think about the relevant issue - communication.
If necessary, could treat tables or other complicated compound entries as a single editable item, although given the mysterious passion everyone I've ever worked with seems to have for putting just about everything into a table regardless of need, I'd hope it could be granular to a cell-level, at least.
Trying to collaboratively write complicated documents with a bunch of inter-relations between sections, from different people (in my case, documentation & regulatory paperwork for medical devices) is a massive pain, and I feel like it's too obvious a problem to be confined to my particular niche.
I vaguely recall Word is widely used for preparing huge legal documents, where the content and stakes are probably similar, so maybe there are some solutions, unless they're just "throw interns at it".
Plus, Sharepoint still has no concept of concurrent editing, so you better hope that nobody works on the same document at the same time. Also, it doesn't track changes.
It is only better than a file on a Windows share by a hair. A very thin hair.
Word's diff is Not Great (tm), but yes, at least it's there. Have you tried using it with more than 1 other changeset?
I share a lot of your sentiment about open formats in previous comments, but this is classic FUD and demonstrably wrong.
No change tracking is visible to me, other than a timestamp and name of last edited.
FUD is isn't. Please don't use buzzword gratuitously, I know _a lot_ more about the deployment here than you. Also, you didn't counter the statement that it doesn't do concurrent editing (like Google Docs, OnlyOffice), which in 2024 is a major gap imho.
As for concurrency, read my comment again, I use the specific word.
What did you do to have concurrent editing (or what did you not do), and how does it integrate the various diffs?
Sharepoint also tracks all versions automatically which is quite handy.
Haven’t yet found anything resembling this in the LaTeX world. Does OpenOffice offer this?
git
Seems like Libreoffice needs this feature soon
co-author of the ODF spec (2006 ISO) here, I also got involved via NLNet to work with my local standards office to improve OOXML.
The OOXML spec was offered to the ISO standard along an unusual path, a fast standardization lane. Where there was no option for any of the people reviewing it to actually change anything. It was rubber-stamped in other words.
That fact alone doesn't mean it is a bad, but it is a bit of a red flag. The fact is, it is a really bad specification. It is a full 7000 pages long with lots of conflicting details. On top of that it is full of references like "this works like wordperfect version-n". While references are useful in specifications, they need to be to existing open standards to be meaningful. Wordperfect has never standardized its format, so referring to it is meaningless.
To implement a competing application that can use this format you'd not be able to do that from this specification alone. Next to that it is so massive that it is essentially an undertaking that makes no sense. Compare it to ODF which is 1/10th of the size. Has a lot of reuse of concepts and was written under OASIS, a standards organization, unlike the OOXML spec which was written by Microsoft and the full 7000 pages dropped on the world.
I stopped looking at the OOXML stuff for some years, so the next part may be outdated. I noticed that after MS got this ratified by OSI, and thus they dodged the threat of law requiring governments to switch to ODF, they never did an update to the spec even though the applications have seen plenty of new features.
A few things worth noting. First, the size comparison was done by counting pages in the PDFs of the two from their respective standards committees. The OOXML PDF used something like twice the line spacing of the ODF PDF, and may have also had a larger font size. Print the two with the same settings and OOXML still was a lot bigger.
Second, ODF deferred some important things to be done in later revisions of the spec. For example spreadsheet formulas. OOXML on the other hand had hundreds of pages covering spreadsheet formulas, including detailed mathematical definitions and explanations for functions.
> On top of that it is full of references like "this works like wordperfect version-n". While references are useful in specifications, they need to be to existing open standards to be meaningful. Wordperfect has never standardized its format, so referring to it is meaningless.
I believe those were in a draft but taken out in the final spec. Also, I think you might be overlooking what those references were meant to be used for.
There were lots of organizations with lots of documents that were created in older proprietary products like WordPerfect, Lotus, etc, and many of those organizations had reverse engineered or partly reverse engineered those formats and built toolchains around them.
Let's say such an organization would like to switch to ODF. They would have to rewrite their tools but they are willing to do that because an XML format will make future development easier. They will also have to convert their existing documents to ODF, which they can do.
But there are things in those documents that must work like they worked in WordPerfect. For example if they print an old document it may be essential that it has the same line breaks that it did when WordPerfect printed it.
They accept that StarOffice or OpenOffice won't be able to do WordPerfect line breaks but that's fine. Their toolchain can handle document printing. And for new documents that they create in StarOffice or OpenOffice using whatever line breaks those programs use is fine--it is just dealing with legacy documents that requires matching what those old programs did.
What they want, then, is when using ODF as a storage format for their legacy documents for some way to mark in the ODF that the document needs WordPerfect line breaks.
Now imagine two different organizations both are doing this. So they both come up with some way to add to their ODF files that some text needs WordPerfect line breaks. But one of them calls it "WP6LineBreak" and one calls it "LB_LIKE_WP6".
Wouldn't it be nicer if all the organizations that are adding a "Use WordPerfect 6 line break" indicator to their converted-to-ODF legacy files did it the same way? It would make it easier if they ever exchanged legacy files, and it would be less confusing to the rest of is if one of these files ever got into the wild.
I remember some people brought up adding support to ODF for legacy documents early in ODF standardization but Sun was not interested. Their attitude generally was ODF was going to support everything StarOffice needed and nothing more.
Microsoft on the other hand did want to support people using OOXML for legacy document storage, and so they made a big list of the various things from the most popular earlier word processors and spreadsheets that they thought people would be wanting to extend OOXML to store, and reserved some names and markup for them.
They were quite clear that these were not meant to be used by general purpose OOXML word processors or spreadsheets. They were just for people in the scenario described above.
Quoting the article:
"Microsoft Corp. admitted Wednesday that an employee at its Swedish
subsidiary offered monetary compensation to partners for voting in
favor of the Office Open XML document format's approval as an ISO standard."Those "standards" are just Office vomit in XML format. The standardization process was really controversial. IBM once threatened to leave ISO/IEC over this. It's not a good standard. It's bad faith effort from Microsoft.
The crazy dogma around these issues hurt everyone.
The smart move is the pragmatic one - just like I can access any of the billions of US Federal Court filings in the intended presentation, mandate production of documents in a standards based PDF or PDF/A format. Then history gets accessible documents for eternity, and entities can choose to use what application makes sense for them.
Or we can bikeshed over the format dick-measuring contest.
I'm talking about what comes before. Most don't have the luxury of a publishing department producing a clean pdf from what's no doubt a handful of Word inputs. Apart from horrendous formatting issues introduced by incompetency and variety of Word versions (including limited mobile/online versions), the purpose would be astronomically better change integration when 10 people concurrently review for starters. If you've never had to integrate changes from a handful of people for 100+ page documents, praise your deity.
The trick is to use open source version tracking and a simpler text editor. I suspect that markdown in a gui editor could do everything that actually needs doing.
Every employee with a reasonably recent office suite can produce a high quality PDF of whatever they are producing.
I actually have done such things. It’s not that bad - the process of review is the painful part.
Nobody has the skillsets to manage latex source code in a collaborative environment. I actually did a pilot a few years ago with Markdown and GitHub to collaborate on a large report for a multi-organization project. We quickly abandoned it for Word/Sharepoint and it worked fine.
The only practical exceptions I can think of are typesetting for publishing and bill drafting. Both are narrow use cases with specialized staff and tools. I definitely see where having a system output LaTeX could be useful for those use cases. But not the the collaborative aspects.
You have your problem right there...Would the Commissioners ramblings be less brilliant in .odt ??
That's the level of the issue. I regularly bark against some executive sending a doc printed, then scanned, then mailed, and they do not understand...
This kind of problem should be solved from schools, but to happen we need the masses feel the need of that, and they do not even know that's a problem, most fails to understand the difference of local/remote contents, have no clue about what is a file https://www.theverge.com/22684730/students-file-folder-direc... so there are few Alphabet-s, owning Meta-information, being Oracle-s of a large mass of illiterates...