[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

UPDATE (2001-11-15) Windows 2000/XP Zapf Dingbats Display Problem



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