My old man has a bunch of .dox stuff saved. He has complicated large files saved that are not supported by any of the FOSS conversion tools. I’ve tried Libre office, Abi Word, and every command line tool and converter I can find. These are entire book sized files.
I have a W10 machine with Word. Is extracting the .exe and running it with wine feasible without making an epic mess or massive project of this?
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.
I can’t even extract the header. It is coming up as a binary, but it is just mystery encoding shenanigans of m$ criminals failing to build to the iso standard, no doubt, to cause this very issue and attempt to justify infinite payments for a finite tool. The error is in position 22 according to iconv. With $ bat, it reports binary, Only Office won’t even display and fails to pop-up. Both AbiWord and Libre Office detect over a dozen Asian languages and freezes after ~1-2 min, but display. Python3 Docx can’t even load the ‘document = Document(’/tmp/test.docx’)` line.
Okay. First off, I downvoted you for obvious reasons.
Second, if you’re not sure how to extract the header of a file, just Google that. You may be ill prepared and asking for help here.
You earned the following block. You make foolish assumptions. The header is garbled in Linux entirely there is nothing available to extract with any tools.
You don’t understand how file formats work I guess. You can’t just ‘head’ an encoded file and expect a terminal to output what you want. Do some research.
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.
Too many documents and Office 365 is a $10 month sub scam.
I can’t comment on how many documents you have, but there’s a free version of Office 365
free is not as in freedom from stalkerware, and there is only a 1 month blank-check impossibscribe extortion type trial scam.
If you’re already thinking of extracting/attempting to run a desktop version of Office, you may as well save yourself the effort if you can and give the free online version a try. You’ll be using a proprietary piece of software either way.
I’m looking at trying to convert a file type that Linux doesn’t presently have a capability of opening. What is this toxic nonsense? Seriously, I’m trying to get my ignorant old man on FOSS. I don’t give a * about m$. I also think evangelical nonsense is worse than m$, so curb that nonsense please. This isn’t some Arch forum.
You don’t have to keep the sub. Pay $10, convert the files, unsubscribe.
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.
OnlyOffice.
Not to be confused with OpenOffice.
(LibreOffice forked from OO back then.)
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.
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.
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.
It’s recent stuff. He likes a Fedora machine, but the only issue is the inability to replicate his Word docs. At this point I don’t know if Libre tools will be easy enough for him. There us nothing really intelligent happening in these files. He is not capable of handling any kind of real world complexity. So everything is going to be whatever was made super simple and easy in m$ Word.
I went through my old CD collection, but don’t have disks beyond Office for XP.
That sucks.
Why do you spell it as “m$ office”?
Greedy fucks.
VMWare and archive dot org are your friend
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.
Just use OnlyOffice or this: https://flathub.org/apps/io.gitlab.o20.word
All of the office suites seem to use either Python 3 docx or iconvert under the surface. These tools do not support whatever default encoding m$ is using. It is clearly a font encoding issue, but I won’t know what that font is until my back is in good enough shape to setup a desktop at my bedside workstation.
Why not just use a VM?
I thought we stopped doing the “m$” thing around 2010.
Word barely supports old Word files. Very few tools can reproduce .doc files other than Office itself, and even Office versions aren’t all compatible.
My approach would be to install some kind of Office on a machine and just script the hell out of opening files and saving them as docx or whatever open format Word supports these days. Word exposes a COM interface you can script against, so most programming languages and JScript or VBS can automate this process.
If you can figure out how to scan files in a loop, this snippet may get you started:
Set word = CreateObject("Word.Application") word.Visible = True word.Documents.Open("C:\Documents and Settings\User\Hello.doc") Set doc = word.ActiveDocument doc.SaveAs "C:\Documents and Settings\Gebruiker\Mijn documenten\export.docx", 16 word.Quit()
To do this with reasonable speed, keep one instance of word around and close the documents rather than quitting Word every time you iterate through the list.
I started using M$ around 2010 personally
I’ve had some success with fmstrat/winapps (if I remember the repo correctly) but that might be overkill for your use case
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.
I bought a cheap win11+office 2021 combo on the net and use a VM. Its not the easiest way but it works…
😔
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.
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.
Yeah, they are all legitimate files and names. He’s even published a book on Amazon using them, so these are transferable somehow. I’m pretty sure he has just uses all default settings in Word.
I would have already set up the computer with W10 and sorted it out, but I had to do some cooking and pasted my limited physical abilities for the day. I should be able to script my way through converting the files in the power shell.
I figured no one was likely using current m$ Word in Linux, but ya never know what might be out there so why not ask. I own the Word that came with W10, so why should the state of kernel support be relevant to my use case. I mean last time I checked I am a citizen and not a feudal serf… As crazy as all these bots here want to make that seem.
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).
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.)