[PATCH 0/1] MR9673: dlls/sane.ds: Workaround for LineArt mode in some SANE backends

[Bernd Herd (＠herdsoft)]

If value for bytes_per_line is not reasonable in 1 bit per pixel mode, calculate a new value.

The sane backend for the HP Officejet Pro 8600 N911a printer/scanner is has the bug that it specified a wrong value for the number of bytes per scan line in lineart mode (1 bit per pixel). Debugging seems to indicate that the faulty value is coming from the firmware of that 11 years old printer/scanner device. Some Sane frontends ignore the bytes_per_line values. This who use it do not work with that device, notable when scanning with Libreoffice Writer. So the problem is obviously caused by the sane backend, not by the sane.ds code.

This merge requests offers a workaround by calculating a new value from the scan width in pixels if the given value is not plausible. This makes scanning in LineArt mode possible for that device.

It is unclear if any other devices are also effected.

It is unclear if the wine project wants to add workrounds like this to the code base, so I see it as a proposal for a discussion.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9673

[PATCH 1/1] dlls/sane.ds: Workaround for LineArt mode in some SANE backends

[Bernd Herd]

From: Bernd Herd <codeberg(a)herdsoft.com>

If value for bytes_per_line is not reasonable in 1 bit per pixel mode, calculate
a new value
---
 dlls/sane.ds/ds_image.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/dlls/sane.ds/ds_image.c b/dlls/sane.ds/ds_image.c
index b0288bd2520..f8dd0bf49db 100644
--- a/dlls/sane.ds/ds_image.c
+++ b/dlls/sane.ds/ds_image.c
@@ -143,6 +143,15 @@ TW_UINT16 SANE_Start(void)
           return TWRC_FAILURE;
       }
 
+      /* Workaround for some SANE backends that report a wrong value
+       * for bytes_per_line in LineArt mode */
+      if (activeDS.frame_params.depth == 1 &&
+          activeDS.frame_params.format == FMT_GRAY &&
+          activeDS.frame_params.bytes_per_line == activeDS.frame_params.pixels_per_line)
+      {
+          activeDS.frame_params.bytes_per_line = (activeDS.frame_params.pixels_per_line + 7) / 8;
+      }
+
       if (activeDS.progressWnd)
       {
           WCHAR szLocaleBuffer[4];
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/9673

[Esme Povirk (＠madewokherd)]

It sounds like the best place for this work-around would be the SANE backend for this device.

I think it's OK to have something like this in Wine, as long as it won't break when SANE is working correctly.

If there's a more robust way we can do this in general, without special logic for the broken case, that'd be preferred. Is there a way to safely calculate bytes_per_line instead of using the supplied value?

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9673#note_124731

[Esme Povirk (＠madewokherd)]

https://sane-project.gitlab.io/standard/api.html?highlight=sane_parameters#s... seems to indicate that we have to use bytes_per_line in general, because there may be padding. Which would mean frontends ignoring it are also broken according to this documentation.

Do the frontends ignoring bytes_per_pixel have other known problems that could relate to this? If not, that suggests to me that the work-around is probably safe, especially as restricted as it is.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9673#note_124732