psdrv: map Courier New to Courier

Ian Pilcher pilcher at
Sat Feb 3 04:18:45 CST 2001

Huw D M Davies wrote:
> Great!  Well the Windows 2000 PS driver stores the font sub table
> under the value name "TTFontSubTable" in the printer driver's
> PrinterDriverData registry key.  To do this we need to implement
> Get/SetPrinterData (if you give me a couple of days I'll do it).  The
> data associated with TTFontSubTable is just a set of 2n \0
> terminated strings the final one terminated by 2 \0
> (i.e. REG_MULTISZ).  The actual configuring should go on in the
> printer setup property sheet.  Hmmm, fancy learning a little of the
> Win32 api?

I just spent some time poking around in the Registry of my Windows 2000
system.  Neither "TTFontSubTable" or "FontSubTable" appears anywhere.
(I have printers installed that use both the Adobe and Microsoft Post-
Script drivers.)

In fact, when I searched on "Helvetica" the only things I found that
looked like font substitution tables were under HKCU\Software\Microsoft\
Shared Tools\Font Mapping and HKLM\SOFTWARE\Microsoft\Windows NT\

Another point of interest -- none of the printer properties dialogs seem
to allow me to configure the font substitution, even though I have
"TrueType Font: Substitute with Device Font" set in the Advanced Options
of the Apple LaserWriter 12/640 PS driver.

> OK, I've just submitted G|SetPrinterData implementations to
> wine-patches - please use these instead of direct Reg apis. (it should
> make life easier anyway.
> You basically want
> HANDLE hprn;
> OpenPrinterA("Wine PostScript Driver", &hprn, NULL);
> SetPrinterDataA(hprn, "FontSubTable" /*or whatever*/, REG_MULTI_SZ, pData, size);
> ClosePrinter(hprn);
> where pData is a list of \0 terminated strings that make up the table,
> finally terminated by a double \0.
> Reading the data back is almost the same using GetPrinterDataA

So is "FontSubTable" what we want to use?  It should be easy enough for
me to have the driver use GetPrinterData and set up a simple array when
it is initialized.  (Although it does seem a little weird to have the
driver calling OpenPrinter; is this OK?)

> > I think we should also allow the Wine config file to override what's
> > in the registry.
> Not really convinced about this. I'd like to move all of the psdrv
> stuff out of the config file (which afterall is just a bit of the
> registry) into its correct place under
> HKLM\System\CurrentControlSet\Control\Printers\Print
> The configuration should all be done via a GUI control.

Two points:

1)  How can a user get this information into the Registry until the GUI
    control is written?  (I hope you weren't thinking that this is some-
    think I'm capable of doing.  Me stupid procedural guy; OO GUI stuff
    make head feel oogey!)

2)  Just because people use Wine to run Windows applications, doesn't
    mean that they've bought into the "everything should be GUI"
    philosophy; some of us actually *like* ASCII configuration files.

> > In the old style, I would have suggested something of the form:
> > 
> >     Windows Font = X LFD, PostScript font name
> > 
> > This would seem to be relatively straightforward to implement, and it
> > would bring a small measure of sanity to the area.  (I currently have
> > both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and
> > the PostScript driver don't agree on what the font should be called!)
> This should all be a lot easier when I get a FreeType engine bolted on
> to gdi.  Then psdrv,x11drv,ttydrv(?) will all have access to the same
> data and thus consistancy should not be a problem.

I actually see a manual font configuration as a *very* small step in
this direction.  At least it will let Wine control it's view of what
fonts are available, rather than trying to make intelligent guesses
based on the X font list and the PostScript driver.

It does assume a certain intelligence on the user's part; mapping the
core Windows fonts to X fonts that aren't installed on the system would
be "bad", but it shouldn't be too hard to supply a reasonable default

Ian Pilcher                                       pilcher at

More information about the wine-devel mailing list