[sane-devel] sane 1.0.31 backend version not supported lineart. Why?...
Ulf.Zibis at gmx.de
Sun Sep 27 10:49:50 BST 2020
I do not have any insight into the SANE architecture, but here are my thoughts for version 2 of SANE:
I like the idea of using a middleware.
Another approach could be to leave the lineart api at the backends, but replace the lineart emulation code in each backend by linking to a general library.
In both cases, additional parameters such as threshold could be helpful.
Some backends may have just copy/pasted the conversion code from each other and some may have there own code. so the general library should be parameterizable to emulate best the backends original behavior for maximum compatibility to the scan results, users are used to get.
So let SANE version 1 as is and maintain it in parallel. Bug fixes and new functionality state should be reflected in same minor version number, i.e. 1.0.31 should have the same functionality as 2.0.31.
Am 27.09.20 um 09:07 schrieb Olaf Meeuwissen:
> 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
>> 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
More information about the sane-devel