https://jasomill.at/proposal.docx

To convert it, I first opened and re-saved using Word 98[1] running on a QEMU-emulated Power Mac, at which point it opened in modern Word for Mac (viz., version 16.82).

The pictures were missing, however, with Word claiming "There is not enough memory or disk space to display or print the picture." (given 64 GB RAM with 30+ GB free at the time, I assume the actual problem is that Word no longer supports the PICT image format).

To restore the images, I used Acrobat (5.0.10) print-to-PDF in Word 98 to create a PDF, then extracted the three images to separate PDFs using (modern) Adobe Illustrator, preserving the original fonts, vector artwork, size, and exact bounding box of each image.

At this point, restoring the images was a simple matter of deleting the original images and dragging and dropping the PDF replacements from the Finder.

For comparison, here's the PDF created by Acrobat from Word 98 on the Power Mac

https://jasomill.at/proposal-Word98.pdf

and here's a PDF created by modern Word running on macOS Sonoma

https://jasomill.at/proposal-Word16.82.pdf

[1] https://archive.org/details/ms-word98-special-edition

[1] http://fileformats.archiveteam.org/wiki/PICT

If you want to give it a go, here's the raw PICT data from the RTF:

https://jasomill.at/Picture1.PICT

(extracted from RTF tag \pict\macpict\picw513\pich459)

https://jasomill.at/Picture2.PICT

(\pict\macpict\picw410\pich327)

https://jasomill.at/Picture3.PICT

(\pict\macpict\picw420\pich291)

and here are MacBinary-encoded[1] PICT files containing the same data:

https://jasomill.at/Picture1.bin

https://jasomill.at/Picture2.bin

https://jasomill.at/Picture3.bin

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

Encoding is required because the PICT file format stores image data in the file's resource fork[2].

[2] https://en.wikipedia.org/wiki/Resource_fork

https://jasomill.at/Clippy.png

Or you would if you had the original fonts. Word 4.0 was released for System 6 with support as far back as System 3.2. Fonts at that time had separate screen and printer files for the different output resolutions. If you're missing the printer font it'll print a scaled (using nearest-neighbor) rendering of the screen font. If you're missing the screen font it'll substitute the system font. (Geneva by default, as seen in the screenshot.)

In this case, only the well-known Palatino and Courier typefaces are needed. But LibreOffice substituted Times New Roman even though I have Palatino Linotype installed.

In the absence of a hard-coded special case, font matching based on common prefixes could easily match something inappropriate, such as — taking the first example I see on my machine — mapping "Lucida" to "LucidaConsole", when almost any proportional sans-serif font would arguably be a better match for the document author's design intent.

Then again, even exact name matches provide no guarantees. For example, Apple has shipped two fonts (internally) named NewYork: the TrueType conversion of Susan Kare's 1983 bitmap design for the original Macintosh, and an unrelated design released in 2019.

Didn't they also name one of their new fonts "SanFrancisco" much to the ire of Susan Kare fans.

Also, as far as I know, of the original Mac fonts, Apple only ever shipped TrueType versions of Chicago, Geneva, Monaco, and New York. And I'm not aware of any OS with native support for both OpenType and classic Mac bitmap fonts (conversions are always possible, of course).

      proposal: Microsoft Word for Macintosh 4.0   

I have cursed so many times in the past when I sat in front of a work computer that ran Windows and didn’t have this tool easily available. (Later on, WSL made life easier, but now I’m luckily nearly Windows-free.)

But I also love using BasiliskII and InfiniteMac emulators!

Figuring out what to ask qemu to do (without libvirt!) is half the battle.

(Thanks though, I have something to play with tonight)

  #!/bin/bash
  export PATH=
  here="$(/opt/ld/bin/realpath -s "$(/usr/bin/dirname "$0")")"
  workdir="$here"
  name="$(/usr/bin/basename "$workdir")"
  qemu='/opt/qemu/bin/qemu-system-ppc'
  
  cd "$workdir" \
      && exec "$qemu" \
          -display cocoa \
          -L pc-bios -boot c -no-reboot \
          -M mac99,via=pmu -m 768 \
          -rtc base=localtime \
          -g 1920x1080x32 \
          -prom-env 'boot-args=-v' \
          -prom-env 'auto-boot?=true' \
          -prom-env 'vga-ndrv?=true' \
          -nodefaults \
          -device pci-ohci,id=usb0 \
          -device usb-kbd,id=keyboard0 \
          -device usb-mouse,id=mouse0 \
          -device VGA,edid=on,vgamem_mb=32,id=vga0 \
          -nic tap,id=nic0,ifname=tap9,script=no,downscript=no,model=sungem,mac=00:50:56:16:65:09 \
          -drive file="$here/disk/Classic.img",format=raw,media=disk,id=hd0 \
          -drive file="$here/../../scratch/$name/Scratch.img",format=raw,media=disk,cache=unsafe,id=hd1 \
          -drive media=cdrom,id=cd0 \
          "$@"

I'm currently running a version of QEMU recently built from Git, though I haven't changed this script in years.

