Restrict print copies on a PDF
Solution 1:
Adobe use their Adobe Content Server to protect eBooks and PDFs along with Adobe Digital Editions (their free eBook and PDF reader) on the client side. This allows the distribution of PDFs with more flexible security options than the usual standalone PDF will allow. For example, documents can be time limited or allow only a certain number of pages to be printed.
This may well be a sledgehammer solution to your problem as I've no idea of Adobe's pricing for this product or whether is's practical for a small number of documents. It's used by the likes of the British Library (until recently anyway) for electronic inter-library loans which expire after 2 weeks and only allow the article to be printed once.
Solution 2:
Even if you can do this, you can't stop user from makeing screenshot and then printing an image or something like that. If user can see data, you can not stop him from makeing a copy, so my advice is "don't even try". Make a noticeable warning that pdf should be printed only once and leave it like that, because if user want's to print it two times he/she will find the way.
Solution 3:
I'd say this is not only impossible technically speaking, but also, impractical.
What's stopping the user from photocopying the document right after printing it ?
What is it that you're trying to accomplish by this, apart from gather a few novel suggestions ?
Solution 4:
If you can print once, you can print an infinite number of times.
Consider a network printer: the raw data to be printed has to be sent to a remote embedded device, which your program would have no way of restricting, even if it somehow assumed ownership of the user's entire machine (which would already be considered extremly offensive; see the Sony rootkit scandal for the kind of reaction to expect).
How could you tell the device the user's machine is talking to is a real HP LaserJet, instead of something which pretends to be one (or, even simpler, pretends to be a remote spooler), but which saves the raw PCL/PS/whatever instead of printing it? Since that data is all that is needed to print the job, one would just have to replay it several times to a real printer to get several copies. You could also use a sniffer (as @dlamblin mentioned) and save the trouble of emulating the printer.
You could think of forbidding network printers, but having only network printers in an office (not simple printers attached to a general-purpose PC, but large printers plugged directly into the Ethernet switch) is not that uncommon. Because of that, several of your users (how many would depend heavily on the target demographic) would not be able to print, which is not good PR.
And even USB is not immune (though it would need more technical knowledge and perhaps special hardware); there exist USB sniffers. And even without them, a usb printer "gadget driver" on an embedded Linux device could be enough (note, however, that as of this writing I know of no usb printer gadget driver for Linux).
This is all assuming the program has somehow managed to obtain complete control of the user's machine. As the several failed attempts at copy protection show, this is easier said than done. How can you know that the printer driver you are using is just an uncommon version of the printer driver for a popular brand of printers, and not a hacked version to save the stream to the disk? How can you know there is no driver somewhere in the printing stack logging all the USB transactions to disk? And how can you differentiate a normal user of virtual machines from someone using them to intercept the communication with the USB devices?
All that said, you do not need to go that far. Most people, even if they have the technical know-how, will not attempt to bypass even the weakest attempts at preventing duplicate printing you make. In fact, I would not be surprised if most users would voluntarily not print more than once if told the file must be printed only once (but then there would be more cases of people accidentally printing twice). So, make a simple program which prints once and then erases the original data. Warn the user that the data will be erased after being printed once. And accept that some people will print more times than you allowed, and that some people will print less times than you allowed (power glitches, defective printers, misconfigured systems, or the dreaded PC LOAD LETTER can all cause the printing to fail). Be prepared for that.
For people who print more times than allowed, just accept the losses, the same way a physical shop has to accept that a fraction of its stock will be accidentally damaged or lost in some way. Have some way of finding the biggest abusers and dealing with them (the legal system seems to be a popular choice).
For people who print less times than allowed, something like phone support where the user can request a new copy would be an option (it works for Microsoft, right?). Of course, some people will abuse this, but see the previous paragraph.
Solution 5:
I know that many event tickets delivered as PDF don't worry very much about this. Instead, they assert very strongly that the venue will be scanning the barcodes, and that only the first copy of a given ticket will be allowed through the door. They also have a tendency to print the purchaser's name on the ticket, making it possible to ask for ID at the door as well.
Fundamentally, I don't think it is possible to make a print-once PDF file. And even if it was, I'd suspect that the customer relations cost from print problems and bad word-of-mouth would cost more that its worth.
TurboTax (a US Federal and State income tax preparation tool for the non-US readers) tried something similar a couple of years ago. They decided that it must only be possible to install the program once with printing enabled, which was enforced by an activation code from their server. It turns out that a significant number of their customers were in the habit of doing taxes at home, but installing a temporary copy at their office to take advantage of the available office printers. There was also a loud complaint from people concerned that about being able to reinstall that year's software later to fix the return if an audit revealed an issue.
The complaints were loud enough that no subsequent version has had these restrictions.