psdrv: map Courier New to Courier

Ian Pilcher pilcher at concentric.net
Sun Feb 4 13:31:08 CST 2001


Huw D M Davies wrote:
> 
> We don't need to worry about compatibility with the native drivers to
> this extent (this data is private to the driver), I was just using
> this as an example to how a native driver does save its data.

I'm glad you feel that way.  I've implemented it as:

    [...\Printers\<printer name>\PrinterDriverData\FontSubTable]
    <Windows font name>=<PostScript font family>
    <Windows font name>=<PostScript font family>
    .
    .
    .

> It doesn't matter: TTFontSubTable is what the native M$ driver uses,
> but we can use anything you like.  Calling OpenPrinter is fine within
> the driver - it only really retrieves a printer handle.

Well, I couldn't get GetPrinterData to work.  The driver would compile
OK,
but Wine was unable to load the driver, because it couldn't resolve the
'GetPrinterData' symbol.  (Probably something I did wrong.)

I went ahead and used the registry APIs, which really aren't all that
bad,
as long as you're good at counting NULLs.  I'm not sure I could have
structured the table as a series of values with GetPrinterData anyway,
and
I think this will be a lot easier for people to configure.  (Neither the
Wine registry files or regapi seem to support REG_MULTI_SZ data in a
very
user friendly way.)

> The Wine registry files are ascii, and adding stuff to the registry
> can be done via the regapi program anyway.

Is it actually possible to just go in and edit them?  I always figured
those numbers at the end of the key names were some sort of checksums
that would get messed up.

I was also under the impression that we would actually be reading the
font substitution table from the Windows PostScript driver.  Since those
substitutions might not be appropriate for the Wine environment, I felt
it was important to provide the user with a way to override them.  As
long as we keep WINEPS's data private, I agree.
> 
> I anticipate that most people will just be happy using TT/Type1/.fon
> fonts all served by FreeType and will not bother using XLFD fonts at
> all.  This makes font configuration quite easy, we just tell the
> FreeType font driver which font files we want it to serve and that's
> it.  The psdrv may still want to substitute builtin type1 fonts, but
> that seems to me to be psdrv's role and thus its configuration is
> unique to that; this becomes more obvious when you think that the user
> may install 2 instances of psdrv that print to different printers
> which may have different fontsets installed, therefore font
> substitution would be on a printer by printer basis.
> 

I absolutely agree.  I see the manual mapping of X fonts to Windows
font names as an interim step in that direction.

While I was playing with the registry, I moved the PPD file
specification
into the PrinterDriverData key, so the driver should support multiple
printers fairly well.

I'll send my changes in as soon as I've had a chance to get them cleaned
up.

-- 
========================================================================
Ian Pilcher                                       pilcher at concentric.net
========================================================================



More information about the wine-devel mailing list