simple-scan-team team mailing list archive

[Michael Nagel <ubuntu@xxxxxxxxxxxxxxxxx>]

Title: Simple Scan Hardware Issues

Hi there,

why did you come here? Let us guess: you wanted to scan something and
„it just does not work“. You filed a Bug Report in Launchpad and someone
helpful sent you over here...

You want to get your scanner to work, or to get all features (such as an
automatic document feeder) to work. We want to improve Simple Scan and
make it an even greater application. Let me explain why your original
Bug Report does not help either of us and what you can do to get your
scanner to work:

Why does your original Bug Report not help us?
To understand why, you need to know something about Simple Scan: Simple Scan is a simple program -- that is what it makes so great -- that does not do the hard work itself. No, all the hard work is done by libsane, which is sometimes called sane-backends. 
Quote of the day: “If I have seen further it is by standing on the shoulders of giants.” (Famously used by Isaac Newton).
Whenever you use Simple Scan and instruct it to look for scanners, Simple Scan in turn instructs libsane to look for Scanners. Whenever you use Simple Scan and instruct it to scan a page, Simple Scan in turn instructs libsane to scan the page. So if something fails, there are two possible reasons:
a) the instructions sent by Simple Scan sent are incorrect
or 
b) the instructions are correct but libsane just messes up.
>From experience we know that b) is way more likely than a). Note: when we blame libsane we have to add that they are doing awesome work over there and they could (rightfully) blame the manufacturers for making their work excruciatingly difficult.

So, bottom line: this probably is not a problem with Simple Scan itself and Simple Scan and its developers cannot make your scanner work.
 HOWEVER -- we are nice people and really want to help you and support the developers of libsane. So read on...

Another famous saying: “Trust, but verify.” (Famously used by Ronald Reagan)
You should verify that what we told above is indeed correct. Luckily this is easy because the awesome developers of libsane also created xsane. xsane is an (a little bit) ugly and overloaded scanning program -- that is why we created Simple Scan -- but it is mighty powerful. And moreover, just as Simple Scan it uses libsane to do the hard work.
There are again two possible outcomes:
a) if everything works with xsane, the problem is within Simple Scan and we will look into it
or
b) if things are broken with xsane, the problem most certainly is in libsane
In either case: read on to find out what you can do!

What can you do to get your scanner working?
While we do not believe that Bug Reports saying no more than “ScanComp Scantist does not work” will lead to any improvement of the situation, we do believe this information is highly valuable. The information that a scanner does work -- and with what settings -- is even more useful. That is why there are “databases” collecting this information. They are located at https://wiki.ubuntu.com/HardwareSupportComponentsScanners and http://www.sane-project.org/sane-backends.html and store that information in a structured manner that is much more useful than a Launchpad Bug Report.

So, first of all:  check those databases for instructions on how to get your very scanner working. Often just one package has to be installed or one line in a configuration file has to be changed and you are good to go!
If your scanner is not listed, or the information is outdated or incorrect, please, please update it!

Then, there is a work-in-progress page
https://help.ubuntu.com/community/ScanningHowTo about scanning in
general, you might have a look at it, but last time we checked it was
not that comprehensive.

Also, if your scanner worked with previous Ubuntu releases and stopped working after an “upgrade”, that is a pretty bad and should not happen. From a developers point of view this is a clear regression in sane-backends and friends, but from a users point of view, you should reconsider sticking with the old release because we feel obliged to tell you that it might take a long time until it gets fixed!
 Also see the next section about filing bugs against sane-backends.

If your scanner is listed as “not working” there and you cannot program and/or cannot devote some time/effort/money into the issue, our sad-but-honest advice is to accept that it does not work and/or buy another scanner that is known to work.
Pick a scanner that is explicitly listed and maybe pick a scanner from some manufacturer where most of the scanners work and not just a few.

If you kept reading up until here you obviously are serious about investing some time/effort in the issue!
Great! Here are some more things that you can do, that cost time/effort but greatly increase your chances of getting your scanner to actually scan:

If your scanner does not work with xsane:
Report a bug against sane-backends in Launchpad. Be sure to include all relevant information (make model, detailed explanation of the situation) and be prepared for further inquiry. The questions will be fairly technical and require to do time-consuming things that generally require some patience and skill.
And then it will only result in your problem being presented to the SANE developers. They have a fairly active mailing list sane-devel at http://www.sane-project.org/mailing-lists.html but have a look at  http://lists.alioth.debian.org/pipermail/sane-devel/2011-November/029183.html to get an impression what they are talking about! We do not want you to stop from creating a Bug Report, but you should know what awaits you and decide if you are prepared for that. Otherwise you will be wasting your time, and other people's time who could otherwise be working on making your scanner work!

If your scanner works with xsane:
Wow! But we believe you! It might really be that Simple Scan sends stupid instructions to your scanner. In that case:
Please report a Bug Report against Simple Scan!
Here is a tutorial on how to make your Bug Report the best Simple Scan Bug Report ever:

