[sane-devel] SANE 1.1.0 Release discussion

[René Rebe]

Hi Allan,

can you explain the paper width option to me? Why can we
not simply use br x/y?

Actually I got a Fujitsu scanner here and find the duplicate
paper width option annoying at best.

Aside the already mentioned button to use some more extend-able
XML encoding instead of a hardcoded set, I wonder if it is
good to expose sensors, frontends would rarely (if ever?) want
to check for them explicitly and the backend must check the
sensors before or during scan to generate proper errors
accordingly anyway.

Yours,

m. allan noah wrote:
> ok guys- take 3:
> 
> Six general points for sane 1.1.x:
>  - no changes to function calls
>  - no changes to structures
>  - 1.0 backends forward compatible with 1.1
>  - improve backend consistency
>  - support more advanced scanners
>  - improve cooperation with modern system services
> 
> Specific proposals:
> 
> 1. Consistent, translatable option groups:
> 
> 'Standard' = source, mode, resolution
> 'Geometry' = x/y and paper size params
> 'Enhancement' = bright/gamma/contrast/thresh, rif, halftone, etc
> 'Advanced' = compression, calibration, feed controls, etc
> 'Sensors' = an option for every hardware button or sensor
> 
> 2. Two new well-known options for ADF paper alignment: page-width and
> page-height
> 
> 3. Two new SANE_STATUS values: HW_LOCKED and WARMING_UP
> 
> 4. Nine new SANE_FRAME values: TEXT, JPEG, G31D, G32D, G42D, IR, RGBI,
> GRAYI, and XML
> 
> 5. Several new well-known options for buttons and sensors. Backends
> should use the closest one to the meaning of the label on the scanner
> or the button's use in the manufacturer's software. Backends may also
> use a different name if no suitable one is found, or button1, etc for
> unlabeled buttons
> 
> well-known buttons:
> scan, email, fax, copy, pdf, cancel
> 
> well-known sensors:
> page-loaded, cover-open
> 
> 6. Clarify standard text for SANE_CAP_HARD_SELECT to indicate it
> should be used for polling the current state of hardware sensors and
> buttons, with a refresh interval <= 1 sec.
> 
> 7. New DBGBM macro for bitmask debugging output (bit # listed below):
> 
> 1 DBG_LVL_ERROR      (errors only)
> 2 DBG_LVL_FUNC       (function tracing 'enter xxx()' or 'exit xxx()')
> 3 DBG_LVL_DETAIL     ('trying action X' or 'action succeeded' etc)
> 4 DBG_LVL_OPTION     (any sane_option parsing code)
> 5 DBG_LVL_CALIB      (calibration info)
> 6 DBG_LVL_IMAGE      (dump image data read from scanner)
> 7 DBG_LVL_DATA       (dump data packets read from scanner, other than
> image or cal?)
> 8 DBG_LVL_FILE       (write internal data files to disk from within backend?)
> 
> 8. Add common configuration reading function in sanei_* so that new or
> maintained backends can benefit from it. Wholesale config file restructuring?
> 
> 9. Require backends to always accept the sanei device name as an
> alternative to the backend generated name.
> 
> The first 5 are already in SANE CVS, and the fujitsu backend is
> updated to use them. I'd like to get some more comment on the rest
> before we more forward. Particularly on #8, if your backend uses a
> complex config file format, we need to hear from you...
> 
> Timetable is still feature freeze around July 4th, and release close
> to July 30th.
> 
> Comments welcome-
> 
> allan



-- 
   René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   Geschäftsführer: Susanne Klaus, René Rebe
   Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
   USt-IdNr.: DE251602478
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name