Would like to contribute to wine

Marcel Partap mpartap at gmx.net
Sun Sep 9 07:03:44 CDT 2007

>> 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

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..
many regards,

More information about the wine-devel mailing list