Switch to Libreoffice file format then convert to doc/docx then send back that doc/docx file.

[0] it's sneaky, basically Libreoffice will show you your edits and let you manipulate and modify the document as wish but what it saves into the file is corrupted and you will only notice it next time you open that file. Sometimes it's a mismatched tag in the internal xml representation (can be fixed), sometimes huge chunk of the doc will be missing (can't be fixed).

Import docx if necessary, but work on the OASIS OpenDocument format.

>Switch to Libreoffice file format then convert to doc/docx then send back that doc/docx file.

If you need to send work to a msoffice user, just send OpenDocument. Office can open them. Should there issues, it's more likely to be their bug, not libreoffice's.

MS Office users need to get used to working with the standard document format, which is what OpenDocument is.

In the real world, we can't all afford to be this idealistic. When I need to send someone a document for work purposes and they can't open my .odt file in MS Word (something that frequently happens to me), I'm not going to say "You need to get used to working with the standard document format. It isn't my problem that you can't open it - it's more likely to be your bug, not Libreoffce's". I'm going to send them a .docx so that we can both get on with our work.

The bugs of programs trying to read others' file formats goes both ways. LibreOffice has problems reading some *.docx files -- and likewise -- Microsoft Word has problems reading some *.odt files.

Example thread of trying to keep "tracked changes" preserved in .odt files when co-workers open it in MS Word: https://forum.openoffice.org/en/forum/viewtopic.php?t=99962

That type of interoperability issue also happen with *.xlsx and *.ods spreadsheets that have non-trivial formatting or advanced functionality.

The advice of "just use the OpenDocument format" is not that simple because round-trip fidelity of the file may not be 100% preserved depending on what features of the software the collaborators use.

it's sadly not that rear

> or are is MS's ODT support incredibly buggy or what?

Sometimes, _especially_ if it's the "web" Word 365, which in my experience is really good in messing up files including ironically docx files (through I haven't used it in the last ~2 years so maybe it got better).

Why is responsibility for the software YOU decide to use somehow not something you get, but responsibility for the car you choose to drive is most certainly something you get

I bet most people would consider Libre/OpenOffice the shitty office suit and Microsoft Office the standard.

This is not how the world, in which most of Fortune 500 operate in, works. The software and format people use, is the one usually mandated by their working environment. If your org operates in Office, you operate in Office. The question 99.9% of all users are concerned with is ”I want to review/edit this document I got from Sarah/need to send to Jane”. Not ”does this conform to standard xyz”.

Standars are just paper that software may support. The real question is phenomenological - is there a support, at what level, and is the software vendor incentivized to implement support.

There is no ”this format must be followed” convention in userspace software (sadly) unlike in say, hardware drivers for a desktop os. Even if the standard would have an ISO label.

Maybe, but it's probably more reliable for them to just grab LibreOffice to open it.

It's much easier to get LibreOffice than MS Office.

Bug: Microsoft has a majority market share

https://bugs.launchpad.net/ubuntu/+bug/1

Could you please elaborate?

For what it's worth, [docx][1] is technically standard. Not sure how that pans out in practice.

[1]: https://en.wikipedia.org/wiki/Office_Open_XML

It doesn’t, basically,—the spec isn’t enough to render it, and Microsoft has stopped engaging with ISO in favour of publishing what is now nineteen major versions[1] of their own spec in step with Office updates. There also was a huge shitstorm[2] around the ratification of the original, unsurprisingly given how useless and patent-infested it was.

[1] https://learn.microsoft.com/en-us/openspecs/office_standards...

[2] http://www.groklaw.net/article.php?story=2007011720521698

But why would countries be the right entities to do this work? They aren't, but there are a conveniently small number of them internationally and there were already bodies to represent them. Specifically they send representatives from their own national standards bodies to the relevant JTC1 sub-sub-committees. Yes that means Taiwan isn't represented.

For situations where there's just a matter of agreeing a few narrow specifics, such as the A-series paper standards, it doesn't really matter how it's done. For a huge problem like "Standardize Word processor application data" it's completely impractical and the results are all you'd expect. Microsoft basically leaned on national representatives from smaller countries to push their pointless vanity standard through both ECMA and subsequently JTC1.

