Re: wine based win32 printer drivers

[Marcel Partap]

> I am looking at ddiwrapper lately and having a lot of fun with it.

Well I didn't have much fun with it because for me first it did not build properly, then segfaulted. 
Anyways.
> Is Marcel's on-going not-merged work anywhere on line that I can have
> a peek before its merge into wine?

ot online but attached is the work done last year. This year's work is still in the pipeline, not 
much time for it lately but its on the agenda.
regards.
> Hin-Tak
>
> --- On Mon, 31/3/08, Detlef Riekenberg  wrote:
> > From: Detlef Riekenberg  Subject: wine based win32 printer drivers To: "Marcel
> > Partap"  Cc: [e-mail] 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/