Specifying a gamma value for acquired scan data would greatly add to usability as well.
—Jürgen > Am 12.10.2020 um 20:00 schrieb Ralph Little <[email protected]>: > > Hi, > > On 2020-10-12 2:06 a.m., Olaf Meeuwissen wrote: >> Hi Ralph, >> >> Ralph Little writes: >> >>> I would be interested to participate. >> You're welcome but I'm not sure how we want to go about things. A lot >> has changed since the bulk of that version 2 draft was written. From >> what I've seen of the changes (during the conversion from LaTeX to >> Sphinx), they look sensible but I feel there is a lot more that ought >> to be updated for the 2000-twenties. >> > My main motivation is related to my experience in using a few different > devices now and some common usability themes have emerged for me: > > 1) Often scanners spend a lot of time in calibration and it isn't always > that obvious mechanically or audibly that that is what is going on. It > would be cool if a frontend could emit some kind of status update to > reassure the user that something is actually going on. We don't have > anything in the current spec to support that. > > 2) Backends have different ideas about what is "advanced" and what is > basic which just looks a bit messy. It would be good to establish some > guidelines on some of the more common options. I'm thinking the x/y, w/h > type options primarily. > > 3) We talked a bit ago about polling options and it would be good to get > something more formal to deal with this. Just as a reminder, there was a > machine with a "copy count" display indicator that the user could > increment/decrement with buttons next to the display. We can now display > the content of that window but since the value of this is "volatile" and > could be conceptually linked to the scan count in the frontend (e.g. > xsane), there is no way to indicate that the frontend should regularly > poll for the value. Obviously there are frontend issues regarding the > conceptual linkage and there was some concern about idly polling over > the network as a form of DDOS attack, but I think that some thought > might be put into a backend solution to support that capability. > > There are probably some other things that are not coming immediately to > mind. > > I actually really love the simplicity of the current API and I would > hate to complicate things much if at all. I also appreciate that > whatever happens, the NET protocol has to support it. > > As regards the issue of backwards compatibility, that is a serious > concern since many of the machines cannot be easily regression tested. > However, if we could expand the scope of the number of officially > recognised "options", then that might work for much of what I have > listed above. > > Cheers, > Ralph > >