After all that, it's basically futile because of course Microsoft can't magically make their "Office" suite and particularly Word behave in a documented internationally standard way, they don't even know how to describe much of the behaviour except "You know, that's how Word does it". And so, the "Office Open XML" standard has long sections where there's a magic escape hatch for "legacy" documents, which Word uses extensively, and it will always do that.

"Standard" except that yeah, all this non-standard stuff is critical and will be used forever. Futile.

there was the funny thing thy MS published the standard and at the same time implemented a different standard then due to some stuff MS had to implement their standard properly and now you had 2 docx standards and had to "choose" which to use when setting up MS Word (like back in ~2007 or so) .... then they always switched to the standardized docx but they kinda continued to mess with it to a point where you shouldn't expect a MS Word document to be readable by anything even if it supposedly is saved in the standardized format (and when nitpicking it theoretically also is, just practically not in a very useful way).

Of course MS Office is easily dominant on Windows.

Right you are! I stand corrected: https://stats.documentfoundation.org/downloads#week,os

Linux is probably under-represented on this one because most Linux users will install from distro repos (or flatpack, snap or similar).

Markdown in git, reviewed as a pull request on GitHub, is the best way to do an RFC. I will die on this hill.

Alternatively, I wonder if an old school message board would work. Each RFC gets its own (sub)board, and within that board each thread is a discussion about some topic -- an individual review, debate about a section, etc. I wonder if such a thing already exists, _specifically_ for technical specification review.

I'm so sorry. Any rueful ideas on how another company might avoid that pitfall?

1. Some devs just didn't like having review discussions as PR comments. Maybe it's the way that the threads break up the markdown source. Or maybe WYSIWYG feels better for doc review. I also recall people saying "it's hard to know what's changed, could you add a changelog section?" When I replied "it's a git repo, and I leave detailed commit messages," there was no response. I think this means that they don't like that.

2. The managers who decide things don't use git. We use Google Docs for everything else, why not for this?

In the end, Google Docs works well enough. I do miss the commit log, though. It's tricky to link to a previous revision in the changelog table -- maybe I'll get into the habit of it.

Both GitHub PRs and Google Docs have this problem, though: There's no ready record of the review process -- the comments. They eventually disappear and are difficult or impossible to retrieve, and they lose context.

Not like anybody is bothering to dig.

I wonder if someone could build something clever with git-notes [0] to capture such discussions in the repo itself.

I'm sure others have thought about it already, so there must be some kind of pitfall... A little more searching finds projects like git-appraise. [1]

[0] https://git-scm.com/docs/git-notes

[1] https://github.com/google/git-appraise

So the overhead of semantic markup of the whole content (instead of just marking words as bold) might be worth it.

I dont think either of them have to be turing complete though.

I recently started using it because Lyx does not work on my ARM based Linux tablet and its not too bad when used with a GUI editor.

It is a lot more powerful than other things I use (Markdown, Sphinx) and a lot better for version tracking and multiple output formats than word processors.

XML is a good start to describing structured text.

If you're compiling a report for a college group project (or the workplace equivalent of that) you might well need things like equations and tables and suchlike.

For example if you've got a table of performance results with the best performer in each row highlighted in bold, a fact the text references - then separating content and formatting doesn't really make that much sense.

You can tag the text as "important": see vs. in HTML.

- create DOCX with change tracking in Word

- edit that in LibreOffice and save multiple times

- open it in Word modify something and save

- Word cannot load that file. Loading and saving in LibreOffice fixes that.

All cases I have seen involved change tracking, which is probably not that surprising as the internal representation of change tracking in DOCX is totally brain damaged (even more than the rest of that "dump RTF and random crap as XML" format).

To be fair, Word will won't eat it, but it will eventually shred it quite well to the point where there is no practical difference.

The Word's format is just something to avoid.

Vendor A's development team spends all their time developing, testing, bug-squashing, updating, etc. Format A, and developing, etc. their application, and developing the two to work together. They also have all the bug data, data from users, etc.

Vendor B can't possibly keep up. They have their own application and format to develop. They lack the institutional knowledge, the data, etc. There's no way their application will correctly handle complex data in Format A nearly as reliably as Vendor A (which will have bugs itself).

And in this case, Microsoft's Office team probably has far greater resources overall than LibreOffice.