For networking, I'm currently using the notarized tap kext bundled with Tunnelblick[1].

Finally, I'm currently using an Intel Mac, so YMMV with Apple Silicon or Linux, though I have no particular reason to believe any command-line changes would be necessary, other than the obvious -display change to something other than cocoa for Linux.

[1] https://www.tunnelblick.net/downloads.html

Yes, the OP also mentions that LibreOffice opens it.

...but they also point out with LibreOffice that "Although there's something weird about the margins and there are other formatting problems." - which is also apparent in your screenshot? Certainly that level support for such an old proprietary format is pretty good, but I'm not sure I'd class it as "really excellent" with those issues.

7zip has similar support for a wide range of compressed file formats, exes, data files, cabinets, and so on. Another good tool to save time and keep you on your modern operating system.

7zfm.exe (7-Zip File Manager) anyway, which I agree is very useful. I've wanted it in Linux multiple times to avoid creating loopback devices but seem to always find it's Windows only.

It works okay with most old school (pre-XML) ones, since the document text is in the file in plain ASCII amidst all the binary formatting stuff. For the new XML formats, less by itself doesn’t do anything useful, but unzip them and you can read the XML containing the document text.

I know it's being pedantic, but it absolutely can, libreoffice will happily run over a ssh -X tunnelled X display.

Also, less starts a lot faster than LibreOffice does

If I was going to use the document in anger, I would open it with something proper, of course

The graphics did not open however, due to a missing graphics filter for the Microsoft Word Picture format. Seem it's been deprecated for a while now but Word 2003 should be able to open it? Which is old, but not that old not to run on modern systems.

I think the moral of the story is that the Windows Office team seems to spend a bit more time on backwards compatibility.

[1] https://www.infoworld.com/article/2618153/how-microsoft-was-...

https://drive.google.com/file/d/1lnaSr22l3kQbmFHnxg3Ggd3-46v...

Full version string:

Microsoft® Word for Microsoft 365 MSO (Version 2311 Build 16.0.17029.20140) 64-bit

Not sure just curious not even sure where to look that one up honestly.

http://fileformats.archiveteam.org/wiki/PICT

Imagemagick supports it. What's more important, QuickDraw source is available, so not only we can have “some” conversion, we can also reason about its correctness (to some extent — according to comments, it's from 1982-1985).

https://computerhistory.org/blog/macpaint-and-quickdraw-sour...

Extracting raw embedded PICT files from the document and working with them would be the best way to get proper charts. To see what appeared on paper, we can direct emulated system output to an emulated printer, or capture the PostScript commands and rasterize them at the resolution that was used by device available to the author. It is well known that Word for Windows stored last used printer settings in the document, so it could be the same for files produced by Mac version.

(M-hm, it says “Laserwriter” at 0x10097. Maybe they all do.)

Because Microsoft made the most popular document editor for both Windows and Mac, they had to deal with interoperability of two versions of their own software. Supporting WMF/EMF on Mac meant they had to drag GDI implementation along with Office (luckily, the reference could be grabbed from their colleagues). Supporting PICT on Windows meant they had to re-implement QuickDraw primitives.

https://en.wikipedia.org/wiki/History_of_Microsoft_Word

https://news.microsoft.com/1999/04/26/office-98-built-for-th...

It is totally possible that Office applications used built-in PICT parser even on Mac to make things simple, and not rely on 15 years of compatibility layers in the system.

Unless, of course, you've found some portable version on the net that packs ThinApp and an assortment of old system libraries under the hood.

Or Acrobat may be available for that old of an OS and would have a virtual print driver to go directly to PDF.

Or, if you prefer to do more tweaking yourself, dive into the Ghostscript deep end :)

https://www.ghostscript.com

https://help.libreoffice.org/latest/en-US/text/shared/guide/...

https://opensource.com/article/21/3/libreoffice-command-line

If they are worried about vulnerabilities in the old parsing code, move it to an external process, run it under isolation in a sandbox to spit out a newer readable version on the fly, but don't eliminate this capability from the software.

EDIT: zokier pointed out to me that the desktop version of Word opens the file fine, it is only the web version that doesn't. So, consider this post void.

EDIT 2: Well it opens the document, but is not able to display or print the embedded graphics, it seems.

There was (contrary to popular belief) not a deliberate strategy to limit interoperability. It was simply the reality of the approaches utilized that made them tightly coupled to the MS Word codebase and less standardizable than would have otherwise been ideal.

Source: one of the guys who worked on it at MS.

They were effectively working at embedded scale, trying to capture state within tremendously limiting constraints.

This is a case of interpreting past decisions based on current criteria, when those same conditions would have prevented modern methods from being implemented.

I would love to see some modern devs try to write software for a 68000 system with only 512K of memory

I don't trust MS to maintain software, even though as far as that goes, they're better than a lot of companies that have been writing software for decades. "time marches on" is silly when we have millions of times the compute, storage, and transit speeds available to us. I also don't see why people see the need to shill for multi-billion dollar companies.

