On Mon, Feb 05, 2001 at 01:31:08AM +0600, Ian Pilcher wrote:
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.)
You'd need to add the line import winspool.drv to wineps.spec
Actually since you're storing the data as many values under a separate key would you mind moving the key to [..\Printers<name>\FontSubTable] (i.e. get rid of the PrinterDriverData elememt), this will mean the GetPrinterDataEx will still be able to access the data (I really think that we should eventually use these APIs as hard coding the ..\Printers<name> bit into the driver offends me ;) ).
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.
The numbers are modification times, so it's safe to play with the values.
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.
No (or is that Yes?), this is definitely private to a given instance of wineps.drv.
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.
Good. Actually it's hacked into the Devmode too, but this is ugly and I'll get rid of it.
Huw.