C#程序动态设定打印选项 [Programmatically selecting complex printer options in C#]

Programmatically selecting complex printer options in C#

 We print out a full-color eight page customized flyer for every one of our orders. As soon as the order is done being processed, our internal processing application generates the flyer and shoots it off to one of the copier machines. The copier machine prints out the flyer (duplex), folds it, and staples it. This all happens silently and automatically; the employee does not have to twiddle with printer configuration or driver settings.

Getting this to happen automatically, however, was not easy. If you’re used to using thePrinterSettings and PrintDocument classes in Windows Forms, you’ll know that you have some options like a Duplex option available. But in our case, using that Duplex property seemed to make no difference in the printed output; the ol’ copier stubbornly went simplex every single time. It Simply Did Not Work. Not to mention that the .NET-native API doesn’t even begin to provide support for specifying paper folding, saddle stitching, and stapling. In a quest to find out how I could automate the selection of all these settings, I learned a bit more about printer drivers on Windows than I cared to know.

To get down and dirty with printer settings, I had to get familiar with DEVMODE. Being a .NET weenie who really doesn’t know his way around the Windows API very well, discovering this was progress; this structure exposes some of the options that I needed (such as collation), but it still didn’t provide any programmatic way to access folding and stapling settings.

Let’s go into the Printers section of the Control Panel and look at the Printing Preferences for one of these copiers. It turns out that this is a good way to be able to tell where a configuration setting lives. Some of the universal, standard settings are displayed on the “Layout” and “Paper/Quality” tabs. But if I want to get to any of the fancy features such as folding or stapling, well, they’re specific to our unique printer driver (and indeed, they’re exposed on a custom tab called “Fiery Printing” that the printer driver provides). There’s approximately zero documentation out there for configuring Fiery printer drivers programmatically, so how the hell was I going to communicate with this black box?

The Layout and Paper/Quality tabs can be configured by setting fields of the DEVMODE structure to documented values. But many of the Advanced "Printer Features" live in a driver-specific, undocumented part of memory just beyond the DEVMODE structure.

I’m not sure if my solution is genius, expected, or insane, but it’s been working for over a year now. The secret is a curious little member of the DEVMODE structure calleddmDriverExtra. MSDN has the following to say about this little member:

Contains the number of bytes of private driver-data that follow this structure. If a device driver does not use device-specific information, set this member to zero.

Private driver data, I thought. How interesting. It’s perfectly logical to assume that since the stapling and folding features are unique to this printer, then the configuration for those features is stored in some unknown format. That data lives in a block of memory at the end of the DEVMODE structure. The size of that block of memory is the value given in thedmDriverExtra field.

Here’s a crazy idea, I continued. What if I configured the default printer settings via the Printer Preferences pane in the Control Panel to the exact settings that I want the fliers to print with. Then, I’ll write a program that dumps the default DEVMODE structure and its private data for the printer to a file. Then, I can revert the default printer settings in the Control Panel back to normal.

When I want to print the flyer, I’ll just obtain the default DEVMODE, overwrite its spot in memory with the version that I had saved to disk, and then send the document to the printer. That way, I can specify those proprietary folding and stapling settings without actually knowing exactly how they’re defined in memory!

The printer-specific configuration data lives just beyond the DEVMODE structure.

It turns out that this ended up working quite well. Obviously, things will blow up if we ever change the version of the printer driver that’s installed on the server (since they’ll probably have changed the layout of their private data section). Luckily, though, we don’t really plan on changing things once they’re working.

Dumping the DEVMODE

