I hope it's about scanning on the client side.
Sorry for not giving you a real solution; this is a difficult problem, mostly because of transitional state of affairs in Web standardization; I would say, we are not there yet.
I hoped we can be covered by the W3 standard HTML Media Capture (at this moment, candidate recommendations of September 2014):
HTML Media Capture[
^].
Well, not so fast. Even though the major browsers often implement HTML5 features well before the official standard is accepted, don't hold your breath. I've found a good overview of the problem in this Stackoverflow answer:
Can HTML5 communicate with peripherals like scanners and credit card readers? — Stack Overflow[
^].
Another article explains the approach based on WebRTC:
https://hacks.mozilla.org/2013/02/cross-browser-camera-capture-with-getusermediawebrtc[
^];
see also:
WebRTC — Wikipedia, the free encyclopedia[
^],
WebRTC Home | WebRTC[
^].
From the other hand, long time ago, I faced Web sites performing scanning on the client site just by using the scanner installed on the client system. How was it possible? My guess is:
in some dirty way. Oh yes, there are dirty ways, such as ActiveX used in a browser (so it may work only on limited set of platforms and browsers), but this is something I don't even want to discuss. I denied to scan my sensitive documents through the service offered, because such things are considered
utterly unsafe, for some very good reasons, so your security-savvy customer will also deny using such possibility or may even blacklist your site if they find out that you are using such dirty tricks. Perhaps less dangerous approach would be having some browser plug-in which could be installed on the explicit customer's permission, but 1) it can be only specific to a certain browser and platform; 2) it's not too much different from letting the user to scan documents if a file and uploading the file.
Conclusions?
Sure. If you really need to support scanning, I think at this moment the best option would be to leave this job to the user. A person who has a scanner connected to her/his computer or LAN usually knows how to use it. And it has a lot of benefits over scanning from a browser. First of all, the user has more control. This person can scan document today and send it tomorrow. The file created is not a hassle, it's a good feature; it can be saved for user's records, and so on. Finally, the file can be properly converted and processed to the user's liking (cropped, rotated, normalized…). But what I consider as a benefit some may consider as a problem. Let's discuss that…
Some think that forcing the customer to scan a document in a browser would prevent document forging, would ensure authentic copy of a paper. I am not saying that you are one of people thinking this way, so please don't get offended by what I want to say next:
this is one of the most naive delusions. In fact, most people won't even try to forge anything, even if they have an image file to upload. But those who want to create a fake document
could forge it in no time even if you force in-browser scanning. And this is fairly easy. For example, a simulation scanner driver can be created; it would "scan" not physically, but would feed existing (forged or not) picture.
So, I gave you strong arguments to throw out the idea of in-browser scanning and just let people to upload images.
—SA
Submit an article or tip