[sane-devel] Plustek OpticPro A320E (07b3:1826): fourth version, and three wrong statements in sane-genesys.man

[Tero Kankaanperä]

Hello list, and thank you Thierry for the encouragement.

THE MERGE REQUEST QUESTION

Thierry asked why I do not propose this for integration into sane/backends.
The honest answer is about me rather than about the code: I offered this 
as a
one-time contribution and I am not in a position to carry review rounds 
or to
maintain the driver afterwards. Opening a merge request would promise
something I cannot keep.

What I can do is leave it in a state where anyone who wants it upstream does
not have to redo the work. As of today the patch:

   - applies cleanly to master 1db1e33a (10 September)
   - builds the genesys backend with no warnings at all, including under
     -Wall -Wextra -pedantic
   - passes make check, and adds unit tests of its own
   - keeps every change to shared code behind a ModelId check; the single
     exception is a documentation fix, and it is the next section of 
this email
   - carries the licence statement Ralph asked for earlier, in the README

So the merge request is a small piece of work for anyone who has an account
and the inclination, and I will be glad if someone opens one. If
somebody with a stake in it would rather I did it myself, say so and I will
reconsider.

THREE WRONG STATEMENTS IN doc/sane-genesys.man - THESE AFFECT EVERY 
GENESYS DEVICE

While checking my own claims about lineart I found that the backend's 
man page
describes a mode the backend does not offer:

   - "--disable-dynamic-lineart yes|no" - this option does not exist. A grep
     over backend/ finds no trace of it.
   - "When using gray or lineart this option selects the used color"
     (--color-filter) - lineart cannot be selected.
   - "Hardware lineart is limited up to 600 dpi for gl847 based scanners" -
     lineart is not offered on any model; it is commented out of 
mode_list in
     genesys.cpp, together with the halftone entries.

One sentence in LIMITATIONS has also lost the word "lineart" at some 
point and
now reads "Dynamic (emulated from gray data and with dithering) isn't 
enabled
for gl646 scanners", so somebody started this cleanup and left it 
unfinished.

My patch removes the three statements and says instead that the backend 
offers
colour and gray only. That is a documentation change and touches no 
code, but
it is the one thing in the patch that is not limited to my scanner, so I am
reporting it here rather than quietly shipping it. If you would rather 
have it
as a separate one-file patch, it is trivial to split out.

FOURTH VERSION PUBLISHED

   https://terokankaanpera.fi/a320e/

Since the 3 September package:

   - A printed original no longer clips. The white scale was set against the
     internal white strip of other models; this scanner has none, and its
     calibration target measures 3-5 % darker than the brightest part of 
a real
     original. Scale 1.40 clipped 6.1 / 9.4 / 16.3 % of the channels on a
     printed page; at 1.30 it clips 0.000 %, verified twice.
   - The driver no longer reads anything from the environment. All fifteen
     A320E_* variables are gone, each fixed at the value its runs 
measured, or
     the feature deleted where the experiment was negative.
   - The scanner is now in doc/descriptions/genesys.desc and in the man 
page,
     with the two origin-offset options documented.
   - Five unit tests in the genesys testsuite cover the pure functions this
     patch adds, and genesys_session_config_tests walks this scanner's 
twelve
     combinations without a device.

Patch: 21 files, +3474 / -37 as git apply --stat counts it, against master
fcaa30a7.

This is where the published driver is finished. It does what I set out 
to make
it do, and I do not plan further versions of the package. I am still working
on my own copy, on things this backend does not offer - 16-bit output 
with ICC
handling, lineart, and the front-panel buttons - and those are described 
in the
README's limitations rather than shipped.

The version-by-version account, including what was deliberately not changed
and why, is in changes.md at the same URL.

Still open from my message of 3 September: three observations about the 
gl124
branch itself (FASTFED never set, HOME_TABLE never uploaded, FASTNO/FSHDEC
tied to the fast table). They need someone with a LiDE 110/120/210/220 
to say
whether they matter; I have only this one scanner.

-- 
---
Tero Kankaanperä
https://terokankaanpera.fi