Mac-PC Conversions

No. 1, Volume 1
July 1997

Gabe Bokor can be reached at gbokor@accurapid.com

	From the Editor/Webmaster What Is the Translation Journal by Gabe Bokor
	Translator Profiles Saga of a Scientific Translator by Cathy Flick, Ph.D.
	Feature Article Facets of Software Localization by Per N. Dohler
	Science & Technology A Translator's Guide to Organic Chemical Nomenclature by Chester E. Claff, Jr., Ph.D.
	Caught in the Web Web Surfing for Fun and Profit by Cathy Flick, Ph.D.
	Translators’ On-Line Resources by Gabe Bokor
	Translators’ Tools Electronic File Transfer and Conversion by Gabe Bokor
	Translators’ Events
	Letters to the Editor
	Call for Papers

Electronic File Transfer & Conversion

by Gabe Bokor

This article is an update of a file originally posted in FLEFO (CompuServe) Library 11.

Introduction
PC-Mac file transfer
Mac-PC file transfer
File transfer via on-line services and the Internet
Word processing format conversion

Introduction
Almost all professional translators currently work with either IBM PC compatible (80%) or Macintosh (20%) computers. Since our customers are increasingly requesting translations in electronic form, the need arises to transfer word-processed files from one platform to another and to convert them between the different word-processor formats. New software and hardware have made file transfer and conversion simpler and easier in the past few years, and technological progress in the near future is expected to continue in the same direction.
   In order to successfully transfer and convert electronic files between the Macintosh and DOS/Windows, some understanding of the difference between the Mac and PC file structures is necessary.
   PC files have a simple (“binary”) structure and can be stored on either PCs or Macs without losing any of their characteristics. If a PC document is transferred to a Mac, e.g. via modem, diskette, or network, the Mac will recognize its filename, creation date, and size without difficulty. In general, it will not recognize the program in which the document was created, but will show a generic icon or the icon of the application used for transferring the file. For the Mac, all PC documents, and even applications, look like a “text only” document and can usually be opened in a word processor, although what appears on the screen may be gibberish.
   Mac files have a more complex, “double-fork” or “Mac-binary”, structure. Each Mac file (except “text only” files) has a “data fork” and a “resource fork.” Most of the bytes in word processed or other documents can be found in the “data fork” of the file. The “resource fork” contains special instructions for the creator application or the computer’s operating system. Documents (but not applications) may have a zero-length resource fork.
   Mac files have two special four-letter codes in a special location of their data forks. One identifies the file type and the other the creating application. These identifiers establish a link between the document and the application, which allows the resources in the corresponding application (if installed) to show the file with the icon corresponding to that specific file type. They also cause the corresponding application to load when you double click on the icon of the document.
   Applications have relatively large resource forks. Unlike documents, applications written for one platform do not work and cannot be easily converted to work on the other platform.
   PCs cannot store double-fork Mac files. If a Mac file is copied to a PC via a network or a Mac-disk-reading utility, the resource fork is either lost or copied over as an invisible second file. If the file is copied back to the Mac, the resource fork is generally not transferred, in which case the Mac can no longer recognize the file as a Mac document created by a specific application or as an application.

PC-Mac file transfer
PC files can be transferred to the Macintosh via modem, diskette, or network.
   For modem transfer, a transfer protocol such as ZModem, YModem, Kermit or XModem (listed in decreasing order of efficiency) must be used for all but text-only files. It is advisable, although not necessary, that the MacBinary option on the Mac be disabled. Some Mac communication software automatically selects a MacBinary or Binary transfer protocol depending on whether a Mac or a PC (or text) file is to be transferred. CompuServe has a proprietary transfer protocol, CompuServe B+, which is selected by default by almost all CompuServe-specific software.
   Macs equipped with the “superdrive” for reading high-density diskettes and the PC Exchange Control Panel software installed can read PC diskettes directly. The files can be read and processed directly from the PC diskette or copied over to the Mac’s hard disk for faster processing. PCs can read removable Syquest, ZIP, or Bernoulli cartridges formatted for the Mac with special software such as Executor by Ardi or Mac-In-DOS by Pacific Micro. With the appropriate software, such as HDT ToolKit by FWB Software, Macs can read PC-formatted ZIP drives by IOmega; CD-ROMs can usually be read by both Macs and PCs. The same drive can always be used for reading and writing either PC- or Mac-formatted cartridges.
   Mixed PC-Mac network software such as Novell, Timbuktu (by Farallon), or MacLan by (Miramar Systems) can transfer PC files to Macs over a LocalTalk or Ethernet physical network.
   When a PC file is transferred to a Mac via a PC disk read by the PC Exchange Control Panel or via network using special network software, it receives the filetype and creator codes of this software, and it will appear with the icon corresponding to this software.


