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\ CurrentVersion\FontSubstitutes.
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 nameThis 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 configuration.
On Sat, Feb 03, 2001 at 04:18:45PM +0600, Ian Pilcher wrote:
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.)
Try changing an entry in the font sub table. The driver doesn't write anything until you move anyway from the default.
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.
My LaserJet 4/4M driver allows you to edit the table in the Device Settings tab of the Property dailog got by going to Control Panel -> Printers, selecting the printer and then doing Printer->Properties.
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.
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?)
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.
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:
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!)
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.
The Wine registry files are ascii, and adding stuff to the registry can be done via the regapi program anyway.
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 configuration.
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.
Huw.
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.
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.
On Mon, 05 Feb 2001, you wrote:
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
I *think* that I tried that. I'll doublecheck when I have a chance.
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 ;) ).
What part offends you? I have not hardcoded the name of the printer into the driver. It do my setup in PSDRV_GetPrinterInfo, so I have the name available.
Does GetPrinterDataEx allow one to enumerate the values in a key? Keep in mind that with this setup we don't know the value names.
Here is my initial patch. It doesn't include any of the changes you suggest in your most recent note, but take a look and tell me what you think.
-
Huw D M Davies -
Ian Pilcher