summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/.gitignore13
-rw-r--r--doc/Makefile.am101
-rw-r--r--doc/backend-writing.txt3
-rw-r--r--doc/descriptions-external/epkowa.desc26
-rw-r--r--doc/descriptions-external/utsushi.desc46
-rw-r--r--doc/descriptions/avision.desc6
-rw-r--r--doc/descriptions/canon_dr.desc9
-rw-r--r--doc/descriptions/canon_lide70.desc29
-rw-r--r--doc/descriptions/escl.desc109
-rw-r--r--doc/descriptions/fujitsu.desc16
-rw-r--r--doc/descriptions/genesys.desc87
-rw-r--r--doc/descriptions/pixma.desc58
-rw-r--r--doc/descriptions/snapscan.desc17
-rw-r--r--doc/descriptions/unsupported.desc23
-rw-r--r--doc/descriptions/xerox_mfp.desc11
-rw-r--r--doc/figs/area.fig36
-rw-r--r--doc/figs/flow.fig40
-rw-r--r--doc/figs/hierarchy.fig79
-rw-r--r--doc/figs/image-data.fig63
-rw-r--r--doc/figs/xfer.fig32
-rw-r--r--doc/icons/contents.gifbin225 -> 0 bytes
-rw-r--r--doc/icons/index.gifbin180 -> 0 bytes
-rw-r--r--doc/icons/next.gifbin172 -> 0 bytes
-rw-r--r--doc/icons/next_gr.gifbin172 -> 0 bytes
-rw-r--r--doc/icons/previous.gifbin220 -> 0 bytes
-rw-r--r--doc/icons/previous_gr.gifbin220 -> 0 bytes
-rw-r--r--doc/icons/references.gifbin247 -> 0 bytes
-rw-r--r--doc/icons/references_gr.gifbin247 -> 0 bytes
-rw-r--r--doc/icons/up.gifbin145 -> 0 bytes
-rw-r--r--doc/icons/up_gr.gifbin145 -> 0 bytes
-rw-r--r--doc/net.tex479
-rw-r--r--doc/sane-canon_lide70.man104
-rw-r--r--doc/sane-escl.man23
-rw-r--r--doc/sane-fujitsu.man6
-rw-r--r--doc/sane-genesys.man31
-rw-r--r--doc/sane-pixma.man63
-rw-r--r--doc/sane.man23
-rw-r--r--doc/sane.tex1892
-rw-r--r--doc/scanimage.man2
39 files changed, 558 insertions, 2869 deletions
diff --git a/doc/.gitignore b/doc/.gitignore
index 076d975..3abf467 100644
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -2,24 +2,11 @@
*.5
*.7
*.8
-*.eps
*.html
-*.pdf
descriptions-external.db
descriptions.db
doxygen-genesys.conf
doxygen-sanei.conf
doxygen_sqlite3.db
genesys-html
-sane.aux
-sane.cb
-sane.dvi
-sane.idx
-sane.ilg
-sane.ind
-sane.lof
-sane.log
-sane.lot
-sane.ps
-sane.toc
sanei-html
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 56d3517..5cf3011 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -18,6 +18,7 @@ EXTRA_DIST = scanimage.man sane-config.man sane-find-scanner.man \
# custom install/uninstall if we required man pages for every backend.
BACKEND_5MANS = sane-abaton.5 sane-agfafocus.5 sane-apple.5 sane-as6e.5 \
+ sane-canon_lide70.5 \
sane-dll.5 sane-dc25.5 sane-dmc.5 sane-epson.5 sane-epson2.5 sane-epsonds.5 \
sane-escl.5 sane-hp.5 sane-gphoto2.5 sane-leo.5 sane-lexmark.5 \
sane-matsushita.5 sane-microtek.5 sane-microtek2.5 sane-mustek.5 \
@@ -40,6 +41,7 @@ BACKEND_5MANS = sane-abaton.5 sane-agfafocus.5 sane-apple.5 sane-as6e.5 \
sane-kvs40xx.5 sane-p5.5 sane-magicolor.5
EXTRA_DIST += sane-abaton.man sane-agfafocus.man sane-apple.man sane-as6e.man \
+ sane-canon_lide70.man \
sane-dll.man sane-dc25.man sane-dmc.man sane-epson.man \
sane-epson2.man sane-epsonds.man sane-escl.man sane-hp.man sane-gphoto2.man \
sane-leo.man sane-lexmark.man sane-matsushita.man sane-microtek.man \
@@ -80,11 +82,10 @@ HTML_PAGES = sane-backends.html sane-backends-external.html \
endif
doc_DATA = $(HTML_PAGES)
-all: bemans $(API_SPECS) html-pages
+all: bemans html-pages
dist_doc_DATA = backend-writing.txt
nobase_dist_doc_DATA = $(BEDOCS)
-doc_DATA += $(API_SPECS)
EXTRA_DIST += descriptions.txt releases.txt sane-logo2.jpg sane-logo.png \
sane.png
@@ -151,6 +152,7 @@ DESC_FILES = descriptions/abaton.desc descriptions/agfafocus.desc \
descriptions/artec_eplus48u.desc descriptions/as6e.desc \
descriptions/avision.desc descriptions/bh.desc descriptions/canon630u.desc \
descriptions/canon.desc descriptions/canon_dr.desc \
+ descriptions/canon_lide70.desc \
descriptions/canon_pp.desc descriptions/cardscan.desc \
descriptions/coolscan2.desc descriptions/coolscan.desc \
descriptions/coolscan3.desc \
@@ -215,89 +217,6 @@ install-data-local: install-beman5
uninstall-local:
rm -rf $(DESTDIR)$(beman5dir)/sane-*.5
-## SANE API specification format conversion support
-
-API_SPECS =
-if WITH_API_PS
-API_SPECS += sane.ps
-endif
-if WITH_API_PDF
-API_SPECS += sane.pdf
-endif
-if WITH_API_HTML
-API_SPECS += sane-html
-endif
-
-API_SPEC_INPUTS = $(srcdir)/sane.tex
-API_SPEC_INPUTS += $(srcdir)/net.tex
-EXTRA_DIST += $(API_SPEC_INPUTS)
-
-API_SPEC_TEX_FIGS =
-API_SPEC_TEX_FIGS += figs/area.fig
-API_SPEC_TEX_FIGS += figs/flow.fig
-API_SPEC_TEX_FIGS += figs/hierarchy.fig
-API_SPEC_TEX_FIGS += figs/image-data.fig
-API_SPEC_TEX_FIGS += figs/xfer.fig
-EXTRA_DIST += $(API_SPEC_TEX_FIGS)
-
-API_SPEC_EPS_FIGS =
-API_SPEC_EPS_FIGS += figs/area.eps
-API_SPEC_EPS_FIGS += figs/flow.eps
-API_SPEC_EPS_FIGS += figs/hierarchy.eps
-API_SPEC_EPS_FIGS += figs/image-data.eps
-API_SPEC_EPS_FIGS += figs/xfer.eps
-
-API_SPEC_PDF_FIGS =
-API_SPEC_PDF_FIGS += figs/area.pdf
-API_SPEC_PDF_FIGS += figs/flow.pdf
-API_SPEC_PDF_FIGS += figs/hierarchy.pdf
-API_SPEC_PDF_FIGS += figs/image-data.pdf
-API_SPEC_PDF_FIGS += figs/xfer.pdf
-
-## These icons are referred to in the generated HTML output.
-API_SPEC_HTML_ICONS =
-API_SPEC_HTML_ICONS += icons/contents.gif
-API_SPEC_HTML_ICONS += icons/index.gif
-API_SPEC_HTML_ICONS += icons/next.gif icons/next_gr.gif
-API_SPEC_HTML_ICONS += icons/previous.gif icons/previous_gr.gif
-API_SPEC_HTML_ICONS += icons/references.gif icons/references_gr.gif
-API_SPEC_HTML_ICONS += icons/up.gif icons/up_gr.gif
-EXTRA_DIST += $(API_SPEC_HTML_ICONS)
-
-am_TEXINPUTS = TEXINPUTS="$(builddir):$(srcdir):$$TEXINPUTS"
-
-sane.ind: $(API_SPEC_INPUTS)
- @echo Generating index for $<...
- @touch sane.ind
- @$(am_TEXINPUTS) $(LATEX) $< </dev/null >/dev/null && \
- $(MAKEINDEX) -q sane.idx && \
- $(am_TEXINPUTS) $(LATEX) $< </dev/null >/dev/null
-
-.fig.eps:
- @test -d $(@D) || $(MKDIR_P) $(@D)
- $(FIG2DEV) -L eps $< $@
-
-sane.dvi: $(API_SPEC_INPUTS) $(API_SPEC_EPS_FIGS) sane.ind
- @echo Generating $@ from $<...
- @$(am_TEXINPUTS) $(LATEX) $< </dev/null >/dev/null
-
-sane.ps: sane.dvi
- @echo Generating $@ from $<...
- @$(am_TEXINPUTS) $(DVIPS) -q $< -o $@
-
-.fig.pdf:
- @test -d $(@D) || $(MKDIR_P) $(@D)
- $(FIG2DEV) -L pdf $< $@
-
-sane.pdf: $(API_SPEC_INPUTS) $(API_SPEC_PDF_FIGS) sane.ind
- @echo Generating $@ from $<...
- @$(am_TEXINPUTS) $(PDFLATEX) $< >/dev/null
-
-sane-html: sane.dvi
- $(am_TEXINPUTS) $(DLH) $(srcdir)/sane.tex
-
-## ^^
-
html-man: $(MANPAGES)
@for page in $(MANPAGES); do \
echo "translating $${page} to $${page}.html..."; \
@@ -344,20 +263,12 @@ descriptions-external.db: $(DESC_EXT_FILES) ../tools/sane-desc
> descriptions-external.db
html-pages: $(HTML_PAGES)
-html-local: html-pages html-man sane-html
-
-clean-local:
- rm -f *.toc *.aux *.log *.cp *.fn *.tp *.vr *.pg *.ky *.blg *.idx *.cb
- rm -f *.ilg
- rm -f $(API_SPEC_EPS_FIGS) $(API_SPEC_PDF_FIGS)
- -rmdir figs
+html-local: html-pages html-man
distclean-local:
rm -f $(MANPAGES)
- rm -f *.lot *.lof *.ind
- rm -f sane.dvi sane.ps sane-backends.html sane-backends-external.html
+ rm -f sane-backends.html sane-backends-external.html
rm -f sane-mfgs.html sane-mfgs-external.html
- rm -f sane/*.html sane/*.gif
rm -f doxygen-sanei.conf doxygen-genesys.conf
-rm -rf sane sanei-html
for manpage in $(MANPAGES) ; do \
diff --git a/doc/backend-writing.txt b/doc/backend-writing.txt
index 736fcec..5823661 100644
--- a/doc/backend-writing.txt
+++ b/doc/backend-writing.txt
@@ -12,6 +12,7 @@ GETTING STARTED
about it. You should mention that the code will be open-source, however.
* Read the SANE standard.
+ See https://sane-project.gitlab.io/standard/
* One approach is to write a stand-alone scanning program first. Debugging
this program is usually easier than using the SANE libraries. However, keep
@@ -157,8 +158,6 @@ sane-backends/doc/
Used by doxygen to create the documentation of the sanei code.
* releases.txt:
Explains how to make releases of sane-backends.
- * sane.tex, net.tex:
- Contains the LaTeX source of the SANE standard.
* descriptions/ (directory)
Contains the .desc files for every backend that is included into
sane-backends.
diff --git a/doc/descriptions-external/epkowa.desc b/doc/descriptions-external/epkowa.desc
index 9217aaf..5bc43bf 100644
--- a/doc/descriptions-external/epkowa.desc
+++ b/doc/descriptions-external/epkowa.desc
@@ -1,5 +1,6 @@
;;; epkowa.desc -*- emacs-lisp -*- (eh, sort of)
;;; Copyright (C) 2004--2015 Olaf Meeuwissen
+;;; Copyright (C) 2019 SEIKO EPSON Corporation
;;;
;;; This file is part of the "Image Scan!" documentation.
;;;
@@ -40,7 +41,7 @@
;; Backend data.
;;
:backend "epkowa"
-:version "iscan 2.30.1/iscan-data 1.36.0"
+:version "iscan 2.30.4/iscan-data 1.39.1"
:url "http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX"
@@ -223,6 +224,11 @@
:status :complete
:comment "requires DFSG non-free iscan-plugin-ds-30"
+:model "DS-G20000"
+:interface "USB"
+:usbid "0x04b8" "0x015b"
+:status :good
+
:model "EP-702A"
:interface "USB"
:usbid "0x04b8" "0x0850"
@@ -650,6 +656,12 @@
:status :good
:comment "overseas version of the ES-G11000"
+:model "Expression 12000XL"
+:interface "USB"
+:usbid "0x04b8" "0x015b"
+:status :good
+:comment "overseas version of the DS-G20000"
+
:model "F-3200" ; product spec (JP)
:interface "USB IEEE1394"
:usbid "0x04b8" "0x080a"
@@ -1198,19 +1210,25 @@
:interface "USB"
:usbid "0x04b8" "0x08ad"
:status :good
-:comment "network interface not supported<br>business all-in-one"
+:comment "network interface supported via DFSG non-free iscan-network-nt package<br>business all-in-one"
:model "LP-M8040A"
:interface "USB"
:usbid "0x04b8" "0x08ad"
:status :good
-:comment "network interface not supported<br>business all-in-one"
+:comment "network interface supported via DFSG non-free iscan-network-nt package<br>business all-in-one"
:model "LP-M8040F"
:interface "USB"
:usbid "0x04b8" "0x08ad"
:status :good
-:comment "network interface not supported<br>business all-in-one"
+:comment "network interface supported via DFSG non-free iscan-network-nt package<br>business all-in-one"
+
+:model "LP-M8170"
+:interface "USB"
+:usbid "0x04b8" "0x1111"
+:status :good
+:comment "network interface supported via DFSG non-free iscan-network-nt package<br>business all-in-one"
:model "M200 Series"
:interface "USB"
diff --git a/doc/descriptions-external/utsushi.desc b/doc/descriptions-external/utsushi.desc
index 105b0c7..231711d 100644
--- a/doc/descriptions-external/utsushi.desc
+++ b/doc/descriptions-external/utsushi.desc
@@ -282,6 +282,11 @@
:usbid "0x04b8" "0x112e"
:status :good
+:model "WF-2850"
+:interface "USB"
+:usbid "0x04b8" "0x1138"
+:status :good
+
:model "WF-4720"
:interface "USB"
:usbid "0x04b8" "0x1125"
@@ -297,6 +302,11 @@
:usbid "0x04b8" "0x08cf"
:status :good
+:model "WF-7720"
+:interface "USB"
+:usbid "0x04b8" "0x112d"
+:status :good
+
:model "WF-8510"
:interface "USB"
:usbid "0x04b8" "0x08bc"
@@ -998,6 +1008,24 @@
:status :good
:comment "ET-16xxx"
+:model "PID 1171"
+:interface "USB"
+:usbid "0x04b8" "0x1171"
+:status :good
+:comment "WFC2xxxx"
+
+:model "PID 1172"
+:interface "USB"
+:usbid "0x04b8" "0x1172"
+:status :good
+:comment "WFC2xxxx"
+
+:model "PID 1173"
+:interface "USB"
+:usbid "0x04b8" "0x1173"
+:status :good
+:comment "WFC2xxxx"
+
:model "PID 1174"
:interface "USB"
:usbid "0x04b8" "0x1174"
@@ -1021,3 +1049,21 @@
:usbid "0x04b8" "0x1177"
:status :good
:comment "ET-16xxx"
+
+:model "PID 117A"
+:interface "USB"
+:usbid "0x04b8" "0x117a"
+:status :good
+:comment "WF-48xx"
+
+:model "PID 117B"
+:interface "USB"
+:usbid "0x04b8" "0x117b"
+:status :good
+:comment "WF-48xx"
+
+:model "PID 117C"
+:interface "USB"
+:usbid "0x04b8" "0x117c"
+:status :good
+:comment "WF-48xx"
diff --git a/doc/descriptions/avision.desc b/doc/descriptions/avision.desc
index f428fe8..780d7e6 100644
--- a/doc/descriptions/avision.desc
+++ b/doc/descriptions/avision.desc
@@ -614,6 +614,12 @@
:usbid "0x040a" "0x6005"
:status :good
+:model "i1120"
+:interface "USB"
+:usbid "0x040a" "0x6013"
+:comment "duplex sheetfed scanner"
+:status :good
+
:mfg "iVina"
diff --git a/doc/descriptions/canon_dr.desc b/doc/descriptions/canon_dr.desc
index 7a45d25..a767cdb 100644
--- a/doc/descriptions/canon_dr.desc
+++ b/doc/descriptions/canon_dr.desc
@@ -364,7 +364,14 @@
:model "P-208II"
:interface "USB"
:usbid "0x1083" "0x165f"
-:status :untested
+:status :basic
+:comment "Simplex+duplex, all resolutions <= 600, gray/color, calibration poor."
+
+:model "P-208II"
+:interface "USB"
+:usbid "0x1083" "0x1660"
+:status :basic
+:comment "This is the same device as the 0x165f P-208II, but the mode switch on the scanner is in the wrong position, you must move the switch."
:model "DR-P215"
:interface "USB"
diff --git a/doc/descriptions/canon_lide70.desc b/doc/descriptions/canon_lide70.desc
new file mode 100644
index 0000000..6b50fe4
--- /dev/null
+++ b/doc/descriptions/canon_lide70.desc
@@ -0,0 +1,29 @@
+;
+; SANE Backend specification file
+;
+; It's basically emacs-lisp --- so ";" indicates comment to end of line.
+; All syntactic elements are keyword tokens, followed by a string or
+; keyword argument, as specified.
+;
+; ":backend" *must* be specified.
+; All other information is optional (but what good is the file without it?).
+;
+
+:backend "canon_lide70" ; name of backend
+:new :yes
+:url "http://www.juergen-ernst.de/info_sane.html"
+:version "0" ; version of backend
+:manpage "sane-canon_lide70" ; name of manpage (if it exists)
+:devicetype :scanner ; start of a list of devices....
+ ; other types: :stillcam, :vidcam,
+ ; :meta, :api
+
+:mfg "Canon" ; name a manufacturer
+:url "http://www.canon.com/"
+
+;==================================================
+:model "CanoScan LiDE 70"
+:interface "USB"
+:usbid "0x04a9" "0x2225"
+:status :basic
+:comment "Please test!"
diff --git a/doc/descriptions/escl.desc b/doc/descriptions/escl.desc
index f654f75..798f906 100644
--- a/doc/descriptions/escl.desc
+++ b/doc/descriptions/escl.desc
@@ -1,7 +1,114 @@
:backend "escl"
-:new :yes
:manpage "sane-escl"
:url "https://support.apple.com/en-us/HT201311"
:comment "The eSCL backend for sane supports AirScan/eSCL devices that announce themselves on mDNS as _uscan._utcp or _uscans._utcp"
:devicetype :scanner
+
+:mfg "Brother"
+:url "https://www.brother.ee/support/drivers"
+
+:model "DCP-L2530DW"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported."
+
+:mfg "Canon"
+:url "https://www.canon-europe.com/support/"
+
+:model "PIXMA G7050"
+:interface "Ethernet WiFi"
+:status :untested
+:comment "Testers needed!"
+
+:model "IR C3520"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:model "PIXMA TS3100 Series"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported."
+
+:model "PIXMA TS3300 Series"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported."
+
+:model "PIXMA TS6150"
+:interface "Wifi"
+:status :untested
+:comment "Testers needed!"
+
+:model "PIXMA TS8050"
+:interface "Wifi"
+:status :untested
+:comment "Testers needed!"
+
+:model "PIXMA TS9100 Series"
+:interface "Wifi"
+:status :untested
+:comment "Testers needed!"
+
+:model "PIXMA TR4540 Series"
+:interface "Wifi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:model "PIXMA TR8500 Series"
+:interface "Ethernet WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:model "PIXMA TR8520"
+:interface "Ethernet WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:mfg "Epson"
+:url "http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX"
+
+:model "ET-3750"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:model "ET-4750"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:mfg "HP"
+:url "https://support.hp.com/us-en/drivers/printers"
+
+:model "LaserJet MFP M28w"
+:interface "WiFi"
+:status :untested
+:comment "Testers needed!"
+
+:model "OfficeJet 4630"
+:interface "WiFi"
+:status :untested
+:comment "Testers needed!"
+
+:model "OfficeJet Pro 8610"
+:interface "Ethernet WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
+
+:mfg "Ricoh"
+:url "http://support.ricoh.com/bb/html/dr_ut_e/re2/"
+
+:model "SP3710S"
+:interface "WiFi"
+:status :untested
+:comment "Testers needed!"
+
+:mfg "Xerox"
+:url "https://www.support.xerox.com/"
+
+:model "VERSALINK C7220"
+:interface "WiFi"
+:status :good
+:comment "All resolutions supported, Flatted and ADF supported."
diff --git a/doc/descriptions/fujitsu.desc b/doc/descriptions/fujitsu.desc
index b858415..0527579 100644
--- a/doc/descriptions/fujitsu.desc
+++ b/doc/descriptions/fujitsu.desc
@@ -657,3 +657,19 @@
:status :good
:usbid "0x04c5" "0x159f"
:comment "small, current, WiFi not supported."
+
+:model "fi-800R"
+:interface "USB"
+:status :good
+:usbid "0x04c5" "0x15fc"
+:comment "small, current, both feed methods are supported."
+
+:model "fi-7900"
+:interface "USB"
+:status :good
+:usbid "0x04c5" "0x160a"
+
+:model "fi-7800"
+:interface "USB"
+:status :good
+:usbid "0x04c5" "0x160b"
diff --git a/doc/descriptions/genesys.desc b/doc/descriptions/genesys.desc
index 888f252..e809d4b 100644
--- a/doc/descriptions/genesys.desc
+++ b/doc/descriptions/genesys.desc
@@ -17,20 +17,59 @@
:status :basic
:comment "Has a Primax USB ID"
+:model "OpticFilm 7200"
+:interface "USB"
+:usbid "0x07b3" "0x0807"
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported"
+
+:model "OpticFilm 7200 (v2)"
+:interface "USB"
+:usbid "0x07b3" "0x0c07"
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported"
+
:model "OpticFilm 7200i"
:interface "USB"
:usbid "0x07b3" "0x0c04"
-:status :basic
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported in both regular transparency and infrared modes"
:model "OpticFilm 7300"
:interface "USB"
:usbid "0x07b3" "0x0c12"
-:status :basic
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported"
+
+:model "OpticFilm 7400"
+:interface "USB"
+:usbid "0x07b3" "0x0c3a"
+:status :complete
+:comment "900, 1800, 3600, 7200 or 600, 1200, 1800, 3600 and 7200 dpi resolutions are supported (depending on exact scanner model)"
:model "OpticFilm 7500i"
:interface "USB"
:usbid "0x07b3" "0x0c13"
-:status :basic
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported in both regular transparency and infrared modes"
+
+:model "OpticFilm 7600i"
+:interface "USB"
+:usbid "0x07b3" "0x0c3b"
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported in both regular transparency and infrared modes"
+
+:model "OpticFilm 8100"
+:interface "USB"
+:usbid "0x07b3" "0x130c"
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported"
+
+:model "OpticFilm 8200i"
+:interface "USB"
+:usbid "0x07b3" "0x130d"
+:status :complete
+:comment "900, 1800, 3600 and 7200 dpi resolutions are supported in both regular transparency and infrared modes"
; -----------------------------------------------------------------------------
@@ -148,79 +187,83 @@
:status :basic
:comment "No 2400 dpi support, slow speed at lower resolution"
+:model "CanoScan LiDE 90"
+:interface "USB"
+:usbid "0x04a9" "0x1900"
+:status :good
+:comment "resolutions from 300 to 2400 dpi are supported"
+
:model "CanoScan LiDE 100"
:interface "USB"
:usbid "0x04a9" "0x1904"
:status :complete
-:comment "GL847 based, resolution from 75 to 2400 dpi"
+:comment "resolutions from 75 to 2400 dpi are supported"
:model "CanoScan LiDE 110"
:interface "USB"
:usbid "0x04a9" "0x1909"
:status :complete
-:comment "GL124 based, resolution from 75 to 2400 dpi"
+:comment "resolutions from 75 to 2400 dpi are supported"
:model "CanoScan LiDE 120"
:interface "USB"
:usbid "0x04a9" "0x190e"
:status :complete
-:comment "GL124+ based, resolution from 75 to 2400 dpi"
+:comment "resolutions from 75 to 2400 dpi are supported"
:model "CanoScan LiDE 200"
:interface "USB"
:usbid "0x04a9" "0x1905"
:status :complete
-:comment "GL847 based, resolution from 75 to 4800 dpi"
+:comment "resolutions from 75 to 4800 dpi are supported"
:model "CanoScan LiDE 210"
:interface "USB"
:usbid "0x04a9" "0x190a"
:status :complete
-:comment "GL124 based, resolution from 75 to 4800 dpi"
+:comment "resolutions from 75 to 4800 dpi are supported"
:model "CanoScan LiDE 220"
:interface "USB"
:usbid "0x04a9" "0x190f"
:status :complete
-:comment "GL124+ based, resolution from 75 to 4800 dpi"
+:comment "resolutions from 75 to 4800 dpi are supported"
:model "CanoScan 4400F"
:interface "USB"
:usbid "0x04a9" "0x2228"
-:status :basic
-:comment "GL843 based"
+:status :complete
+:comment "300, 600, 1200 dpi resolutions are supported in flatbed mode; 1200, 2400, 4800 dpi resolutions are supported in transparency scanning mode"
:model "CanoScan 5600F"
:interface "USB"
:usbid "0x04a9" "0x1906"
-:status :unsupported
-:comment "GL847 based, to be added to the genesys backend"
+:status :complete
+:comment "300, 600, 1200, 2400, 4800 dpi resolutions are supported in both flatbed and transparency modes"
:model "CanoScan 8400F"
-:url "unsupported/canon-8400f.html"
:interface "USB"
:usbid "0x04a9" "0x221e"
-:status :basic
-:comment "GL841 based, to be added to genesys backend"
+:status :complete
+:comment "400, 800, 1600, 3200 dpi resolutions are supported in flatbed, transparency and infrared transparency scanning modes"
:model "CanoScan 8600F"
-:url "unsupported/canon-8600.html"
:interface "USB"
:usbid "0x04a9" "0x2229"
-:status :basic
-:comment "normal and transparency scans work up to 1200 dpi resolution"
+:status :complete
+:comment "300, 600, 1200 dpi resolutions supported in flatbed scanning mode; 300, 600, 1200, 2400, 4800 dpi resolutions are supported in transparency and infrared transparency scanning modes"
:model "CanoScan 700F"
:interface "USB"
:usbid "0x04a9" "0x1907"
-:status :good
-:comment "GL847 based, resolution from 75 to 4800 dpi"
+:status :basic
+:comment "GL847 based, resolutions from 75 to 1200 dpi are supported"
:model "Canon Image Formula 101"
:interface "USB"
:usbid "0x1083" "0x162e"
:status :unsupported
-:comment "GL846 based, work in progress"
+:comment "GL846 based"
; -----------------------------------------------------------------------------
diff --git a/doc/descriptions/pixma.desc b/doc/descriptions/pixma.desc
index 4366891..3b7ac6c 100644
--- a/doc/descriptions/pixma.desc
+++ b/doc/descriptions/pixma.desc
@@ -11,7 +11,7 @@
; See doc/descriptions.txt for details.
:backend "pixma" ; name of backend
-:version "0.27.0" ; version of backend (or "unmaintained")
+:version "0.28.5" ; version of backend (or "unmaintained")
:manpage "sane-pixma" ; name of manpage (if it exists)
;:comment "Devices marked as experimantal are disabled by default. See the manual page for how to enable them."
@@ -31,8 +31,8 @@
:model "PIXMA E410 Series"
:interface "USB"
:usbid "0x04a9" "0x181e"
-:status :untested
-:comment "Testers needed!"
+:status :complete
+:comment "All resolutions supported (up to 600DPI)."
:model "PIXMA E460 Series"
:interface "USB Ethernet"
@@ -133,8 +133,8 @@
:model "PIXMA G4000 Series"
:interface "USB WiFi"
:usbid "0x04a9" "0x181d"
-:status :untested
-:comment "Testers needed!"
+:status :complete
+:comment "All resolutions supported (up to 600DPI)."
:model "PIXMA G4010 Series"
:interface "USB WiFi"
@@ -154,6 +154,18 @@
:status :untested
:comment "Testers needed!"
+:model "PIXMA G7000 Series"
+:interface "USB Ethernet WiFi"
+:usbid "0x04a9" "0x1863"
+:status :untested
+:comment "Testers needed!"
+
+:model "PIXMA GM4000 Series"
+:interface "USB Ethernet WiFi"
+:usbid "0x04a9" "0x1869"
+:status :untested
+:comment "Testers needed!"
+
:model "PIXMA MG2100 Series"
:interface "USB"
:usbid "0x04a9" "0x1751"
@@ -490,8 +502,8 @@
:model "PIXMA MP495"
:interface "USB"
:usbid "0x04a9" "0x1747"
-:status :untested
-:comment "Same protocol as Pixma MP280? Testers needed!"
+:status :complete
+:comment "All resolutions supported (up to 600DPI)"
:model "PIXMA MP500"
:interface "USB"
@@ -854,8 +866,8 @@
:model "PIXMA TR4500 Series"
:interface "USB WiFi"
:usbid "0x04a9" "0x1854"
-:status :untested
-:comment "Testers needed!"
+:status :complete
+:comment "Flatbed and ADF scan. All resolutions supported (up to 600DPI)"
:model "PIXMA TR7500 Series"
:interface "USB WiFi"
@@ -902,8 +914,8 @@
:model "PIXMA TS3300 Series"
:interface "USB WiFi"
:usbid "0x04a9" "0x18a2"
-:status :untested
-:comment "Testers needed!"
+:status :good
+:comment "All resolutions supported (up to 1200DPI). WiFi not working."
:model "PIXMA TS5000 Series"
:interface "USB WiFi"
@@ -914,8 +926,8 @@
:model "PIXMA TS5100 Series"
:interface "USB WiFi"
:usbid "0x04a9" "0x1825"
-:status :untested
-:comment "Testers needed!"
+:status :good
+:comment "All resolutions supported (up to 1200DPI). WiFi not working."
:model "PIXMA TS5300 Series"
:interface "USB WiFi"
@@ -1199,6 +1211,12 @@
:status :untested
:comment "Testers needed!"
+:model "i-SENSYS MF440 Series"
+:interface "USB Ethernet WiFi"
+:usbid "0x04a9" "0x2823"
+:status :complete
+:comment "Flatbed and ADF scan. All resolutions supported (up to 600DPI, ADF up to 300DPI)."
+
:model "i-SENSYS MF510 Series"
:interface "USB Ethernet WiFi"
:usbid "0x04a9" "0x27c2"
@@ -1241,6 +1259,12 @@
:status :complete
:comment "Flatbed and ADF scan. All resolutions supported (up to 600DPI)."
+:model "i-SENSYS MF720 Series"
+:interface "USB Ethernet WiFi"
+:usbid "0x04a9" "0x27b5"
+:status :untested
+:comment "Testers needed!"
+
:model "i-SENSYS MF730 Series"
:interface "USB Ethernet WiFi"
:usbid "0x04a9" "0x27e4"
@@ -1406,8 +1430,8 @@
:model "i-SENSYS MF4700 Series"
:interface "USB Ethernet"
:usbid "0x04a9" "0x2774"
-:status :good
-:comment "Flatbed scan. All resolutions supported (up to 600DPI). ADF buggy."
+:status :complete
+:comment "Flatbed and ADF scan. All resolutions supported (up to 600DPI)."
:model "i-SENSYS MF4800 Series"
:interface "USB Ethernet"
@@ -1568,8 +1592,8 @@
:model "MAXIFY MB5100 Series"
:interface "USB Ethernet WiFi"
:usbid "0x04a9" "0x1790"
-:status :untested
-:comment "Testers needed!"
+:status :complete
+:comment "Flatbed and ADF scan. All resolutions supported (up to 1200DPI)."
:model "MAXIFY MB5300 Series"
:interface "USB Ethernet"
diff --git a/doc/descriptions/snapscan.desc b/doc/descriptions/snapscan.desc
index 73f3f4d..2943e2d 100644
--- a/doc/descriptions/snapscan.desc
+++ b/doc/descriptions/snapscan.desc
@@ -311,38 +311,43 @@
:interface "USB"
:usbid "0x04b8" "0x0114"
:status :good
+:comment "Requires firmware tail_058.bin."
:model "Perfection 1270"
:interface "USB"
:usbid "0x04b8" "0x0120"
:status :good
+:comment "Requires firmware esfw3e.bin."
:model "Perfection 1670"
:interface "USB"
:usbid "0x04b8" "0x011f"
:status :good
+:comment "Requires firmware esfw30.bin."
-:model "Perfection 2480"
+:model "Perfection 2480 PHOTO"
:interface "USB"
:usbid "0x04b8" "0x0121"
:status :good
+:comment "Requires firmware esfw41.bin."
-:model "Perfection 2580"
+:model "Perfection 2580 PHOTO"
:interface "USB"
:status :basic
:usbid "0x04b8" "0x0121"
-:comment "Film scanning unit unsupported"
+:comment "Requires firmware esfw41.bin, film scanning unit unsupported."
-:model "Perfection 3490"
+:model "Perfection 3490 PHOTO"
:interface "USB"
:usbid "0x04b8" "0x0122"
:status :good
+:comment "Requires firmware esfw51.bin."
-:model "Perfection 3590"
+:model "Perfection 3590 PHOTO"
:interface "USB"
:usbid "0x04b8" "0x0122"
:status :basic
-:comment "Film scanning unit unsupported"
+:comment "Requires firmware esfw52.bin, film scanning unit unsupported."
:model "Stylus CX-1500"
:interface "USB"
diff --git a/doc/descriptions/unsupported.desc b/doc/descriptions/unsupported.desc
index e062682..03788c4 100644
--- a/doc/descriptions/unsupported.desc
+++ b/doc/descriptions/unsupported.desc
@@ -395,20 +395,6 @@
:status :unsupported
:comment "Not supported. However, a stand-alone program for FreeBSD is available."
-:model "CanoScan LiDE 70"
-:url "http://www.juergen-ernst.de/info_sane.html"
-:interface "USB"
-:usbid "0x04a9" "0x2225"
-:status :unsupported
-:comment "Philips chip. Backend started, see link"
-
-:model "CanoScan LiDE 90"
-:url "unsupported/canon-lide-90.html"
-:interface "USB"
-:usbid "0x04a9" "0x1900"
-:status :unsupported
-:comment "Unsupported. See link for details."
-
:model "CanoScan LiDE 500F"
:url "unsupported/canon-canoscan-lide-500f.html"
:interface "USB"
@@ -1745,13 +1731,6 @@
:url "http://www.plustek.de/"
:url "http://www.plustek.com/"
-:model "OpticFilm 7200"
-:url "unsupported/plustek-opticfilm-7200.html"
-:interface "USB"
-:usbid "0x07b3" "0x0807"
-:status :unsupported
-:comment "GL842 based, maybe to be added to genesys backend"
-
:model "OpticPro A3U"
:interface "USB"
:status :unsupported
@@ -1953,7 +1932,7 @@
:interface "USB"
:usbid "0x18dd" "0x1000"
:status :unsupported
-:comment "Probably not supported. No details known."
+:comment "Supported by gPhoto2."
:model "DocuPen R700"
:url "unsupported/planon-docupen-r700.html"
diff --git a/doc/descriptions/xerox_mfp.desc b/doc/descriptions/xerox_mfp.desc
index 46c2867..f78bf94 100644
--- a/doc/descriptions/xerox_mfp.desc
+++ b/doc/descriptions/xerox_mfp.desc
@@ -38,6 +38,11 @@
:usbid "0x0924" "0x4294"
:status :good
+:model "WorkCentre 3225"
+:interface "USB"
+:usbid "0x0924" "0x42dc"
+:status :good
+
:mfg "Dell"
:url "http://www.dell.com/"
@@ -388,6 +393,12 @@
:usbid "0x04e8" "0x3469"
:status :good
+:model "M288x Series"
+:interface "USB"
+:usbid "0x04e8" "0x346a"
+:status :unsupported
+:comment "M2885FW is reported to work with sane-airscan in network mode (WSD)"
+
:model "C1860FW"
:interface "USB"
:usbid "0x04e8" "0x346b"
diff --git a/doc/figs/area.fig b/doc/figs/area.fig
deleted file mode 100644
index d0e62e4..0000000
--- a/doc/figs/area.fig
+++ /dev/null
@@ -1,36 +0,0 @@
-#FIG 3.1
-Portrait
-Center
-Inches
-1200 2
-6 1650 1650 1800 1800
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 1725 1650 1725 1800
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 1650 1725 1800 1725
--6
-6 3300 2700 3450 2850
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 3375 2700 3375 2850
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 3300 2775 3450 2775
--6
-6 1725 1725 3375 2775
-2 2 0 0 7 7 10 0 18 0.000 0 0 -1 0 0 5
- 1725 1725 3375 1725 3375 2775 1725 2775 1725 1725
-4 1 -1 10 0 16 12 0.0000 4 105 840 2550 2302 scan area\001
--6
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 1200 675 4275 675 4275 3375 1200 3375 1200 675
-2 1 0 1 -1 7 10 0 16 0.000 0 0 -1 1 0 2
- 2 1 1.00 60.00 120.00
- 1200 525 1200 3825
-2 1 0 1 -1 7 10 0 16 0.000 0 0 -1 1 0 2
- 2 1 1.00 60.00 120.00
- 1050 675 4650 675
-4 1 -1 10 0 16 12 0.0000 4 180 1020 3375 3150 bottom-right\001
-4 1 -1 10 0 16 12 0.0000 4 180 615 1725 1500 top-left\001
-4 1 -1 10 0 16 12 0.0000 4 135 1080 2700 1050 scan surface\001
-4 1 -1 10 0 16 12 0.0000 4 150 105 1050 3600 y\001
-4 1 -1 10 0 16 12 0.0000 4 105 90 4425 525 x\001
-4 1 -1 10 0 16 12 0.0000 4 135 105 1080 585 0\001
diff --git a/doc/figs/flow.fig b/doc/figs/flow.fig
deleted file mode 100644
index 3abcc0b..0000000
--- a/doc/figs/flow.fig
+++ /dev/null
@@ -1,40 +0,0 @@
-#FIG 3.1
-Portrait
-Center
-Inches
-1200 2
-6 4200 7305 9945 7575
-4 0 -1 0 0 17 18 0.0000 4 270 1500 4200 7515 - go back to\001
-4 0 -1 0 0 16 18 0.0000 4 270 1440 5775 7515 sane_start()\001
-4 0 -1 0 0 17 18 0.0000 4 210 2670 7275 7515 if more frames desired\001
--6
-2 2 0 1 -1 7 10 0 19 0.000 0 0 -1 0 0 5
- 2700 600 10200 600 10200 9600 2700 9600 2700 600
-2 2 0 1 -1 7 8 0 18 0.000 0 0 -1 0 0 5
- 3300 2400 10200 2400 10200 8925 3300 8925 3300 2400
-2 2 0 1 -1 7 8 0 17 0.000 0 0 -1 0 0 5
- 3900 2925 10200 2925 10200 4650 3900 4650 3900 2925
-2 2 0 1 -1 7 8 0 17 0.000 0 0 -1 0 0 5
- 3900 4800 10200 4800 10200 8250 3900 8250 3900 4800
-2 1 0 1 -1 7 8 0 -1 0.000 0 0 -1 0 0 4
- 10350 3000 10425 3075 10425 4500 10350 4575
-2 1 0 1 -1 7 8 0 -1 0.000 0 0 -1 0 0 4
- 10350 4875 10425 4950 10425 8100 10350 8175
-4 0 -1 0 0 17 18 0.0000 4 150 735 4200 3300 - use:\001
-4 0 -1 0 0 16 18 0.0000 4 270 1680 4200 5100 - sane_start()\001
-4 0 -1 0 0 17 18 0.0000 4 270 4950 4500 4500 repeatedly to configure device as desired\001
-4 0 -1 0 0 16 18 0.0000 4 270 2715 5400 4080 sane_control_option()\001
-4 0 -1 0 0 16 18 0.0000 4 270 3660 5400 3600 sane_get_option_descriptor()\001
-4 0 -1 0 0 17 18 0.0000 4 150 735 4200 5700 - use:\001
-4 0 -1 0 0 17 18 0.0000 4 270 4080 4500 6900 repeatedly until read returns EOF\001
-4 0 -1 0 0 16 18 0.0000 4 270 2805 5400 6000 sane_get_parameters()\001
-4 0 -1 0 0 16 18 0.0000 4 270 1440 5400 6450 sane_read()\001
-4 0 -1 0 0 16 18 0.0000 4 270 1935 4200 8100 - sane_cancel()\001
-4 0 -1 0 0 16 18 0.0000 4 270 1500 3000 1200 - sane_init()\001
-4 0 -1 0 0 16 18 0.0000 4 270 1590 3000 9300 - sane_exit()\001
-4 0 -1 0 0 17 18 0.0000 4 270 4845 3600 1800 - pick desired device, possibly by using\001
-4 0 -1 0 0 16 18 0.0000 4 270 1770 3600 2700 - sane_open()\001
-4 0 -1 0 0 16 18 0.0000 4 270 1800 3600 8700 - sane_close()\001
-4 0 -1 0 0 16 18 0.0000 4 270 2415 4800 2175 sane_get_devices()\001
-4 0 -1 8 0 17 18 0.0000 4 270 2070 10575 6600 image acquisition\001
-4 0 -1 8 0 17 18 0.0000 4 270 1500 10575 3825 device setup\001
diff --git a/doc/figs/hierarchy.fig b/doc/figs/hierarchy.fig
deleted file mode 100644
index 5545b8d..0000000
--- a/doc/figs/hierarchy.fig
+++ /dev/null
@@ -1,79 +0,0 @@
-#FIG 3.1
-Landscape
-Center
-Inches
-1200 2
-6 10500 4500 12300 5400
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 10650 4785 12150 4785 12150 5385 10650 5385 10650 4785
-4 1 -1 0 0 16 18 0.0000 4 210 660 11399 5182 qcam\001
--6
-6 7200 4500 9000 5400
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 7350 4785 8850 4785 8850 5385 7350 5385 7350 4785
-4 1 -1 0 0 16 18 0.0000 4 270 315 8099 5182 hp\001
--6
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 2250 1185 3750 1185 3750 1785 2250 1785 2250 1185
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 450 2985 1950 2985 1950 3585 450 3585 450 2985
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 2250 2985 3750 2985 3750 3585 2250 3585 2250 2985
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 4050 2985 5550 2985 5550 3585 4050 3585 4050 2985
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 8850 1185 10350 1185 10350 1785 8850 1785 8850 1185
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 2700 1800 1200 3000
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 3000 1800 3000 3000
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 3300 1800 4800 3000
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 9600 1800 9600 2100
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 9450 2700 8100 4800
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 11400 4200 11400 4800
-2 2 0 0 0 0 10 0 2 0.000 0 0 -1 0 0 5
- 5700 3825 300 3825 300 300 5700 300 5700 3825
-2 2 0 0 0 0 10 0 2 0.000 0 0 -1 0 0 5
- 12300 5550 7200 5550 7200 300 12300 300 12300 5550
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 1200 3600 1200 4200
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 3000 3600 3000 4125
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 7875 5400 7350 5850
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 8250 5400 8775 5850
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 11475 5400 11475 5850
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 8850 2100 10350 2100 10350 2700 8850 2700 8850 2100
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 10650 3600 12150 3600 12150 4200 10650 4200 10650 3600
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 2
- 9750 2700 11400 3600
-3 2 0 1 -1 7 0 0 -1 0.000 0 0 0 7
- 4800 3600 4275 4500 5025 5475 6150 4575 6525 1350 9450 900
- 9600 1200
- 0.00 0.00 4390.23 4024.37 4258.98 4249.38 4300.21 4894.51
- 4554.60 5418.20 5575.94 5541.53 5962.09 4914.18 6573.46 3810.63
- 5758.15 2145.68 7223.99 624.74 8573.68 446.85 9524.49 938.52
- 9561.99 1013.52 0.00 0.00
-4 1 -1 0 0 16 18 0.0000 4 210 525 1199 3382 pnm\001
-4 1 -1 0 0 16 18 0.0000 4 210 870 2999 3382 mustek\001
-4 1 -1 0 0 17 14 0.0000 4 210 855 1200 4425 pnm files\001
-4 1 -1 0 0 17 14 0.0000 4 120 765 3000 4380 scanner\001
-4 1 -1 0 0 17 14 0.0000 4 150 945 7350 6165 scanner 1\001
-4 1 -1 0 0 17 14 0.0000 4 150 945 8925 6165 scanner 2\001
-4 1 -1 0 0 17 14 0.0000 4 165 1290 11475 6135 video camera\001
-4 1 -1 0 0 17 14 0.0000 4 165 1035 3000 600 machine A\001
-4 1 -1 0 0 17 14 0.0000 4 165 1020 9600 630 machine B\001
-4 1 -1 0 0 17 14 0.0000 4 165 1860 4725 5850 network connection\001
-4 1 -1 0 0 16 18 0.0000 4 210 285 2999 1582 dll\001
-4 1 -1 0 0 16 18 0.0000 4 195 390 4799 3382 net\001
-4 1 -1 0 0 16 18 0.0000 4 210 735 9599 1582 saned\001
-4 1 -1 0 0 16 18 0.0000 4 210 285 9599 2482 dll\001
-4 1 -1 0 0 16 18 0.0000 4 210 960 11399 3982 autolum\001
diff --git a/doc/figs/image-data.fig b/doc/figs/image-data.fig
deleted file mode 100644
index d52a90e..0000000
--- a/doc/figs/image-data.fig
+++ /dev/null
@@ -1,63 +0,0 @@
-#FIG 3.1
-Portrait
-Center
-Inches
-1200 2
-6 1725 450 5925 1650
-6 1800 975 3150 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 1800 1200 3150 1200 3150 1350 1800 1350 1800 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 1875 1125 7 6 5 4 3 2 1 0\001
--6
-6 3150 975 4500 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 3150 1200 4500 1200 4500 1350 3150 1350 3150 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 3225 1125 7 6 5 4 3 2 1 0\001
--6
-6 4500 975 5850 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 4500 1200 5850 1200 5850 1350 4500 1350 4500 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 4575 1125 7 6 5 4 3 2 1 0\001
--6
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 1800 1200 5850 1200 5850 1350 1800 1350 1800 1200
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 7
- 1800 900 1950 825 3750 825 3825 750 3900 825 5700 825
- 5850 900
-4 0 -1 0 0 16 12 0.0000 4 105 60 2475 1575 r\001
-4 1 -1 0 0 16 12 0.0000 4 150 105 3825 1575 g\001
-4 1 -1 0 0 16 12 0.0000 4 135 105 5175 1575 b\001
-4 1 -1 0 0 16 12 0.0000 4 180 555 3825 600 pixel 0\001
--6
-6 5850 975 7200 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 5850 1200 7200 1200 7200 1350 5850 1350 5850 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 5925 1125 7 6 5 4 3 2 1 0\001
--6
-6 7200 975 8550 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 7200 1200 8550 1200 8550 1350 7200 1350 7200 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 7275 1125 7 6 5 4 3 2 1 0\001
--6
-6 8550 975 9900 1350
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 8550 1200 9900 1200 9900 1350 8550 1350 8550 1200
-4 0 -1 0 0 16 12 0.0000 4 135 1260 8625 1125 7 6 5 4 3 2 1 0\001
--6
-2 2 0 2 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 5850 1200 9900 1200 9900 1350 5850 1350 5850 1200
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 7
- 5850 900 6000 825 7800 825 7875 750 7950 825 9750 825
- 9900 900
-4 0 -1 0 0 16 12 0.0000 4 105 60 6525 1575 r\001
-4 1 -1 0 0 16 12 0.0000 4 150 105 7875 1575 g\001
-4 1 -1 0 0 16 12 0.0000 4 135 105 9225 1575 b\001
-4 1 -1 0 0 16 12 0.0000 4 180 555 7875 600 pixel 1\001
-4 1 -1 0 0 16 12 0.0000 4 180 525 9225 1950 byte 5\001
-4 1 -1 0 0 16 12 0.0000 4 180 525 7875 1950 byte 4\001
-4 1 -1 0 0 16 12 0.0000 4 180 525 6525 1950 byte 3\001
-4 1 -1 0 0 16 12 0.0000 4 180 525 5175 1950 byte 2\001
-4 1 -1 0 0 16 12 0.0000 4 180 465 3825 1950 byte1\001
-4 1 -1 0 0 16 12 0.0000 4 180 465 2475 1950 byte0\001
-4 1 -1 0 0 16 12 0.0000 4 15 180 10050 1275 ....\001
-4 2 -1 0 0 16 12 0.0000 4 135 240 1725 1125 bit:\001
diff --git a/doc/figs/xfer.fig b/doc/figs/xfer.fig
deleted file mode 100644
index c4d8921..0000000
--- a/doc/figs/xfer.fig
+++ /dev/null
@@ -1,32 +0,0 @@
-#FIG 3.1
-Portrait
-Center
-Inches
-1200 2
-6 2325 3150 8175 3750
-2 1 0 2 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 2400 3300 8100 3300
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 8100 3375 2400 3675
--6
-6 2325 3600 8175 4200
-2 1 0 2 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 2400 3750 8100 3750
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 8100 3825 2400 4125
--6
-2 2 0 1 -1 7 0 0 -1 0.000 0 0 -1 0 0 5
- 2250 3150 8250 3150 8250 6150 2250 6150 2250 3150
-2 1 0 2 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 2400 4200 8100 4200
-2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 8100 4275 2400 4575
-2 1 0 2 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 2400 4650 8100 4650
diff --git a/doc/icons/contents.gif b/doc/icons/contents.gif
deleted file mode 100644
index 7b3c904..0000000
--- a/doc/icons/contents.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/index.gif b/doc/icons/index.gif
deleted file mode 100644
index b9b3108..0000000
--- a/doc/icons/index.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/next.gif b/doc/icons/next.gif
deleted file mode 100644
index 7a2dbe9..0000000
--- a/doc/icons/next.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/next_gr.gif b/doc/icons/next_gr.gif
deleted file mode 100644
index 1416b1c..0000000
--- a/doc/icons/next_gr.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/previous.gif b/doc/icons/previous.gif
deleted file mode 100644
index aef90f1..0000000
--- a/doc/icons/previous.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/previous_gr.gif b/doc/icons/previous_gr.gif
deleted file mode 100644
index c6acaab..0000000
--- a/doc/icons/previous_gr.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/references.gif b/doc/icons/references.gif
deleted file mode 100644
index 68c6331..0000000
--- a/doc/icons/references.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/references_gr.gif b/doc/icons/references_gr.gif
deleted file mode 100644
index 682548c..0000000
--- a/doc/icons/references_gr.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/up.gif b/doc/icons/up.gif
deleted file mode 100644
index 3d1aebf..0000000
--- a/doc/icons/up.gif
+++ /dev/null
Binary files differ
diff --git a/doc/icons/up_gr.gif b/doc/icons/up_gr.gif
deleted file mode 100644
index a8b463a..0000000
--- a/doc/icons/up_gr.gif
+++ /dev/null
Binary files differ
diff --git a/doc/net.tex b/doc/net.tex
deleted file mode 100644
index d6bc110..0000000
--- a/doc/net.tex
+++ /dev/null
@@ -1,479 +0,0 @@
-\chapter{Network Protocol}\label{chap:net}
-
-The SANE interface has been designed to facilitate network access to
-image acquisition devices. In particular, most SANE implementations
-are expected to support a network backend (net client) and a
-corresponding network daemon (net server) that allows accessing image
-acquisition devices through a network connection. Network access is
-useful in several situations:
-\begin{itemize}
-
-\item To provide controlled access to resources that are inaccessible
- to a regular user. For example, a user may want to access a device
- on a host where she has no account on. With the network protocol,
- it is possible to allow certain users to access scanners without
- giving them full access to the system.
-
- Controlling access through the network daemon can be useful even in
- the local case: for example, certain backends may require root
- privileges to access a device. Rather than installing each frontend
- as setuid-root, a system administrator could instead install the
- SANE network daemon as setuid-root. This enables regular users to
- access the privileged device through the SANE daemon (which,
- presumably, supports a more fine-grained access control mechanism
- than the simple setuid approach). This has the added benefit that
- the system administrator only needs to trust the SANE daemon, not
- each and every frontend that may need access to the privileged
- device.
-
-\item Network access provides a sense of ubiquity of the available
- image acquisition devices. For example, in a local area network
- environment, this allows a user to log onto any machine and have
- convenient access to any resource available to any machine on the
- network (subject to permission constraints).
-
-\item For devices that do not require physical access when used (e.g.,
- video cameras), network access allows a user to control and use
- these devices without being in physical proximity. Indeed, if such
- devices are connected to the Internet, access from any place in the
- world is possible.
-
-\end{itemize}
-
-The network protocol described in this chapter has been design with
-the following goals in mind:
-\begin{enumerate}
-
-\item Image transmission should be efficient (have low encoding
- overhead).
-
-\item Accessing option descriptors on the client side must be
- efficient (since this is a very common operation).
-
-\item Other operations, such as setting or inquiring the value of an
- option are less performance critical since they typically require
- explicit user action.
-
-\item The network protocol should be simple and easy to implement on
- any host architecture and any programming language.
-
-\end{enumerate}
-The SANE protocol can be run across any transport protocol that
-provides reliable data delivery. While SANE does not specify a
-specific transport protocol, it is expected that TCP/IP will be among
-the most commonly used protocols.
-
-\section{Data Type Encoding}
-
-\subsection{Primitive Data Types}
-
-The four primitive types of the SANE standard are encoded as follows:
-\begin{description}
-
-\item[\code{\defn{SANE\_Byte}}:] A byte is encoded as an 8 bit value.
- Since the transport protocol is assumed to be byte-orientd, the bit
- order is irrelevant.
-
-\item[\code{\defn{SANE\_Word}}:] A word is encoded as 4 bytes (32
- bits). The bytes are ordered from most-significant to
- least-significant byte (big-endian byte-order).
-
-\item[\code{\defn{SANE\_Char}}:] A character is currently encoded as an 8-bit
- ISO LATIN-1 value. An extension to support wider character sets (16 or 32
- bits) is planned for the future, but not supported at this point.
-
-\item[\code{\defn{SANE\_String}}:] A string pointer is encoded as a
- \code{SANE\_Char} array. The trailing NUL byte is considered part
- of the array and a \code{NULL} pointer is encoded as a zero-length
- array.
-
-\item[\code{\defn{SANE\_Handle}}:] A handle is encoded like a word.
- The network backend needs to take care of converting these integer
- values to the opaque pointer values that are presented to the user
- of the network backend. Similarly, the SANE daemon needs to take
- care of converting the opaque pointer values it receives from its
- backends into 32-bit integers suitable for use for network encoding.
-
-\item[{\em\defn{enumeration types}}:] Enumeration types are encoded
- like words.
-
-\end{description}
-
-\subsection{Type Constructors}
-
-Closely following the type constructors of the C language, the SANE network
-protocol supports the following four constructors:
-\begin{description}
-
-\item[{\em\defn{pointer}}:] A pointer is encoded by a word that indicates
- whether the pointer is a NULL-pointer which is then followed by the
- value that the pointer points to (in the case of a non-NULL pointer;
- in the case of a NULL pointer, no bytes are encoded for the pointer
- value).
-
-\item[{\em\defn{array}}:] An array is encoded by a word that indicates
- the length of the array followed by the values of the elements in
- the array. The length may be zero in which case no bytes are
- encoded for the element values.
-
-\item[{\em\defn{structure}}:] A structure is encoded by simply encoding the
- structure members in the order in which they appear in the
- corresponding C type declaration.
-
-\item[{\em\defn{union}}:] A union must always be accompanied by a tag
- value that indicates which of the union members is the currently the
- active one. For this reason, the union itself is encoded simply by
- encoding the value of the currently active member.
-
-\end{description}
-
-Note that for type constructors, the pointer, element, or member
-values themselves may have a constructed type. Thus, the above rules
-should be applied recursively until a sequence of primitive types has
-been found.
-
-Also SANE had no need for encoding of circular structures. This
-greatly simplifies the network protocol.
-
-\section{Remote Procedure Call Requests}
-
-The SANE network protocol is a client/server-style remote procedure
-call (RPC) protocol. This means that all activity is initiated by the
-client side (the network backend)---a server is restricted to
-answering requests sent by the client.
-
-The data transferred from the client to the server is comprised of the RPC code
-(as a \code{SANE\_WORD}), followed by arguments defined in the {\bf request}
-column below. The format of the server's answer is given in the {\bf reply}
-column.
-
-\subsection{\code{\defn{SANE\_NET\_INIT}}}
-
-RPC Code: 0
-
-This RPC establishes a connection to a particular SANE network daemon.
-It must be the first call in a SANE network session. The parameter
-and reply arguments for this call are shown in the table below:
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word version\_code} & \code{SANE\_Word status} \\
- \code{SANE\_String user\_name} & \code{SANE\_Word version\_code} \\
-\end{tabular}
-\end{center}
-The \code{version\_code} argument in the request is the SANE
-version-code of the network backend that is contacting the network
-daemon (see Section~\ref{sec:saneversioncode}). The
-``build-revision'' in the version code is used to hold the network
-protocol version. The SANE network daemon receiving such a request
-must make sure that the network protocol version corresponds to a
-supported version since otherwise the encoding of the network stream
-may be incompatible (even though the SANE interface itself may be
-compatible). The \code{user\_name} argument is the name of the user
-on whose behalf this call is being performed. If the network backend
-cannot determine a user-name, it passes a \code{NULL} pointer for this
-argument. No trust should be placed in the authenticity of this
-user-name. The intent of this string is to provide more convenience
-to the user. E.g., it could be used as the default-user name in
-subsequent authentication calls.
-
-In the reply, \code{status} indicates the completion status. If the
-value is anything other than \code{SANE\_STA\-TUS\_GOOD}, the
-remainder of the reply has undefined values.\footnote{The sane network
- daemon should be careful not to leak information in the undefined
- portion of the reply.} The \code{version\_code} argument returns the
-SANE version-code that the network daemon supports. See the comments
-in the previous paragraph on the meaning of the build-revision in this
-version code.
-
-\subsection{\code{\defn{SANE\_NET\_GET\_DEVICES}}}
-
-RPC Code: 1
-
-This RPC is used to obtain the list of devices accessible by the SANE
-daemon.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{void} & \code{SANE\_Word status} \\
- & \code{SANE\_Device ***device\_list} \\
-\end{tabular}
-\end{center}
-There are no arguments in the request for this call.
-
-In the reply, \code{status} indicates the completion status. If the
-value is anything other than \code{SANE\_STA\-TUS\_GOOD}, the
-remainder of the reply has undefined values. The \code{device\_list}
-argument is a pointer to a \code{NULL}-terminated array of
-\code{SANE\_Device} pointers.
-
-\subsection{\code{\defn{SANE\_NET\_OPEN}}}
-
-RPC Code: 2
-
-This RPC is used to open a connection to a remote SANE device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_String device\_name} & \code{SANE\_Word status} \\
- & \code{SANE\_Word handle} \\
- & \code{SANE\_String resource} \\
-\end{tabular}
-\end{center}
-The \code{device\_name} argument specifies the name of the device to
-open.
-
-In the reply, \code{status} indicates the completion status. If the
-value is anything other than \code{SANE\_STA\-TUS\_GOOD}, the
-remainder of the reply has undefined values. The \code{handle}
-argument specifies the device handle that uniquely identifies the
-connection. The \code{resource} argument is used to request
-authentication. If it has a non-\code{NULL} value, the network
-backend should authenticate the specified resource and then retry this
-operation (see Section~\ref{sec:authorization} for details on how to
-authorize a resource).
-
-\subsection{\code{\defn{SANE\_NET\_CLOSE}}}
-
-RPC Code: 3
-
-This RPC is used to close a connection to a remote SANE device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{SANE\_Word dummy} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the connection that should be
-closed.
-
-In the reply, the \code{dummy} argument is unused. Its purpose is to
-ensure proper synchronization (without it, a net client would not be
-able to determine when the RPC has completed).
-
-\subsection{\code{\defn{SANE\_NET\_GET\_OPTION\_DESCRIPTORS}}}
-
-RPC Code: 4
-
-This RPC is used to obtain {\em all\/} the option descriptors for a
-remote SANE device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{Option\_Descriptor\_Array odesc} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the remote device whose option
-descriptors should be obtained.
-
-In the reply, the \code{odesc} argument is used to return the array of
-option descriptors. The option descriptor array has the following
-structure:
-\begin{quote}\index{Option\_Descriptor\_Array}
-\begin{verbatim}
-struct Option_Descriptor_Array
- {
- SANE_Word num_options;
- SANE_Option_Descriptor **desc;
- };
-\end{verbatim}
-\end{quote}
-
-
-\subsection{\code{\defn{SANE\_NET\_CONTROL\_OPTION}}}
-
-RPC Code: 5
-
-This RPC is used to control (inquire, set, or set to automatic) a
-specific option of a remote SANE device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{SANE\_Status status} \\
- \code{SANE\_Word option} & \code{SANE\_Word info} \\
- \code{SANE\_Word action} & \code{SANE\_Word value\_type} \\
- \code{SANE\_Word value\_type} & \code{SANE\_Word value\_size} \\
- \code{SANE\_Word value\_size} & \code{void *value} \\
- \code{void *value} & \code{SANE\_String *resource} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the remote device whose option
-should be controlled. Argument \code{option} is the number (index) of
-the option that should be controlled. Argument \code{action}
-specifies what action should be taken (get, set, or set automatic).
-Argument \code{value\_type} specifies the type of the option value
-(must be one of \code{SANE\_TYPE\_BOOL}, \code{SANE\_TYPE\_INT},
-\code{SANE\_TYPE\_FIXED}, \code{SANE\_TYPE\_STR\-ING},
-\code{SANE\_TYPE\_BUTTON}). Argument \code{value\_size} specifies
-the size of the option value in number of bytes (see
-Section~\ref{sec:valuesize} for the precise meaning of this value).
-Finally, argument \code{value} is a pointer to the option value. It
-must be a writeable area that is at least \code{value\_size} bytes
-large. (Note that this area must be writable even if the action is to
-set the option value. This is because the backend may not be able to
-set the exact option value, in which case the option value is used to
-return the next best value that the backend has chosen.)
-
-In the reply, argument \code{resource} is set to the name of the
-resource that must be authorized before this call can be retried. If
-this value is non-\code{NULL}, all other arguments have undefined
-values (see Section~\ref{sec:authorization} for details on how to
-authorize a resource). Argument \code{status} indicates the
-completion status. If the value is anything other than
-\code{SANE\_STA\-TUS\_GOOD}, the remainder of the reply has undefined
-values. The \code{info} argument returns the information on how well
-the backend was able to satisfy the request. For details, see the
-description of the corresponding argument in
-Section~\ref{sec:control}. Arguments \code{value\_type} and
-\code{value\_size} have the same values as the arguments by the same
-name in corresponding request. The values are repeated here to ensure
-that both the request and the reply are self-contained (i.e., they can
-be encoded and decoded independently). Argument \code{value} is holds
-the value of the option that has become effective as a result of this
-RPC.
-
-
-\subsection{\code{\defn{SANE\_NET\_GET\_PARAMETERS}}}
-
-RPC Code: 6
-
-This RPC is used to obtain the scan parameters of a remote SANE
-device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{SANE\_Status status} \\
- & \code{SANE\_Parameters params} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the connection to the remote
-device whose scan parameters should be returned.
-
-In the reply, \code{status} indicates the completion status. If the
-value is anything other than \code{SANE\_STA\-TUS\_GOOD}, the
-remainder of the reply has undefined values. The argument
-\code{params} is used to return the scan parameters.
-
-\subsection{\code{\defn{SANE\_NET\_START}}}
-
-RPC Code: 7
-
-This RPC is used to start image acquisition (scanning).
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{SANE\_Status status} \\
- & \code{SANE\_Word port} \\
- & \code{SANE\_Word byte\_order} \\
- & \code{SANE\_String resource} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the connection to the remote
-device from which the image should be acquired.
-
-In the reply, argument \code{resource} is set to the name of the
-resource that must be authorized before this call can be retried. If
-this value is non-\code{NULL}, all other arguments have undefined
-values (see Section~\ref{sec:authorization} for details on how to
-authorize a resource). Argument, \code{status} indicates the
-completion status. If the value is anything other than
-\code{SANE\_STA\-TUS\_GOOD}, the remainder of the reply has
-undefined values. The argument \code{port} returns the port number
-from which the image data will be available. To read the image data,
-a network client must connect to the remote host at the indicated port
-number. Through this port, the image data is transmitted as a
-sequence of data records. Each record starts with the data length in
-bytes. The data length is transmitted as a sequence of four bytes.
-These bytes should be interpreted as an unsigned integer in big-endian
-format. The four length bytes are followed by the number of data
-bytes indicated by the length. Except for byte-order, the data is in
-the same format as defined for \code{sane\_read()}. Since some
-records may contain no data at all, a length value of zero is
-perfectly valid. The special length value of \code{0xffffffff} is
-used to indicate the end of the data stream. That is, after receiving
-a record length of \code{0xffffffff}, the network client should close
-the data connection and stop reading data.
-
-Argument \code{byte\_order} specifies the byte-order of the image
-data. A value of 0x1234 indicates little-endian format, a value of
-0x4321 indicates big-endian format. All other values are presently
-undefined and reserved for future enhancements of this protocol. The
-intent is that a network server sends data in its own byte-order and
-the client is responsible for adjusting the byte-order, if necessary.
-This approach causes no unnecessary overheads in the case where the
-server and client byte-order match and puts the extra burden on the
-client side when there is a byte-order mismatch. Putting the burden
-on the client-side improves the scalability properties of this
-protocol.
-
-\subsection{\code{\defn{SANE\_NET\_CANCEL}}}
-
-RPC Code: 8
-
-This RPC is used to cancel the current operation of a remote SANE
-device.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_Word handle} & \code{SANE\_Word dummy} \\
-\end{tabular}
-\end{center}
-The \code{handle} argument identifies the connection whose operation
-should be cancelled.
-
-In the reply, the \code{dummy} argument is unused. Its purpose is to
-ensure proper synchronization (without it, a net client would not be
-able to determine when the RPC has completed).
-
-\subsection{\code{\defn{SANE\_NET\_AUTHORIZE}}}\label{sec:authorization}
-\index{network authorization}
-
-RPC Code: 9
-
-This RPC is used to pass authorization data from the net client to the
-net server.
-\begin{center}
-\begin{tabular}{ll}
- {\bf request:} & {\bf reply:} \\
- \code{SANE\_String resource} & \code{SANE\_Word dummy} \\
- \code{SANE\_String username} & \\
- \code{SANE\_String password} & \\
-\end{tabular}
-\end{center}
-The \code{resource} argument specifies the name of the resource to be
-authorized. This argument should be set to the string returned in the
-\code{resource} argument of the RPC reply that required this
-authorization call. The \code{username} and \code{password} are the
-name of the user that is accessing the resource and the password for
-the specified resource/user pair.
-
-Since the password is not encrypted during network transmission, it is
-recommended to use the following extension:
-
-If the server adds the string `\code{\$MD5\$}' to the resource-name followed
-by a random string not longer then 128 bytes, the client may answer with the
-MD5 digest of the concatenation of the password and the random string. To
-differentiate between the MD5 digest and a strange password the client prepends
-the MD5 digest with the string `\code{\$MD5\$}'.
-
-In the reply, \code{dummy} is completely unused. Note that there is
-no direct failure indication. This is unnecessary since a net client
-will retry the RPC that resulted in the authorization request until
-that call succeeds (or until the request is cancelled). The RPC that resulted
-in the authorization request continues after the reply from the client and may
-fail with \code{SANE\_STATUS\_ACCESS\_DENIED}.
-
-
-\subsection{\code{\defn{SANE\_NET\_EXIT}}}
-
-RPC Code: 10
-
-This RPC is used to disconnect a net client from a net server. There
-are no request or reply arguments in this call. As a result of this
-call, the connection between the client and the server that was
-established by the \code{SANE\_NET\_INIT} call will be closed.
-
-% Local Variables:
-% mode: latex
-% TeX-master: "sane.tex"
-% End:
diff --git a/doc/sane-canon_lide70.man b/doc/sane-canon_lide70.man
new file mode 100644
index 0000000..ae807a3
--- /dev/null
+++ b/doc/sane-canon_lide70.man
@@ -0,0 +1,104 @@
+.TH sane\-canon_lide70 5 "26 Nov 2019" "@PACKAGEVERSION@" "SANE Scanner Access Now Easy"
+.IX sane\-canon_lide70
+.SH NAME
+sane\-canon_lide70 \- SANE backend for the Canon LiDE 70 USB flatbed scanner
+.SH DESCRIPTION
+The
+.B canon_lide70
+library implements a SANE (Scanner Access Now Easy) backend that
+provides access to the Canon Inc. CanoScan LiDE 70 flatbed scanner.
+.PP
+Due to Canon's unwillingness to provide scanner documentation, this
+software was developed by analyzing the USB traffic of the Windows
+XP driver. The precise meaning of the individual commands that are sent
+to the scanner is known only to a very limited extent. Some sophistication
+present in the Windows XP driver has been left out. There is, for example,
+no active calibration.
+.PP
+TESTERS ARE WELCOME. Send your bug reports and comments to
+the sane\-devel mailing list <sane\-devel@alioth-lists.debian.net>
+.PP
+The
+.B Canoscan LiDE 600
+(or 600f, with film unit) is closely related to the LiDE 70, but
+it does not work with this backend. Support for the LiDE 600 will
+be added by the end of 2020.
+.PP
+.SH CONFIGURATION
+The
+.I @CONFIGDIR@/canon_lide70.conf
+file identifies the LiDE 70 by its vendor code 0x04a9 and its
+product code 0x2225. For the LiDE 600(f) the product code would be 0x2224.
+.PP
+.SH BACKEND SPECIFIC OPTIONS
+.PP
+.B Scan Mode:
+.TP
+\-\-resolution 75|150|300|600|1200 [default 600]
+.BR
+Sets the resolution of the scanned image in dots per inch. Scanning at 1200 dpi is very slow.
+.TP
+\-\-mode Color|Gray|Lineart [default: Color]
+.BR
+Selects the scan mode. Lineart means fully black and fully white pixels only.
+.TP
+\-\-threshold 0..100 (in steps of 1) [default 75]
+.BR
+Select minimum-brightness percentage to get a white point, relevant only for Lineart
+.TP
+\-\-non-blocking[=(yes|no)] [inactive]
+.BR
+This option has not yet been implemented. Scans are captured in a temporary file with a typical size of 100MB.
+.PP
+.B Geometry:
+.TP
+\-l 0..216.069 [default 0]
+ Top-left x position of scan area in millimeters.
+.TP
+\-t 0..297 [default 0]
+ Top-left y position of scan area in millimeters.
+.TP
+\-x 0..216.069 [default 80]
+ Width of scan-area in millimeters.
+.TP
+\-y 0..297 [default 100]
+ Height of scan-area in millimeters.
+.PP
+.SH FILES
+.TP
+.I @CONFIGDIR@/canon_lide70.conf
+The backend configuration file
+.TP
+.I @LIBDIR@/libsane\-canon_lide70.a
+The static library implementing this backend.
+.TP
+.I @LIBDIR@/libsane\-canon_lide70.so
+The shared library implementing this backend (present on systems that
+support dynamic loading).
+.SH ENVIRONMENT
+.TP
+.B SANE_DEBUG_CANON_LIDE70
+If the library was compiled with debug support enabled, this
+environment variable controls the debug level for this backend. Higher
+debug levels increase the verbosity of the output.
+
+Example:
+.br
+SANE_DEBUG_CANON_LIDE70=128 scanimage > /dev/null
+.SH KNOWN PROBLEMS
+At low resolutions (75 and 150 dpi, implying high slider speeds)
+the scanner misses the top one millimeter of the scan area. This can
+be remedied by shifting the document one millimeter downward, in cases
+where such precision matters. Note that xsane uses the 75 dpi mode for
+prescans.
+.PP
+It is recommended that in xsane the gamma value be set to approximately 1.5
+to get more realistic colors. This also wipes out some artifacts caused by
+the lack of real calibration.
+.SH "SEE ALSO"
+sane(7), sane\-usb(5), sane\-find\-scanner(1), scanimage(1)
+.br
+http://www.juergen-ernst.de/info_sane.html
+.br
+.SH AUTHOR
+pimvantend, building upon pioneering work by Juergen Ernst.
diff --git a/doc/sane-escl.man b/doc/sane-escl.man
index 21a4d6c..a737684 100644
--- a/doc/sane-escl.man
+++ b/doc/sane-escl.man
@@ -7,7 +7,28 @@ The
.B sane\-escl
library implements a SANE (Scanner Access Now Easy) backend that
provides access to eSCL protocol scanners.
-
+.PP
+Currently, the following models work with this backend (This list is not exhaustive):
+.PP
+.RS
+BROTHER DCP-L2530
+.br
+CANON IR C3520
+.br
+CANON PIXMA TS3100, TS3150, TS3300, TS3151, TS3350, TS3351,
+.br
+CANON PIXMA TS3352, TS6150, TS8050, TS9100, TR4540, TR8500,
+.br
+CANON PIXMA TR8520
+.br
+EPSON ET3740, ET4750
+.br
+HP LASERJET MFP M28W, OFFICEJET 4630, OFFICEJET PRO 8610
+.br
+RICOH SP3710S
+.br
+XEROX VERSALINK C7220
+.RE
.PP
The "escl" backend for SANE supports AirScan/eSCL devices that announce
themselves on mDNS as _uscan._utcp or _uscans._utcp.
diff --git a/doc/sane-fujitsu.man b/doc/sane-fujitsu.man
index ccc3d89..400a35e 100644
--- a/doc/sane-fujitsu.man
+++ b/doc/sane-fujitsu.man
@@ -1,4 +1,4 @@
-.TH sane\-fujitsu 5 "08 Apr 2017" "@PACKAGEVERSION@" "SANE Scanner Access Now Easy"
+.TH sane\-fujitsu 5 "07 Feb 2020" "@PACKAGEVERSION@" "SANE Scanner Access Now Easy"
.IX sane\-fujitsu
.SH NAME
@@ -10,7 +10,7 @@ The
library implements a SANE (Scanner Access Now Easy) backend which
provides access to most Fujitsu flatbed and ADF scanners.
-This document describes backend version 134, which shipped with SANE 1.0.28.
+This document describes backend version 136, which shipped with SANE 1.0.30.
.SH SUPPORTED HARDWARE
This version supports every known model which speaks the Fujitsu SCSI and
@@ -54,7 +54,7 @@ Effort has been made to expose all hardware options, including:
source s
.RS
Selects the source for the scan. Options
-may include "Flatbed", "ADF Front", "ADF Back", "ADF Duplex".
+may include "Flatbed", "ADF Front", "ADF Back", "ADF Duplex", "Card Front", "Card Back", "Card Duplex".
.RE
.PP
mode m
diff --git a/doc/sane-genesys.man b/doc/sane-genesys.man
index 6540754..837a5f6 100644
--- a/doc/sane-genesys.man
+++ b/doc/sane-genesys.man
@@ -226,38 +226,15 @@ increase the verbosity of the output. If the debug level is set to 1 or higher,
some debug options become available that are normally hidden. Handle them with
care. This will print messages related to core genesys functions.
.TP
-.B SANE_DEBUG_GENESYS_LOW
-This environment variable controls the debug level for low level functions
-common to all genesys ASICs.
-.TP
-.B SANE_DEBUG_GENESYS_GL646
-This environment variable controls the debug level for the specific GL646 code
-part.
-.TP
-.B SANE_DEBUG_GENESYS_GL841
-This environment variable controls the debug level for the specific GL841 code
-part.
-.TP
-.B SANE_DEBUG_GENESYS_GL843
-This environment variable controls the debug level for the specific GL843 code
-part.
-.TP
-.B SANE_DEBUG_GENESYS_GL847
-This environment variable controls the debug level for the specific GL847 code
-part.
-.TP
-.B SANE_DEBUG_GENESYS_GL124
-This environment variable controls the debug level for the specific GL124 code
-part.
+.B SANE_DEBUG_GENESYS_IMAGE
+If the library was compiled with debug support enabled, this environment
+variable enables logging of intermediate image data. To enable this mode,
+set the environmental variable to 1.
Example (full and highly verbose output for gl646):
.br
export SANE_DEBUG_GENESYS=255
-.br
-export SANE_DEBUG_GENESYS_LOW=255
-.br
-export SANE_DEBUG_GENESYS_GL646=255
.SH CREDITS
diff --git a/doc/sane-pixma.man b/doc/sane-pixma.man
index ea85ec5..87aadd4 100644
--- a/doc/sane-pixma.man
+++ b/doc/sane-pixma.man
@@ -1,4 +1,4 @@
-.TH "sane\-pixma" "5" "28 Dec 2019" "@PACKAGEVERSION@" "SANE Scanner Access Now Easy"
+.TH "sane\-pixma" "5" "15 Aug 2020" "@PACKAGEVERSION@" "SANE Scanner Access Now Easy"
.IX sane\-pixma
.SH NAME
sane\-pixma \- SANE backend for Canon Multi-Function Printers and CanoScan Scanners
@@ -15,9 +15,9 @@ over IPv4 as well as IPv6 (MFNP over IPv6 is untested).
Currently, the following models work with this backend:
.PP
.RS
-PIXMA E510
+PIXMA E410, E510
.br
-PIXMA G2000, G2010, G2100
+PIXMA G2000, G2010, G2100, G4000
.br
PIXMA MG2100, MG2200, MG2400, MG2500, MG2900, MG3000, MG3100
.br
@@ -33,7 +33,7 @@ PIXMA MP210, MP220, MP230, MP240, MP250, MP260, MP270, MP280
.br
PIXMA MP360, MP370, MP390
.br
-PIXMA MP450, MP460, MP470, MP480, MP490
+PIXMA MP450, MP460, MP470, MP480, MP490, MP495
.br
PIXMA MP500, MP510, MP520, MP530, MP540, MP550, MP560
.br
@@ -51,7 +51,11 @@ PIXMA MX410, MX420, MX470, MX510, MX520, MX530, MX700, MX720
.br
PIXMA MX850, MX860, MX870, MX882, MX885, MX890, MX920, MX7600
.br
-PIXMA TS3100, TS5000, TS6100, TS6200, TS8000, TS8200
+PIXMA TR4500
+.br
+PIXMA TS3100, TS3300, TS5000, TS5100, TS6100, TS6200, TS8000
+.br
+PIXMA TS8200
.br
PIXUS MP10
.br
@@ -69,11 +73,13 @@ imageCLASS MF5730, MF5770, MF6550, MPC200
.br
imageCLASS D420, D480, D530, D570
.br
-i-SENSYS MF210, MF230, MF240, MF620, MF630, MF640, MF645C, MF730
+i-SENSYS MF210, MF230, MF240, MF440, MF620, MF630, MF640
+.br
+i-SENSYS MF645C, MF730, MF731/733, MF741/743
.br
-i-SENSYS MF731/733, MF741/743, MF3010, MF4320d, MF4330d, MF4500
+i-SENSYS MF3010, MF4320d, MF4330d, MF4500, MF4700, MF4800
.br
-i-SENSYS MF4700, MF4800, MF6100, MF8030, MF8200C, MF8300
+i-SENSYS MF6100, MF8030, MF8200C, MF8300
.br
imageRUNNER 1020/1024/1025, 1133
.br
@@ -81,7 +87,7 @@ CanoScan 8800F, 9000F, 9000F Mark II
.br
CanoScan LiDE 300, 400
.br
-MAXIFY MB2000, MB2100, MB2300, MB2700, MB5000, MB5400
+MAXIFY MB2000, MB2100, MB2300, MB2700, MB5000, MB5100, MB5400
.RE
.PP
The following models are not well tested and/or the scanner sometimes hangs
@@ -97,31 +103,31 @@ in the backend so that they get recognized and activated.
Feedback in the sane\-devel mailing list welcome.
.PP
.RS
-PIXMA E400, E410, E460, E470, E480, E500, E560, E600, E610
+PIXMA E400, E460, E470, E480, E500, E560, E600, E610
.br
PIXMA E3100, E3300, E4200
.br
PIXMA MG4100, MG6500, MG6600, MG6800, MG6900, MG8100
.br
-PIXMA MP375R, MP493, MP495, MP740
+PIXMA MP375R, MP493, MP740
.br
PIXMA MX320, MX390, MX430, MX450, MX490, MX710
.br
-PIXMA G3000, G3010, G4000, G4010, G6000, G6080
+PIXMA G3000, G3010, G4010, G6000, G6080, G7000, GM4000
.br
-PIXMA TR4500, TR7500, TR7530, TR8500, TR8530, TR8580, TR9530
+PIXMA TR7500, TR7530, TR8500, TR8530, TR8580, TR9530
.br
-PIXMA TS5100, TS6000, TS6130, TS6180, TS6230, TS6280, TS6300
+PIXMA TS6000, TS6130, TS6180, TS6230, TS6280, TS6300, TS6330
.br
-PIXMA TS6330, TS6380, TS7330, TS8100, TS8130, TS8180, TS8230
+PIXMA TS6380, TS7330, TS8100, TS8130, TS8180, TS8230, TS8280
.br
-PIXMA TS8280,, TS8300, TS8330, TS8380, TS9000, TS9100, TS9180
+PIXMA TS8300, TS8330, TS8380, TS9000, TS9100, TS9180, TS9500
.br
-PIXMA TS9500, TS9580
+PIXMA TS9580
.br
PIXUS MP5, XK50, XK60, XK70, XK80
.br
-imageCLASS MF810/820, MF5630, MF5650, MF5750, MF8170c
+imageCLASS MF720, MF810/820, MF5630, MF5650, MF5750, MF8170c
.br
imageCLASS MPC190, D550
.br
@@ -129,7 +135,7 @@ i-SENSYS MF110, MF220, MF260, MF410, MF420, MF510, MF520, MF740
.br
i-SENSYS MF5880dn, MF5900, MF6680dn, MF8500C
.br
-MAXIFY MB5100, MB5300
+MAXIFY MB5300
.RE
.PP
The following models may use partly the same Pixma protocol as other devices
@@ -234,10 +240,25 @@ or 1 = JPEG, 2 = TIFF, 3 = PDF, 4 = Compact PDF. For some scanners this value
is equivalent to the number of the pressed button. Not all scanners can provide
this data.
.TP
-.I scan-resolution
+.I scan\-resolution
(read only) Returns the resolution of the scan operation if the scanner
provides that data. Known values: 1 = 75 dpi, 2 = 150 dpi, 3 = 300 dpi,
4 = 600 dpi. Not all scanners can provide this data.
+.TP
+.I document\-type
+(read only) Returns the type of the scanned document if the scanner provides
+that data. Known values: 1 = Document, 2 = Photo, 3 = Auto scan. Not all scanners
+can provide this data.
+.TP
+.I adf\-status
+(read only) Returns the status of the document feeder if the scanner provides
+that data. Known values: 1 = ADF empty, 2 = ADF filled. Not all scanners can
+provide this data.
+.TP
+.I adf\-orientation
+(read only) Returns the scan orientation of the medium scanned from ADF if the
+scanner provides that data. Known values: 1 = Portrait, 2 = Landscape. Not all
+scanners can provide this data.
.SH FILES
.TP
.I @LIBDIR@/libsane\-pixma.a
@@ -418,6 +439,8 @@ to "/tmp/config:" would result in directories "tmp/config", ".", and
.SH "SEE ALSO"
.BR sane (7),
.BR sane\-dll (5),
+.BR scanimage (1),
+.BR gamma4scanimage (1),
.PP
In case of trouble with a recent Pixma model, try the latest code for
the pixma backend, available in the Sane git repository at:
diff --git a/doc/sane.man b/doc/sane.man
index 070a993..ed8116c 100644
--- a/doc/sane.man
+++ b/doc/sane.man
@@ -40,9 +40,8 @@ provides some means to manage one or more other backends.
.SH "SOFTWARE PACKAGES"
The package
.RB ` sane\-backends '
-contains a lot of backends, documentation (including the
-.B SANE
-standard), networking support, and the command line frontend
+contains a lot of backends, documentation, networking support, and the
+command line frontend
.RB ` scanimage '.
The frontends
.RB ` xscanimage "', `" xcam "', and `" scanadf '
@@ -65,7 +64,7 @@ A name with a number in parenthesis (e.g.
points to a manual page. In this case
.RB ` "man 5 sane\-dll" '
will display the page. Entries like
-.RI ` @DOCDIR@/sane.tex '
+.RI ` @DOCDIR@/README '
are references to text files that were copied to the
.B SANE
documentation directory
@@ -218,6 +217,11 @@ The canon_dr backend supports the Canon DR-Series ADF SCSI and USB scanners. See
.BR sane\-canon_dr (5)
for details.
.TP
+.B canon_lide70
+The canon_lide70 backend supports the CanoScan LiDE 70 USB scanner. See
+.BR sane\-canon_lide70 (5)
+for details.
+.TP
.B canon_pp
The canon_pp backend supports the CanoScan FB330P, FB630P, N340P and N640P
parallel port scanners. See
@@ -665,14 +669,7 @@ The
.B SANE
standard defines the application programming interface (API) that is used to
communicate between frontends and backends. It can be found at
-.I @DOCDIR@/sane.ps
-(if latex is installed on your system) and on the
-.B SANE
-website:
-.I http://www.sane\-project.org/html/
-(HTML), or
-.I http://www.sane\-project.org/sane.ps
-(Postscript).
+.I http://sane\-project.gitlab.io/standard/ .
.PP
There is some more information for programmers in
.IR @DOCDIR@/backend\-writing.txt .
@@ -712,7 +709,7 @@ support dynamic loading).
.TP
.I @DOCDIR@/*
.B SANE
-documentation: The standard, READMEs, text files for backends etc.
+documentation: The READMEs, text files for backends etc.
.SH "PROBLEMS"
If your device isn't found but you know that it is supported, make
diff --git a/doc/sane.tex b/doc/sane.tex
deleted file mode 100644
index 71ff6fc..0000000
--- a/doc/sane.tex
+++ /dev/null
@@ -1,1892 +0,0 @@
-\documentclass[11pt]{report}
-
-\usepackage{times,graphicx,url}
-% Not Currently using changebar package so comment out to reduce
-% external dependencies.
-%\usepackage{changebar}
-
-\setlength{\parindent}{0pt}
-\setlength{\parskip}{1.5ex plus 0.5ex minus 0.5ex}
-\setlength{\textwidth}{6.5in}
-\setlength{\textheight}{8.5in}
-\setlength{\marginparwidth}{0pt}
-\setlength{\oddsidemargin}{0pt}
-\setlength{\evensidemargin}{0pt}
-\setlength{\marginparsep}{0pt}
-\addtolength{\topmargin}{-0.75in}
-
-\title{\huge SANE Standard Version 1.06}
-\author{}
-\date{2008-05-03}
-
-\makeindex
-
-\begin{document}
-
-\newcommand{\filename}[1]{{\tt #1}}
-\newcommand{\code}[1]{{\tt #1}}
-\newcommand{\var}[1]{{\it #1}}
-\newcommand{\defn}[1]{#1\index{#1}}
-
-% Uncomment if adding changebars to text
-%\begin{latexonly}
-% \setcounter{changebargrey}{0} % black change bars
-%\end{latexonly}
-
-\maketitle
-\tableofcontents
-\listoffigures
-\listoftables
-
-
-\chapter{Preface}
-
-The SANE standard is being developed by a group of free-software
-developers. The process is open to the public and comments as well as
-suggestions for improvements are welcome. Information on how to join
-the SANE development process can be found in Chapter
-\ref{chap:contact}.
-
-The SANE standard is intended to streamline software development by
-providing a standard application programming interface to access
-raster scanner hardware. This should reduce the number of different
-driver implementations, thereby reducing the need for reimplementing
-similar code.
-
-
-\section{About This Document}
-
-This document is intended for developers who are creating either an
-application that requires access to raster scanner hardware and for
-developers who are implementing a SANE driver. It does not cover
-specific implementations of SANE components. Its sole purpose is to
-describe and define the SANE application interface that will enable
-any application on any platform to interoperate with any SANE backend
-for that platform.
-
-The remainder of this document is organized as follows.
-Chapter~\ref{chap:intro} provides introductional material.
-Chapter~\ref{chap:environ} presents the environment SANE is designed
-for. Chapter~\ref{chap:api} details the SANE Application Programmer
-Interface. Chapter~\ref{chap:net} specifies the network protocol that
-can be used to implement the SANE API in a network transparent
-fashion. Finally, Chapter~\ref{chap:contact} gives information on how
-to join the SANE development process.
-
-\subsection{Typographic Conventions}
-
-Changes since the last revision of this document are highlighted
-like this:
-
-% \begin{changebar}
-% Paragraphs that changed since the last revision of the documention
-% are marked like this paragraph.
-% \end{changebar}
-
-\chapter{Introduction}\label{chap:intro}
-
-SANE is an application programming interface (API) that provides
-standardized access to any raster image scanner hardware. The
-standardized interface allows to write just one driver for each
-scanner device instead of one driver for each scanner and application.
-The reduction in the number of required drivers provides significant
-savings in development time. More importantly, SANE raises the level
-at which applications can work. As such, it will enable applications
-that were previously unheard of in the UNIX world. While SANE is
-primarily targeted at a UNIX environment, the standard has been
-carefully designed to make it possible to implement the API on
-virtually any hardware or operating system.
-
-SANE is an acronym for ``Scanner Access Now Easy.'' Also, the hope is
-that SANE is sane in the sense that it will allow easy implementation
-of the API while accommodating all features required by today's
-scanner hardware and applications. Specifically, SANE should be broad
-enough to accommodate devices such as scanners, digital still and
-video cameras, as well as virtual devices like image file filters.
-
-\section{Terminology}
-
-An application that uses the SANE interface is called a SANE {\em
- frontend}. A driver that implements the SANE interface is called a
-SANE {\em backend}. A {\em meta backend\/} provides some means to
-manage one or more other backends.
-
-
-\chapter{The SANE Environment}\label{chap:environ}
-
-SANE is defined as a C-callable library interface. Accessing a raster
-scanner device typically consists of two phases: first, various
-controls of the scanner need to be setup or queried. In the second
-phase, one or more images are acquired.
-
-Since the device controls are widely different from device to device,
-SANE provides a generic interface that makes it easy for a frontend to
-give a user access to all controls without having to understand each
-and every device control. The design principle used here is to
-abstract each device control into a SANE {\em option\/}. An option is
-a self-describing name/value pair. For example, the brightness
-control of a camera might be represented by an option called
-\code{brightness} whose value is an integer in the range from 0 to
-255.
-
-With self-describing options, a backend need not be concerned with
-{\em presentation\/} issues: the backend simply provides a list of
-options that describe all the controls available in the device.
-Similarly, there are benefits to the frontend: it need not be
-concerned with the {\em meaning\/} of each option. It simply provides
-means to present and alter the options defined by the backend.
-
-
-\section{Attaching to a SANE backend}
-
-The process through which a SANE frontend connects to a backend is
-platform dependent. Several possibilities exist:
-\begin{itemize}
-
-\item {\bf Static linking:} A SANE backend may be linked directly into
- a frontend. While the simplest method of attaching to a backend, it
- is somewhat limited in functionality since the available devices is
- limited to the ones for which support has been linked in when the
- frontend was built. But even so static linking can be quite useful,
- particularly when combined with a backend that can access scanners
- via a network. Also, it is possible to support multiple backends
- simultaneously by implementing a meta backend that manages several
- backends that have been compiled in such a manner that they export
- unique function names. For example, a backend called \code{be}
- would normally export a function called \code{sane\_read()}. If
- each backend would provide such a function, static linking would
- fail due to multiple conflicting definitions of the same symbol.
- This can be resolved by having backend \code{be} include a
- header file that has lines of the form:
- \begin{quote}
-\begin{verbatim}
-#define sane_read be_sane_read
-\end{verbatim}
- \end{quote}
- With definitions of this kind, backend \code{be} will export
- function name \code{be\_sane\_read()}. Thus, all backends will
- export unique names. As long as a meta backend knows about these
- names, it is possible to combine several backends at link time and
- select and use them dynamically at runtime.
-
-\item {\bf Dynamic linking:} A simpler yet more powerful way to
- support multiple backends is to exploit dynamic linking on platforms
- that support it. In this case, a frontend is linked against a
- shared library that implements any SANE backend. Since each
- dynamically linked backend exports the same set of global symbols
- (all starting with the prefix \code{sane\_}), the dynamic library
- that gets loaded at runtime does not necessarily have to be the same
- one as one the frontend got linked against. In other words, it is
- possible to switch the backend by installing the appropriate backend
- dynamic library.
-
- More importantly, dynamic linking makes it easy to implement a meta
- backend that loads other backends {\em on demand}. This is a
- powerful mechanism since it allows adding new backends merely by
- installing a shared library and updating a configuration file.
-
-\item {\bf Network connection:} Arguably the ultimate way to attach to
- a scanner is by using the network to connect to a backend on a
- remote machine. This makes it possible to scan images from any host
- in the universe, as long as there is a network connection to that
- host and provided the user is permitted to access that scanner.
-
-\end{itemize}
-
-\begin{figure}[htbp]
- \begin{center}
- \leavevmode
- \includegraphics[width=\textwidth]{figs/hierarchy}
- \caption{Example SANE Hiearchy}
- \label{fig:hierarchy}
- \end{center}
-\end{figure}
-
-The above discussion lists just a few ways for frontends to attach to
-a backend. It is of course possible to combine these solutions to
-provide an entire hierarchy of SANE backends. Such a hierarchy is
-depicted in Figure~\ref{fig:hierarchy}. The figure shows that machine
-A uses a dynamic-linking based meta backend called \code{dll} to
-access the backends called \code{pnm}, \code{mustek}, and \code{net}.
-The first two are real backends, whereas the last one is a meta
-backend that provides network transparent access to remote scanners.
-In the figure, machine B provides non-local access to its scanners
-through the SANE frontend called \code{saned}. The \code{saned} in
-turn has access to the \code{hp} and \code{autolum} backends through
-another instance of the \code{dll} backend. The \code{autolum} meta
-backend is used to automatically adjust the luminance (brightness) of
-the image data acquired by the camera backend called \code{qcam}.
-
-Note that a meta backend really is both a frontend and a backend at
-the same time. It is a frontend from the viewpoint of the backends
-that it manages and a backend from the viewpoint of the frontends that
-access it. The name ``meta backend'' was chosen primarily because the
-SANE standard describes the interface from the viewpoint of a (real)
-frontend.
-
-
-\section{Image Data Format}\label{sec:imageformat}\index{image data format}
-
-Arguably the most important aspect of an image acquisition system is
-how images are represented. The SANE approach is to define a simple
-yet powerful representation that is sufficient for vast majority of
-applications and devices. While the representation is simple, the
-interface has been defined carefully to allow extending it in the
-future without breaking backwards compatibility. Thus, it will be
-possible to accommodate future applications or devices that were not
-anticipated at the time this standard was created.
-
-A SANE image is a rectangular area. The rectangular area is
-subdivided into a number of rows and columns. At the intersection of
-each row and column is a quadratic pixel. A pixel consists of one or
-more sample values. Each sample value represents one channel (e.g.,
-the red channel). Each sample value has a certain bit depth. The bit
-depth is fixed for the entire image and can be as small as one bit.
-Valid bit depths are 1, 8, or 16 bits per sample. If a device's
-natural bit depth is something else, it is up to the driver to scale
-the sample values appropriately (e.g., a 4 bit sample could be scaled
-by a factor of four to represent a sample value of depth 8).
-
-\subsection{Image Transmission}
-
-The SANE API transmits an image as a sequence of frames. Each frame
-covers the same rectangular area as the entire image, but may contain
-only a subset of the channels in the final image. For example, a
-red/green/blue image could either be transmitted as a single frame
-that contains the sample values for all three channels or it could be
-transmitted as a sequence of three frames: the first frame containing
-the red channel, the second the green channel, and the third the blue
-channel.
-
-Conceptually, each frame is transmitted a byte at a time. Each byte
-may contain 8 sample values (for an image bit depth of 1), one full
-sample value (for an image bit depth of 8), or a partial sample value
-(for an image bit depth of 16 or bigger). In the latter case, the
-bytes of each sample value are transmitted in the machine's native
-byte order. For depth 1, the leftmost pixel is stored in the most
-significant bit, and the rightmost pixel in the least significant bit.
-\begin{quote}
- \begin{center}
- {\bf Backend Implementation Note}
- \end{center}
- A network-based meta backend will have to ensure that the byte order
- in image data is adjusted appropriately if necessary. For example,
- when the meta backend attaches to the server proxy, the proxy may
- inform the backend of the server's byte order. The backend can then
- apply the adjustment if necessary. In essence, this implements a
- ``receiver-makes-right'' approach.
-\end{quote}
-
-\begin{figure}[htbp]
- \begin{center}
- \leavevmode
- \includegraphics[width=0.5\textwidth]{figs/xfer}
- \caption{Transfer order of image data bytes}
- \label{fig:xfer}
- \end{center}
-\end{figure}
-
-The order in which the sample values in a frame are transmitted is
-illustrated in Figure~\ref{fig:xfer}. As can be seen, the values are
-transmitted row by row and each row is transmitted from left-most to
-right-most column. The left-to-right, top-to-bottom transmission
-order applies when the image is viewed in its normal orientation (as
-it would be displayed on a screen, for example).
-
-If a frame contains multiple channels, then the channels are
-transmitted in an interleaved fashion. Figure~\ref{fig:pixels}
-illustrates this for the case where a frame contains a complete
-red/green/blue image with a bit-depth of 8. For a bit depth of 1,
-each byte contains 8 sample values of a {\em single\/} channel. In
-other words, a bit depth 1 frame is transmitted in a byte interleaved
-fashion.
-
-\begin{figure}[htbp]
- \begin{center}
- \leavevmode
- \includegraphics[width=0.8\textwidth]{figs/image-data}
- \caption{Bit and byte order or image data}
- \label{fig:pixels}
- \end{center}
-\end{figure}
-
-When transmitting an image frame by frame, the frontend needs to know
-what part of the image a frame represents (and how many frames it
-should expect). For that purpose, the SANE API tags every frame with
-a type. This version of the SANE standard supports the following
-frame types:
-\begin{quote}
-\begin{description}
-
-\item[\code{\defn{SANE\_FRAME\_GRAY}}:] The frame contains a single
- channel of data that represents sample values from a spectral band
- that covers the human visual range. The image consists of this
- frame only.
-
-\item[\code{\defn{SANE\_FRAME\_RGB}}:] The frame contains three
- channels of data that represent sample values from the red, green,
- and blue spectral bands. The sample values are interleaved in the
- order red, green, and blue. The image consists of this frame only.
-
-\item[\code{\defn{SANE\_FRAME\_RED}}:] The frame contains one channel
- of data that represents sample values from the red spectral band.
- The complete image consists of three frames:
- \code{SANE\_\-FRA\-ME\_RED}, \code{SANE\_FRAME\_GREEN}, and
- \code{SANE\_FRAME\_BLUE}. The order in which the frames are
- transmitted chosen by the backend.
-
-\item[\code{\defn{SANE\_FRAME\_GREEN}}:] The frame contains one
- channel of data that represents sample values from the green
- spectral band. The complete image consists of three frames:
- \code{SANE\_\-FRA\-ME\_RED}, \code{SANE\_FRAME\_GREEN}, and
- \code{SANE\_FRAME\_BLUE}. The order in which the frames are
- transmitted chosen by the backend.
-
-\item[\code{\defn{SANE\_FRAME\_BLUE}}:] The frame contains one channel
- of data that represents sample values from the blue spectral band.
- The complete image consists of three frames:
- \code{SANE\_\-FRA\-ME\_RED}, \code{SANE\_FRAME\_GREEN}, and
- \code{SANE\_FRAME\_BLUE}. The order in which the frames are
- transmitted chosen by the backend.
-
-\end{description}
-\end{quote}
-
-In frames of type \code{SANE\_FRAME\_GRAY}, when the bit depth is 1 there are
-only two sample values possible, 1 represents minimum intensity
-(black) and 0 represents maximum intensity (white). For all other bit
-depth and frame type combinations, a sample value of 0 represents
-minimum intensity and larger values represent increasing intensity.
-
-The combination of bit depth 1 and \code{SANE\_FRAME\_RGB} (or
-\code{SANE\_FRAME\_RED}, \code{SANE\_FRAME\_GREEN}, \code{SANE\_FRAME\_BLUE})
-is rarely used and may not be supported by every frontend.
-
-\chapter{The SANE Application Programmer Interface (API)}\label{chap:api}
-
-This Section defines version 1 of the SANE application
-programmer interface (API). Any SANE frontend must depend on the
-interface defined in this section only. Converseley, any SANE backend
-must implement its functionality in accordance with this
-specification. The interface as documented here is declared as a C
-callable interface in a file called \filename{sane/sane.h}. This file should
-normally be included via a C pre-processor directive of the form:
-\begin{verbatim}
- #include <sane/sane.h>
-\end{verbatim}
-
-
-\section{Version Control}
-
-The SANE standard is expected to evolve over time. Whenever a change
-to the SANE standard is made that may render an existing frontend or
-backend incompatible with the new standard, the major version number
-must be increased. Thus, any frontend/backend pair is compatible
-provided the major version number of the SANE standard they implement
-is the same. A frontend may implement backwards compatiblity by
-allowing major numbers that are smaller than the expected major number
-(provided the frontend really can cope with the older version). In
-contrast, a backend always provides support for one and only one
-version of the standard. If a specific application does require that
-two different versions of the same backend are accessible at the same
-time, it is possible to do so by installing the two versions under
-different names.
-
-SANE version control also includes a minor version number and a build
-revision. While control of these numbers remains with the implementor
-of a backend, the recommended use is as follows. The minor version is
-incremented with each official release of a backend. The build
-revision is increased with each build of a backend.
-
-The SANE API provides the following five macros to manage version
-numbers.
-\begin{quote}
- \begin{description}
- \item[\code{\defn{SANE\_CURRENT\_MAJOR}}:] The value of this macro is the
- number of the SANE standard that the interface implements.
-
- \item[\code{\defn{SANE\_VERSION\_CODE}(\var{maj},\var{min},\var{bld})}:]
- \label{sec:saneversioncode}
- This macro can be used to build a monotonically increasing version
- code. A SANE version code consists of the SANE standard major
- version number (\var{maj}), the minor version number \var{min},
- and the build revision of a backend (\var{bld}). The major and
- minor version numbers must be in the range 0\ldots255 and the
- build revision must be in the range 0\ldots65535.
-
- Version codes are monotonic in the sense that it is possible to
- apply relational operators (e.g., equality or less-than test)
- directly on the version code rather than individually on the three
- components of the version code.
-
- Note that the major version number alone determines whether a
- frontend/backend pair is compatible. The minor version and the
- build revision are used for informational and bug-fixing purposes
- only.
-
- \item[\code{\defn{SANE\_VERSION\_MAJOR}(\var{vc})}:] This macro returns the
- major version number component of the version code passed in
- argument \var{vc}.
- \item[\code{SANE\_VERSION\_MINOR(\var{vc})}:] This macro returns the
- minor version number component of the version code passed in
- argument \var{vc}.
- \item[\code{SANE\_VERSION\_BUILD(\var{vc})}:] This macro returns the
- build revision component of the version code passed in argument
- \var{vc}.
- \end{description}
-\end{quote}
-
-
-\section{Data Types}
-
-\subsection{Base Types}
-
-The SANE standard is based on just two SANE-specific base types: the
-SANE byte and word.
-\begin{quote}
- \code{typedef \var{some-scalar-type\/} \defn{SANE\_Byte};} \\
- \code{typedef \var{some-scalar-type\/} \defn{SANE\_Word};}
-\end{quote}
-\verb|SANE_Byte| must correspond to some scalar C type that is capable
-of holding values in the range 0 to 255. \verb|SANE_Word| must be
-capable of holding any of the following:
-\begin{itemize}
- \item the truth values \verb|SANE_FALSE| and \verb|SANE_TRUE|
- \item signed integers in the range $-2^{31}\ldots2^{31}-1$
- \item fixed point values in the range $-32768\ldots32767.9999$ with
- a resolution of $1/65536$
- \item 32 bits (for bit sets)
-\end{itemize}
-Note that the SANE standard does not define what C type
-\verb|SANE_Byte| and \verb|SANE_Word| map to. For example, on some
-platforms, the latter may map to \verb|long int| whereas on others it
-may map to \verb|int|. A portable SANE frontend or backend must
-therefore not depend on a particular mapping.
-
-\subsection{Boolean Type}
-
-\code{\defn{SANE\_Bool}} is used for variables that can take one of
-the two truth values \code{\defn{SANE\_FALSE}} and
-\code{\defn{SANE\_TRUE}}. The former value is defined to be 0,
-whereas the latter is 1.\footnote{This is different from ANSI C where
- any non-zero integer value represents logical TRUE.} The C
-declarations for this type are given below.
-\begin{quote}
-\begin{verbatim}
-#define SANE_FALSE 0
-#define SANE_TRUE 1
-typedef SANE_Word SANE_Bool;
-\end{verbatim}
-\end{quote}
-Note that \verb|SANE_Bool| is simply an alias of \verb|SANE_Word|. It
-is therefore always legal to use the latter type in place of the
-former. However, for clarity, it is recommended to use
-\verb|SANE_Bool| whenever a given variable or formal argument has a
-fixed interpretation as a boolean object.
-
-\subsection{Integer Type}
-
-\code{\defn{SANE\_Int}} is used for variables that can take integer
-values in the range $-2^{32}$ to $2^{31}-1$. Its C declaration is
-given below.
-\begin{quote}
-\begin{verbatim}
-typedef SANE_Word SANE_Int;
-\end{verbatim}
-\end{quote}
-Note that \verb|SANE_Int| is simply an alias of \verb|SANE_Word|. It
-is therefore always legal to use the latter type in place of the
-former. However, for clarity, it is recommended to use
-\verb|SANE_Int| whenever a given variable or formal argument has a
-fixed interpretation as an integer object.
-
-
-\subsection{Fixed-point Type}
-
-\code{\defn{SANE\_Fixed}} is used for variables that can take fixed
-point values in the range $-32768$ to $32767.9999$ with a resolution
-of $1/65535$. The C declarations relating to this type are given
-below.
-\begin{quote}
-\begin{verbatim}
-#define SANE_FIXED_SCALE_SHIFT 16
-typedef SANE_Word SANE_Fixed;
-\end{verbatim}
-\end{quote}
-The macro \code{\defn{SANE\_FIXED\_SCALE\_SHIFT}} gives the location
-of the fixed binary point. This standard defines that value to be 16,
-which yields a resolution of $1/65536$.
-
-Note that \verb|SANE_Fixed| is simply an alias of \verb|SANE_Word|.
-It is therefore always legal to use the latter type in place of the
-former. However, for clarity, it is recommended to use
-\verb|SANE_Fixed| whenever a given variable or formal argument has a
-fixed interpretation as a fixed-point object.
-
-For convenience, SANE also defines two macros that convert fixed-point
-values to and from C double floating point values.
-\begin{quote}
- \begin{description}
-
- \item[\code{\defn{SANE\_FIX}(\var{d})}:] Returns the largest SANE
- fixed-point value that is smaller than the double value \var{d}.
- No range checking is performed. If the value of \var{d} is out of
- range, the result is undefined.
-
- \item[\code{\defn{SANE\_UNFIX}(\var{w})}:] Returns the nearest
- double machine number that corresponds to fixed-point value
- \var{w}.
-
- \end{description}
-\end{quote}
-SANE does {\em not\/} require that the following two expressions hold
-true (even if the values of \var{w} and \var{d} are in range):
-\begin{quote}
-\begin{verbatim}
-SANE_UNFIX(SANE_FIX(d)) == d
-SANE_FIX(SANE_UNFIX(w)) == w
-\end{verbatim}
-\end{quote}
-In other words, conversion between fixed and double values may be
-lossy. It is therefore recommended to avoid repeated conversions
-between the two representations.
-
-
-\subsection{Text}
-
-\subsubsection{Character Type}
-
-Type \code{\defn{SANE\_Char}} represents a single text character or
-symbol. At present, this type maps directly to the underlying C
-\verb|char| type (typically one byte). The encoding for such
-characters is currently fixed as ISO LATIN-1. Future versions of this
-standard may map this type to a wider type and allow multi-byte
-encodings to support internationalization. As a result of this, care
-should be taken to avoid the assumption that
-\verb|sizeof(SANE_Char)==sizeof(char)|.
-\begin{quote}
-\begin{verbatim}
-typedef char SANE_Char;
-\end{verbatim}
-\end{quote}
-
-\subsubsection{String Type}
-
-Type \code{\defn{SANE\_String}} represents a text string as a sequence
-of C \verb|char| values. The end of the sequence is indicated by a
-\verb|'\0'| (\defn{NUL}) character.
-\begin{quote}
-\begin{verbatim}
-typedef SANE_Char *SANE_String;
-typedef const SANE_Char *SANE_String_Const;
-\end{verbatim}
-\end{quote}
-The type \code{\defn{SANE\_String\_Const}} is provided by SANE to
-enable declaring strings whose contents is unchangable. Note that in
-ANSI C, the declaration
-\begin{quote}
-\begin{verbatim}
-const SANE_String str;
-\end{verbatim}
-\end{quote}
-declares a string pointer that is constant (not a string pointer that
-points to a constant value).
-
-
-\subsection{Scanner Handle Type}
-
-Access to a scanner is provided through an opaque type called
-\code{\defn{SANE\_Handle}}. The C declaration of this type is given
-below.
-\begin{quote}
-\begin{verbatim}
-typedef void *SANE_Handle;
-\end{verbatim}
-\end{quote}
-While this type is declared to be a void pointer, an application must
-not attempt to interpret the value of a \verb|SANE_Handle|. In
-particular, SANE does not require that a value of this type is a legal
-pointer value.
-
-
-\subsection{Status Type}
-
-Most SANE operations return a value of type \code{\defn{SANE\_Status}}
-to indicate whether the completion status of the operation. If an
-operation completes successfully, \verb|SANE_STATUS_GOOD| is returned.
-In case of an error, a value is returned that indicates the nature of
-the problem. The complete list of available status codes is listed in
-Table \ref{tab:status}. It is recommended to use function
-\code{sane\_strstatus()} to convert status codes into a legible
-string.
-
-\begin{table}[htbp]
- \begin{center}
- \begin{tabular}{|l|r|l|}
- \hline
- \multicolumn{1}{|c|}{\bf Symbol} & \multicolumn{1}{c|}{\bf Code} &
- \multicolumn{1}{c|}{\bf Description} \\
- \hline\hline
-\code{\defn{SANE\_STATUS\_GOOD}}
- & 0 & Operation completed succesfully. \\
-\code{\defn{SANE\_STATUS\_UNSUPPORTED}}
- & 1 & Operation is not supported. \\
-\code{\defn{SANE\_STATUS\_CANCELLED}}
- & 2 & Operation was cancelled. \\
-\code{\defn{SANE\_STATUS\_DEVICE\_BUSY}}
- & 3 & Device is busy---retry later. \\
-\code{\defn{SANE\_STATUS\_INVAL}}
- & 4 & Data or argument is invalid. \\
-\code{\defn{SANE\_STATUS\_EOF}}
- & 5 & No more data available (end-of-file). \\
-\code{\defn{SANE\_STATUS\_JAMMED}}
- & 6 & Document feeder jammed. \\
-\code{\defn{SANE\_STATUS\_NO\_DOCS}}
- & 7 & Document feeder out of documents. \\
-\code{\defn{SANE\_STATUS\_COVER\_OPEN}}
- & 8 & Scanner cover is open. \\
-\code{\defn{SANE\_STATUS\_IO\_ERROR}}
- & 9 & Error during device I/O. \\
-\code{\defn{SANE\_STATUS\_NO\_MEM}}
- & 10 & Out of memory. \\
-\code{\defn{SANE\_STATUS\_ACCESS\_DENIED}}
- & 11 & Access to resource has been denied. \\
- \hline
- \end{tabular}
- \caption{Status Codes}\label{tab:status}
- \end{center}
-\end{table}
-
-
-\subsection{Device Descriptor Type}
-
-Each SANE device is represented by a structure of type
-\code{\defn{SANE\_Device}}. The C declaration of this type is given
-below.
-\begin{quote}
-\begin{verbatim}
-typedef struct
- {
- SANE_String_Const name;
- SANE_String_Const vendor;
- SANE_String_Const model;
- SANE_String_Const type;
- }
-SANE_Device;
-\end{verbatim}
-\end{quote}
-\index{device-name}
-The structure provides the unique name of the scanner in member
-\code{name}. It is this unique name that should be passed in a call
-to \code{sane\_open()}. The format of this name is completely up to
-the backend. The only constraints are that the name is unique among
-all devices supported by the backend and that the name is a legal SANE
-text string. To simplify presentation of unique names, their length
-should not be excessive. It is {\em recommended\/} that backends keep
-unique names below 32 characters in length. However, applications
-{\em must\/} be able to cope with arbitrary length unique names.
-
-The remaining members in the device structure provide additional
-information on the device corresponding to the unique name.
-Specifically, members \code{vendor}, \code{model}, and \code{type} are
-single-line strings that give information on the vendor
-(manufacturer), model, and the type of the device. For consistency's
-sake, the following strings should be used when appropriate (the lists
-will be expanded as need arises):
-
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \hspace{\fill}
- \begin{tabular}[t]{|ll|}
- \hline
- \multicolumn{2}{|c|}{\bf \defn{Vendor Strings}} \\
- \hline\hline
- \code{AGFA} & \code{Microtek} \\
- \code{Abaton} & \code{Minolta} \\
- \code{Acer} & \code{Mitsubishi} \\
- \code{Apple} & \code{Mustek} \\
- \code{Artec} & \code{NEC} \\
- \code{Avision} & \code{Nikon} \\
- \code{CANON} & \code{Plustek} \\
- \code{Connectix} & \code{Polaroid} \\
- \code{Epson} & \code{Relisys} \\
- \code{Fujitsu} & \code{Ricoh} \\
- \code{Hewlett-Packard} & \code{Sharp} \\
- \code{IBM} & \code{Siemens} \\
- \code{Kodak} & \code{Tamarack} \\
- \code{Lexmark} & \code{UMAX} \\
- \code{Logitech} & \code{Noname} \\
- \hline
- \end{tabular}
- \hspace{\fill}
- \begin{tabular}[t]{|l|}
- \hline
- \multicolumn{1}{|c|}{\bf \defn{Type Strings}} \\
- \hline\hline
- \code{film scanner} \\
- \code{flatbed scanner} \\
- \code{frame grabber} \\
- \code{handheld scanner} \\
- \code{multi-function peripheral} \\
- \code{sheetfed scanner} \\
- \code{still camera} \\
- \code{video camera} \\
- \code{virtual device} \\
- \hline
- \end{tabular}
- \hspace{\fill}
- \caption{Predefined Device Information Strings}
- \label{tab:devinfo}
- \end{center}
-\end{table}
-Note that vendor string \code{Noname} can be used for virtual devices
-that have no physical vendor associated. Also, there are no
-predefined model name strings since those are vendor specific and
-therefore completely under control of the respective backends.
-
-
-\subsection{Option Descriptor Type}\label{sec:odesc}
-
-Option descriptors are at the same time the most intricate and
-powerful type in the SANE standard. Options are used to control
-virtually all aspects of device operation. Much of the power of the
-SANE API stems from the fact that most device controls are completely
-described by their respective option descriptor. Thus, a frontend can
-control a scanner abstractly, without requiring knowledge as to what
-the purpose of any given option is. Conversely, a scanner can
-describe its controls without requiring knowledge of how the frontend
-operates. The C declaration of the
-\code{\defn{SANE\_Option\_Descriptor}} type is given below.
-\begin{quote}
-\begin{verbatim}
-typedef struct
- {
- SANE_String_Const name;
- SANE_String_Const title;
- SANE_String_Const desc;
- SANE_Value_Type type;
- SANE_Unit unit;
- SANE_Int size;
- SANE_Int cap;
- SANE_Constraint_Type constraint_type;
- union
- {
- const SANE_String_Const *string_list;
- const SANE_Word *word_list;
- const SANE_Range *range;
- }
- constraint;
- }
-SANE_Option_Descriptor;
-\end{verbatim}
-\end{quote}
-
-\subsubsection{Option Name}
-
-Member \code{name} is a string that uniquely identifies the option.
-The name must be unique for a given device (i.e., the option names
-across different backends or devices need not be unique). The option
-name must consist of lower-case ASCII letters (\code{a}--\code{z}),
-digits (\code{0}--\code{9}), or the dash character (\code{-}) only.
-The first character must be a lower-case ASCII character (i.e., not a
-digit or a dash).
-
-\subsubsection{Option Title}
-
-Member \code{title} is a single-line string that can be used by the
-frontend as a title string. This should typically be a short (one or
-two-word) string that is chosen based on the function of the option.
-
-\subsubsection{Option Description}
-
-Member \code{desc} is a (potentially very) long string that can be
-used as a help text to describe the option. It is the responsibility
-of the frontend to break the string into managable-length lines.
-Newline characters in this string should be interpreted as paragraph
-breaks.
-
-\subsubsection{Option Value Type}
-
-Member \code{type} specifies the type of the option value. The
-possible values for type \code{\defn{SANE\_Value\_Type}} are described
-in Table \ref{tab:valuetype}.
-
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|l|p{0.6\textwidth}|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{c|}{\bf Code} &
-\multicolumn{1}{c|}{\bf Description} \\
-\hline\hline
-
-\code{\defn{SANE\_TYPE\_BOOL}} & 0 & Option value is of type
- \verb|SANE_Bool|. \\
-
-\code{\defn{SANE\_TYPE\_INT}} & 1 & Option value is of type
- \verb|SANE_Int|. \\
-
-\code{\defn{SANE\_TYPE\_FIXED}}&2 & Option value is of type
- \verb|SANE_Fixed|. \\
-
-\code{\defn{SANE\_TYPE\_STRING}}&3 & Option value is of type
- \verb|SANE_String|. \\
-
-\code{\defn{SANE\_TYPE\_BUTTON}} & 4 & An option of this type has no value.
-Instead, setting an option of this type has an option-specific
-side-effect. For example, a button-typed option could be used by a
-backend to provide a means to select default values or to the tell an
-automatic document feeder to advance to the next sheet of paper. \\
-
-\code{\defn{SANE\_TYPE\_GROUP}} & 5 & An option of this type has no value.
-This type is used to group logically related options. A group option
-is in effect up to the point where another group option is encountered
-(or up to the end of the option list, if there are no other group
-options). For group options, only members \code{title} and
-\code{type} are valid in the option descriptor. \\
-
- \hline
- \end{tabular}
- \caption{Option Value Types (\code{SANE\_Value\_Type})}
- \label{tab:valuetype}
- \end{center}
-\end{table}
-
-\subsubsection{Option Value Unit}
-
-Member \code{unit} specifies what the physical unit of the option
-value is. The possible values for type \code{\defn{SANE\_U\-nit}} are
-described in Table \ref{tab:units}. Note that the specified unit is
-what the SANE backend expects. It is entirely up to a frontend as to
-how these units a presented to the user. For example, SANE expresses
-all lengths in millimeters. A frontend is generally expected to
-provide appropriate conversion routines so that a user can express
-quantities in a customary unit (e.g., inches or centimeters).
-
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|l|l|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{|c|}{\bf Code} &
-\multicolumn{1}{|c|}{\bf Description} \\
-
-\hline\hline
-
-\code{\defn{SANE\_UNIT\_NONE}} & 0 & Value is unit-less (e.g., page count).\\
-\code{\defn{SANE\_UNIT\_PIXEL}} & 1 & Value is in number of pixels. \\
-\code{\defn{SANE\_UNIT\_BIT}} & 2 & Value is in number of bits. \\
-\code{\defn{SANE\_UNIT\_MM}} & 3 & Value is in millimeters. \\
-\code{\defn{SANE\_UNIT\_DPI}} & 4 & Value is a resolution in dots/inch. \\
-\code{\defn{SANE\_UNIT\_PERCENT}}& 5 & Value is a percentage. \\
-\code{\defn{SANE\_UNIT\_MICROSECOND}}& 6 & Value is time in $\mu$-seconds. \\
-
-\hline
- \end{tabular}
- \caption{Physical Units (\code{SANE\_Unit})}
- \label{tab:units}
- \end{center}
-\end{table}
-
-\subsubsection{Option Value Size}\label{sec:valuesize}
-
-Member \code{size} specifies the size of the option value (in bytes).
-This member has a slightly different interpretation depending on the
-type of the option value:
-\begin{quote}
- \begin{description}
- \item[\code{SANE\_TYPE\_STRING}:] The size is the maximum size of
- the string. For the purpose of string size calcuations, the
- terminating \code{NUL} character is considered to be part of the
- string. Note that the terminating \code{NUL} character must
- always be present in string option values.
- \item[\code{SANE\_TYPE\_INT}, \code{SANE\_TYPE\_FIXED}:] The size
- must be a positive integer multiple of the size of a
- \verb|SANE_Word|. The option value is a vector of length
- \[ \code{size}/\code{sizeof(SANE\_Word)}. \]
- \item[\code{SANE\_TYPE\_BOOL}:] The size must be set to
- \code{sizeof(SANE\_Word)}.
- \item[\code{SANE\_TYPE\_BUTTON}, \code{SANE\_TYPE\_GROUP}:] The
- option size is ignored.
- \end{description}
-\end{quote}
-
-\subsubsection{Option Capabilities}
-
-Member \code{cap} describes what capabilities the option posseses.
-This is a bitset that is formed as the inclusive logical OR of the
-capabilities described in Table \ref{tab:capabilities}. The SANE API
-provides the following to macros to test certain features of a given
-capability bitset:
-\begin{quote}
- \begin{description}
-
- \item[\code{\defn{SANE\_OPTION\_IS\_ACTIVE}(\var{cap})}:] This macro
- returns \code{SANE\_TRUE} if and only if the option with the
- capability set \var{cap} is currently active.
-
- \item[\code{\defn{SANE\_OPTION\_IS\_SETTABLE}(\var{cap})}:] This
- macro returns \code{SANE\_TRUE} if and only if the option with the
- capability set \var{cap} is software settable.
- \end{description}
-\end{quote}
-
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|r|p{0.59\textwidth}|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{c|}{\bf Code} &
-\multicolumn{1}{c|}{\bf Description} \\
-\hline\hline
-
-\code{\defn{SANE\_CAP\_SOFT\_SELECT}} & 1 & The option
- value can be set by a call to \code{sane\_con\-trol\_opt\-ion()}.\\
-
-\code{\defn{SANE\_CAP\_HARD\_SELECT}} & 2 & The option value can be set by
- user-intervention (e.g., by flipping a switch). The user-interface
- should prompt the user to execute the appropriate action to set such
- an option. This capability is mutually exclusive with
- SANE\_CAP\_SOFT\_SELECT (either one of them can be set, but not both
- simultaneously). \\
-
-\code{\defn{SANE\_CAP\_SOFT\_DETECT}} & 4 & The option
- value can be detected by software. If
- \code{SANE\_\-CAP\_\-SO\-FT\_SEL\-ECT} is set, this capability {\em must\/}
- be set. If \code{SANE\_CAP\_HARD\_SELECT} is set, this capability
- may or may not be set. If this capability is set but neither
- \code{SANE\_CAP\_SO\-FT\_SEL\-ECT} nor \code{SANE\_CAP\_HA\-RD\_SEL\-ECT}
- are, then there is no way to control the option. That is, the
- option provides read-out of the current value only. \\
-
-\code{\defn{SANE\_CAP\_EMULATED}} & 8 & If set, this capability indicates
- that an option is not directly supported by the device and is
- instead emulated in the backend. A sophisticated frontend may
- elect to use its own (presumably better) emulation in lieu of an emulated
- option. \\
-
-\code{\defn{SANE\_CAP\_AUTOMATIC}} & 16 & If set, this capability indicates
- that the backend (or the device) is capable to picking a reasonable
- option value automatically. For such options, it is possible to
- select automatic operation by calling \code{sane\_control\_option()}
- with an action value of \code{SANE\_ACTION\_SET\_AUTO}. \\
-
-\code{\defn{SANE\_CAP\_INACTIVE}} & 32 & If set, this capability indicates
- that the option is not currently active (e.g., because it's
- meaningful only if another option is set to some other value). \\
-
-\code{\defn{SANE\_CAP\_ADVANCED}} & 64 &
- If set, this capability indicates that the option should be
- considered an ``advanced user option.'' A frontend typically
- displays such options in a less conspicuous way than regular options
- (e.g., a command line interface may list such options last or a
- graphical interface may make them available in a seperate ``advanced
- settings'' dialog).
- \\
-
-\hline
- \end{tabular}
- \caption{Option Capabilities}
- \label{tab:capabilities}
- \end{center}
-\end{table}
-
-\subsubsection{Option Value Constraints}
-
-It is often useful to constrain the values that an option can take.
-For example, constraints can be used by a frontend to determine how to
-represent a given option. Member \code{constraint\_type} indicates
-what constraint is in effect for the option. The constrained values
-that are allowed for the option are described by one of the union
-members of member \code{constraint}. The possible values of type
-\code{\defn{SANE\_Constraint\_Type}} and the interpretation of the
-\code{constraint} union is described in Table~\ref{tab:constraints}.
-
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|r|p{0.5\textwidth}|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{|c|}{\bf Code} &
-\multicolumn{1}{|c|}{\bf Description} \\
-
-\hline\hline
-
-\code{\defn{SANE\_CONSTRAINT\_NONE}} & 0 & The value is unconstrained.
- The option can take any of the values possible for the option's
- type. \\
-
- \code{\defn{SANE\_CONSTRAINT\_RANGE}} & 1 & This constraint is
- applicable to integer and fixed-point valued options only. It
- constrains the option value to a possibly quantized range of
- numbers. Option descriptor member \code{constraint.range} points to
- a range of the type \code{\defn{SANE\_Range}}. This type is illustrated
- below:
- \begin{quote}
-\begin{verbatim}
-typedef struct
- {
- SANE_Word min;
- SANE_Word max;
- SANE_Word quant;
- }
-SANE_Range;
-\end{verbatim}
- \end{quote}
- All three members in this structure are interpreted according to the
- option value type (\verb|SANE_TYPE_INT| or \verb|SANE_TYPE_FIXED|).
- Members \code{min} and \code{max} specify the minimum and maximum
- values, respectively. If member \code{quant} is non-zero, it
- specifies the quantization value. If $l$ is the minimum value, $u$
- the maximum value and $q$ the (non-zero) quantization of a range,
- then the legal values are $v=k\cdot q+l$ for all non-negative
- integer values of $k$ such that $v<=u$. \\
-
-\code{\defn{SANE\_CONSTRAINT\_WORD\_LIST}} & 2 & This constraint is applicable
- to integer and fixed-point valued options only. It constrains the
- option value to a list of numeric values. Option descriptor member
- \code{constraint.word\_list} points to a list of words that
- enumerates the legal values. The first element in that list is an
- integer (\verb|SANE_Int|) that specifies the length of the list (not
- counting the length itself). The remaining elements in the list are
- interpreted according to the type of the option value
- (\verb|SANE_TYPE_INT| or \verb|SANE_TYPE_FIXED|). \\
-
-\code{\defn{SANE\_CONSTRAINT\_STRING\_LIST}} & 3 & This constraint is
- applicable to string-valued options only. It constrains the option
- value to a list of strings. The option descriptor member
- \code{con\-strai\-nt.str\-ing\_list} points to a \code{NULL} terminated
- list of strings that enumerate the legal values for the option
- value.
-\\\hline
- \end{tabular}
- \caption{Option Value Constraints}
- \label{tab:constraints}
- \end{center}
-\end{table}
-
-
-\section{Operations}
-
-\subsection{\code{sane\_init}}
-
-This function must be called before any other SANE function can be called.
-The behavior of a SANE backend is undefined if this function is not called
-first or if the status code returned by \code{sane\_init} is different from
-\code{\defn{SANE\_STATUS\_GOOD}}. The version code of the backend is returned
-in the value pointed to by \code{version\_code}. If that pointer is
-\code{NULL}, no version code is returned. Argument \code{authorize} is either
-a pointer to a function that is invoked when the backend requires
-authentication for a specific resource or \code{NULL} if the frontend does not
-support authentication.
-\begin{quote}\index{sane\_init}
-\begin{verbatim}
-SANE_Status sane_init (SANE_Int * version_code,
- SANE_Authorization_Callback authorize);
-\end{verbatim}
-\end{quote}
-
-The authorization function may be called by a backend in response to
-any of the following calls:
-\begin{quote}
- \code{sane\_open}, \code{sane\_control\_option}, \code{sane\_start}
-\end{quote}
-If a backend was initialized without authorization function, then
-authorization requests that cannot be handled by the backend itself
-will fail automatically and the user may be prevented from accessing
-protected resources. Backends are encouraged to implement means of
-authentication that do not require user assistance. E.g., on a
-multi-user system that authenticates users through a login process a
-backend could automatically lookup the apporpriate password based on
-resource- and user-name.
-
-The authentication function type has the following declaration:
-\begin{quote}\index{SANE\_Authorization\_Callback}
- \index{domain}\index{username}\index{password}
-\begin{verbatim}
-#define SANE_MAX_USERNAME_LEN 128
-#define SANE_MAX_PASSWORD_LEN 128
-
-typedef void (*SANE_Authorization_Callback)
- (SANE_String_Const resource,
- SANE_Char username[SANE_MAX_USERNAME_LEN],
- SANE_Char password[SANE_MAX_PASSWORD_LEN]);
-\end{verbatim}
-\end{quote}
-Three arguments are passed to the authorization function:
-\code{resource} is a string specifying the name of the resource that
-requires authorization. A frontend should use this string to build a
-user-prompt requesting a username and a password. The \code{username}
-and \code{password} arguments are (pointers to) an array of
-\code{SANE\_MAX\_USERNAME\_LEN} and \code{SANE\_MAX\_PASSWORD\_LEN}
-characters, respectively. The authorization call should place the
-entered username and password in these arrays. The returned strings
-{\em must\/} be ASCII-NUL terminated.
-
-\subsection{\code{sane\_exit}}
-
-This function must be called to terminate use of a backend. The
-function will first close all device handles that still might be open
-(it is recommended to close device handles explicitly through a call
-to \code{sane\_clo\-se()}, but backends are required to release all
-resources upon a call to this function). After this function returns,
-no function other than \code{sane\_init()} may be called (regardless
-of the status value returned by \code{sane\_exit()}. Neglecting to
-call this function may result in some resources not being released
-properly.
-\begin{quote}\index{sane\_exit}
-\begin{verbatim}
-void sane_exit (void);
-\end{verbatim}
-\end{quote}
-
-
-\subsection{\code{sane\_get\_devices}}
-
-This function can be used to query the list of devices that are
-available. If the function executes successfully, it stores a pointer
-to a \code{NULL} terminated array of pointers to \verb|SANE_Device|
-structures in \code{*device\_list}. The returned list is guaranteed
-to remain unchanged and valid until (a) another call to this function
-is performed or (b) a call to \code{sane\_exit()} is performed. This
-function can be called repeatedly to detect when new devices become
-available. If argument \code{local\_only} is true, only local devices
-are returned (devices directly attached to the machine that SANE is
-running on). If it is false, the device list includes all remote
-devices that are accessible to the SANE library.
-\begin{quote}\index{sane\_get\_devices}
-\begin{verbatim}
-SANE_Status sane_get_devices (const SANE_Device *** device_list,
- SANE_Bool local_only);
-\end{verbatim}
-\end{quote}
-
-This function may fail with \code{SANE\_STATUS\_NO\_MEM} if an
-insufficient amount of memory is available.
-
-\begin{quote}
- \begin{center}
- {\bf Backend Implementation Note}
- \end{center}
- SANE does not require that this function is called before a
- \code{sane\_open()} call is performed. A device name may be
- specified explicitly by a user which would make it unnecessary and
- undesirable to call this function first.
-\end{quote}
-
-
-\subsection{\code{sane\_open}}
-
-This function is used to establish a connection to a particular
-device. The name of the device to be opened is passed in argument
-\code{name}. If the call completes successfully, a handle for the
-device is returned in \code{*h}. As a special case, specifying a
-zero-length string as the device requests opening the first available
-device (if there is such a device).
-\begin{quote}\index{sane\_open}
-\begin{verbatim}
-SANE_Status sane_open (SANE_String_Const name, SANE_Handle * h);
-\end{verbatim}
-\end{quote}
-
-This function may fail with one of the following status codes.
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_DEVICE\_BUSY}:] The device is currently
- busy (in use by somebody else).
-\item[\code{SANE\_STATUS\_INVAL}:] The device name is not valid.
-\item[\code{SANE\_STATUS\_IO\_ERROR}:] An error occured while
- communicating with the device.
-\item[\code{SANE\_STATUS\_NO\_MEM}:] An insufficent amount of memory
- is available.
-\item[\code{SANE\_STATUS\_ACCESS\_DENIED}:] Access to the device has
- been denied due to insufficient or invalid authentication.
-\end{description}
-\end{quote}
-
-
-\subsection{\code{sane\_close}}
-
-This function terminates the association between the device handle
-passed in argument \code{h} and the device it represents. If the
-device is presently active, a call to \code{sane\_cancel()} is
-performed first. After this function returns, handle \code{h} must
-not be used anymore.
-
-\begin{quote}\index{sane\_close}
-\begin{verbatim}
-void sane_close (SANE_Handle h);
-\end{verbatim}
-\end{quote}
-
-\subsection{\code{sane\_get\_option\_descriptor}}
-
-This function is used to access option descriptors. The function
-returns the option descriptor for option number \code{n} of the device
-represented by handle \code{h}. Option number 0 is guaranteed to be a
-valid option. Its value is an integer that specifies the number of
-options that are available for device handle \code{h} (the count
-includes option 0). If $n$ is not a valid option index, the function
-returns \code{NULL}. The returned option descriptor is guaranteed to
-remain valid (and at the returned address) until the device is closed.
-
-\begin{quote}\index{sane\_get\_option\_descriptor}
-\begin{verbatim}
-const SANE_Option_Descriptor *
- sane_get_option_descriptor (SANE_Handle h, SANE_Int n);
-\end{verbatim}
-\end{quote}
-
-\subsection{\code{sane\_control\_option}}\label{sec:control}
-
-This function is used to set or inquire the current value of option
-number \code{n} of the device represented by handle \code{h}. The
-manner in which the option is controlled is specified by parameter
-\code{a}. The possible values of this parameter are described in more
-detail below. The value of the option is passed through argument
-\code{v}. It is a pointer to the memory that holds the option value.
-The memory area pointed to by \code{v} must be big enough to hold the
-entire option value (determined by member \code{size} in the
-corresponding option descriptor). The only exception to this rule is
-that when setting the value of a string option, the string pointed to
-by argument \code{v} may be shorter since the backend will stop
-reading the option value upon encountering the first \code{NUL}
-terminator in the string. If argument \code{i} is not \code{NULL},
-the value of \code{*i} will be set to provide details on how well the
-request has been met. The meaning of this argument is described in
-more detail below.
-\begin{quote}\index{sane\_control\_option}
-\begin{verbatim}
-SANE_Status sane_control_option (SANE_Handle h, SANE_Int n,
- SANE_Action a, void *v,
- SANE_Int * i);
-\end{verbatim}
-\end{quote}
-
-The way the option is affected by a call to this function is
-controlled by parameter \code{a} which is a value of type
-\code{\defn{SANE\_Action}}. The possible values and their meaning is
-described in Table~\ref{tab:actions}.
-
-\begin{table}[h]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|r|p{0.5\textwidth}|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{|c|}{\bf Code} &
-\multicolumn{1}{|c|}{\bf Description} \\
-
-\hline\hline
-
-\code{\defn{SANE\_ACTION\_GET\_VALUE}} & 0 & Get current option value. \\
-
-\code{\defn{SANE\_ACTION\_SET\_VALUE}} & 1 & Set option value. The
- option value passed through argument \code{v} may be modified by the
- backend if the value cannot be set exactly. \\
-
-\code{\defn{SANE\_ACTION\_SET\_AUTO}} & 2 & Turn on automatic mode. Backend
- or device will automatically select an appropriate value. This mode
- remains effective until overridden by an explicit set value request.
- The value of parameter \code{v} is completely ignored in this case and
- may be \code{NULL}. \\
-
-\hline
- \end{tabular}
- \caption{Action Values (\code{SANE\_Action})}
- \label{tab:actions}
- \end{center}
-\end{table}
-
-After setting a value via an action value of
-\verb|SANE_ACTION_SET_VALUE|, additional information on how well the
-request has been met is returned in \code{*i} (if \code{i} is
-non-\code{NULL}). The returned value is a bitset that may contain any
-combination of the values described in Table~\ref{tab:info}.
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|r|p{0.5\textwidth}|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{|c|}{\bf Code} &
-\multicolumn{1}{|c|}{\bf Description} \\
-
-\hline\hline
-
-\code{\defn{SANE\_INFO\_INEXACT}} & 1 & This value is returned when
- setting an option value resulted in a value being selected that does
- not exactly match the requested value. For example, if a scanner
- can adjust the resolution in increments of 30dpi only, setting the
- resolution to 307dpi may result in an actual setting of 300dpi.
- When this happens, the bitset returned in \code{*i} has this member
- set. In addition, the option value is modified to reflect the
- actual (rounded) value that was used by the backend. Note that
- inexact values are admissible for strings as well. A backend may
- choose to ``round'' a string to the closest matching legal string
- for a constrained string value. \\
-
- \code{\defn{SANE\_INFO\_RELOAD\_OPTIONS}} & 2 & The setting of an
- option may affect the value or availability of one or more {\em
- other\/} options. When this happens, the SANE backend sets this
- member in \code{*i} to indicate that the application should reload
- all options. This member may be set if and only if at least one
- option changed. \\
-
-\code{\defn{SANE\_INFO\_RELOAD\_PARAMS}} & 4 & The setting of an option may
- affect the parameter values (see \code{sane\_get\_parameters()}).
- If setting an option affects the parameter values, this member will
- be set in \code{*i}. Note that this member may be set even if the
- parameters did not actually change. However, it is guaranteed that
- the parameters never change without this member being set. \\
-
-\hline
- \end{tabular}
- \caption{Additional Information Returned When Setting an Option}
- \label{tab:info}
- \end{center}
-\end{table}
-
-This function may fail with one of the following status codes.
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_UNSUPPORTED}:] The operation is not
- supported for the specified handle and option number.
-\item[\code{SANE\_STATUS\_INVAL}:] The option value is not valid.
-\item[\code{SANE\_STATUS\_IO\_ERROR}:] An error occured while
- communicating with the device.
-\item[\code{SANE\_STATUS\_NO\_MEM}:] An insufficent amount of memory
- is available.
-\item[\code{SANE\_STATUS\_ACCESS\_DENIED}:] Access to the option has
- been denied due to insufficient or invalid authentication.
-\end{description}
-\end{quote}
-
-
-
-\subsection{\code{sane\_get\_parameters}}
-
-This function is used to obtain the current scan parameters. The
-returned parameters are guaranteed to be accurate between the time a
-scan has been started (\code{sane\_start()} has been called) and the
-completion of that request. Outside of that window, the returned
-values are best-effort estimates of what the parameters will be when
-\code{sane\_start()} gets invoked. Calling this function before a
-scan has actually started allows, for example, to get an estimate of
-how big the scanned image will be. The parameters passed to this
-function are the handle \code{h} of the device for which the
-parameters should be obtained and a pointer \code{p} to a parameter
-structure. The parameter structure is described in more detail below.
-
-\begin{quote}\index{sane\_get\_parameters}
-\begin{verbatim}
-SANE_Status sane_get_parameters (SANE_Handle h,
- SANE_Parameters * p);
-\end{verbatim}
-\end{quote}
-
-The scan parameters are returned in a structure of type
-\code{\defn{SANE\_Parameters}}. The C declaration of this structure
-is given below.
-\begin{quote}
-\begin{verbatim}
-typedef struct
- {
- SANE_Frame format;
- SANE_Bool last_frame;
- SANE_Int bytes_per_line;
- SANE_Int pixels_per_line;
- SANE_Int lines;
- SANE_Int depth;
- }
-SANE_Parameters;
-\end{verbatim}
-\end{quote}
-
-Member \code{format} specifies the format of the next frame to be
-returned. The possible values for type \code{\defn{SANE\_Frame}} are
-described in Table~\ref{tab:frameformat}. The meaning of these
-values is described in more detail in Section~\ref{sec:imageformat}.
-\begin{table}[htbp]
- \begin{center}
- \leavevmode
- \begin{tabular}{|l|r|l|}
-\hline
-\multicolumn{1}{|c|}{\bf Symbol} &
-\multicolumn{1}{|c|}{\bf Code} &
-\multicolumn{1}{|c|}{\bf Description} \\
-
-\hline\hline
-
-\code{\defn{SANE\_FRAME\_GRAY}} & 0 & Band covering human visual range. \\
-\code{\defn{SANE\_FRAME\_RGB}} & 1 & Pixel-interleaved red/green/blue bands. \\
-\code{\defn{SANE\_FRAME\_RED}} & 2 & Red band of a red/green/blue image. \\
-\code{\defn{SANE\_FRAME\_GREEN}} & 3 & Green band of a red/green/blue image. \\
-\code{\defn{SANE\_FRAME\_BLUE}} & 4 & Blue band of a red/green/blue image. \\
-
-\hline
- \end{tabular}
- \caption{Frame Format (\code{SANE\_Frame})}
- \label{tab:frameformat}
- \end{center}
-\end{table}
-
-Member \code{last\_frame} is set to \code{SANE\_TRUE} if and only if
-the frame that is currently being acquired (or the frame that will be
-acquired next if there is no current frame) is the last frame of a
-multi frame image (e.g., the current frame is the blue component of a
-red, green, blue image).
-
-Member \code{lines} specifies how many scan lines the frame is
-comprised of. If this value is -1, the number of lines is not known a
-priori and the frontend should call \code{sane\_read()} until it
-returns a status of \code{SANE\_STATUS\_EOF}.
-
-Member \code{bytes\_per\_line} specifies the number of bytes that
-comprise one scan line.
-
-Member \code{depth} specifies the number of bits per sample.
-
-Member \code{pixels\_per\_line} specifies the number of pixels that
-comprise one scan line.
-
-Assume $B$ is the number of channels in the frame, then the bit depth
-$d$ (as given by member \code{depth}) and the number of pixels per
-line $n$ (as given by this member \code{pixels\_per\_line}) are
-related to $c$, the number of bytes per line (as given by member
-\code{bytes\_per\_line}) as follows:
-\[
- c >= \left\{
- \begin{array}{ll}
- B\cdot \lfloor (n + 7) / 8\rfloor & \mbox{if $d=1$}\\
- B\cdot n \cdot d / 8 & \mbox{if $d>1$}
- \end{array}
- \right.
-\]
-Note that the number of bytes per line can be larger than the minimum
-value imposed by the right side of this equation. A frontend must be
-able to properly cope with such ``padded'' image formats.
-
-
-\subsection{\code{sane\_start}}
-
-This function initiates aquisition of an image from the device
-represented by handle \code{h}.
-\begin{quote}\index{sane\_start}
-\begin{verbatim}
-SANE_Status sane_start (SANE_Handle h);
-\end{verbatim}
-\end{quote}
-This function may fail with one of the following status codes.
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_CANCELLED}:] The operation was cancelled through
- a call to \code{sane\_cancel}.
-\item[\code{SANE\_STATUS\_DEVICE\_BUSY}:] The device is busy. The
- operation should be retried later.
-\item[\code{SANE\_STATUS\_JAMMED}:] The document feeder is jammed.
-\item[\code{SANE\_STATUS\_NO\_DOCS}:] The document feeder is out of
- documents.
-\item[\code{SANE\_STATUS\_COVER\_OPEN}:] The scanner cover is open.
-\item[\code{SANE\_STATUS\_IO\_ERROR}:] An error occurred while communicating
- with the device.
-\item[\code{SANE\_STATUS\_NO\_MEM}:] An insufficent amount of memory
- is available.
-\item[\code{SANE\_STATUS\_INVAL}:] The scan cannot be started with the current
- set of options. The frontend should reload the option descriptors, as if
- \code{\defn{SANE\_INFO\_RELOAD\_OPTIONS}} had been returned from a call to
- \code{sane\_control\_option()}, since the device's capabilities may have
- changed.
-\end{description}
-\end{quote}
-
-
-\subsection{\code{sane\_read}}
-
-This function is used to read image data from the device represented
-by handle \code{h}. Argument \code{buf} is a pointer to a memory area
-that is at least \code{maxlen} bytes long. The number of bytes
-returned is stored in \code{*len}. A backend must set this to zero
-when a status other than \code{SANE\_STA\-TUS\_GOOD} is returned.
-When the call succeeds, the number of bytes returned can be anywhere in
-the range from 0 to \code{maxlen} bytes.
-\begin{quote}\index{sane\_read}
-\begin{verbatim}
-SANE_Status sane_read (SANE_Handle h, SANE_Byte * buf,
- SANE_Int maxlen, SANE_Int * len);
-\end{verbatim}
-\end{quote}
-If this function is called when no data is available, one of two
-things may happen, depending on the I/O mode that is in effect for
-handle \code{h}.
-\begin{enumerate}
-\item If the device is in blocking I/O mode (the default mode), the
- call blocks until at least one data byte is available (or until some
- error occurs).
-
-\item If the device is in non-blocking I/O mode, the call returns
- immediately with status \code{SANE\_STA\-TUS\_GOOD} and with
- \code{*len} set to zero.
-\end{enumerate}
-The I/O mode of handle \code{h} can be set via a call to
-\code{sane\_set\_io\_mode()}.
-
-This function may fail with one of the following status codes.
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_CANCELLED}:] The operation was cancelled through
- a call to \code{sane\_cancel}.
-\item[\code{SANE\_STATUS\_EOF}:] No more data is available for the
- current frame.
-\item[\code{SANE\_STATUS\_JAMMED}:] The document feeder is jammed.
-\item[\code{SANE\_STATUS\_NO\_DOCS}:] The document feeder is out of
- documents.
-\item[\code{SANE\_STATUS\_COVER\_OPEN}:] The scanner cover is open.
-\item[\code{SANE\_STATUS\_IO\_ERROR}:] An error occurred while communicating
- with the device.
-\item[\code{SANE\_STATUS\_NO\_MEM}:] An insufficent amount of memory
- is available.
-\item[\code{SANE\_STATUS\_ACCESS\_DENIED}:] Access to the device has
- been denied due to insufficient or invalid authentication.
-\end{description}
-\end{quote}
-
-
-\subsection{\code{sane\_cancel}}
-
-This function is used to immediately or as quickly as possible cancel
-the currently pending operation of the device represented by handle
-\code{h}.
-\begin{quote}\index{sane\_cancel}
-\begin{verbatim}
-void sane_cancel (SANE_Handle h);
-\end{verbatim}
-\end{quote}
-This function can be called at any time (as long as handle \code{h} is
-a valid handle) but usually affects long-running operations only (such
-as image is acquisition). It is safe to call this function
-asynchronously (e.g., from within a signal handler). It is important
-to note that completion of this operaton does {\em not\/} imply that
-the currently pending operation has been cancelled. It only
-guarantees that cancellation has been {\em initiated}. Cancellation
-completes only when the cancelled call returns (typically with a
-status value of \code{SANE\_STATUS\_CANCELLED}). Since the SANE API
-does not require any other operations to be re-entrant, this implies
-that a frontend must {\em not\/} call any other operation until the
-cancelled operation has returned.
-
-
-\subsection{\code{sane\_set\_io\_mode}}
-
-This function is used to set the I/O mode of handle \code{h}. The I/O mode
-can be either blocking or non-blocking. If argument \code{m} is
-\code{SANE\_TRUE}, the mode is set to non-blocking mode, otherwise it's set to
-blocking mode. This function can be called only after a call to
-\code{sane\_start()} has been performed.
-\begin{quote}\index{sane\_set\_io\_mode}
-\begin{verbatim}
-SANE_Status sane_set_io_mode (SANE_Handle h, SANE_Bool m);
-\end{verbatim}
-\end{quote}
-By default, newly opened handles operate in blocking mode. A backend
-may elect not to support non-blocking I/O mode. In such a case the
-status value \code{SANE\_STATUS\_UNSUPPORTED} is returned. Blocking
-I/O must be supported by all backends, so calling this function with
-argument \code{m} set to \code{SANE\_FALSE} is guaranteed to complete
-successfully.
-
-This function may fail with one of the following status codes:
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_INVAL}:] No image acquisition is pending.
-\item[\code{SANE\_STATUS\_UNSUPPORTED}:] The backend does not support
- the requested I/O mode.
-\end{description}
-\end{quote}
-
-
-\subsection{\code{sane\_get\_select\_fd}}
-
-This function is used to obtain a (platform-specific) file-descriptor
-for handle \code{h} that is readable if and only if image data is
-available (i.e., when a call to \code{sane\_read()} will return at
-least one byte of data). If the call completes successfully, the
-select file-descriptor is returned in \code{*fd}.
-\begin{quote}\index{sane\_get\_select\_fd}
-\begin{verbatim}
-SANE_Status sane_get_select_fd (SANE_Handle h, SANE_Int *fd);
-\end{verbatim}
-\end{quote}
-This function can be called only after a call to \code{sane\_start()}
-has been performed and the returned file-descriptor is guaranteed to
-remain valid for the duration of the current image acquisition (i.e.,
-until \code{sane\_cancel()} or \code{sane\_start()} get called again
-or until \code{sane\_read()} returns with status
-\code{SANE\_STA\-TUS\_EOF}). Indeed, a backend must guarantee to
-close the returned select file descriptor at the point when the next
-\code{sane\_read()} call would return \code{SANE\_STA\-TUS\_EOF}.
-This is necessary to ensure the application can detect when this
-condition occurs without actually having to call \code{sane\_read()}.
-
-A backend may elect not to support this operation. In such a case,
-the function returns with status code
-\code{SANE\_STATUS\_UNSUPPORTED}.
-
-Note that the only operation supported by the returned file-descriptor
-is a host operating-system dependent test whether the file-descriptor
-is readable (e.g., this test can be implemented using \code{select()}
-or \code{poll()} under UNIX). If any other operation is performed on
-the file descriptor, the behavior of the backend becomes
-unpredictable. Once the file-descriptor signals ``readable'' status,
-it will remain in that state until a call to \code{sane\_read()} is
-performed. Since many input devices are very slow, support for this
-operation is strongly encouraged as it permits an application to do
-other work while image acquisition is in progress.
-
-This function may fail with one of the following status codes:
-\begin{quote}
-\begin{description}
-\item[\code{SANE\_STATUS\_INVAL}:] No image acquisition is pending.
-\item[\code{SANE\_STATUS\_UNSUPPORTED}:] The backend does not support
- this operation.
-\end{description}
-\end{quote}
-
-
-\subsection{\code{sane\_strstatus}}
-
-This function can be used to translate a SANE status code into a
-printable string. The returned string is a single line of text that
-forms a complete sentence, but without the trailing period
-(full-stop). The function is guaranteed to never return \code{NULL}.
-The returned pointer is valid at least until the next call to this
-function is performed.
-\begin{quote}\index{sane\_strstatus}
-\begin{verbatim}
-const SANE_String_Const sane_strstatus (SANE_Status status);
-\end{verbatim}
-\end{quote}
-
-\section{Code Flow}\index{code flow}
-
-The code flow for the SANE API is illustrated in
-Figure~\ref{fig:flow}. Functions \code{sane\_init()} and
-\code{sane\_exit()} initialize and exit the backend, respectively.
-All other calls must be performed after initialization and before
-exiting the backend.
-
-\begin{figure}[htb]
- \begin{center}
- \leavevmode
- \includegraphics[height=0.5\textheight]{figs/flow}
- \caption{Code flow}
- \label{fig:flow}
- \end{center}
-\end{figure}
-
-Function \code{sane\_get\_devices()} can be called any time after
-\code{sane\_init()} has been called. It returns the list of the
-devices that are known at the time of the call. This list may change
-over time since some devices may be turned on or off or a remote host
-may boot or shutdown between different calls. It should be noted that
-this operation may be relatively slow since it requires contacting all
-configured devices (some of which may be on remote hosts). A frontend
-may therefore want to provide the ability for a user to directly
-select a desired device without requiring a call to this function.
-
-Once a device has been chosen, it is opened using a call to
-\code{sane\_open()}. Multiple devices can be open at any given time.
-A SANE backend must not impose artificial constraints on how many
-devices can be open at any given time.
-
-An opened device can be setup through the corresponding device handle
-using functions \code{sane\_get\_opt\-ion\_desc\-riptor()} and
-\code{sane\_control\_option()}. While setting up a device, obtaining
-option descriptors and setting and reading of option values can be
-mixed freely. It is typical for a frontend to read out all available
-options at the beginning and then build a dialog (either graphical or
-a command-line oriented option list) that allows to control the
-available options. It should be noted that the number of options is
-fixed for a given handle. However, as options are set, other options
-may become active or inactive. Thus, after setting an option, it
-maybe necessary to re-read some or all option descriptors. While
-setting up the device, it is also admissible to call
-\code{sane\_get\_parameters()} to get an estimate of what the image
-parameters will look like once image acquisition begins.
-
-The device handle can be put in blocking or non-blocking mode by a
-call to \code{sane\_set\_io\_mode()}. Devices are required to support
-blocking mode (which is the default mode), but support for
-non-blocking I/O is strongly encouraged for operating systems such as
-UNIX.
-
-After the device is setup properly, image acquisition can be started
-by a call to \code{sane\_start()}. The backend calculates the exact
-image parameters at this point. So future calls to
-\code{sane\_get\_parameters()} will return the exact values, rather
-than estimates. Whether the physical image acquisition starts at this
-point or during the first call to \code{sane\_read()} is unspecified
-by the SANE API. If non-blocking I/O and/or a select-style interface
-is desired, the frontend may attempt to call
-\code{sane\_set\_io\_mode()} and/or \code{sane\_get\_select\_fd()} at
-this point. Either of these functions may fail if the backend does
-not support the requested operation.
-
-Image data is collected by repeatedly calling \code{sane\_read()}.
-Eventually, this function will return an end-of-file status
-(\code{SANE\_STATUS\_EOF}). This indicates the end of the current
-frame. If the frontend expects additional frames (e.g., the
-individual channels in of a red/green/blue image or multiple images),
-it can call \code{sane\_start()} again. Once all desired frames have
-been acquired, function \code{sane\_cancel()} must be called. This
-operation can also be called at any other time to cancel a pending
-operation. Note that \code{sane\_cancel()} must be called even if the
-last read operation returned \code{SANE\_STATUS\_EOF}.
-
-When done using the device, the handle should be closed by a call to
-\code{sane\_close()}. Finally, before exiting the application,
-function \code{sane\_exit()} must be called. It is important not to
-forget to call this function since otherwise some resources (e.g.,
-temporary files or locks) may remain unclaimed.
-
-
-\section{Well-Known Options}\index{well-known options}
-
-While most backend options are completely self-describing, there are a
-cases where a user interface might want to special-case the handling
-of certain options. For example, the scan area is typically defined
-by four options that specify the top-left and bottom-right corners of
-the area. With a graphical user interface, it would be tedious to
-force the user to type in these four numbers. Instead, most such
-interfaces will want to present to the user a preview (low-resolution
-scan) of the scanner surface and let the user pick the scan area by
-dragging a rectangle into the desired position. For this reason, the
-SANE API specifies a small number of option names that have
-well-defined meanings.
-
-\subsection{Option Number Count}\index{option count}
-
-Option number 0 has an empty string as its name. The value of this
-option is of type \code{SANE\_TYPE\_INT} and it specifies the total
-number of options available for a given device (the count includes
-option number 0). This means that there are two ways of counting the
-number of options available: a frontend can either cycle through all
-option numbers starting at one until
-\code{sane\_get\_option\_descriptor()} returns \code{NULL}, or a
-frontend can directly read out the value of option number 0.
-
-\subsection{Scan Resolution Option}\index{scan resolution}\index{resolution option}
-
-Option \code{resolution} is used to select the resolution at which an
-image should be acquired. The type of this option is either
-\code{SANE\_TYPE\_INT} or \code{SANE\_TYPE\_FIXED}. The unit is
-\code{SANE\_UNIT\_DPI} (dots/inch).
-
-This option is not mandatory, but if a backend does support it, it
-must implement it in a manner consistent with the above definition.
-
-\subsection{Preview Mode Option}\index{preview mode}
-
-The boolean option \code{preview} is used by a frontend to inform the
-backend when image acquisition should be optimized for speed, rather
-than quality (``preview mode''). When set to \code{SANE\_TRUE},
-preview mode is in effect, when set to \code{SANE\_FALSE} image
-acquisition should proceed in normal quality mode. The setting of
-this option \emph{must not\/} affect any other option. That is, as
-far as the other options are concerned, the preview mode is completely
-side effect free. A backend can assume that the frontend will take
-care of appropriately setting the scan resolution for preview mode
-(through option \code{resolution}). A backend is free to override the
-\code{resolution} value with its own choice for preview mode, but it
-is advised to leave this choice to the frontend wherever possible.
-
-This option is not mandatory, but if a backend does support it, it
-must implement it in a manner consistent with the above definition.
-
-\subsection{Scan Area Options}\index{scan area options}
-
-The four most important well-known options are the ones that define
-the scan area. The scan area is defined by two points (x/y coordinate
-pairs) that specify the top-left and the bottom-right corners. This
-is illustrated in Figure~\ref{fig:area}. Note that the origin of the
-coordinate system is at the top-left corner of the scan surface as
-seen by the sensor (which typically is a mirror image of the scan
-surface seen by the user). For this reason, the top-left corner is
-the corner for which the abscissa and ordinate values are
-simultaneously the {\em smallest} and the bottom-right corner is the
-corner for which the abscissa and ordinate values are simulatenously
-the {\em largest}. If this coordinate system is not natural for a
-given device, it is the job of the backend to perform the necessary
-conversions.
-\begin{figure}[tbp]
- \begin{center}
- \leavevmode
- \includegraphics[height=0.3\textheight]{figs/area}
- \caption{Scan area options}
- \label{fig:area}
- \end{center}
-\end{figure}
-
-The names of the four options that define the scan area are given in
-the table below:
-\begin{center}
-\begin{tabular}{ll}
-{\bf Name} & {\bf Description} \\
-\code{\defn{tl-x}} & Top-left $x$ coordinate value \\
-\code{\defn{tl-y}} & Top-left $y$ coordinate value \\
-\code{\defn{br-x}} & Bottom-right $x$ coordinate value \\
-\code{\defn{br-y}} & Bottom-right $y$ coordinate value \\
-\end{tabular}
-\end{center}
-There are several rules that should be followed by front and backends
-regarding these options:
-\begin{itemize}
-
-\item Backends must attach a unit of either pixels
- (\code{SANE\_UNIT\_PIXEL}) or millimeters (\code{SANE\_UNIT\_MM}) to
- these options. The unit of all four options must be identical.
-
-\item Whenever meaningful, a backend should attach a range or a
- word-list constraint to these options.
-
-\item A frontend can determine the size of the scan surface by first
- checking that the options have range constraints associated. If a
- range or word-list constraints exist, the frontend can take the
- minimum and maximum values of one of the x and y option
- range-constraints to determine the scan surface size.
-
-\item A frontend must work properly with any or all of these options
- missing.
-
-\end{itemize}
-
-\input{net.tex}
-
-\chapter{Contact Information}\label{chap:contact}
-
-The SANE standard is discussed and evolved via a mailing list.
-Anybody with email access to the Internet can automatically join and
-leave the discussion group by sending mail to the following address.
-\begin{quote}\index{mailing list}
-\url{sane-devel-request@alioth-lists.debian.net}
-\end{quote}
-To subscribe, send a mail with the body ``\verb|subscribe sane-devel|'' to the
-above address.
-
-A complete list of commands supported can be obtained by sending a
-mail with a subject of ``\code{help}'' to the above address. The
-mailing list is archived and available through the SANE home page at
-URL:
-\begin{quote}
-\url{http://www.sane-project.org/}
-\end{quote}
-
-\newpage
-\input{sane.ind}
-
-\end{document}
diff --git a/doc/scanimage.man b/doc/scanimage.man
index 83624a4..b439c45 100644
--- a/doc/scanimage.man
+++ b/doc/scanimage.man
@@ -44,7 +44,7 @@ normally proceeds to acquire an image. The image data is written to
standard output in one of the PNM (portable aNyMaP) formats (PBM for
black-and-white images, PGM for grayscale images, and PPM for color
images), TIFF format (black-and-white, grayscale or color), PNG format,
-or JPEG format.
+or JPEG format (compression level 75).
.B scanimage
accesses image acquisition devices through the
.B SANE