Support for local scanners has been discussed mainly on bug 1892. We believe that the best way of implementing this is by supporting a libusb based USB redirection. Until that is in place, a limited solution can be implemented where the scanning is done locally and the resulting file is made available via local drives redirection. This was implemented on TLCOS on bug 3526, but TLCOS is no longer available, and customers are requesting this functionality on other client platforms. Pieces of this functionality has been left as a hidden feature: You can still enable the F8 option by creating a file "lib/tlclient/local-scan". However, in practice, using this hidden feature is difficult: * You must manually create a temporary directory for the scans and export it, then create a "local-scan" script that uses this directory. * Typically, you want to remove the scans when the session ends, but there are no hooks for doing that. * We are requiring that the client platform not only provides the SANE API, but also some command line utility (such as "scanimage") which can be called from local-scan. Terminals such as the IGEL LX10 actually has "libsane", thus provides the SANE API, but does not have any scanning tools. A better solution is to only require the "libsane" and not any tools. This way, we would be operating at the library level, just like we do with PC/SC, Sound etc In practice, the easiest way is to include "scanimage" (from sane-backends) in the ThinLinc Client. This bug only covers Linux clients (thus SANE platforms), but the general principle of doing scans locally can be used with other platforms as well, such as Windows and macOS.
Wrt functionality and requirements: Since the scanning is done on the client side, all settings must be done here. Let's define these levels: 1) Settings are always fixed (hardcoded) and cannot be changed 2) Settings can be changed through tlclient.conf (typically by the administrator) 3) Settings can be changed from the tlclient GUI (before the session starts) 4) Settings can be changed during the session and/or at each scan One problem is that even if we go for 3) or 4), the GUI will be different from what the user is used to (compared to scanning via xsane, GIMP, Photoshop etc). On the other hand, hardcoded settings which cannot be changed even by the administrator is likely too restricted, since it may be necessary to adopt to hardware and software limits (network, scanners, types of applications etc). This means that level 2) could be a reasonable compromise. For some use cases, being able to directly control scan settings on every scan is a must, so obviously this solution will not solve everything. That's why we still have bug 310. But are there use cases where it is sufficient to scan with fixed settings? I believe so, and here are some arguments: * We've had two customers using this approach with TLCOS * I have some personal experience with scanning through a multifunction printer with fixed settings, and I've used this solution for several years, with good results * Many scanners nowadays comes with "quick buttons", which allows you to perform a scan with a single button, ie not alter any settings. This corresponds to our popup menu command "Start Image scan" * It is also common to scan on multifunction printers, and then email the result. In this case, you typically have access to a very limited set of settings. For example, on our HP printer, you can only select File Type, Resolution, Paper Size and Gray/Color. We have discussed if it is better to call this feature "document scanning" or similar, instead of "image scanning". I've rejected this idea, because: * "Image" is a more generic term (https://en.wikipedia.org/wiki/Image_scanner). If we were to say "Document scanning", users might ask if/why they cannot scan photos, which they in fact can. * In many cases, document scanning have higher requirements that image or photo scanning. For example, our HP MFP says "Photo - 150 dpi" and "Text - 300 dpi". * "Document scanning" might also imply PDF output, which is less general more difficult to implement
We don't do limited.