1)If you use Ubuntu, run “ubuntu-bug simple-scan” from command line to get a big head start. If you use another distribution skip this step and start with 2)
2)If it is in any way related to the user interface (the user interface is what you see on your screen) include a screen-shot. It takes 10 seconds to create a screen-shot and might save us hours of trying to understand. One hour is 3600 seconds, so 359 useless screen-shot still pay out.
3)If your scanner scans something at all (but e.g. suffers from line creep) include an example scan. Same argument as in 2) applies here.
4)ALWAYS explicitly mention the full make and model of your scanner, e.g. “HP Deskjet F4580”
5)ALWAYS provide the id, that might be determined by running lsusb and pasting the corresponding line, that might look like “Bus 001 Device 004: ID 062a:900d Creative Labs”. Adapt for SCSI scanners.
6)Include a statement of the following: “I have a good faith belief that this is a bug in Simple Scan and not in sane-backends because I actually tried with xsane and it worked there.” Info: this is not really a requirement, but you get the idea. You really should check if it is a bug in sane-backends before filing the Bug Report. And while Simple Scan aims to be an improvement over xsane, regarding hardware support it is to be considered gold standard and we are not going to investigate cases where xsane fails. This of course is not true for usability issues/the user interface/etc but only for hardware support.

Thanks for using Simple Scan!
Thanks for reading this wall of text!
We really hope this helped you scanning your documents!
You are very welcome to help us improve Simple Scan!
See https://launchpad.net/simple-scan for more information, like mailing lists or IRC.

tl;dr (too long -- did not read):
check https://wiki.ubuntu.com/HardwareSupportComponentsScanners and http://www.sane-project.org/sane-backends.html

-- 
You received this bug notification because you are a member of Simple
Scan Development Team, which is the registrant for Simple Scan.
https://bugs.launchpad.net/bugs/896729

Title:
  Problem Management

Status in Simple Scan:
  In Progress

Bug description:
  Lacking any other discussion platform this bug report shall be used to
  discuss how problems/incidents/bugs/issues/tickets should be managed
  for the Simple Scan project.

  With the current situation I see two major problems:
  1) lack of manpower to fix the problems -- beyond the scope of this discussion, although all & any support is highly appreciated!
  2) unclear organisation of bug reports -- *this shall be discussed here*

  a) lots of duplicate bugs not merged -- I am working on this. I tend
  to rather merge bug reports too aggressively than too careful, because
  right now, Simple Scan suffers more from scattered information that
  from bugs that "slip through" because of incorrect merging with a
  (only seemingly) related bug.

  b) lots of bugs lacking important information -- I am working on this.
  I go through bugs and try to improve them, especially by reproducing
  them and/or getting additional information from the original reporter.
  If this information cannot be provided, I advocate to close these
  bugs. "Bad bugs" take away manpower from good bugs, and there is not
  nearly enough manpower. This does not mean I want to dismiss all
  feature requests or stop accepting bug reports from users knowing less
  about the inner workings of Simple Scan. However it does mean that
  some bugs should be rejected for lack of quality.

  c) "my scanner does not work" bug reports -- In my opinion we should
  not accept such bugs if it is not proven by the bug reporter that the
  problem is not with SANE and/or his/her scanner driver. We should
  provide them with some helpful explanation why Simple Scan probably is
  not to blame, and where they can more realistically get help. Just
  letting the bug report rot does not help anybody (the reporter does
  not learn anything, and our list gets clogged); it is better to tell
  the hard but honest truth -- that we cannot help them, that if it
  worked in the past, the safest bet is not to upgrade all six month but
  to use a LTS release, that if they try for the first time that there
  is a chance they can get it to work with another driver, but the SANE
  people are a better contact than we are, and that if they really need
  a working scanner they should buy one from a list of devices that are
  known to work. That may sound harsh, but we should work on a text that
  does not sound harsh or bitter, then most of the people are thankful
  for a honest and timely reply.

  d) too similar feature request -- while for (well described, see b))
  defects I think there should be one bug report per problem to keep
  track of the debugging progress/process, I think for (vague) feature
  requests it is better to have one ticket about "area 51 needs to be
  improved" and then some ideas like "build a road, plant a tree, and
  fix the drain" instead of three tickets "build a road in area 51",
  "plant a tree in area 51", ... because anyone working on area 51 will
  see the ticket and after he finished his work, the situation will have
  changed and the other bugs are probably obsolete. Also this will
  increase signal-to-noise ratio for the remaining bug reports.

  e) Simple Scan upstream vs. simple-scan Ubuntu package -- in my
  opinion we make our lives harder by following a process that is
  designed for big packages like e.g. LibreOffice, where upstream
  development and packaging are somewhat different tasks, involve
  different people, where there are different versions of the software
  that are actively maintained... by tracking some bugs upstream, some
  in the package, some in both places, ... we increase the noise, lists
  become less clear, we get distracted PLUS we need to do the work to
  correctly track the flow of the fixes back into the packaged versions.
  I suggest all bugs should be forwarded to the upstream project,
  because we can be happy if the bugs are fixed there at all. Right now
  not even this is guaranteed. Only if this works "too good" we should
  care to incorporate these fixes into the existing packaged releases
  and keep track of what patch went into what release already. We can
  keep the bug tracker for the package for everything concerning the
  packaging and Ubuntu integration and as a first point of contact for
  users filing bugs (via apport) and the "c)" type of bugs. When
  forwarding bug reports to the upstream project, I don't think we
  should files it as "also affects" and then wait until it is fixed
  there, and then later when the release with the fix hits Ubuntu set it
  to "Fix Released" but just set the project to simple-scan, stop
  duplication and save us some work. I am willing to accept another (the
  "official") workflow here, too, but I think it is counter-productive.

  Any comments regarding this nice wall of text?

To manage notifications about this bug go to:
https://bugs.launchpad.net/simple-scan/+bug/896729/+subscriptions