i need to write a print preview application that is tied into our printer
driver. that
is, after the user prints to our driver, we will display a preview of the
print job
that the user can scroll through. typical printing features will be
displayed in the
image for each page such as orientation, N-up, etc.
development for the actual printer driver is being done as Unidrv plug-ins.
from the preview application the user can decide as to whether they really
want
to print out to the physical printer or to cancel the job.
QUESTION 1
is there a preferred point in the printing process that a preview
application should
be kicked off from such as from the rendering plug-in or from a custom print
processor?
i was looking into microsoft's sample print processor in their DDK however
all
of the GDI functions in Print Processors seem to just replay the EMF into
the
printers DC.
QUESTION 2
is it possible to use these GDI functions (e.g. GdiPlayPageEMF) to play back
EMF
in a preview application into the applications device context?
i've seen mention of the function gdiPlaySpoolStream in this newsgroup
however
there is no current documentation on it. it does appear in GDI32.DLL and
there
is documentation on it in the Windows 98 DDK. interestingly, Microsoft has
stated
in some newsgroup articles that this function should be used.
QUESTION 3
is the gdiPlaySpoolStream function valid (i.e. will be support in later
OSes, etc.)
for Windows 2000/XP?
can it be used to play back a page at a time (for previewing)?
Microsoft reiterates in numerous articles that EMF data that ends up in the
Spooler
is not the same as EMF generated by an application thus you can not rely on
this
format for playing back using normal EMF API functions.
QUESTION 4
if this is the case how are other printers displaying their Print Preview
applications
or are they just relying (i.e. hoping) that the format does not change.