"Ian Pilcher" ian.pilcher@home.com wrote:
dlls/wineps/init.c, ppd.c Change some PS driver FIXMEs/MESSAGEs to WARNs
I think it's not the time to do it. Those messages/fixme's help a lot to add missing page and bin type into psdrv: they are not complete now.
And without message about missing fonts in ppd/afm it would be nightmare to track down problems with ps fonts at least for me.
Dmitry Timoshkov wrote:
I think it's not the time to do it. Those messages/fixme's help a lot to add missing page and bin type into psdrv: they are not complete now.
And without message about missing fonts in ppd/afm it would be nightmare to track down problems with ps fonts at least for me.
The messages are still there. All you have to do is turn them on if you have problems.
"Ian Pilcher" ian.pilcher@home.com wrote:
I think it's not the time to do it. Those messages/fixme's help a lot to add missing page and bin type into psdrv: they are not complete now.
And without message about missing fonts in ppd/afm it would be nightmare to track down problems with ps fonts at least for me.
The messages are still there. All you have to do is turn them on if you have problems.
Sure. -debugmsg +??? serves for finding problems too, doesn't it? FIXME tells about not complete implementation, in the case of psdrv - about missing page and bin type.
Dmitry Timoshkov wrote:
Sure. -debugmsg +??? serves for finding problems too, doesn't it? FIXME tells about not complete implementation, in the case of psdrv - about missing page and bin type.
Is it really appropriate to spit out a FIXME every time we encounter a paper size or bin type that we don't recognize?
In the case of the *InputSlot option, for example, p. 97 of Adobe's Post- Script Printer Description File Format Specification says:
Any arbitrary strings that appropriately describe the device's input slots are valid inputSlotOptions.
Referring to media types, p. 183 says:
A device manufacturer is free to list a new size in a PPD file for a new device.
So the fact is that we're never going to recognize all options. I'll grant that we could probably recognize more options, but that hardly seems to justify issuing a FIXME -- and I can see no logic to issuing the FIXME only when an option isn't recognized.
"Ian Pilcher" ian.pilcher@home.com wrote:
Is it really appropriate to spit out a FIXME every time we encounter a paper size or bin type that we don't recognize?
I would agree with you, if you have added all regular possible values listed in wine/include/wingdi.h and only then replaced FIXME's by WARN's.
Dmitry Timoshkov wrote:
I would agree with you, if you have added all regular possible values listed in wine/include/wingdi.h and only then replaced FIXME's by WARN's.
Well, the only paper size missing is DMPAPER_11X17, presumable because it isn't mentioned in Adobe's documentation.
For the bin types, if someone can tell me how to map the following PPD file bin types, I'll do it:
2ndTray 3rdHCFTray 3rdTray 4thHCFTray 4thTray 500Sheet ASFbin1 ASFbin2 AUTO AnyLargeFormat Auto AutoSelect Auto_Tray1 Auto_Tray2 Automatic Autoselect Autotray Bin1 Bin2 Bottom Bottomtray Bypass BypassHeavy BypassPaper BypassT1 BypassT2 BypassT3 BypassTransparency BypassTray BypassXHeavy CPF1 CPF2 Cassette Cassette1 Cassette2 Cassette3 Cassette4 Cassette5 EnvFeed Envelope EnvelopeFeeder EnvelopeTray Front FrontFeed FrontFeeder HCEF HCF HighCapTray1 Hopper InsertSheet LCIT LargeCapacity LargeCapacityTray LargeLower LargeUpper Largesheet Lower Lower1 Lower2 Lower250SheetFeeder Lower500SheetFeeder LowerCassette LowerOptTray LowerTray Lowercassette MBF MP MPF MPMF MPT MPTray MSI Main MainTray Manual ManualBypass ManualEnvelope ManualFeed ManualFeedTray ManualFeeder ManualNormal ManualOHP ManualPaper ManualThick ManualTransparency Medium Middle Middle250SheetFeeder Middle500SheetFeeder Middletray Multi-Feeder Multi-MediaFeeder Multi-Purpose MultiMediaFeeder MultiPurpose Multimedia Multipurpose MultipurposeTray NotSpec OnlyOne OptionalCassette OptionalCassette1 OptionalCassette2 OptionalTray Paper PaperDeck PaperTray Paper_Deck PrinterDefault Rear Roll RollFeed SecondCassette SideTray Slot0 Slot1 Slot2 Slot3 Slot4 Small Standard StandardCassette StandardTray StandardTray Top Toptray Transparency Tray Tray0 Tray1 Tray2 Tray3 Tray4 Tray5 Tray6 Tray7 TrayManual Tray_Auto Universal Upper UpperCassette UpperOptTray UpperTray Uppercassette Version2 Web
(Every single one of these comes from a PPD file on Adobe's FTP site.)
On Wed, Apr 04, 2001 at 02:16:49AM +0600, Ian Pilcher wrote:
Dmitry Timoshkov wrote:
I would agree with you, if you have added all regular possible values listed in wine/include/wingdi.h and only then replaced FIXME's by WARN's.
Well, the only paper size missing is DMPAPER_11X17, presumable because it isn't mentioned in Adobe's documentation.
For the bin types, if someone can tell me how to map the following PPD file bin types, I'll do it:
The fallback should be to map unmapped names to DMBIN_USER, DMBIN_USER+1, etc... This is what the FIXME is now telling us to do ;)
Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1@physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK
"Ian Pilcher" ian.pilcher@home.com wrote:
Well, the only paper size missing is DMPAPER_11X17, presumable because it isn't mentioned in Adobe's documentation.
For the bin types, if someone can tell me how to map the following PPD file bin types, I'll do it:
Since we have a fairly limited set of available DMBIN_???, some approximation could be used. For all missing bins we could just assign some reasonable value, for instance DMBIN_AUTO:
2ndTray 3rdHCFTray 3rdTray 4thHCFTray 4thTray 500Sheet ASFbin1 ASFbin2 AUTO --> DMBIN_AUTO AnyLargeFormat --> DMBIN_LARGEFMT Auto --> DMBIN_AUTO AutoSelect --> DMBIN_AUTO Auto_Tray1 --> DMBIN_AUTO Auto_Tray2 --> DMBIN_AUTO Automatic --> DMBIN_AUTO Autoselect --> DMBIN_AUTO Autotray --> DMBIN_AUTO Bin1 Bin2 Bottom --> DMBIN_LOWER Bottomtray --> DMBIN_LOWER Bypass BypassHeavy BypassPaper BypassT1 BypassT2 BypassT3 BypassTransparency BypassTray BypassXHeavy CPF1 CPF2 Cassette --> DMBIN_CASSETTE Cassette1 --> DMBIN_CASSETTE Cassette2 --> DMBIN_CASSETTE Cassette3 --> DMBIN_CASSETTE Cassette4 --> DMBIN_CASSETTE Cassette5 --> DMBIN_CASSETTE EnvFeed --> DMBIN_ENVELOPE Envelope --> DMBIN_ENVELOPE EnvelopeFeeder --> DMBIN_ENVELOPE EnvelopeTray --> DMBIN_ENVELOPE Front FrontFeed FrontFeeder HCEF HCF HighCapTray1 --> DMBIN_LARGECAPACITY Hopper InsertSheet LCIT LargeCapacity --> DMBIN_LARGECAPACITY LargeCapacityTray --> DMBIN_LARGECAPACITY LargeLower --> DMBIN_LOWER LargeUpper --> DMBIN_UPPER Largesheet --> DMBIN_LARGEFMT Lower --> DMBIN_LOWER Lower1 --> DMBIN_LOWER Lower2 --> DMBIN_LOWER Lower250SheetFeeder --> DMBIN_LOWER Lower500SheetFeeder --> DMBIN_LOWER LowerCassette --> DMBIN_LOWER or DMBIN_CASSETTE LowerOptTray --> DMBIN_LOWER LowerTray --> DMBIN_LOWER Lowercassette --> DMBIN_LOWER or DMBIN_CASSETTE MBF MP --> DMBIN_AUTO MPF MPMF MPT --> DMBIN_AUTO MPTray --> DMBIN_AUTO MSI Main --> DMBIN_AUTO MainTray --> DMBIN_AUTO Manual --> DMBIN_MANUAL ManualBypass --> DMBIN_MANUAL ManualEnvelope --> DMBIN_ENVMANUAL ManualFeed --> DMBIN_MANUAL ManualFeedTray --> DMBIN_MANUAL ManualFeeder --> DMBIN_MANUAL ManualNormal --> DMBIN_MANUAL ManualOHP --> DMBIN_MANUAL ManualPaper --> DMBIN_MANUAL ManualThick --> DMBIN_MANUAL ManualTransparency --> DMBIN_MANUAL Medium --> DMBIN_MIDDLE Middle --> DMBIN_MIDDLE Middle250SheetFeeder --> DMBIN_MIDDLE Middle500SheetFeeder --> DMBIN_MIDDLE Middletray --> DMBIN_MIDDLE Multi-Feeder --> DMBIN_AUTO Multi-MediaFeeder --> DMBIN_AUTO Multi-Purpose --> DMBIN_AUTO MultiMediaFeeder MultiPurpose --> DMBIN_AUTO Multimedia Multipurpose --> DMBIN_AUTO MultipurposeTray --> DMBIN_AUTO NotSpec --> DMBIN_AUTO OnlyOne --> DMBIN_ONLYONE OptionalCassette --> DMBIN_CASSETTE OptionalCassette1 --> DMBIN_CASSETTE OptionalCassette2 --> DMBIN_CASSETTE OptionalTray Paper PaperDeck PaperTray Paper_Deck PrinterDefault --> DMBIN_AUTO Rear Roll RollFeed SecondCassette --> DMBIN_CASSETTE SideTray Slot0 Slot1 Slot2 Slot3 Slot4 Small --> DMBIN_SMALLFMT Standard --> DMBIN_AUTO StandardCassette --> DMBIN_CASSETTE StandardTray --> DMBIN_AUTO StandardTray --> DMBIN_AUTO Top --> DMBIN_UPPER Toptray --> DMBIN_UPPER Transparency Tray Tray0 Tray1 Tray2 Tray3 Tray4 Tray5 Tray6 Tray7 TrayManual --> DMBIN_MANUAL Tray_Auto --> DMBIN_AUTO Universal --> DMBIN_AUTO Upper --> DMBIN_UPPER UpperCassette --> DMBIN_UPPER or DMBIN_CASSETTE UpperOptTray --> DMBIN_UPPER UpperTray --> DMBIN_UPPER Uppercassette --> DMBIN_UPPER or DMBIN_CASSETTE Version2 Web
Dmitry Timoshkov wrote:
Since we have a fairly limited set of available DMBIN_???, some approximation could be used. For all missing bins we could just assign some reasonable value, for instance DMBIN_AUTO:
I wrote a little test program to see what Windows reports for these different bin types, and the results are interesting. On Windows NT 4, both the Microsoft and Adobe PostScript drivers seem to just map every- thing to DMBIN_USER+x values! For example, I installed the "IBM 4019 LaserPrinter PS17" driver (PPD file attached), and got the following from DeviceCapabilities:
DC_BINNAMES DC_BINS
Automatically Select DMBIN_FORMSOURCE Upper 256 Lower 257 Envelope 258 EnvelopeManual 259 Manual Feed DMBIN_MANUAL
(Note that every printer driver I tried had the "Automatically Select" and "Manual Feed" entries.)
Based on this, I see no reason to try to guess what the appropriate DMBIN* type is for undocumented *InputSlot values. In my mind, the question is whether we should use the mappings in Adobe's PPD spec or completely emulate the Windows behavior.
Thoughts?
-
Dmitry Timoshkov -
Huw D M Davies -
Ian Pilcher