<div dir="ltr"><div dir="ltr">Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 5:03 AM m. allan noah <<a href="mailto:kitno455@gmail.com">kitno455@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 24, 2020 at 6:04 AM Wolfram Sang <<a href="mailto:wsa@kernel.org" target="_blank">wsa@kernel.org</a>> wrote:<br>
><br>
> On Thu, Sep 24, 2020 at 11:59:39AM +0200, Ulf Zibis wrote:<br>
> ><br>
> Well, I assumed the answer is 'no'. If it was 'yes', then the proper<br>
> path would be to first code it, convert the users, and only finally<br>
> delete the now obsolete stuff, no?<br>
><br>
<br>
Agreed. Removing code that your users have come to rely on, without<br>
providing a replacement is bad form. In this case, this is a sort of<br>
expected feature for most scanners. I think it should not be provided<br>
by another layer, instead it could be a shared library that all<br>
backends can use. I wrote sanei_magic to provide software deskew and<br>
cropping algorithms to all backends, for just this reason. I've got a<br>
pretty good lineart function in the epjitsu backend, that I could move<br>
up to sanei_magic if other backends wanted to use it.<br>
<br></blockquote><div>My gut says that the backends should restrict themselves to providing functionality that the device can directly support.</div><div>In the pixma backend that I am working on now, conversion to lineart does introduce extra complications that cause bugs because it creates a discontinuity between what the scanner is being asked to scan and what the backend is delivering to the frontend. In conversation with Rolf, we did flirt with the idea of removing the Lineart conversion from the pixma backend for this reason. In the end, I'm putting in some work to try to fix it.<br></div><div><br></div><div>However, I guess I would make some observations:</div><div>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.</div><div>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.<br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Ralph<br></div><div><br></div><div><br></div></div></div>