So, first I went into the Control Panel and selected the duplexing, folding, and stapling options that I wanted in the print driver-supplied tab. Then I ran a quick and dirty console application like the following (I swiped the P/Invoke version of DEVMODE from pinvoke.net:

    class Program2    {        #region P/Invoke         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalFree(IntPtr handle);         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalLock(IntPtr handle);         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalUnlock(IntPtr handle);         #endregion         #region Constants         private const string DUMP_PATH = "DevModeDump.bin";         #endregion         static void Main(string[] args)        {            IntPtr hDevMode;                        // handle to the DEVMODE            IntPtr pDevMode;                        // pointer to the DEVMODE            DEVMODE devMode;                        // the actual DEVMODE structure            PrinterSettings printerSettings;        // our flyer's printer settings            Fall2008LargeFlyerPrintDocument flyer;  // our custom subclass of PrintDocument             flyer = new Fall2008LargeFlyerPrintDocument();             flyer.PrintController = new StandardPrintController();            printerSettings = flyer.PrinterSettings;            printerSettings.PrinterName = "Fiery X3E";             // Get a handle to a DEVMODE for the default printer settings            hDevMode = printerSettings.GetHdevmode(printerSettings.DefaultPageSettings);             // Obtain a lock on the handle and get an actual pointer so Windows won't            // move it around while we're futzing with it            pDevMode = GlobalLock(hDevMode);             // Marshal the memory at that pointer into our P/Invoke version of DEVMODE            devMode = (DEVMODE)Marshal.PtrToStructure(pDevMode, typeof(DEVMODE));             // Read the bytes starting at that pointers position in memory into our            // file stream            using (FileStream fs = new FileStream(DUMP_PATH, FileMode.Create))            {                for (int i = 0; i < devMode.dmSize + devMode.dmDriverExtra; ++i)                {                    fs.WriteByte(Marshal.ReadByte(pDevMode, i));                }            }             // Unlock the handle, we're done futzing around with memory            GlobalUnlock(hDevMode);             // And to boot, we don't need that DEVMODE anymore, either            GlobalFree(hDevMode);        }    }

Using the saved DEVMODE for printing

Now what do I do when I want to crank these suckers out? I just take my saved DEVMODE and overwrite the one that I get in memory when I’m about to print. It’s something like this:

    class Program3    {        #region P/Invoke         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalFree(IntPtr handle);         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalLock(IntPtr handle);         [DllImport("kernel32.dll", ExactSpelling = true)]        public static extern IntPtr GlobalUnlock(IntPtr handle);         #endregion         #region Constants         private const string DUMP_PATH = "DevModeDump.bin";         #endregion         static void Main(string[] args)        {            IntPtr hDevMode;                        // a handle to our current DEVMODE            IntPtr pDevMode;                        // a pointer to our current DEVMODE            PrinterSettings printerSettings;        // our flyer's printer settings            Fall2008LargeFlyerPrintDocument flyer;  // our custom subclass of PrintDocument            byte[] savedDevMode;                    // will hold the DEVMODE we saved earlier            Stream savedDevStream;                  // used to read the DEVMODE we saved earlier             flyer = new Fall2008LargeFlyerPrintDocument();             renderedFlyer.PrintController = new StandardPrintController();            printerSettings = renderedFlyer.PrinterSettings;            printerSettings.PrinterName = "Fiery X3E";             // Obtain the current DEVMODE position in memory            hDevMode = printerSettings.GetHdevmode(printerSettings.DefaultPageSettings);             // Obtain a lock on the handle and get an actual pointer so Windows won't move            // it around while we're futzing with it            pDevMode = GlobalLock(hDevMode);             // Load the saved DEVMODE that we dumped earlier            savedDevStream = new FileStream(DUMP_PATH, FileMode.Open, FileAccess.Read);            savedDevMode = new byte[savedDevStream.Length];            savedDevStream.Read(savedDevMode, 0, savedDevMode.Length);            savedDevStream.Close();            savedDevStream.Dispose();             // Overwrite our current DEVMODE in memory with the one we saved.            // They should be the same size since we haven't like upgraded the OS            // or anything.            for (int i = 0; i < savedDevMode.Length; ++i)            {                Marshal.WriteByte(pDevMode, i, savedDevMode[i]);            }             // We're done futzing            GlobalUnlock(hDevMode);             // Tell our printer settings to use the one we just overwrote            printerSettings.SetHdevmode(hDevMode);             // It's copied to our printer settings, so we can free the OS-level one            GlobalFree(hDevMode);             // Print and we're done!            renderedFlyer.Print();            renderedFlyer.Dispose();        }    }

Is it insane? Probably. But watching it duplex, fold, and staple automatically is great. I love it when something Simply Works!