[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: (Recipient list suppressed)
Subject: UPDATE (2001-11-15) Windows 2000/XP Zapf Dingbats Display Problem
From: Dov Isaacs <isaacs@xxxxxxxxx>
Date: Thu, 15 Nov 2001 11:10:53 -0800
Sender: owner-framers@xxxxxxxxx
This is going out to a number of lists. My apologies if you receive it multiple times as a result of this form of distribution. If you are solely a Macintosh user and/or don't need to deal with problems associated with PostScript and PDF workflows originating from Windows-based systems, you can safely delete this message now ... - Dov There is a known problem under Windows 2000 and Windows XP (all flavours) in which characters chosen from the ITC Zapf Dingbats font, one of the “base 35” PostScript Type 1 fonts, display in the TrueType WingDings font on the screen, but print OK to PostScript printers and generate correct PDF files. A similar problem occurs with Carta and any other Type 1 symbol fonts (other than the actual font “Symbol”) that might be resident in the PostScript printing device (as defined in the printer's PPD file) and also installed on an end-user's computer system. (Obviously, if a font is printer-resident but a copy of that font is not installed at all on an end-user's computer system, characters in that font will not display correctly!) This problem affects many but not all, applications. These applications in which the problem occurs appears to include many applications which use Windows 2000/XP's font rendering services as opposed to applications which internally control their own fonts. The applications affected include FrameMaker, Microsoft Office, and Lotus Smartsuite, amongst others. No other Adobe applications are affected being that they control and manage their own font services. Adobe is aware of the problem. The cause of the problem is a mismatch between how the OS font rendering system and the PostScript driver “see” what are ostensibly the same fonts. Unfortunately, a short term driver/OS fix are not forthcoming. A VIABLE WORKAROUND The following is the best known workaround that effectively solves the problem in a manner that would be compatible with any future fixes issued by Adobe and/or Microsoft: (1) Logon as “Administrator” or with a user ID that has administrator privileges. (2) Make sure no printing is occurring or spooled to any PostScript printer and close all regular applications. (3) Go to directory “C:\WINNT\system32\spool\drivers\w32x86\3”. (4) For each .PPD file in that directory: (a) Copy the PPD file to a backup location in case you need to subsequently retrieve a pre-modified version. (b) Open the PPD with an ASCII text editor, such as “NotePad”. (c) Find the line in the PPD file that begins “*Font ZapfDingbats:” (d) Change the initial “*Font” in that line to “*% Font” (e) Save the PPD file and exit the text editor. (5) Delete all the .BPD files in directory “C:\WINNT\system32\spool\drivers\w32x86\3”. The PostScript driver will then recreate the .BPD files as necessary from the edited PPD files. Note that with this solution, you do NOT need to delete and recreate the printer instances. This hackery is only a Windows 2000 and XP solution. The problems mentioned above do not occur with Windows'9x or Me. FURTHERMORE I PERSONALLY recommend that at stage (4)(c-d) above, you change ALL the lines that begin with “*Font” to “* Font” with the exception of the one line that begins with “*Font Courier:”, Why? Because this effectively tells the driver and operating system to always use the fonts resident on your computer system as opposed to those which may be ROM or disk-based in your printing device. And why is that important? Two reasons: (1) We continually hear about problems in which users compose documents with fonts that appear in the list of available fonts but surprisingly enough, fail to be recognized or embedded when creating PDF files. This problem is caused by the fact that the operating system in conjunction with the driver allows on-host access for formatting purposes to fonts that are printer-resident, even if they cannot be really accessed or displayed on your computer because they are not actually installed on your computer! When you “switch” to the Acrobat Distiller printer instance, the fonts seem to “disappear.” Well, they weren't really there to start with. This “fix” eliminates the “phantom phonts” and the problems associated with same. (2) Over time, changes have occurred in fonts, especially in the size and content of their character sets. The best example of this is the addition of the Euro symbol into many Type 1 fonts that can also be “printer resident.” In some cases, such as the Arial and Times New Roman families, the fonts being shipped with Windows 2000 / XP each have over 1000 more character definitions (from multiple alphabets and symbols) than the equivalent printer-resident fonts in PostScript 3 implementations and some PostScript Level 2 emulations. This fix forces use of the host-based font when printing and thus virtually eliminates the possibility of missing characters on output due to font mismatches. Note that it is critical that you DON'T change the line for Courier. The driver appears to “die” if it doesn't have at least one printer-resident font to chew on and Courier is the font that will likely cause you least grief with any of the two issues above. - Dov ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **