|
Computers & Writing Systems
You are here: Rendering > Resources > Font FAQ Moving Documents Across Platforms – FAQ
Question: Why is Word changing my IPA characters when documents are moved between Windows and Macintosh? I’m working with the SIL IPA fonts in Word documents that are being exchanged between Macintosh and Windows systems. Since the native character sets of the two systems are different, Word is translating characters in the IPA font when the documents change platforms with disastrous results. Can you recommend any software or technique that will unmap the SIL IPA characters (or prevent the mapping in the first place) in documents that have changed platforms? Answer: See below. Question: Why do IPA characters get changed between Word 97 (Windows) and Word 98 (Macintosh)? We are having trouble translating a Microsoft Word document from Word 97 into Word 98 for Macintosh. The document is using SIL Encore IPA fonts. The font displays clearly on a Windows machine, but will not translate to the Macintosh format. Answer: See below. Question: I had a question about the SIL IPA fonts. When the font is used in a Mac program and then viewed on a PC (or vice-versa), some of the characters are different. Answer: See below. Question: If a Mac document is read on a Windows machine (or vice versa), do the fonts translate correctly from one to the other? Answer: It's important to understand that some characters are represented differently on Windows and the Mac. The same characters are in the same locations in both the Windows and Mac versions of the fonts. If the document is saved as ASCII text on one type of machine, it should be able to be read correctly on the other type of machine. If it is saved in Word format, however, the characters probably will not show up correctly on the other machine. That’s because the standard character sets for Windows and Mac are different. When a WinWord document is opened in MacWord or vice-versa, Word typically rearranges the characters in the document to match the standard character set for the platform (Mac or Windows) it’s being opened in. It’s possible to keep the characters from being rearranged, however. Depending on the version(s) of Word being used, the strategies are either:
Details follow: PROBLEM: Text formatted with non-MS symbol fonts (such as most SIL fonts including SIL IPA) in Word 97 and later (Windows) documents appears as blank spaces when opened in Word 98 and later (Macintosh), even if the corresponding Macintosh fonts are installed. SOLUTION: The text display can be fixed globally (for all documents) with a simple change to a special text file. Word 98 and later uses a file called “Word Font Substitutes” to determine which fonts are to be considered “symbol” fonts. Every font that is encoded as a “symbol” font on the PC side must be listed in this file to be displayed correctly. In OS 9 and earlier, this file is located in the folder. In OS X, this file is located in the folder.To make the change open up the “Word Font Substitutes” file in a text editor such as BBEdit (be sure that Word is not running). Near the end of the file you will see a section that begin like this: ; CUSTOM SETTINGS FOLLOW [SymbolFonts] Symbol= Wingdings= ... Zapf Dingbats= Add a similar line for each additional “symbol” font you have. For example, add the following line for SILDoulos IPA93: SILDoulos IPA93= Just be sure that you use the actual font name (as it appears in the font name window in Word’s toolbars), not the font suitcase filename. When done, save the file and open your document in Word. PROBLEM:
SOLUTION: The standard Windows and Macintosh character sets are different. The lower 96 characters are the same (access codes 32-127, which are the characters accessed by the standard keys on the keyboard), but there are many differences in the upper 128 characters in the font. Most of the characters are the same, but are assigned to different access codes on the two systems. Some characters on one system do not exist on the other system. Word knows about this, so when a Word document is moved to the other format, Word converts the character codes in the document to the codes expected on the other format. The IPA fonts for Windows and Macintosh have exactly the same character layout, however. The result is that a file created in Windows and saved as “text only” can be transferred to and from the Macintosh without any rearranging of codes. The downside of this is that files saved in other formats may not transfer correctly. For example, Microsoft Word for Windows allows you to save documents in the Word for Macintosh format. While doing so, however, Word reassigns most of the upper 128 character slots and drops some characters out completely. The Mac-to-Windows migration does not do any better. For Word, there is a way to get around this access code jumbling. Using the RTF (Rich Text Format) filter that is available in both WinWord and Word for Mac retains the correct encoding of most of the characters if a few changes are made to the file. The process is as follows:
Moving from WinWord to MacWord
Characters to replace when moving a Word document from Windows to the Mac (See note below) Moving from MacWord to WinWord
Characters to replace when moving a Word document from the Mac to Windows Note If you have used character code 160 in your WinWord document, you will have had to insert it by doing an operation, and the actual search string may look different from this. You should scan your RTF document for anything that looks like “symbol 160” and then look for the enclosing {field<|>.<|>.<|>.<|>} block. This whole string should be replaced by “'a0”. Be aware, however, that character code 160 doesn’t work very well on some Windows printers, most notably the HP Series 4 LaserJet.
Use this Consistent Changes table to convert a Mac RTF file to a Windows RTF file. Requires SIL Consistent Changes. Instructions are inside the file. Note: the opinions expressed in submitted contributions below do not necessarily reflect the opinions of our website. © 2003-2024 SIL International, all rights reserved, unless otherwise noted elsewhere on this page. |