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
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.