Regression from Windows XP to Windows 7

Report · Jun 03, 2011

Hi,

For many years our company has distributed a monospace TrueType font called "SAS Monospace". This font contains 'box characters' (see the wikipedia article if you've never heard of box characters). In Windows XP, it is possible to use GDI in an application to send output to the:

PostScript Printer Driver
Version 5.2 (6.0.6000.16386)
Jointly developed by Microsoft Corp. and Adobe Systems Inc.
Model name: Adobe PDF Converter
PPD filename: ADPDF9.PPD

driver and create a PostScript file that utilizes the font's box characters. All the box charcaters line up fine when the file is viewed in GSview. In Windows 7, you can run the exact same application, on a machine where the exact same font is installed, and the box characters will be slightly misaligned. In Windows 7 RTM, the version of the driver is:

Version 5.2 (6.1.7800.16285)

In Windows 7 SP1 the version of the driver is:

Version 5.2 (6.1.7601.17514)

In both Windows 7 RTM and Windows 7 SP1 the same misalignment occurs. The problem apparently has to do with character spacing. If you go on to create a PDF from the PostScript and use the 'Edit Document Text' tool in Acrobat X, and select all the box character text, and right click and select 'properties', and set the 'Character Spacing' property away from zero and then back to zero, the characters are now aligned in the PDF! If you change the source code of the GDI application so that it calls

SetTextCharacterExtra(DC, 1);

then everything will be aligned in the PostScript and any PDF derived from it. That's not what we want, however, because it spreads everything out. But it
does go to emphasize that it's a problem of character spacing. I'm using GSView to view the PostScript files. The problem occurs at execution time, not viewing time. That is, if you move the misaligned Windows 7 document over to Windows XP and view it there, the misalignment is still evident. And if you move the Windows XP document over to Windows 7, the alignment is still just fine. In one experiment I rewrote the GDI sample program so that it uses
Courier New to print the box characters, and those were aligned OK on Windows 7. The code points for the box characters are different in Courier New than in our SAS Monospace font. Please ignore any odd looking dates in the files I'm sending to document the problem. These are just an artifact of some other unrelated testing I'm doing on the virtual machines I'm using for testing. I don't speak PostScript, but the only significant diffs I see between the XP-generated file and the Win7 one are:

Comparing files TestFileFromWin7.ps and TESTFILEFROMXP.PS

***** TestFileFromWin7.ps
659: pop
660: 625 4860 M <0808080808080808080813141415141415141415141415141415141416>[193 193 193 193 193 193 193 193 193 193 193 193 193 193
661: 193 193 193 193 193 193 193 193 193 193 193 193 193 193 0]xS
662: N 625 5000 5597 450 rp C
***** TESTFILEFROMXP.PS
659: pop
660: 625 4860 M <0808080808080808080813141415141415141415141415141415141416>S
661: N 625 5000 5597 450 rp C
*****

***** TestFileFromWin7.ps
693: pop
694: 625 5760 M <080808080808080808081814141914141914141914141914141914141A>[193 193 193 193 193 193 193 193 193 193 193 193 193 193
695: 193 193 193 193 193 193 193 193 193 193 193 193 193 193 0]xS
696: N 625 5900 5597 450 rp C
***** TESTFILEFROMXP.PS
692: pop
693: 625 5760 M <080808080808080808081814141914141914141914141914141914141A>S
694: N 625 5900 5597 450 rp C
*****

***** TestFileFromWin7.ps
698: N 625 6350 5597 450 rp C
699: 1 5 scol L 0 5 scol 625 6660 M <080808080808080808081814141914141914141914141914141914141A>[193 193 193 193 193 193 193 193 19
700: 3 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 0]xS
701: N 625 6800 5597 450 rp C
***** TESTFILEFROMXP.PS
696: N 625 6350 5597 450 rp C
697: 1 5 scol L 0 5 scol 625 6660 M <080808080808080808081814141914141914141914141914141914141A>S
698: N 625 6800 5597 450 rp C
*****

***** TestFileFromWin7.ps
703: N 625 7250 5597 450 rp C
704: 1 5 scol L 0 5 scol 625 7560 M <080808080808080808081814141914141914141914141914141914141A>[193 193 193 193 193 193 193 193 19
705: 3 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 0]xS
706: N 625 7700 5597 450 rp C
***** TESTFILEFROMXP.PS
700: N 625 7250 5597 450 rp C
701: 1 5 scol L 0 5 scol 625 7560 M <080808080808080808081814141914141914141914141914141914141A>S
702: N 625 7700 5597 450 rp C
*****

***** TestFileFromWin7.ps
729: N 625 8600 5597 450 rp C
730: 1 5 scol L 0 5 scol 625 8910 M <0808080808080808080813141415141415141415141415141415141416>[193 193 193 193 193 193 193 193 19
731: 3 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 193 0]xS
732: LH
***** TESTFILEFROMXP.PS
725: N 625 8600 5597 450 rp C
726: 1 5 scol L 0 5 scol 625 8910 M <0808080808080808080813141415141415141415141415141415141416>S
727: LH
*****

Evidently there is a sort of preprocessor macro facility to PostScript and the S above expands as 'show', xS is 'xshow', and M is 'moveto'. You can tell I'm a PostScript noob, right? I created a zip file which contains:

sasmono.ttf          -- Our monospace font.
TestFileFromWin7.ps -- The results of running the sample on Windows 7
                        (box characters don't align).
TestFileFromXP.ps    -- The results of running the sample on Windows XP
                        (box characters do align).
GDIPrintSample       -- Folder containing the modified GDI print sample
                        code that I ran. The URL in Readme.txt points to
                        Microsoft's EULA for this sample. I used
                        Visual Studio 2010 to build the sample.

This link should provide access to the zip file.

I think the problem must lie in either the GDI libraries or the PS driver. I would appreciate any insights. Thanks.

Statements I am required to make: I am an employee of SAS Institute Inc. The postings on this site are my own and do not represent the positions, strategies or opinions of SAS.

Report · Jun 04, 2011

I remember from my experience with FrameMaker on Windows XP that GDI allows two variants of font metrics handling:

a) using the metrics of the glyphs derived from the original font for rendering on the display

b) using the original font metrics

To ensure equivalent output on both screen and printer, the metrics handling chosen by the application is the same

for both output devices.

In your case, it seems to me that your GDI application uses method b) above on XP but a) above on Win 7.

Perhaps you need to modify some registry keys to do a global change on this behaviour.

Helge

Report · Jun 10, 2011

The GDI print sample, on which I based my repo application, is quite trivial. There can't be any confusion between the screen and a printer, because the code only targets the single device that is hard-coded in the source.

Regarding your speculation about registry keys, are you suggesting that there might be some OS registry keys that control this? If so, it seems to me, these keys would have names and somebody would have named them by now. Or are you speculating that the application uses its own registry keys for control? Again, the application is trivial. Someone would be able to cite the source file and line number if control points like this existed in the application.

If the source code is changed to target the XPS document writer, the box characters all line up perfectly. Doesn't that eliminate everything except the PostScript driver?

Is there a more formal channel for reporting bugs in the PostScript driver?

Adobe Community

Regression from Windows XP to Windows 7