(Forgot to post this one since it happened while Damiano was born...) When I worked as a System Administrator, I stumbled a few times into the issue that Samba only supports RAW printing. The drawbacks aren't particularly huge, you just go ahead, install the driver on the client which does all the conversions needed and then sends the RAW data to Samba, which stores it in a spool file and then passes it on to CUPS which takes over from that point on. The only drawback with this approach is that some drivers disable a couple of "advanced features" when the Network printing queue is a RAW one (most often the multiple sheet per page option). A possible workaround is to print directly via IPP to cups, but in a scenario where you need to do printed page accounting, you need to authenticate users and presenting another login mask to users who already logged on isn't particularly appealing. Note, that even on an NT4 Print server if you enable "RAW printing only" you get these same issues I'm describing (By checking "Printer Properties, General Tab, Print Processor, Always Spool RAW datatype). After a bit of research, I concluded that it simply wasn't possible for samba to support non-RAW jobs (which normally use EMF - Enhanced Metafile Format), since it requires running Windows drivers on the server.
So I was a little surprised when I saw a Summer of Code project proposal for Samba called "Implement support for EMF print jobs" on projects.samba.org. So I checked on #samba-technical and asked Jerry Carter what the idea behind that project was. Here's the relevant IRC excerpt:
01/04/07 18:16:45 what's the plan behind the "Implement support for EMF print jobs" project? An EMF->PS converter server-side, or something different? 01/04/07 18:17:40 That would be the idea. 01/04/07 18:17:51 bandini: interested ? 01/04/07 18:18:14 coffeedude, sort of ;) are you the one to annoy about it? :) 01/04/07 18:20:07 Yup. 01/04/07 18:30:08 coffeedude, when you say "use the installed Win32 printer driver to render to final format". You mean this server-side, right? What do you have in mind exactly? 01/04/07 18:31:25 bandini: yes. All server side. I was thinking of a command line utility (based on Wine probably) which would use the driver config DLL to process the EMF. 01/04/07 18:34:50 bandini: I'm not sure how much Wine already has in place for this. I know I've talked to some of the devs before and there's a good bit there. 01/04/07 18:36:13 coffeedude: why the need for the dll? jsut to get printer settings? 01/04/07 18:38:14 jmcd: I think so. 01/04/07 18:38:32 The GDI calls have to be processed by the driver for printer specifics IIRC.
Apparently, the way to go would be to create a command line-utility which takes an EMF file (or the windows .SPL spool file) and using wine and the driver .DLL files is able to produce the wanted output