capturing emf spool file for later replay.

Discussion in 'Windows Vista Drivers' started by hwilcox, Jul 16, 2008.

  1. hwilcox

    hwilcox Guest

    Hi,

    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
     
    hwilcox, Jul 16, 2008
    #1
    1. Advertisements

  2. I am trying to capture the emf spool file, so that I can replay it later on
    Am I wrong that the EMF file is generated for one particular driver?
     
    Maxim S. Shatskih, Jul 16, 2008
    #2
    1. Advertisements

  3. hwilcox

    hwilcox Guest

    I though that the emf file is basically a list of gdi calls that make up the
    page, and was therefore independent of the driver, am I wrong to think this?
     
    hwilcox, Jul 17, 2008
    #3
  4. Coordinates can be driver-dependent.
     
    Maxim S. Shatskih, Jul 17, 2008
    #4
  5. hwilcox

    Jeff Henkels Guest

    Also, the sequence of GDI calls may change depending on the driver. GDI
    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.
     
    Jeff Henkels, Jul 17, 2008
    #5
  6. Also, the sequence of GDI calls may change depending on the driver.

    Yes. Use of driver-provided fonts is one such area.
    No NtGdi driver can draw circles, they can only do StrokePath or FillPath.
    Paths are polygons or Bezier splines.
     
    Maxim S. Shatskih, Jul 17, 2008
    #6
  7. hwilcox

    hwilcox Guest

    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.

    Hugh
     
    hwilcox, Jul 18, 2008
    #7
  8. 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 ...
     
    Christoph Lindemann, Jul 22, 2008
    #8
  9. 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, Jul 26, 2008
    #9
  10. 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. ;-)
     
    Carey Gregory, Jul 26, 2008
    #10
  11. hwilcox

    lwon Guest

    For the same purpose as Hugh, now that I have created a metafile object with
    the emf file, and tried playrecord() method and it works, is there a way I
    can redirect the instructions to my printer driver?

    Thanks.
     
    lwon, Aug 7, 2008
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.