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.