What microsoft should have done is trademark a new name for their word processor the second they made the decision to not open word .doc from older versions. That way there's no confusion.

[0] having a hard time remembering the name/company of the software i purchased for in-house streaming over a decade ago. Plex is still a hassle to use for in-house streaming compared to the "service" or whatever they're selling. Unfortunately Synology seems to have grown weary of releasing a version of their client for every newfangled device that comes to market, so i'm stuck with plex on my TV; that is, unless i want to use a stick/set-top/computer attached to it.

Then you should champion removal of any "old" software they have that is under maintenance-only status. You wouldn't want security vulnerabilities to go unfixed, would you?

> What microsoft should have done is trademark a new name for their word processor the second they made the decision to not open word .doc from older versions. That way there's no confusion.

That makes zero sense. Word is still Word. It performs the same tasks (and more) as Word 1.0 did.

And Word today still reads/writes .doc, just not versions that are that old.

But this really goes more into the facet of Office files that allowed embedding pretty much anything into them, and relying on this "filter" system (I guess OLE) to handle embedded objects. So while the DOC file itself is getting parsed and rendered pretty much perfectly, the embedded objects are another story.

In the same sense I'd say browser might open some HTML page "fine" even if it doesn't know how to handle some image format that is used on the page; it'd still handles the HTML correctly.

You can recover text but the result is horrible. No graphics and all formatting lost.

It is common to have backups with retention of 10 years, some may have 20 years for legal reasons… but the majority of people don't understand the difference between "readable" and "usable".

Of course, it depends on the data… And there are companies backing up whole virtual machines with infinite retention, believing to be able to run them: it is hard enough to restore a vSphere 5.x machine on a brand new vSphere 8, I really don't understand this waste of space.

At this price it's not worth sorting, when one single devops costs 100 USD+ per hour, not including the opportunity cost of not working on something more productive (and less boring for the developer).

Then X years after the company is acquired, or sufficient time has lapsed, you can delete / drop the data without sorting.

Regarding virtual machines, if it's VMDK for example, you can read the raw disks without booting it, and again, it's not worth taking a risk to lose data to potentially save 10 USD per month, which is similar to one developer taking one beer extra at a team event.

Yes, but that's the difference between "readable" and "usable". Many companies don't realize the technical difficulties to be able to run the VMs. They just expect that it will work, if needed.

So the waste of space is more of an administrative character than a waste of disk space.

I had a lot of old Word 4.0 for Mac files at one point, and remember some point in the late 1990's or early 2000's opening them all up in a version of Word for Windows, and then re-saving them in a more up-to-date Word format. I believe there was an official converter tool Microsoft provided as a free add-on or an optional install component -- it wouldn't open the "ancient" Word formats otherwise.

There's definitely going to be a chain here of 1 or 2 intermediate versions of Word that should be able to open the document perfectly and get it into a modern Word format, I should think -- and I'm curious what the exact versions are. (Although as other people point out, if you don't need to edit it, then exporting it as PostScript in Word 4.0 and converting it to PDF works fine too.)

Current Word for Mac blocks opening the file under discussion, with no obvious workarounds.

Current Word for Windows will only open the file with non-default security settings, and won't render the images at all.

Per Microsoft, PICT image support was removed from all versions of Word for Windows in August 2019[1].

The current version of Word for Mac fails to render the images with a misleading error message ("There is not enough memory or disk space to display or print the picture.").

As for fonts, they should render fine assuming you have matching fonts, where "matching" is defined by some application- or OS-specific algorithm, e.g., a post above indicates LibreOffice (on Linux?) substituting Times New Roman for Palatino when Palatino Linotype was avilable, whereas current Word on Windows 11 has no problem rendering Palatino as Palatino, presumably using the copy of Palatino Linotype installed with the OS.

Finally, if matching spacing (character, word, and line), line breaks, and page breaks is important, you should definitely open the document using as close a version of Word as possible with the exact fonts used when creating the document installed.

Oh, and hope the original author didn't rely on printer fonts without matching scalable screen fonts available, or else you're probably SOL unless your goal is printing to a sufficiently similar printer.

[1] https://support.microsoft.com/en-gb/office/support-for-pict-...

I use markdown, plaintext and png for all the documents I need to store long term.

Even if these formats disappear, I could trivially reimplement my own parser.

There is also Just Solve The File Format Problem wiki (which I have added stuff to), although it uses HTML, and does not include full specifications for all file formats (but it does for some of them), and in some cases are links to external files, but it is helpful to find information about file formats anyways.

implementing a parser that tricks people into believing it parses markdown because it acts like a markdown parser in simple cases is what is trivial

it's likely that your markdown data will indeed be recoverable, but if you're generating it yourself, html is probably safer

Although I find myself wondering what this "parsing Markdown" business is even about. It's perfectly legible as plain text, that was the main design principle behind it. If the goal is to have your data accessible in future, if you can read it now, and you don't go blind, you'll be able to read it later as well.

And it has the merit to be human-readable in plaintext!

    perhaps you mean
      indented fixed-width blocks
        you can use for ascii art
          or typewriter-style tables?