Bug 6207 - Limited scanner redirection using local drives (Linux client)
: Limited scanner redirection using local drives (Linux client)
: ThinLinc
: trunk
: PC Unknown
: P2 Normal
: ProductCouncil
Assigned To:
: 6217 6218
  Show dependency treegraph
Reported: 2017-03-27 14:03 by
Modified: 2017-05-02 12:24 (History)



You need to log in before you can comment on or make changes to this bug.

Description From cendio 2017-03-27 14:03:40
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

* 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

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.
------- Comment #6 From cendio 2017-04-04 11:01:13 -------
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

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

* 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