I don't know if I would call LibreOffice sneaky here, they're the good guys IMO enabling you to break the clutches of MS Office

Feel free to craft problematic docx that trigger conversion errors and report them as bug for the converter.

It'd be nice to have some documentation of the internals of old DOC and XLS formats, just for the sake of recovering old files for archival purposes, but it's likely that Microsoft never bothered documenting them, even internally.

Hence why they had to completely overhaul it with DOCX/XLSX when we had the open standards requirements come in. There was no possible way for Microsoft to document it. Although it doesn't help that DOCX/XLSX have tags for "Internal binary dump of Word/Excel" so they also fall into the same trap.

https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...

All file formats are, in the end, just memory structures written in binary.

Per Spolsky, they're an absolute shower. But they are, technically, documented!

https://techcommunity.microsoft.com/t5/ask-the-performance-t...

Wine is however able to run 16 bit executables on 64 bit hosts using their version of NTVDM.

[1] http://bytepointer.com/resources/old_new_thing/20060525_178_...

[2] http://retro.ircx.net.pl/nt/mips/wx86/

But you don't have to imagine -- early amd64 Linux could do it, and there was a patch floating around that kept that feature all the way to 2.6.2x series.

These days vm86 is borked even in 32-bit kernels.

And it would cost a lot too.

Might be worth checking out for you. Though I see only one Nancy Drew game there.

The main reason was so they could our timecard software. We could have just gave them a $2 RFID card like the production employees, but then they would have to walk down to the time clock and "punch in".

I think they also ended up using it for the Windows version of Outlook because there was some feature they wanted to use that the Mac version did not have.

The amazing stuff was that that vm ran circles around my previous windows laptop, which at that point was three years old. Just way faster than that ever was. Virtual machines and emulators are a good solution for legacy applications. Much easier than pretending ancient APIs are still supported. MS could have saved themselves a lot of grief by just embracing that decades ago and breaking compatibility with each new windows version. Just run the old crap in some vm or emulator. Apple has done that a few times when they switched CPU architectures and when they introduced OS X. They of course removed legacy support as well. But the point is valid: emulation works great.

And it works well enough with Linux support in windows these days; so why not apply that for legacy stuff as well. There's no reason why you wouldn't be able to run everything from the DOS era forty years ago up until now on a modern laptop. And there's no reason to burden modern APIs with all that crap.

[1] https://news.ycombinator.com/item?id=28731534

[2] https://github.com/saagarjha/TSOEnabler

[3] https://news.ycombinator.com/item?id=33635720

And what's even funnier? I installed Wine in Ubuntu running in WSL on a Windows 11 machine, and the game runs in that environment! Never thought I would run an old game in such a convoluted way.

You don't need WSL.

https://fdossena.com/?p=wined3d/index.frag

Compiled wined3d dlls that work on windows.

https://github.com/doitsujin/dxvk

Works on windows.

Just drop them in the game folder and the game should load them instead of the real directx.

There's also other implementations of old APIs to keep old video games running, some of them are even used by linux users who use wine, like dgVoodoo :

http://dege.freeweb.hu/dgVoodoo2/ (supports Glide, a proprietary API from the 3dfx era cards, along with dx 1-7, 8.1 and 9)

https://github.com/FunkyFr3sh/cnc-ddraw (fixes all issues you can have with DirectDraw, an old 2d API, can have its use for both windows users and people who use wine on linux)

https://github.com/otya128/winevdm run 16 bit apps on 64 windows

This, along with Windows's own compatibility mode tweaks, should run almost any game that has ever been released on Windows, without having the heavy overheard of a VM (as far as I know, WSL doesn't even know how to free memory it has claimed).

https://www.youtube.com/watch?v=Bg1NiXtrJ6g

https://www.youtube.com/watch?v=3b50Stm8gu4

Was the process straightforward?

Not that anyone should expect different, but Apple has not preserved backwards compatibility with their iWork formats and I have several legacy documents that I need to find old versions to open.

https://wiki.documentfoundation.org/ReleaseNotes/4.0#Feature...

I can't think of any other program that removed the ability to open older versions of its own files. Kinda crazy.

I have no source to back me up. This is something I read about sometime back and it's probably lost in some deeply nested bookmark folder I'll never open.

