Re: print preview on Windows works

Hi Jordi,

> This is really great Dom. This is really useful from a user point of view!

Thanks!

> Please, correct me if I'm wrong. When you print in Windows you paint on
> a Device Context using Windows drawing directives. Many drivers are able
> to convert this to direct printer directives (like happens Postscript
> printers). My perception is that generating a big TIFF we are loosing
> all the capabilities of the printer on terms of rendering and we are
> taking the responsibility of rendering instead of the printer.

That's correct. The code captures each page's drawing commands as an
EMF. I then render this as a page in a multi-page TIFF. I do this
because Windows doesn't have any multi-page vector metafile format and
print preview needs to be able to support multiple pages.

Now, of course we're going to render this instead of a printer. The
point of "print preview" is to see the output on-screen as it would be
printed, so we're necessarily not involving a printer. There's a
legitimate concern that the vector data is lost in the rasterization
process, but that's why I'm running this @ a high DPI. At least the
output will look ok if a user printed the preview. You're correct that
this would send a big RGB blob to the printer instead of vector
drawing commands.

> In Windows Vista the printing subsytem in based now on XPS, that is
> basically a PDF alike system.
>
> To me looks more correct to convert the page drawing commands into Win32
> Device Context directives.

If there's a way to capture multiple pages of vector drawing commands,
save them to a single file, and then have Windows display the file,
I'm all for it. But neither WMF, EMF, or EMF+ supports this. If we
can't do it, this is a good first approximation of correct behavior.
In an ideal world, GDI+ would come with a PDF backend (like cairo
does), and we could save everything as a PDF, thus preserving most of
the vector drawing commands. But then we have to worry if a PDF viewer
is installed on every Windows machine.

It would be trivial to use my code as a basis for a custom preview
widget if one were so inclined to write one, since 90% of what it
handles is redirecting drawing commands to a hidden EMF graphics
class. We could still redirect the drawing to an EMF, and then save
the EMFs in a vector. The preview widget would "replay" the correct
EMF for whatever page you wanted to see.

Cheers,
Dom

-- 
Counting bodies like sheep to the rhythm of the war drums.