Have you tried the online version of MS Office? I'm not sure, but I think there's a free version. Depending on the file, you might be able to convert it to another format, then use a FOSS tool going forwards.
this post was submitted on 25 Aug 2024
66 points (88.4% liked)
Linux
48193 readers
1305 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I was thinking along the same lines. Use the online version available via portal.office.com, and use that to convert everything to something more FOSS-friendly.
Not sure if access is free, though.
This is what I would recommend as well. Try to convert within Word to an older version or open version that's likely to be compatible with other software. Test one and see if it converts okay.
load more comments
(7 replies)
In my experience, OnlyOffice has the best compatibility with M$ Office. You should try it if you haven't
It's worth a try, though in my experience it can struggle with very large files.
OnlyOffice.
Not to be confused with OpenOffice.
(LibreOffice forked from OO back then.)
I will agree with the people suggesting "VM and a pirated copy"
Just get like office 2010 and windows 7 off of the web, run it in a VM, convert the files, dump it all.
Instead of pirating anything, you can instead use:
https://github.com/massgravel/Microsoft-Activation-Scripts for activation
https://massgrave.dev/office_msi_links for download of office
(these count as piracy, but yes, they work well and are reliable)
Yeah this is the last version of Office that doesn't nag you and your can find keys or buy generated ones off eBay if you feel guilty or worried about malicious cracks.
Doesn't Office 2010 work in Wine?
I wouldn't know, but since OP is having compatibility issues, I'd try to get as close to native as I could. Hence the VM with actual Windows.
They can just delete the lot after they've converted their files to an opener format. :P
You can try Pandoc and see if that works, Google Docs, Office365, finding an abandonware version of Word and running on Wine...lots of options to work with.
It might be easier to start narrowing down where you need to look if you get the header info from one of these files.
load more comments
(4 replies)
Assuming you meant ".docx files", those should open without issue in LibreOffice. As others have said, OnlyOffice is another popular option if format preservation is a goal.
What do you mean when you say the files are "not supported" by the tools you've tried? What, exactly, is happening and what are you trying to accomplish? The end goal wasn't clear to me from your post.
Getting Word to run under wine will require much more effort than copying the Word binary.
Yes .docx.
It appears as though the encoding is missing in such a way that nothing in Linux recognizes the file. The underlying CLI tools don't have a way of converting the file. I tried with Python's docx tool and with iconv. It has to be encoding related because some tools initially load the file with several sets of Asian characters instead of English. However, there is no hexadecimal or sections of entirely binary looking data. Archiving tools do not open up the the file to reveal anything else like a metafile or header. Neo vim shows garbled nonsense throughout. Bat warns of binary. Python won't load the file, nor will Only Office. Libre Office and Abi Word load initially with Asian characters before crashing.
The only option is likely gong to be setting up the W10 machine and converting a bunch of files within it.
Ultimately, my old man thinks he can be an author all of the sudden and is trying to write. He's not very capable of learning. I'm not confident that he can learn to use FOSS to do the same thing he has been doing. This post was just to see if there are options I am not already aware of that might actually work in practice. I can easily do everything I need in FOSS. I can do everything he needs to do. I'm more concerned about becoming his tech support when he forgets how to copy pasta. He already fails to separate the internet hardware connectivity from the web browser and operating system within his mental model of technology.
Sounds like it's actually a .doc file that has been renamed to a .docx for some reason. Real MS Word would probably still open it fine, but open source tools would fall over hard.
You mentioned you can't decompress it either. If it was a real .docx you could rename the extension to .zip and unzip it with any archiver to see the contents. If the archiver complains about the format, then it's not a real docx.
If it really is a .doc file and written in an ASCII-compatible encoding as most English-language documents are, opening it in a hex editor (or a non-codepage-aware text editor like the Notepad on a W10 or earlier Windows machine) will show an indecipherable proprietary header followed by the text in the file, possibly with a single space or "junk" character between each letter depending on the exact version of Word and system encoding it was written with. There may be occasional additional stretches of markup junk. At the end, there will be a footer with occasional decipherable text strings like "MSWordDoc" and font names.
If you open a .docx file in such a program, you should get a typical zipfile signature: the letters "PK" at the beginning of the file, followed by a lot of gobbledegook. If you don't get that "PK", it probably isn't a .docx.
(I've looked at a lot of MS file guts, for both curiosity and information extraction purposes.)
Thanks for clarifying, and I can appreciate your overall concerns as I face the same dilemma with my aging relatives.
Just to confirm, have you opened these files in Word yourself (or witnessed them being opened), to verify they are in fact valid documents? if valid, are they meant to be in English?
It wouldn't be the first time I've seen "other" files renamed with an incorrect file extension.
load more comments
(1 replies)
Sure it's not .doc? Earlier .docx were rather more standard compliant than new ones. .doc is the old proprietary MS Word format, while .docx is to the OOXML standard (though with all the proprietary extensions, making the standard useless).
Assuming the latest version of OpenOffice doesn't work for these files...
My next course of action would be using the Win 10 machine with Word, or a VM with Win10 or 11 and the latest version of Word. Use MASGrave to trick M$ into considering it licensed if you need to.
Use a Powershell script to interact with Word through the COM object interface and automate opening Word, opening the file, saving it as a different filetype, and closing. Here's a snippet of Powershell from Reddit for going in the opposite direction (odt to docx) for a single file. I wouldn't try to do this through Linux, just suck it up and use Windows so you don't have an extra layer of mess to deal with.
Going off M$ documentation of the save types enum, I would replace "wdFormatDocumentDefault" in that snippet with wdFormatOpenDocumentText or wdFormatStrictOpenXMLDocument, then test it with a single file to see which gives the output you need.
Getting all the files of the starting type from a folder can be done using Get-ChildItem. Store those in a variable and use a foreach loop over the initial file list.
Why do you spell it as "m$ office"?
Greedy fucks.
I wouldn't even try with wine these days.
Why don't you use the Win10 machine you have, the online version of Microsoft Office (web browser or app), a VM with Windows, or (if it works for your case) Google Docs or OnlyOffice.
VMWare and archive dot org are your friend
To be honest, there’s a few good comments linking to scripts and methods here to batch convert them on a windows pc/vm. That’s the best way to go.
To add on to their comments. If you’re just interested in preserving them then maybe printing them to pdf, specifically pdf/a, would be my approach once you got them opened.
Honestly it might be worthwhile to just get a month of Microsoft 365 and use the web client. You can upload all of the files to OneDrive and open them in the web version of Word to do what you need. Nothing beats native compatibility in a project of this scope.
Isn't there a free tier anyways?
I have office 2007 on a winxp VM, I haven't had to use it in a few years, but it is there as a back up
That's EOL
Long past, but for old files especially, old .doc files it is great as a backup.
It lives in a VM that never has access to the internet, it almost never gets started up.
How old of Docx files are you talking? Something like Office 2010 might run quite well, and your father would have probably had to have used some very weird features for it to be incompatible.
load more comments
(2 replies)
Generally, no. M$ office has some pretty invasive DRM, so your best bet to running it on linux is to run it on a windows virtual machine
Just use OnlyOffice or this: https://flathub.org/apps/io.gitlab.o20.word
load more comments
(2 replies)
I've had some success with fmstrat/winapps (if I remember the repo correctly) but that might be overkill for your use case
I bought a cheap win11+office 2021 combo on the net and use a VM. Its not the easiest way but it works...
😔
Try your local library.
im pretty surs that codeweavers crossover still works for microsoft365. atleast I used it with office365 last year without major issue.
Why not just use the windows machine?
view more: next ›