I converted, 100gb of xls/doc files to upload to SharePoint and netted something like 5x space savings just by resaving in an open format.

I am not surprised at all that Libre is better at opening old files, there are files that Microsoft wont let you open without going back into security settings and allowing them, we were converting a library that goes back nearly 30 years, lots of stuff dated 20+ years ago, why would you carry compat for this trash today?

Countries were refusing to use MS office because it didn't support open document standards. MS basically showed up to the spec committee with a bunch of MS Word documentation and said it was a new spec. It was flatly rejected, but then at the last second, a whole bunch of the committee changed their minds for no logical reason (I suspect they were simply paid off) and the "standard" was adopted.

Of course, it's impossible to write something compliant with their garbage and Office didn't comply with the "spec" in the slightest.

At the same time, MS refused to keep up with ODF standards in a massive case of malicious compliance.

In the end, it worked out for MS. They faked being open just enough for European governments to continue giving them huge piles of money for systems that are as locked down and proprietary as ever and consumers (like always) were the big losers.

There is a Wikipedia page about that standardization process https://en.wikipedia.org/wiki/Standardization_of_Office_Open...

As someone who develops a library for xlsx, you have to check all three, as well as spend some time experimenting with various changes to xlsx. Patch notes are generally regulary updated with valuable information (when MS is asked a question it often is incorporated there). Standard is full of inaccuracies and is mostly primer. Some essential info misses from all and it's described as "implementation spexific", e.g. text to number conversation in formulas.

Excel has gotten better over the years, so it is mostly in line with standard.

Microsoft moved away from the core tenet of backwards compatibility at all costs more than a decade ago seemingly across the entire company all at once.

This is because old Japanese Word files are saved in Shift JIS, but LibreOffice opens them in UTF-8.

[1] https://bugs.documentfoundation.org/

WINE does fine for the top 10k or so most common apps. But whenever I've tried something in the long tail, I've been disappointed by cryptic error messages that don't turn up any useful answers in a search.

Meanwhile, Windows's compatibility mode settings for Win XP have worked fine every time I've tried.

The problem with Windows isn't a lack of backwards compatibility, the problem is that Windows 11 is Windows XP with lots of cruft added on top over the decades.

It is not only cruft but also:

1 - Security. Lots of stuff that doesn't work it is because of features that couldn't be made secure and had to be removed from windows.

2 - Developers that used undocumented behavior that ended up being removed in modern windows versions, a lot of times because of the first item. Being undocumented behavior, it is a lot more probable that WINE doesn't implement it. And sometimes this was not a fault of the developer, but from a particular development environment and framework he used.

(My MS kernel developer friends might disagree with this assessment, though)

I guess it's true they do affect quality of life ;)

[1]: Of course .psd isn't an exchangeable format. It's proprietary. But just like your friend's case, CSP can kinda read/write .psd, while Photoshop can't read .clip at all.

Generally speaking I think game dev industry relies on closed-source stuff much more than web dev. It's not that surprising tho; after all the most targeted platforms (Windows, iOS, consoles), except Android, are all closed OS.

Another one is salary (again compared to web dev). But I heard web devs had a hard time lately too.

Regrettably, my personal devices are all Linux or Android only at this point, so, I lack a proper copy of Word to fix it for him.

I really love the preview, where you can choose what delimiters and character encoding you want to work with, which row to start from and so on. It's so very user friendly and nice to use.

Don't even get me started on Adobe Creative Cloud.

  "It took a lot of work, but LibreOffice 7.6.4 can now open a wide range of word processor documents from pre-1994 on both Windows and Mac machines."
  "Can it edit .docx files without screwing up formatting yet?"
  "No, but who uses THAT?"

They manage to trash the formattimg for plain text resumes too.

I tried compiling it for Mac recently and there is code that was deprecated in 2016 with the release of macOS Sierra.

The reality is, both MS Office and LibreOffice are legacy messes. In the 90s MS aggressively broke compatibility to get users to upgrade, which is why LO can read it. Now MS is excellent at compatibility, because the focus is subscription software your employer pays for.

We have a full circle. "The job ain't done until Word won't run".

[Edit] I guess someone doesn't get the joke about how bad Words grammar checker is. It used to flag so much stuff as "fragmented" and didn't suggest improvements.