Mac-PC file transfer
As mentioned before, Mac files normally have a Mac-binary, or double-fork structure that the PC cannot handle directly. Therefore, it is convenient to convert any Mac file prior to transferring it to a PC or a PC-based network (or to another Mac via a PC or an on-line service) so that its structure will resemble the binary structure of the conventional PC file. The Mac software to accomplish this is called MacBinary (formerly BinHex), and it is available as freeware from CompuServe (GO MACFF, filename BINHEX.HEX). It is also one of the utilities of Stuffit by Aladdin Systems, v. 3.07 or higher, and comes bundled with some communication programs. MacBinary adds a header consisting of a few (usually 128) bytes to the file. This header contains the file type and creator information and a filename that can be different from the original Mac filename. It acts as a “wrapper,” hiding the double-fork Mac structure for transfer to and storage in a PC system.
   When the file is transferred via modem, the MacBinary file transfer protocol (ZModem MacBinary, YModem MacBinary, etc.) automatically creates the binary PC header for the transfer. However, when the transfer is done via diskette or a typical network (or when a Binary, rather than a MacBinary, modem transfer protocol is used), the conversion from MacBinary to Binary format must be done prior to the transfer in a separate step.
   If a Mac file is converted to a PC format, e.g. WordPerfect DOS or Microsoft Word Windows, on the Mac and subsequently transferred to a PC, no MacBinary conversion is needed, since the converted file no longer has the double-fork structure of the Mac. Also text-only files (which have no resource fork) need no MacBinary conversion prior to their transfer to the PC, unless they contain non-ASCII characters (accented and other non-English characters, special symbols, etc.).
   If a Mac file (MacBinaried as described above) is transferred back from a PC to a Mac, the reverse Binary-MacBinary conversion is needed to strip away the binary “wrapper” and expose the original double-fork Mac structure. This conversion is automatic when using modem transfer with a MacBinary protocol on the Mac side, or manual when transferring via diskette or network.

