Interchanging Mac and WinTel files
October 1, 2005 9:13 AM Subscribe
What files are truly interchangeable between Mac and WinTel?
I know that PDF files are supposed to be readable on either platform. I suspect that ASCII text files are as well. Wouldn't RTF files be inter-legible given the fact that RTF is a tagged language based on text?
I know that PDF files are supposed to be readable on either platform. I suspect that ASCII text files are as well. Wouldn't RTF files be inter-legible given the fact that RTF is a tagged language based on text?
It depends what you mean by truly. At a technical level, even ASCII text files are different between the Mac and Windows -- they use different codes to mark the end of a line, for one.
However, Mac OS X at least is very relaxed about such things, so opening PC ASCII on a Mac is 99% foolproof. The system will know their provenance, but the user won't. So for all intents, most files are truly interchangeable. Strictly speaking, none of them are.
posted by bonaldi at 9:29 AM on October 1, 2005
However, Mac OS X at least is very relaxed about such things, so opening PC ASCII on a Mac is 99% foolproof. The system will know their provenance, but the user won't. So for all intents, most files are truly interchangeable. Strictly speaking, none of them are.
posted by bonaldi at 9:29 AM on October 1, 2005
Fonts are largely interchangeable too. OS X and Windows both understand TrueType.
Occasionally I run into problems on my PowerBook with DRM'ed Windows Media content. The player that MS provides is v9 and only supports the older standard. Some newer WMV codecs also fail to work.
But other than that... very few problems.
posted by sbutler at 9:31 AM on October 1, 2005
Occasionally I run into problems on my PowerBook with DRM'ed Windows Media content. The player that MS provides is v9 and only supports the older standard. Some newer WMV codecs also fail to work.
But other than that... very few problems.
posted by sbutler at 9:31 AM on October 1, 2005
I've found every Word file created on a PC using Word 2003 at least will display and print fine in Word 2004 on the Mac.
Powerpoint is another story altogether. Even simple text boxes with standard TrueType fonts [like Verdana] will rag differently on the Mac than the PC. I was working on a document on my XP machine and then switched over to the powerbook for more screen clarity and size. I would fixed the messed up text and it looked OK when I opened it on the PC again.
Since 100% of the people that will receive the presentation will be using a PC, it has to look best on the PC.
Then again, Powerpoint has the same issues even between PCs. Its WYSIWG hasn't improved since Office 97.
Excel files on the PC and Mac open seamlessly and preserve the formulas and values. Of course CSV and TXT files are OK. The only thing I noticed is you can have colored tabs on the PC but not on the Mac version. Editing the file on the Mac and saving the changes will preserve the colored tabs when viewed on the PC. I don't receive or get a lot of files with macros so I have no idea how broken that could be.
PDFs made with Adobe Acrobat seem 100% similar but PDFs made with Tiger's "save as PDF..." sometimes don't look exactly the same.
posted by birdherder at 9:45 AM on October 1, 2005
Powerpoint is another story altogether. Even simple text boxes with standard TrueType fonts [like Verdana] will rag differently on the Mac than the PC. I was working on a document on my XP machine and then switched over to the powerbook for more screen clarity and size. I would fixed the messed up text and it looked OK when I opened it on the PC again.
Since 100% of the people that will receive the presentation will be using a PC, it has to look best on the PC.
Then again, Powerpoint has the same issues even between PCs. Its WYSIWG hasn't improved since Office 97.
Excel files on the PC and Mac open seamlessly and preserve the formulas and values. Of course CSV and TXT files are OK. The only thing I noticed is you can have colored tabs on the PC but not on the Mac version. Editing the file on the Mac and saving the changes will preserve the colored tabs when viewed on the PC. I don't receive or get a lot of files with macros so I have no idea how broken that could be.
PDFs made with Adobe Acrobat seem 100% similar but PDFs made with Tiger's "save as PDF..." sometimes don't look exactly the same.
posted by birdherder at 9:45 AM on October 1, 2005
This is actualy a rather strange question. Other then a few types of files (like fonts, actualy) Operating systems do not interprate files, the application programs do. So the question isn't "can this file be read on a mac/pc" it's "Is there a program that can read these files on both a mac and PC".
The answer for almost every filetype is yes, although I'm not sure about complicated MS-Office docs that use OLE embeding.
However, Mac OS X at least is very relaxed about such things, so opening PC ASCII on a Mac is 99% foolproof. The system will know their provenance, but the user won't. So for all intents, most files are truly interchangeable. Strictly speaking, none of them are.
I have no idea what you mean by 'strictly speaking', but that's just wrong. Pure ASCII text (7-bit ascii) is a uniform standard on all computers, while the extended ascii bit may change. The type of linefeed '\n' or '\r\n' is not really a big deal, and programs that can read it either way exist on windows as well as MacOS.
HTML is complicated because every program interprates HTML diffrently... but if we allow for those diffrences between browsers HTML is perfictly interchangeable, as is PDF, GIF, JPEG, MPEG, PS, TIF, PNG and every standard binary filetype.
posted by delmoi at 9:55 AM on October 1, 2005
The answer for almost every filetype is yes, although I'm not sure about complicated MS-Office docs that use OLE embeding.
However, Mac OS X at least is very relaxed about such things, so opening PC ASCII on a Mac is 99% foolproof. The system will know their provenance, but the user won't. So for all intents, most files are truly interchangeable. Strictly speaking, none of them are.
I have no idea what you mean by 'strictly speaking', but that's just wrong. Pure ASCII text (7-bit ascii) is a uniform standard on all computers, while the extended ascii bit may change. The type of linefeed '\n' or '\r\n' is not really a big deal, and programs that can read it either way exist on windows as well as MacOS.
HTML is complicated because every program interprates HTML diffrently... but if we allow for those diffrences between browsers HTML is perfictly interchangeable, as is PDF, GIF, JPEG, MPEG, PS, TIF, PNG and every standard binary filetype.
posted by delmoi at 9:55 AM on October 1, 2005
Here's a longer answer because I'm not sure how much you understand about filesystems and data.
There are two things that every filesystem stores: the file data and what's called its metadata. The file data is what you would expect: text for a text document, the image for a JPEG, the HTML for a web page, etc. The metadata is everything else: filename, size, permissions, etc.
For example, FAT and ext3 (the Linux filesystem) are pretty simple. Outside of file data they don't store much metadata. FAT keeps the name, size, some timestamps, and some attributes (read only, archive, hidden, and system) while ext3 stores the name, size, some timestamps, owner, group, and permissions. So if I copy a file from FAT to ext3 I'll only keep the metadata that is common between them; the other values get initialized to defaults. Similarly if I copy from ext3 to FAT.
Other filesystems allow applications to store much, much more information in the metadata: HFS+, NTFS, ReiserFS, BeFS, and so on. HFS+ (the MacOS filesystem) is notorious for this. Files in Classic didn't have extensions because there were type and creator codes stored in the metadata. So if you copied a file from HFS+ to FAT then you lost the type and creator and often couldn't just double click on it. But if you knew which application it was created with then you could force it open. There were all sorts of work arounds to fix type/creator codes on files downloaded from the internet.
But it's not just type/creator codes. All of the above listed systems can store arbitrary metadata. It's a useful feature but it often means the metadata is just as important as the actual data. You wouldn't want to lose any of it.
Modern filesystems, however, are much better at transparently handling metadata. The HFS+ included with OS 10.4 dynamically creates a hidden file to hold metadata on systems that don't support it. And OS X has largely moved away from relying on its flexible metadata capabilities (largely relying on a concept called bundles now). I think ReiserFS has a system too but I am not as familiar with it.
There's also the issue of endianess. Take the four byte hex number 0x12345678, how do you think the bytes are stored in memory? If you say 0x12, 0x34, 0x56, 0x78 then you're thinking in big endian terms, which is how the PowerPC chip does things. But if you say 0x78, 0x56, 0x34, 0x12 then you're thinking in little endian terms, which is how the x86 chip does things.
So if you're a programmer and you're thinking of cross platform issues then you can't just dump an integer into a file. You'll get a different number depending on which platform you read it back on. This isn't really a problem though, as long as you standardize on one format or the other. You hear people talking about translating into network byte order, which is just a standard that says everything is big endian.
Maybe you find this interesting, maybe not, but the point is that file data can be moved from any system to any other. It is, after all, just a sequence of bytes. The real question is "do I have an application to open it on the other system?" For OS X, the answer is largely "yes". Well documented formats like JPEG, MPEG, RTF, HTML, etc all have applications on OS X. For the proprietary ones you're stuck with that vendor. Fortunately, MS has a version of Office for OS X and (like I said) a crippled version of Media Player.
posted by sbutler at 10:10 AM on October 1, 2005 [1 favorite]
There are two things that every filesystem stores: the file data and what's called its metadata. The file data is what you would expect: text for a text document, the image for a JPEG, the HTML for a web page, etc. The metadata is everything else: filename, size, permissions, etc.
For example, FAT and ext3 (the Linux filesystem) are pretty simple. Outside of file data they don't store much metadata. FAT keeps the name, size, some timestamps, and some attributes (read only, archive, hidden, and system) while ext3 stores the name, size, some timestamps, owner, group, and permissions. So if I copy a file from FAT to ext3 I'll only keep the metadata that is common between them; the other values get initialized to defaults. Similarly if I copy from ext3 to FAT.
Other filesystems allow applications to store much, much more information in the metadata: HFS+, NTFS, ReiserFS, BeFS, and so on. HFS+ (the MacOS filesystem) is notorious for this. Files in Classic didn't have extensions because there were type and creator codes stored in the metadata. So if you copied a file from HFS+ to FAT then you lost the type and creator and often couldn't just double click on it. But if you knew which application it was created with then you could force it open. There were all sorts of work arounds to fix type/creator codes on files downloaded from the internet.
But it's not just type/creator codes. All of the above listed systems can store arbitrary metadata. It's a useful feature but it often means the metadata is just as important as the actual data. You wouldn't want to lose any of it.
Modern filesystems, however, are much better at transparently handling metadata. The HFS+ included with OS 10.4 dynamically creates a hidden file to hold metadata on systems that don't support it. And OS X has largely moved away from relying on its flexible metadata capabilities (largely relying on a concept called bundles now). I think ReiserFS has a system too but I am not as familiar with it.
There's also the issue of endianess. Take the four byte hex number 0x12345678, how do you think the bytes are stored in memory? If you say 0x12, 0x34, 0x56, 0x78 then you're thinking in big endian terms, which is how the PowerPC chip does things. But if you say 0x78, 0x56, 0x34, 0x12 then you're thinking in little endian terms, which is how the x86 chip does things.
So if you're a programmer and you're thinking of cross platform issues then you can't just dump an integer into a file. You'll get a different number depending on which platform you read it back on. This isn't really a problem though, as long as you standardize on one format or the other. You hear people talking about translating into network byte order, which is just a standard that says everything is big endian.
Maybe you find this interesting, maybe not, but the point is that file data can be moved from any system to any other. It is, after all, just a sequence of bytes. The real question is "do I have an application to open it on the other system?" For OS X, the answer is largely "yes". Well documented formats like JPEG, MPEG, RTF, HTML, etc all have applications on OS X. For the proprietary ones you're stuck with that vendor. Fortunately, MS has a version of Office for OS X and (like I said) a crippled version of Media Player.
posted by sbutler at 10:10 AM on October 1, 2005 [1 favorite]
I may be misinterpreting Mega's concern here, but I think the ? is about having to re-save files in a different flavor of PDF, PSD, XLS, etc. or not. The answer is no - new versions of software will take care of writing out fat binary versions that should address all the previously mentioned issues in this post.
posted by glyphlet at 11:29 AM on October 1, 2005
posted by glyphlet at 11:29 AM on October 1, 2005
Response by poster: Perhaps things are looser than I imagined. My primary concern is whether, say, a Word file created on a WinTel machine could be opened, edited, and saved on a Mac, using the Mac version of Word, and then reopened on a WinTel machine. Wackybrit's answer tells me it can. I had thought not, and thus was looking at other formats that could bridge between them.
posted by megatherium at 11:46 AM on October 1, 2005
posted by megatherium at 11:46 AM on October 1, 2005
The Powerpoint thing is a problem. The fact that it's Microsoft's fault is immaterial - it's the one thing that's keeping me from using a Mac as my work machine.
posted by lbergstr at 11:46 AM on October 1, 2005
posted by lbergstr at 11:46 AM on October 1, 2005
Re big endian vs little endian, the conversion is relatively simple, and many file formats have a header that says what format the data is stored in. Most people writing file format code generally know about the issue, as does anyone that's worked with sockets before (network-byte order = big endian).
posted by devilsbrigade at 12:31 PM on October 1, 2005
posted by devilsbrigade at 12:31 PM on October 1, 2005
Meatherium, I'll tell you that I've worked on books via MS word, totatlly cross platform and cared what OS anyone else was on. The only headaches? People who didn't know how word functions (revisions, indexing, that sort of thing.)
So, in a word, *Yes*. (sorry for that pun)
posted by filmgeek at 3:22 PM on October 1, 2005
So, in a word, *Yes*. (sorry for that pun)
posted by filmgeek at 3:22 PM on October 1, 2005
delmoi, by "strictly speaking" I mean the sorts of issues that sbutler brings up. Line feeds - while relatively minor - are different by default on the three major platforms and software must account for it.
Under OS X, for instance, you can make a mac-encoded file in TextWrangler, the open it in vi and it will show up as one big long line of text with ^M where returns should be. Nice that, files on the same machine not being interchangable.
posted by bonaldi at 6:40 PM on October 1, 2005
Under OS X, for instance, you can make a mac-encoded file in TextWrangler, the open it in vi and it will show up as one big long line of text with ^M where returns should be. Nice that, files on the same machine not being interchangable.
posted by bonaldi at 6:40 PM on October 1, 2005
Valid, semantic HTML cannot be said to be "interpreted differently" by different systems of any kind. The typographic display may differ slightly, but valid, semantic HTML is unambiguous in the majority of cases. Some edge counterexamples, as with selection of
posted by joeclark at 1:05 PM on October 2, 2005
cite/em/i, certainly exist, but those ambiguities occur at the author level rather than the display level.posted by joeclark at 1:05 PM on October 2, 2005
This thread is closed to new comments.
Obviously, things like fonts may vary unless you embed them (in formats which support that).
Heck, pretty much everything is interchangeable as long as there's an app that can read it on both sides. So the only things you couldn't move would be highly proprietary formats, IME. Possibly some DRM-ridden formats too.
posted by wackybrit at 9:17 AM on October 1, 2005