[sane-devel] Pixma future

[Olaf Meeuwissen]

Hi Allan,

m. allan noah writes:

> On Wed, Nov 25, 2020 at 2:01 AM Alexander Pevzner <pzz at apevzner.com> wrote:
>>
>> Obviously, this is better not to implement emulation of missed (in
>> hardware) features in the drivers, to avoid code duplication and having
>> an assortment of independent, often incompatible implementations of the
>> similar features.
>>
>
> Nonsense. You can have every driver implement a consistent level of
> features, and only have a single implementation of emulated functions.
> You just need a library

At which point the driver does *not* implement it anymore.  It just
outsources to an already existing implementation ;-P

> like sanei_magic, which is already used by a number of existing
> backends to provide software deskew and autocrop functions. It would
> be pretty easy to do something similar for binarization.

The problem that I perceive is that there is no "well-known" agreed upon
library for these kind of image data manipulations.  It just seems that
every backend does its own thing.  When I was working on utsushi[1] at
the office, I pretty much outsourced all of the image processing to one
of ImageMagick or GraphicsMagick.  Your sanei_magic rolls its own.

 [1]: https://gitlab.com/utsushi/utsushi

An additional issue is whether the backend or the frontend should handle
the image processing.  You most definitely do not want to do it twice.
I remember horror stories with stacked CUPS filters rotating pages or
doing n-ups repeatedly.  In a bad case you could end up with a total
rotation being a multiple of 360 degrees, for a net no rotation, and
compounding 2-ups so you'd get 16 pages to a sheet :-o

Whatever component gets to deal with part of the processing should be
able to communicate what parts have been taken care of.

If you favour frontends taking care of this, it'd be natural to call it
middleware.  For backends, calling it a library may make more sense but
there is no functional difference, really.

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