Version 9.75 of the Black Ice printer drivers introduces new Plug-In support which is accessed through a dynamic linked library or DLL, and is loaded by the printer driver during printing. The printer driver calls pre-defined functions from the Plug-in at each phase of printing, and will not continue printing until the function returns.  Developers will have full access to the DLL they can also insert their own custom code to each DLL function to perform a variety of tasks as required by their application.

 

 

How It Works

The Black Ice printer driver will load the Plug-In DLL with each print job and will pass to each DLL function a pointer to the devmode of the current print job. When the print job starts, at the Start Document phase, the Plug-In DLL can pass custom data to the printer driver. The custom data will be stored by the driver for the duration of the print job. The size of the custom data is not limited by the printer driver, however using a large data block is not recommended since the printing can be negatively impacted.  Specifying a data block of no larger than 10-20 KB should be sufficient in most cases and will not have an impact on

performance. The printer driver will return a pointer to the custom data in each additional function call to the Plug-in DLL. The Plug-in DLL can then modify or use the custom data in any way desired.

The Plug-in DLL functions must return TRUE on success or FALSE on any failure. If any of the custom functions return FALSE, the Black Ice Printer driver will abort the current print job.

 

Add a Custom Plug-in to the Black Ice Printer Drivers!
Text Box: Page # Text Box: Developer Text Box: Image File Directory there is offset for the image which is pointing to the beginning of the file. It looks a little backward, but there is a reason to it. TIFF File format originated in the mid 1980s when memory was very limited. The image was decompressed and compressed from the video buffer. An image was segmented and cut up to strips. Each strip contained 32k or 64k of data and each strip’s offset and length was written into the IFD. As the image was compressed one did not know in advance how big the compressed image data would be. Therefore one could not fill out the IFD tags until the entire image strips were written to the file. Once the image is written to the file then one can write the IFD tags. To make it Text Box: more complicated each strip in the image header is an entry, so one could not compute how big the IFD would be in advance. Therefore it makes sense to write the image data first, and then write the IFD tags. The TIFF specification allows both approaches. The conventional tiff file structure was Text Box: dictated by necessity at the time. The Cisco approach is more convenient in an IP application to process the data stream. One can start to decompress the image before the entire image is received since the header information is in front of the image.