Print Distributor - Load Balancing
The load balancing feature in Print Distributor seems to create a lot of questions so I thought I would try and explain what it does and does not do in a little more detail.
Load balancing lets you create a pool of printers and spread the print load across the pool automatically.
Printers are selected from the pool sequentially, so the first print goes to the first printer, the next print to the second printer and so on. When every printer has been used it starts back at the first printer again.
You can temporarily remove a printer from the pool by pausing it in Windows, Print Distributor checks the status of each printer before it prints and shrinks the pool accordingly.
Print Distributor will also remove a printer from the pool if it detects it is unavailable. It does this by looking for a print at the front of the queue with an error status or by asking Windows if the printer is available.
Unfortunately Windows can't always tell whether the printer is available, this is dependent on the printer manufacturers software as well as the type of connection. You can check whether your printer reports this by taking your printer off line and looking at the status in the Printers folder in Windows.
If your printers are connected using the standard Windows TCP/IP port then you can often improve the status feedback by enabling SNMP in the port configuration.
I do get asked if it is possible to ping the printer before printing, although we could do this it wouldn't provide useful feedback in most cases. Any USB attached printers aren't pingable and if the printer is on another server it is out of reach. Even if it is available a ping won't tell you if the printer is out of toner or has a fault.
If none of the printers are available in the pool then Print Distributor will spread the load across the whole pool, Windows will queue the prints until the printers are available again.
All jobs are handled individually, they do not get split, so if you print ten copies of a 100 page document then all one thousand pages will go to the next available printer.
The last printer used in the pool is available in the LastPrinter variable in the script action, you could copy this into the PrinterName variable and use the ?PN? field in any other action if you need it.
Creating a null printer in Windows
I get quite a lot of requests for support on how to set-up Print Distributor to create a null printer that discards any documents. It seems there are applications which produce regular unwanted reports that can't be turned off.
Actually you don't need Print Distributor to do this, everything is already available in Windows.
Start by opening the Printers folder and launch the add printer wizard.
Choose a local printer and create a new port selecting local port for the type.
Enter NUL: for the port name and then select a driver, any one will do although I tend to select the HP LaserJet 5.
Name your printer and finish the wizard, now anything you print to this printer will just disappear.
First screen cast
I've been playing with Camtasia from TechSmith for the last couple of days trying to produce a reasonable screen cast of a new feature in Print Distributor.
Print Distributor Accumulate Action
I am happy with the result although it took a lot longer than I expected.
The trouble with C++
I have been using C++ for quite a few years now, both Mail Print and Print Distributor are written in it and I consider myself reasonable competent with it.
However I loathe it deeply. It really is a complete mess, there are so many gotcha's and even the simplest of tasks can run to dozens of lines of code. Take a look at stackoverflow.com/questions/536148/c-string-parsing-python-style for example. The C++ code presented is appropriate but virtually unreadable at a quick glance. On the other hand the Python code is simple and easily read.
Product Road Maps
Why I don't publish product road maps
I have rough maps of where my development effort is going to go on both Mail Print and Print Distributor so why don't I make them public? I certainly get enough requests for new features, many of the requests are followed by demands for when they will be implemented.
The problem is development is pretty unpredictable, especially if you are working in area you are unfamiliar with. Setting an expectation that a new feature will be available in March then not delivering until November isn't going to win you many friends. Promising a feature then cancelling it is even worse.
There is also the problem of letting your competitors know what you are planning, there are a few products which are obviously inspired by my software. The problem these people have, is they are always a step behind, this is where I want them to be.
So my response to questions about future features and roadmaps is please buy the product on its current capabilities, if it doesn't do what you want then look elsewhere. If you have bought and aren't satisfied then let me know and I will refund your order.