Craig White <craigwhite at azapple.com> wrote: > There is room for misinterpretation of what you are saying > and the way other people would believe would occur. Okay, in the context of comparing this "unofficial hack" of, and I quote ... "- a valid device mode generated by the driver for the printer (defining things like paper size, orientation and duplex settings). - A complete set of printer driver data generated by the driver. ... Fortunately, most drivers automatically generate the printer driver data that is needed when they are uploaded to the [print$] share with the help of the APW or rpcclient. The generation and setting of a first valid device mode, however, requires some tickling from a client to set it on the Samba server. The easiest means of doing so is to simply change the page orientation on the server's printer. This executes enough of the printer driver program on the client for the desired effect to happen and feeds back the new device mode to our Samba server." First off, this is _very_subjective_. Remember, there are *2* differing configuration screens to any printer. We're not talking about page orientation, which tray you want by default, etc... We're talking core printer assembly details -- memory, font sets, trays, bays and other options installed. Things I do _not_ want people changing because -- e.g., Tray 4 doesn't exist! -- that type of stuff. ;-> The "device mode" that Samba can store is rather limited. It's not going to help you with more advanced features that can change, which will require you to re-upload your original printer data from Windows again. It's more about page orientation than what trays are configured. Secondly, and far more relevant, this is _laughable_ compared to a PPD. My response was with regards to how the PPD provides such settings, especially in conjuction with the "unified" approach of CUPS and the CUPS driver for Windows. That's where the CUPS driver and CUPS-Samba integration is better than just using the Adobe PS with a PPD. You really have to see it in action to understand what it does. For 1-2 printers on a small network, not a big deal. For 5+ printers on an enterprise network -- thank God! Easy Software Products (ESP) makes money on selling fully supported CUPS solutions because it just works so much better -- for _all_ vendor printers, various clients (especially Windows), etc... In Windows, to get the same, I have to select *1* vendor, and use only their printers with their management software. Especially for non-Windows clients. > This would appear to be at odds with your statement. I have > had no problem propagating default settings to 'client' > installs from printers set up via APW/Point and Print on samba > servers. Again, not nearly the same level of "control" as a PPD, especially given the fact that it is "unified" with the CUPS server. Even using the Adobe PS driver with a PPD and using it to feed back changes to the share would not be as good. > it would be hard to make an argument to use Microsoft's > PostScript print driver for anything other than the fact > that it is built in. Some things just don't mix. ;-> -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)