>> On this year's Google SoC I found an interesting application called >> "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from >> wine)". >> It was accepted but I can't find any information about any progress. I am the guy responsible for not providing information about the progress - during SoC time I was most busy with actual coding and so did not even update my project blog.. sorry bout that :)
> The final solution must work with CreateDC("winspool",....) and need > the complete DIB-Engine. Exactly, the gdi engines drawing engine functions (EngBitBlt, EngTextOut...) need support for raster operations, which should best be implemented in dib.c .. Right now the driver initialisation and > Marcel is still working to improve his code and will start sending patches. Yeees I aam.. ;) But I am visiting my family for a few days ... you can have a look though at the current code under http://synth-worldz.de/wine-ddi/ddi.c ... too many stubs and unimplemented functions though, even if a few drivers already start feeling comfortable with it. >> In suse repository I found ddiwrapper package. It does something similar >> but only for some Canon drivers and wraps to use by CUPS. Of course that code was a great source of inspiration (thank you Uli Hecht) for the current implementation of printbitmap.exe which you can have a look at at http://synth-worldz.de/wine-ddi/printbitmap.c.. > ddiwrapper use ghostscript to convert Postscript to a Bitmap and the That is an unsolved problem up to now, how to get a drawing operation to the driver? there's two options for that: variant 1: application: sends drawing calls -> wineps.drv: renders a postscript -> ghostscript(win version preferably): renders to bitmap -> printbitmap.exe: loads native driver and simply blts the bitmap onto device surface and prints variant2: GDI32/DDI: CreateDC("WINSPOOL"...): normal driver loading like on native: hook drawing functions from driver -> native driver: draw stuff on device surface, punt unhandled calls back to GDI -> GDI32/DDI+DIB: Eng* functions wrap around the specific DIB functions which do the actual raster operations Right now variant 1 is kinda 'working' although it needs some more glue and love. Variant 2 is the next step, I'll start on this in a week or two after submitting the patches.. By the way who did work on CreateDC? Any ideas how to handle a printer device context? I have not yet looked into the details of the current implementation because I was instantly scared away by it ;) > There are a lot of things in wine, that are missing and need a lot of work. Wow definite :) All the printer property sheets will require another major amount of care.. Anyways many regards, marcel