capturing emf spool file for later replay.
hwilcox
I am trying to capture the emf spool file, so that I can replay it later on
different print drivers. I'm trying to do this to simpify automated
regression testing of my driver.
While I have found a number of websites that say its possible, and some
programs that save a print job as emf, I haven't found any real details, and
as I understand it, spool file emf is a modified, undocumented version of emf
so something I download of the net might not work.
Thanks in advance
Hugh
Maxim S. Shatskih
> different print drivers.
Am I wrong that the EMF file is generated for one particular driver?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
hwilcox
page, and was therefore independent of the driver, am I wrong to think this?
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"hwilcox" <hwi...@discussions.microsoft.com> wrote in message
news:A91BD135-6B7B-4E77...@microsoft.com...
Jeff Henkels
will ask the driver what it can do (e.g. can it draw chords, circles,
polygons, etc.) ; for the supported operations, the EMF will contain the
appropriate commands. If GDI is asked to do something the driver can't
handle, it'll either fail the request or break it down into a series of
steps the driver can handle.
For example, if you tell GDI to draw a circle, but the driver can't do it,
GDI may send a many-sided polygon or a series of line segments to the
driver, to approximate a circle. If the driver can draw a circle, the EMF
will contain a single circle command. This is all based on my experience
writing printer drivers back in the Win 3.1/95 days; the details may have
changed a bit, but as I understand it, the basics are still the same.
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:%23cyDVd%235IH...@TK2MSFTNGP04.phx.gbl...
Maxim S. Shatskih
Yes. Use of driver-provided fonts is one such area.
> For example, if you tell GDI to draw a circle, but the driver can't do it,
No NtGdi driver can draw circles, they can only do StrokePath or FillPath.
Paths are polygons or Bezier splines.
hwilcox
performance optimisation. We have a number of scripts that print out our test
files, but:
1. its slow
2. not all the apps we test can be easily automated (currently use a system
to emulate mouse clicks, thats slow and error prone)
3. some of the apps take a long time to load (> 1 hour) a file, if we had
the spool files we could just run those, since driver capabilities shouldn't
be changing between versions, and it will be taking place on a small number
of testing machines (eliminating differences such as different fonts
installed) it would make our lives a lot easier.
Hugh
Christoph Lindemann
connection with "Open Protocol Specifications"
http://www.undocprint.org/formats/winspool/spl
When you want to capture the "GDI sequences" from a application please
notice that many applications first query the driver, to decide how the
printing should be done. Some applications might do their own dithering if
the driver does not support enough colors, or collating, or ...
--
Christoph Lindemann
Undocumented Printing
http://www.undocprint.org/
"hwilcox" <hwi...@discussions.microsoft.com> wrote in message
news:AF61FDC5-19D0-47AE...@microsoft.com...
Carey Gregory
>The purpose of this is to help regression test our driver as we do
>performance optimisation. We have a number of scripts that print out our test
>files, but:
>1. its slow
>2. not all the apps we test can be easily automated (currently use a system
>to emulate mouse clicks, thats slow and error prone)
>3. some of the apps take a long time to load (> 1 hour) a file, if we had
>the spool files we could just run those, since driver capabilities shouldn't
>be changing between versions, and it will be taking place on a small number
>of testing machines (eliminating differences such as different fonts
>installed) it would make our lives a lot easier.
Using EMF spool files for regression testing has some major drawbacks. It
*might* reduce some of the drudgery of regression testing, but I'm not so
sure it would be enough to outweigh the cost of development.
First, correctly parsing a spool file and playing it back as EMF is a
distinctly non-trivial project. The spool file format is undocumented,
it is *not* standard EMF, and it varies slightly between NT4, Win2K, XP,
and Vista. You'll quite likely spend many weeks reverse engineering it
and getting it to play back correctly.
Second, you'll never be 100% sure if a test result represents what would
have happened if you had printed with the application instead. You'll
have both false positives and false negatives because it's pretty much
impossible to replicate the print job with the EMF extracted from a spool
file with %100 fidelity. And, of course, your metafile player isn't the
original printing app, so any bugs specific to your driver's interaction
with the printing app would go undetected.
Anyway, if you really want to try this approach, you'll definitely want to
visit this site http://www.undocprint.org/
Carey Gregory
>Windows spool EMF is now fully documented. MS has released the docs in
>connection with "Open Protocol Specifications"
>http://www.undocprint.org/formats/winspool/spl
>
>When you want to capture the "GDI sequences" from a application please
>notice that many applications first query the driver, to decide how the
>printing should be done. Some applications might do their own dithering if
>the driver does not support enough colors, or collating, or ...
I'm be damned! It's been a while since I looked at this and I'm truly
surprised MS finally documented it.
Thanks for that info, Christoph! I take back my previous post about it
being undocumented. ;-)
lwon
the emf file, and tried playrecord() method and it works, is there a way I
can redirect the instructions to my printer driver?
Thanks.