That’s what I thought.
Yes. It may not be possible, but it seems like it should be possible.
Yes, that’s the easy part 
Do you mean it exists locally on the machine, or that Windows looks it up from an online database? I would guess the latter. In which case maybe I can do this in the background and parse the results. Mac also has something similar when adding a printer. But I don’t know if there are ways to do all that in code.
It should, but that probably requires going very deep close to the hardware, and there seems to be no information in Msdn about it for Windows.
No idea from where the data comes. When installing a new printer, for instance with Bonjour, you are presented with a list of manufacturer, and for each a list of printers. It does not seem to be possible to copy/paste, though.
Another way would be to get hold of a catalog of toner suppliers (I suspect you can find that on one of the gazillion toner web sites), where every printer in existence is listed.
[quote=237103:@Christian Schmitz]Maybe you check printer properties again.
A virtual printer may not have an IP, LPT or COM port or another location identifier.[/quote]
Well after all this, I think this must be the solution, but I am not using the right tool to find this information. The PRINTER_INFO_2 structure does not include it. It lists only a Port Name, but this doesn’t seem to help.
How exactly do I get these parameters?
Not practical. New printers are being added every day.
There is some way to do this…
A virtual printer exists only in software as a driver. A physical printer will have some other way to identify it, either as a device on the serial bus, or on the network. So in principle it should be possible to match a printer in a list to a physical device, whereas trying to do that for a virtual destination will fail.
The question is, exactly what information do I need to get, and how do I get it?
On OS X I’d try
Creative users will find a way around the restriction
And I would suspect that unless you can print directly to the printer with no other intermediary software like printer queues etc that people will figure out something similar on WIndows
Heck print one scan it back in as vector (which you can do fairly easily) and you’re off
[quote=237159:@Norman Palardy]On OS X I’d try
Creative users will find a way around the restriction[/quote]
Good point. But MBS does give me some control the print job, so I think I can stop users from doing that, or at least make it harder to do that.
This whole idea is more of a “security theatre”. I have to provide as much security as possible, inform users of the rules, and give the impression that breaking the rules is seriously wrong.
I’ve done this in VB6 but not Xojo about a decade ago.
On Windows, look at the port that the printer is attached to. If it is going to FILE: or /… then suppress it from the options.
[quote=237113:@Aaron Hunt]Thank you. On Mac, unless there are 3rd party “PDF Printers” that can be installed (I don’t know of any) then I have the problem solved on Mac.
I’m asking 2 questions really:
can a “PDF printer” be installed on Mac that will appear in the physical printer list? If so then I have the same problem on Mac that I have on Windows.
how can I filter out all non-physical printers on Windows?
Please read my original post as I tried to explain there what I need.[/quote]
Assume that there are;
I’ve been working with some of the printing API recently, and I don’t see any way how you can exclude a kind of printer.
You can however see what kind of print job it is, in the sense that the options are “Print”, “Fax”, “Preview”, “PDF”.
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPrintInfo_Class/#//apple_ref/occ/instp/NSPrintInfo/jobDisposition
However, I don’t think this information is valid until the actual print process has started, unless you want to force a PDF or something. You could check this and if it’s anything other then print then exit and they get a blank page, but it could be fooled if there was a fake printer that actually created PDFs, but reported that it printed to a physical printer.
Seems your weakness here is users printing to a piece of paper and scanning it back in and running OCR on it, as you have already noted. Printing directly to a PDF removes the scanning and OCR step, but almost every business class printer will scan, do OCR and creates a searchable PDF with the press of the SCAN button!
So, to make them have to use OCR. Why not just render the file as a bitmap before printing it. Even if it is intercepted by a PDF printer driver it is no better than a scanned image. I would even go so far as to render the bitmap with a watermark across it that makes OCR even more difficult.
Depending on your clients aversion to ‘weird stuff’ you could go one step further and use one of the many fonts designed to break OCR - http://technabob.com/blog/2013/06/25/anti-nsa-typeface/
also make sure you render in 72 dpi, to make OCR more difficult
You could include a small QRCode in the printed output. To ensure their continued access to their account, they must present the barcode to a camera after each print.
Hmmmmmmmm. There might be a way to put a poison pill in your output that would create a damaged or password-protected PDF if it were redirected to a file, but still print correctly. Let me think about that. It would only work against PDFs, though.
There are also business class printers with internal storage. It’s real easy to “Print” 1 copy, walk over to the printer, ask for 20 more copies. Then your database count is way off.
Are the documents PDFs? If yes, then maybe your protection can be built right into the PDFs. At least I have seen PDF documents that have a password, can’t be printed at all etc.
True, but PDF native encryption is weak, and can be broken by many free apps.
Without giving too much away here, the source documents are PDFs, but they are being encrypted as binary blobs and wrapped in another file type along with metadata and other things like image thumbnails. The files can’t be read by anything but this app, and beyond the wrapper which is easy to parse, the source data appears as indecipherable garbage in a hex editor.
The app extracts and decrypts the PDF data, so potentially it could also alter that data before sending it to the destination. The source files could themselves be encrypted using the standard PDF encryption methods before being “blob encrypted” as well. Even though PDF encryption is weak, I suppose we should use it since it’s one more thing to crack.
Yes, I know. Physical copying and scanning are possible, though obviously prohibited by the license. I can’t stop anyone from doing those things, but I want to at least prohibit saving the unencrypted source PDF as a file as best I can.
Brilliant idea! The QR code would be dynamically linked to each printing, I suppose by date, so they could not reuse a previously printed copy for verification.
QRCodes are easy enough, but I don’t know about implementing the camera.
[quote=237179:@David Andrews]Seems your weakness here is users printing to a piece of paper and scanning it back in and running OCR on it, as you have already noted. Printing directly to a PDF removes the scanning and OCR step, but almost every business class printer will scan, do OCR and creates a searchable PDF with the press of the SCAN button!
So, to make them have to use OCR. Why not just render the file as a bitmap before printing it. Even if it is intercepted by a PDF printer driver it is no better than a scanned image. I would even go so far as to render the bitmap with a watermark across it that makes OCR even more difficult.
Depending on your clients aversion to ‘weird stuff’ you could go one step further and use one of the many fonts designed to break OCR - http://technabob.com/blog/2013/06/25/anti-nsa-typeface/ [/quote]
Good suggestions, David. I didn’t know about the special anti-OCR fonts. Thank you!
Yes, this seems to be reasonable:
I wonder about false positives though.
I tried doing this but the print to PDF tools I’m looking at don’t show FILE as the output port… I think I’m still looking in the wrong place.