Proposed fix for 688033: pdfwrite puts characters on top of each other

Reviewers,

   Because it was considered customer-critical (and release-desirable),
I tracked down bug 688033. The problem was that the CDevProc procedure
for the font was getting called with values that were already scaled
down by .001, even though the PLRM3 says "all of the numeric values are
expressed in the glyph coordinate system of the font." (5.9.2, p. 350)

   My proposed fix is to pass in the identity matrix, instead of the
font matrix, to the gs_default_glyph_info procedure.

   From the comments attached to previous CVS commits of this file, it
sounds like this code path is not heavily exercised in our test suite.
I did test with the test file for 687681, but there should obviously
be a full regression.

Raph

Index: src/zchar1.c
===================================================================
RCS file: /cvs/ghostscript/gs/src/zchar1.c,v
retrieving revision 1.43
diff -C2 -r1.43 zchar1.c
*** src/zchar1.c	23 Dec 2004 23:48:59 -0000	1.43
--- src/zchar1.c	13 Apr 2005 00:48:19 -0000
***************
*** 1208,1213 ****
      int wmode = gs_rootfont(igs)->WMode;
      int code;
  
!     code = gs_default_glyph_info((gs_font *)pbfont, glyph, &pbfont->FontMatrix,
  		((GLYPH_INFO_WIDTH0 | GLYPH_INFO_VVECTOR0) << wmode) | GLYPH_INFO_BBOX,
  	        &info);
--- 1208,1214 ----
      int wmode = gs_rootfont(igs)->WMode;
      int code;
+     gs_matrix id_matrix = { identity_matrix_body };
  
!     code = gs_default_glyph_info((gs_font *)pbfont, glyph, &id_matrix,
  		((GLYPH_INFO_WIDTH0 | GLYPH_INFO_VVECTOR0) << wmode) | GLYPH_INFO_BBOX,
  	        &info);