Note about Text Files: Plain 7-bit ASCII texts without special (non-English or graphic) characters use the same character set on the Mac and the PC, except for the carriage return character, which is one character on the Mac (ASCII # 13), but two characters on the PC (# 13 and Line Feed ASCII # 10). Therefore a text originally created on a PC may show an extra character after each forced line break on the Mac, while a Mac text may not wrap around properly in some PC editors. The extra character can be added or removed on the Mac by searching (in Microsoft Word) for ^13 and replacing it with ^13 ^10 or vice-versa. 8-bit text files (such as texts with accented or other special characters) use different characters for the Mac, DOS, and Windows above ASCII # 128, and a conversion utility is needed for the proper characters to show in each system.


File transfer via on-line services and the Internet
CompuServe’s Mail system accepts both plain text and binary (word processed, DTP, graphic, etc.) files to be sent from one CompuServe account to another. For binary transfers, a file transfer protocol is needed, and, when transferring a Mac file from a Mac, a MacBinary protocol must be selected or the file must be converted from MacBinary to Binary prior to the transfer. Most CompuServe-specific software automatically selects the CompuServe B+ protocol. CompuServe Mail (OLDMAIL) also supports XModem (don’t use it if you can avoid it), and Kermit (slow but reliable). It does not support ZModem.
   Some other on-line services only accept plain text files as e-mail. Internet e-mail is also basically restricted to 7-bit plain text files (no accents or special characters), but fortunately any file can be converted to (7-bit) text for transfer as e-mail. This conversion is accomplished by most popular Internet mailers (Eudora, Netscape and others) using automatic “client-side” MIME encoding/decoding of 8-bit files sent either in the body of the message or as “attachments.” Recently, CompuServe has also introduced automatic “host-side” MIME encoding/decoding which, contrary to the Internet, is accomplished not by the user’s software, but by the CompuServe host. This new capability allows easy transfer of binary files between CompuServe and other on-line services, such as AOL, or the Internet without need for manual “asciicizing” via UUENCODE, MIME, BinHex, or RTF.
   The markup language of the World-Wide Web, HTML, provides both conversion to plain text and indirect Mac <--> PC conversion, inasmuch as properly encoded web pages can be read correctly on either platform. You should have no difficulty in reading words like Überschuß or animação, or the curly quotation marks and apostrophes in this text regardless of what platform you are using.
   Conversion to plain text, when needed, should always be the last operation prior to file transfer if the file is also subjected to some other operation ( e.g. file conversion and/or compression). Conversion from plain text to Binary or MacBinary should be the first operation after the file is received.
   FTP file transfer of binary files to or from an FTP server on the Internet is also accomplished with user-transparent asciicizing/de-asciicizing. Mac files are usually stored in the BinHex format on the server and converted to MacBinary by the FTP client software.

Word processing format conversion
Since translators usually deal with word-processed texts, we shall only discuss inter-platform conversion of word-processed files.
   Almost any Mac <--> PC conversion is done more efficiently on the Mac because of the Mac’s capability of handling either single-fork or double-fork file structures.
   Recent versions of most major word processing programs (and also some DTP, spreadsheet, and other programs) on both the Mac and the PC can read their counterparts from the other platform. They also come with some built-in conversion utilities. Microsoft Word for the Mac (v. 5.1) can save files in RTF, RFT-DCA, Word for DOS 5.5, Word for Windows 1.0 and 2.0, Word Perfect 5.0 and 5.1, and Microsoft Works. It can also read files of the same formats plus (with the add-on Word for Windows 6.0 Word for DOS 6.0 Converter) also Word 6.0 for Windows or DOS. This latter utility is available in the Microsoft File Finder forum on CompuServe (GO MSFF, filename MSWRD6.SEA), and it should be placed in the Word Commands folder to work properly. Word 6.0 (Mac) has the same file format as its Windows and DOS counterparts—the software adds the missing resource fork when the PC file is opened from Word 6.0 (Mac).
   Microsoft Word 6.0, which can freely interchange files between the Mac and Windows, can also save files in RTF and Word/Mac 4.0-5.1 formats. WordPerfect 5.2 Windows (but not WP 5.1 DOS) is supposed to read and write RTF, although I never succeeded in having my copy of the software do either.
   An excellent standalone file conversion software package is sold by DataViz:

MacLink Plus (for the Mac, latest v. 9.0) and Conversions Plus (for Windows, latest v. 3.53) — DataViz Inc., 55 Corporate Drive, Trumbull, CT 06611, 800-733-0030 or 203-268-0030, fax: 203-268-4345).

  This software includes a large number of PC <--> Mac conversion utilities, as well as conversion into and from RTF and some graphic, spreadsheet, and database formats. It converts word-processed files not only in the major West-European languages, but also in some Eastern European languages and languages using non-Latin alphabets such as Cyrillic, Greek, and Arabic, provided the appropriate fonts are used on both platforms.
   When a PC file is converted to a Mac format on the PC, its resource fork is created on the Mac (after the file is transferred) either by the Mac application itself or by a specific utility. One of these utilities, Stamper, was supplied with the Windows version of Word for Word (now discontinued). It also adds the file type and creator codes corresponding to the Mac application (e.g. WDBN/MSWD for Microsoft Word).
   Other file type/creator changers and resource editors are available in the Mac forums of CompuServe and at different Internet sites. Some of these utilities, however, require that you know the file type/creator codes of the application format into which the file was converted.

Acknowledgments: Thanks to Alicia Gordon, Los Angeles, CA and Nigel Palmer, Paris, France for their valuable contributions to this article. Further additions/corrections are gratefully accepted and will be incorporated in future editions of this article.