[sane-devel] sane 1.0.31 backend version not supported lineart. Why?...

[Olaf Meeuwissen]

Hi,

Ralph Little writes:

> Hi,
>
> On Thu, Sep 24, 2020 at 5:03 AM m. allan noah <kitno455 at gmail.com> wrote:
>
>> On Thu, Sep 24, 2020 at 6:04 AM Wolfram Sang <wsa at kernel.org> wrote:
>> >
>> > On Thu, Sep 24, 2020 at 11:59:39AM +0200, Ulf Zibis wrote:
>> > >
>> > Well, I assumed the answer is 'no'. If it was 'yes', then the proper
>> > path would be to first code it, convert the users, and only finally
>> > delete the now obsolete stuff, no?
>>
>> Agreed. Removing code that your users have come to rely on, without
>> providing a replacement is bad form. In this case, this is a sort of
>> expected feature for most scanners. I think it should not be provided
>> by another layer, instead it could be a shared library that all
>> backends can use. I wrote sanei_magic to provide software deskew and
>> cropping algorithms to all backends, for just this reason. I've got a
>> pretty good lineart function in the epjitsu backend, that I could move
>> up to sanei_magic if other backends wanted to use it.
>
> My gut says that the backends should restrict themselves to providing
> functionality that the device can directly support.

Same here.  Let the backend focus on getting images from the scanner
that are as close as possible given the device's protocol constraints
and limitations.  It can be hard enough already to get that working
reliably according to the SANE API specification without having to deal
with all kinds of software emulation.  Software emulation can be added
on top of that via middleware (SANE calls this a virtual backend).  One
place that might be suitable is the dll backend, however, things may be
difficult to get right due to the fact that backends have so much leeway
in naming their options.

# Even the additional well-known options in the comatose version 2 draft
# of the SANE Standard don't cut it.

> [...]
>
> However, I guess I would make some observations:
> 1) We could push the lineart conversion out of the backend, but there is no
> middleware in which to implement it. The frontend would have to offer that
> or leave it to the user to add it to their workflow outside of the scan
> operation.
> 2) If we remove it from a backend, then users consider that a regression,
> and that's fair. So I think that we are stuck with it.
> 3) I really dig the idea of having a sanei library of common operations. We
> do have some copy/pasted conversions sprayed around the backends and it
> would be great to get that code extracted out into something common, thus
> reducing the code footprint of the backend. As ever, regression testing is
> the issue for backends that are not well supported/maintained.

# Radical idea: leave unmaintained backends just that, unmaintained.  We
# might even disable their build by default so they stop holding hostage
# any of the progress we might consider if it weren't for mortal fear of
# introducing regressions.
#
# In terms of semantic versioning, we could split off a 1.x branch where
# all the unmaintained backends remain and remove them from master for a
# sane-backends-2.0.0.  Note, the version here is for the source tarball
# and has *nothing* to do with SANE backend API versions and even less
# with the SANE Standard version.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join