wine based win32 printer drivers

[Hin-Tak Leung]

I am looking at ddiwrapper lately and having a lot of fun with it. Is Marcel's on-going 
not-merged work anywhere on line that I can have a peek before its merge into wine?

Hin-Tak

--- On Mon, 31/3/08, Detlef Riekenberg <wine.dev at web.de> wrote:

> From: Detlef Riekenberg <wine.dev at web.de>
> Subject: wine based win32 printer drivers
> To: "Marcel Partap" <mpartap at gmx.net>
> Cc: wine-devel at winehq.org
> Date: Monday, 31 March, 2008, 12:12 AM
> On So, 2008-03-30 at 06:03 +0200, Marcel Partap wrote:
> > Anyways, I am working on getting something merged.. 
> 
> Great!
> 
> > For now the target is to get the Adobe pscript5 driver
> working which
> > has its own raster renderer and thus does not depend
> on the dib
> > engine. 
> A Postscript Driver has no raster renderer...
> A Postscript Driver has a Postscript Engine.
> 
> > Just started by making AddPrinter correctly get 
> > a default devmode out of the driver, patch is
> attached, 
> 
> > DRIVER_EVENT_INITIALIZE, 3,
> "3" is wrong here. See:
> myAddPrinterDriverEx(DWORD level, ...
> 
> Since there are much more Events, we need the DriverUI in
> more Places
> later. I suggest a simple struct, which can be extended
> later
> (The struct must include the Results from GetProcAddress)
> 
> 
> The changes for winspool.drv must go in a seperate Patch.
> WINSPOOL_CallDrvDocumentProperties is the wrong name, when
> you 
> call DrvDocumentPropertySheets.
> 
> You should collect all API in winspool.drv, that need the
> driverui
> (some are not implemented) and design a simple struct
> with helper functions (Use monitor_t as example).
> Not all Drivers Export DrvDocumentPropertySheets.
> You must prepare to use a Fallback to get the default
> devmode
> (DrvConvertDevMode)
> See winspool.drv/monitor_load as Example:
> - InitializePrintMonitor2 is suggested my MSDN, but not
> needed yet
> - InitializePrintMonitor implemented
> - InitializeMonitorEx and InitializeMonitor as Fallback.
> 
> The current Code is a crosscall from DocumentPropertiesW to
> DocumentPropertiesA.
> The DDI-API is unicode and should be the prefered way.
> When wineps.drv is updated, the old code with the crosscall
> can be
> removed, since we do not support ANSI Drivers (Windows 9x).
> 
> You can even use the same struct and helper functions 
> in localspl.dll and winspool.drv
> 
> 
> -- 
>  
> By by ... Detlef


      ___________________________________________________________ 
Yahoo! For Good helps you make a difference  

http://uk.promotions.yahoo.com/forgood/