More device properties

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

More device properties

Étienne Bersac-3
Hi,

Developing Gnome Scan, i realize that device with ADF may introduce the
paper from different side. i have at home two HP All-in-one printers,
one has ADF at right side of the paper, the other has ADF at bottom of
the paper.

If the frontend can access such property, it will be able to
automatically select the right scan area if the user select ADF source.
This is very useful since user can't preview a paper in ADF.

Some ADF may not center the document on the side, maybe a "adf-padding"
option should be useful for that.

Please comment.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Olaf Meeuwissen
Étienne Bersac <[hidden email]> writes:

> Hi,
>
> Developing Gnome Scan, i realize that device with ADF may introduce the
> paper from different side. i have at home two HP All-in-one printers,
> one has ADF at right side of the paper, the other has ADF at bottom of
> the paper.

Some things to keep in mind with ADF units:

  - simplex vs duplex
  - automatic page size detection (may include orientation as well)
  - alignment of original to scan origin or not (centered feeds)
  - sheet feeding from the top or the bottom of the stack
  - capability to leave a page on the scan area (useful for preview)

The only things I think are useful as options, in that a user can/may
control behaviour:

  - choice of simplex/duplex
  - limiting scan area to page size
  - rotation of original
  - "ADF preview" (feed first page, do a preview scan, leave it on the
    scan area so the user can fiddle with whatever other options before
    starting a scan of a 100 page document.  You may even want to allow
    for repeating the preview with the same page.)

> If the frontend can access such property, it will be able to
> automatically select the right scan area if the user select ADF source.
> This is very useful since user can't preview a paper in ADF.

See above.

> Some ADF may not center the document on the side, maybe a "adf-padding"
> option should be useful for that.
>
> Please comment.

Hope this helps,
--
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
FSF Associate Member #1962           sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
Penguin's lib!       -- I hack, therefore I am --               LPIC-2

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,

Thanks for you comments. There are very useful.

>   - alignment of original to scan origin or not (centered feeds)

That's an important point. SANE should provide a "adf padding" option or
similar.


>   - limiting scan area to page size

This can be done via {tl,br}-{x,y}. Isn't it ?

>   - rotation of original

Imo, this is post processing, device/sane/backend should not care this.

>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>     scan area so the user can fiddle with whatever other options before
>     starting a scan of a 100 page document.  You may even want to allow
>     for repeating the preview with the same page.)

That makes sense.

So, I propose the following options add:

      * simplex/duplex document
              * name: "adf-duplex"
              * title: "Duplex/simplex"
              * desc: "Wether the document in the ADF is duplex or
                simplex."
              * type: string enum
              * values: none/long-edge/short-edge
      * ADF introduced side
              * name: "adf-side"
              * title: "From which side of the scan area the document
                come from"
              * desc: ""
              * type: enum
              * values: right/left/top/bottom
      * ADF document centered
              * name: "adf-centered"
              * title: "Document centered in ADF"
              * desc: "Expose wether document are centered in ADF."
              * type: Bool
      * ADF padding
              * name: "adf-padding"
              * title: "ADF padding"
              * desc: "Expose the padding of the document in the ADF,
                relative to scan area origin of the adf-side. If
                adf-centered is set to true, then the padding refer to
                the center of the document."
              * type: Fixed
              * unit: mm
              * readonly

I guess adding those options worth adding a "adf" options group :)

Thanks,
Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

m. allan noah-3
In reply to this post by Étienne Bersac-3
sorry for the weird forward from new account- having email troubles....

> On Wed, 17 Jan 2007, Étienne Bersac wrote:
>
> > Hi,
> >
> > Thanks for you comments. There are very useful.
> >
> >>   - alignment of original to scan origin or not (centered feeds)
> >
> > That's an important point. SANE should provide a "adf padding" option or
> > similar.
>
> >>   - limiting scan area to page size
> >
> > This can be done via {tl,br}-{x,y}. Isn't it ?
> >
> >>   - rotation of original
> >
> > Imo, this is post processing, device/sane/backend should not care this.
> >
> >>   - "ADF preview" (feed first page, do a preview scan, leave it on the
> >>     scan area so the user can fiddle with whatever other options before
> >>     starting a scan of a 100 page document.  You may even want to allow
> >>     for repeating the preview with the same page.)
> >
> > That makes sense.
>
but requires that the user understand that the page that has been
previewed cannot be rescanned without reloading the hopper.

>
> >
> > So, I propose the following options add:
> >
> >      * simplex/duplex document
> >              * name: "adf-duplex"
> >              * title: "Duplex/simplex"
> >              * desc: "Wether the document in the ADF is duplex or
> >                simplex."
> >              * type: string enum
> >              * values: none/long-edge/short-edge
>
i do not understand the need for this? what will the front-end do
differently with this info? why the need for long/short edge?
>
> >      * ADF introduced side
> >              * name: "adf-side"
> >              * title: "From which side of the scan area the document
> >                come from"
> >              * desc: ""
> >              * type: enum
> >              * values: right/left/top/bottom
>
maybe crazy, but why not have the backend just rotate to standard
orientation before returning data?
>
> >      * ADF document centered
> >              * name: "adf-centered"
> >              * title: "Document centered in ADF"
> >              * desc: "Expose wether document are centered in ADF."
> >              * type: Bool
>
what will a front-end do with this info? i feel like we are perhaps
exposing things that should be taken care of by backend...

>
> >      * ADF padding
> >              * name: "adf-padding"
> >              * title: "ADF padding"
> >              * desc: "Expose the padding of the document in the ADF,
> >                relative to scan area origin of the adf-side. If
> >                adf-centered is set to true, then the padding refer to
> >                the center of the document."
> >              * type: Fixed
> >              * unit: mm
> >              * readonly
> >
>
i just dont get this. i guess i am slow today :)

i propose another method which removes the need for this, i think:

add paper-width and paper-height options. the user can tell the scanner
what size the paper is, and the scanner can move the users scan area
coordinates so that they are always anchored in the upper left corner of
the paper. then the backend deals with centering, etc.

otherwise, you are potentially talking about extending all front-ends that
might ever use an adf scanner to understand all this centering
manipulations?

in the interest of full disclosure, this is how the fujitsu backend
already works, and it works pretty well, other than the overscanning
issues which i need to address.

allan
--
"The truth is an offense, but not a sin"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

abel deuring
In reply to this post by Étienne Bersac-3
Hi all,

Étienne Bersac wrote:

> Thanks for you comments. There are very useful.
>
>>   - alignment of original to scan origin or not (centered feeds)
>
> That's an important point. SANE should provide a "adf padding" option or
> similar.

Some hints how the alignment of the paper width in the feeder
affects the scan window settings may be useful, but I think this is
too simple.

I see several "scanner parameters" that can affect the scan window
settings:

(1) the paper can be centered/left aligned/right aligned in the
    feeder
(2) some scanners know about the parameters "page width" and "page
    length"
(3) the origin of the scan window coordinates is fixed, or it is at
    the "corner" of the selected page size.

Another question is, if a frontend really needs to know about all
these details: If a user does not properly adjust the paper width of
the  feeder, the scan results will anyway be a bit messy. And if we
assume that the feeder is properly aligned, I think that (1) is no
longer important.

>>   - limiting scan area to page size
>
> This can be done via {tl,br}-{x,y}. Isn't it ?

right.

>
>>   - rotation of original
>
> Imo, this is post processing, device/sane/backend should not care this.

right.

>>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>>     scan area so the user can fiddle with whatever other options before
>>     starting a scan of a 100 page document.  You may even want to allow
>>     for repeating the preview with the same page.)
>
> That makes sense.

...only for some, if any, ADF scanners. Those ADF/flatbed scanners I
know work a bit different in ADF mode: They do _not_ place the paper
on the glass pane and then move the scan head across the pane;
instead they acquire the scan data while the _paper_ is moving,
while the scan head stays at a fixed position. This is faster, since
the paper must be moved anyway in ADF mode, so first placing the
paper on the glass pane and then scanning it in "flatbed mode"
simply requires additional time.

> So, I propose the following options add:
>
>       * simplex/duplex document
>               * name: "adf-duplex"
>               * title: "Duplex/simplex"
>               * desc: "Wether the document in the ADF is duplex or
>                 simplex."
>               * type: string enum
>               * values: none/long-edge/short-edge

I think the options currently used by the Fujitsu and Avision
backends (and perhaps others) are sufficient: source = flatbed | ADF
front | ADF back | ADF duplex.

"long edge/short edge" depends on the paper size: I can scan an A5
size paper in landscape mode, if the maximum scan size is at least
A4. For proper rotation of the scanned images by a frontend, you
need to know several things:

(1) Which "rotation axis" is used by humans in order to turn the
    paper from the front side to the back side (aka "long edge
    binding/short edge binding" for books) -- this must be selected
    for each batch of documents,
(2) how this axis is oriented, when the paper in the ADF,
(3) the orientation of the frontside and backside images as produced
    by the scanner.

It might make sense to add an option for (3) to ADF-duplex backends,
but (1) and (2) are a challenge for the UI of a frontend ;)

>       * ADF introduced side
>               * name: "adf-side"
>               * title: "From which side of the scan area the document
>                 come from"
>               * desc: ""
>               * type: enum
>               * values: right/left/top/bottom

Is this really necessary? I have the impression that this mixes with
your suggested adf-padding and the details, how a scanner handles
the paper size settings (if the latter is settable at all).

>       * ADF document centered
>               * name: "adf-centered"
>               * title: "Document centered in ADF"
>               * desc: "Expose wether document are centered in ADF."
>               * type: Bool
>       * ADF padding
>               * name: "adf-padding"
>               * title: "ADF padding"
>               * desc: "Expose the padding of the document in the ADF,
>                 relative to scan area origin of the adf-side. If
>                 adf-centered is set to true, then the padding refer to
>                 the center of the document."
>               * type: Fixed
>               * unit: mm
>               * readonly

See above: The details, how the scan window coordinates are affected
by mechanical details of an ADF etc, are a bit more complicated, I
believe.

>
> I guess adding those options worth adding a "adf" options group :)


More important might be a flag like "processing hints" for options:
We are talking about some options, which do not need to be shown to
the user, but which can help a frontend to make "better decisions"
how to set other options or how to post-process the data.

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,


> (1) the paper can be centered/left aligned/right aligned in the
>     feeder

right and left depend on which side of the scan area the ADF is :
top/bottom/left/right. The paper can be centered/"start" aligned/"end"
aligned in the feeder.

> (2) some scanners know about the parameters "page width" and "page
>     length"

You mean that e.g. some ADF allow to press paper between two handles,
and the scanner will scan only between the two handle ?

> (3) the origin of the scan window coordinates is fixed, or it is at
>     the "corner" of the selected page size.

I don't understand. That's too fuzzy. Please explain.

> Another question is, if a frontend really needs to know about all
> these details: If a user does not properly adjust the paper width of
> the  feeder, the scan results will anyway be a bit messy.

Also, some ADF does not properly introduce the paper.

> And if we
> assume that the feeder is properly aligned, I think that (1) is no
> longer important.

frontend must know how the feeder is aligned.

> >>   - "ADF preview" (feed first page, do a preview scan, leave it on the
> >>     scan area so the user can fiddle with whatever other options before
> >>     starting a scan of a 100 page document.  You may even want to allow
> >>     for repeating the preview with the same page.)
> >
> > That makes sense.
>
> ...only for some, if any, ADF scanners. Those ADF/flatbed scanners I
> know work a bit different in ADF mode:

ACK. However, some might allow ADF preview, we must support that. The
backend must teach the frontend if it can preview with ADF.

> I think the options currently used by the Fujitsu and Avision
> backends (and perhaps others) are sufficient: source = flatbed | ADF
> front | ADF back | ADF duplex.

I think that this source usage is a confusion of two separate options.
That's a quirks common in various backend.

> "long edge/short edge" depends on the paper size: I can scan an A5
> size paper in landscape mode, if the maximum scan size is at least
> A4. For proper rotation of the scanned images by a frontend, you
> need to know several things:
>
> (1) Which "rotation axis" is used by humans in order to turn the
>     paper from the front side to the back side (aka "long edge
>     binding/short edge binding" for books) -- this must be selected
>     for each batch of documents,
> (2) how this axis is oriented, when the paper in the ADF,
> (3) the orientation of the frontside and backside images as produced
>     by the scanner.
>
> It might make sense to add an option for (3) to ADF-duplex backends,
> but (1) and (2) are a challenge for the UI of a frontend ;)
ACK. frontend should ask for document size, orientation and duplex mode.
For (3), please explain the option.

>
> >       * ADF introduced side
> >               * name: "adf-side"
> >               * title: "From which side of the scan area the document
> >                 come from"
> >               * desc: ""
> >               * type: enum
> >               * values: right/left/top/bottom
>
> Is this really necessary? I have the impression that this mixes with
> your suggested adf-padding and the details, how a scanner handles
> the paper size settings (if the latter is settable at all).
This option teach the frontend where is the ADF relative to the flatbed.
The padding is just an offset, teaching where is placed the document in
the wide scan area.

> >       * ADF padding
> >               * name: "adf-padding"
> >               * title: "ADF padding"
> >               * desc: "Expose the padding of the document in the ADF,
> >                 relative to scan area origin of the adf-side. If
> >                 adf-centered is set to true, then the padding refer to
> >                 the center of the document."
> >               * type: Fixed
> >               * unit: mm
> >               * readonly
>
> See above: The details, how the scan window coordinates are affected
> by mechanical details of an ADF etc, are a bit more complicated, I
> believe.
Please explain.

> More important might be a flag like "processing hints" for options:

ACK.

Thanks for your comments.



This is how i see the problem :

User has a scanner with an ADF and a flatbed. The ADF can be either on
top/bottom/left/right of the flatbed. The ADF has a padding relative to
flatbed : when a document is introduced, the document is not at top
right corner of the flatbed. The ADF can center the document or align it
to start or end of the side.

User has a multipage document. This document can be simplex or duplex,
portrait or landscape.


Here is an example :

User A has an all-in-one printer with flatbed and ADF.
      * The feeder is at right side of the scan area.
      * The feeder center the document.
      * The center of the feeder is at 170mm from the top of the scan
        area. adf-offset = 170mm
      * Wide scan area (flatbed geometry) = 240x350mm

User A has a multipage A4 document in landscape orientation with duplex
printing.

      * He sets source to "Automatic Document Feeder"
      * He sets format to A4
      * He sets orientation to landscape (in portrait/landscape/reverse
        landscape).
      * He checks duplex.

The frontend computes the scan area and rotation and set various
options. The scanner geometry does not allow to scan an A4 landscape
without rotating the document.

      * set source = ADF
      * Since the document is landscape (not reverse landscape), the
        images will naturally be rotated 90° clockwise for frontside and
        counterclockwise for backside.
      * Since the document is A4 landscape and rotated, the document
        will be introduced by the 297mm long side. So scan area width =
        210 and scan area height = 297mm.
      * Since the feeder is at right of the scan area, set tl-x =
        240-210.
      * Since the feeder center document and feeder center is at 170mm,
        set tl-y = 170-(297/2) = 21,5mm.
      * set br-x = tl-x + 210
      * set br-y = tl-y + 297

According to this example, i don't really know if adf-duplex is usefull.
Can device rotate the paper ?


Another example :

User B has a scanner with flatbed and ADF source.

      * The feeder is on bottom of the flatbed, document are introduced
        by the top (adf-side = top).
      * The feeder center document.
      * The feeder has two "handles" the user have to move to the
        "press" the fit the document in. This handles teach the device
        the width of the document. adf-offset is 0mm.
      * The flatbed geometry is 220x320mm.

User B has a one page simplex A5 document.
      * He set format to A4
      * orientationto portrait.
      * source to ADF
      * Uncheck duplex

Behind the UI, the frontend

      * Compute that no rotation is needed (210 fit 220)
      * adf-offset is 0, set tl-x = 0
      * adf-side is top : set tl-y = 0
      * set br-x = tl-x + 210
      * set br-y = tl-y + 297
      * sane_start () :)

Please tell me what you think of.

Thanks,
Étienne
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
In reply to this post by m. allan noah-3
Hi,

> > > That makes sense.
> >
> but requires that the user understand that the page that has been
> previewed cannot be rescanned without reloading the hopper.

ACK. That's not very important since the purpose of adding option is to
avoid preview by computing almost all paramaters by the frontend.

> i do not understand the need for this? what will the front-end do
> differently with this info? why the need for long/short edge?

You're right. A boolean value should be enough.

> > >      * ADF introduced side
> maybe crazy, but why not have the backend just rotate to standard
> orientation before returning data?

This option help the frontend computing right scan-area. This is not
about rotation. And, yeah, rotating in the backend is crazy, imho :).

> > >      * ADF document centered
> > >              * name: "adf-centered"
> > >              * title: "Document centered in ADF"
> > >              * desc: "Expose wether document are centered in ADF."
> > >              * type: Bool
> >
> what will a front-end do with this info?

Again, the purpose of this option is for frontend to compute scan-area
using ADF.

> > >      * ADF padding
> i just dont get this. i guess i am slow today :)

think "offset" or "document-offset" if you prefer.

> add paper-width and paper-height options. the user can tell the scanner
> what size the paper is, and the scanner can move the users scan area
> coordinates so that they are always anchored in the upper left corner of
> the paper. then the backend deals with centering, etc.

That makes sense.

> otherwise, you are potentially talking about extending all front-ends that
> might ever use an adf scanner to understand all this centering
> manipulations?

There is far more backends than frontends, and frontends are almost all
maintained. Also, user can teach almost all those info if the backend
does not provide them. If the backend do not take care of paper-width
and paper-height, we get back to the current situation.

> in the interest of full disclosure, this is how the fujitsu backend
> already works, and it works pretty well, other than the overscanning
> issues which i need to address.

I don't think that implemented that in all backends is a good solution.
Let the frontent do that one for all.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

abel deuring
In reply to this post by Étienne Bersac-3
Étienne Bersac wrote:
> Hi,
>
>
>> (1) the paper can be centered/left aligned/right aligned in the
>>     feeder
>
> right and left depend on which side of the scan area the ADF is :
> top/bottom/left/right. The paper can be centered/"start" aligned/"end"
> aligned in the feeder.

What I meant is probably the same, what you called the "handles".
Some mechanical guides on the left and right side of the feeder
which are adjusted to match the width of the paper and which ensure
(more or less) that the paper is not skewed when it is moved.

>> (2) some scanners know about the parameters "page width" and "page
>>     length"
>
> You mean that e.g. some ADF allow to press paper between two handles,
> and the scanner will scan only between the two handle ?

No, page width and length are parameters for the firmware of some
ADF scanners telling the device the size of the documents. The
length can be used by the firmware to detect feeding problems ("if
the paper does not end after moving it for paper length +/- 10mm,
raise a feeding error"); the width parameter can be used to set the
the origin of the scan window.

>
>> (3) the origin of the scan window coordinates is fixed, or it is at
>>     the "corner" of the selected page size.
>
> I don't understand. That's too fuzzy. Please explain.


An attempt of an ASCII drawing:


        A----------------- max scan/paper size--------------+
        |                                                   |
        |                                                   |
        |     B-----------  paper size ---------------+     |
        |     |                                       |     |
        |     |                                       |     |
        |     |      +-- scan window --+              |     |
        |     |      |                 |              |     |
        |     |      |                 |              |     |
        |     |      |                 |              |     |
        |     |      |                 |              |     |
        |     |      +-----------------+              |     |
        |     |                                       |     |
        |     |                                       |     |
        |     +---------------------------------------+     |
        |                                                   |
        |                                                   |
        +---------------------------------------------------+

Scanners that allow to set the paper size may set the scan window
coordinates relative to point A (top left corner of the max scan
size) or relative to point B (top left corner of the selected paper
size). An example for the latter are the Fujitsu 4120/5120. Their
max scan width is ~225 mm, and they center the paper in the ADF. If
you want to scan an A6 page (width 105mm), you select paper width
105 mm, tl-x=0mm, br-x=105mm. For a scanner that does not move the
origin of the scan window, but which ceneters the paper in the
feeder, you would have to select tl-x = 52mm or so, and br-x = 157mm.

How the area "paper size" is aligned within the area "max scan
size", depends on the paper guides: If both the left and right
guides can be moved/adjusted, or only one of them. ("Decent" ADF
scanners will center the paper in order to ensure that the rollers
which move the paper are placed "grab" the paper symmetrical in
order to avoid skewing the paper, but you never know...)

>> And if we
>> assume that the feeder is properly aligned, I think that (1) is no
>> longer important.
>
> frontend must know how the feeder is aligned.

Perhaps... well, this is probably useful, if you want to have a
selection list with standard paper sizes (A4/A5...). But the
frontend does _not_ need to care about the alignment, if the scanner
allows to set the page width/length, and if it sets the scan window
relative to the selected page size.

>>>>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>>>>     scan area so the user can fiddle with whatever other options before
>>>>     starting a scan of a 100 page document.  You may even want to allow
>>>>     for repeating the preview with the same page.)
>>> That makes sense.
>> ...only for some, if any, ADF scanners. Those ADF/flatbed scanners I
>> know work a bit different in ADF mode:
>
> ACK. However, some might allow ADF preview, we must support that. The
> backend must teach the frontend if it can preview with ADF.

Ummm, I would rather suggest to support a more general way to set
the scan window that is useful for every ADF scanner: Let the user
make a test scan with one page; display this page in a preview
window; allow to set page size (if possible/reasonable) and the scan
window; let the user insert the test page back into the ADF; let him
make again a test scan and so on. (That's the difference between
twain and Sane: A Sane frontend is supposed to support a wide range
of devices, while a Twain driver and its GUI can focus on more or
less special devices ;)

>
>> I think the options currently used by the Fujitsu and Avision
>> backends (and perhaps others) are sufficient: source = flatbed | ADF
>> front | ADF back | ADF duplex.
>
> I think that this source usage is a confusion of two separate options.
> That's a quirks common in various backend.

Maybe. Actually, I don't care that much about these details, as long
as we have the same options in all affected backends. If one or the
other way to specify the ADF mode does not fit the GUI concept of a
frontend, it is easy to use other GUI elements than suggested by the
backend's options and to "map" the values selected in the GUI to the
options.

>> "long edge/short edge" depends on the paper size: I can scan an A5
>> size paper in landscape mode, if the maximum scan size is at least
>> A4. For proper rotation of the scanned images by a frontend, you
>> need to know several things:
>>
>> (1) Which "rotation axis" is used by humans in order to turn the
>>     paper from the front side to the back side (aka "long edge
>>     binding/short edge binding" for books) -- this must be selected
>>     for each batch of documents,
>> (2) how this axis is oriented, when the paper in the ADF,
>> (3) the orientation of the frontside and backside images as produced
>>     by the scanner.
>>
>> It might make sense to add an option for (3) to ADF-duplex backends,
>> but (1) and (2) are a challenge for the UI of a frontend ;)
>
> ACK. frontend should ask for document size, orientation and duplex mode.
> For (3), please explain the option.

I was trying to figure out, how this "feed from the right side of
scan area" device works, to which you obviously have access.

The "average" ADF scanner works this way, perhaps you can explain,
where your scanner works differently:

The maximum scan width is limited by the width of the feeder and of
the CCD sensor; the maximum scan length is generally larger than the
scan width. (In other words, scans are mostly made in "portait
mode", though I'm trying to avoid this word -- it is easy to confuse
this with the orientation of the text/images on the paper, which can
also be in portait/landscape.) The feeder moves the paper "across"
the CCD sensor, and the host computer needs to read the scan data
directly from the scanner, while the scan is running.

Normally, you insert the paper into the ADF so that the top edge,
not the bottom edge, of a page is scanned first, so that the backend
"seems" the data coming in starting from the top edge. This data can
be stored in a straghtforward way to most image file formats, and it
is also straightforward to display it in a preview window.

So, no rotation is necessary, provided that for example an
"ordinary" A4 page, printed in "portait mode" mode (main text
direction parallel to the short edge of the paper...) is scanned,
and that the top (short) edge of the paper is scanned first.

For duplex scanners, this works too for the backside data, provided
that the text on the backside starts at the same edge (which is the
case for the average book page or magazine page).

>
>>>       * ADF introduced side
>>>               * name: "adf-side"
>>>               * title: "From which side of the scan area the document
>>>                 come from"
>>>               * desc: ""
>>>               * type: enum
>>>               * values: right/left/top/bottom
>> Is this really necessary? I have the impression that this mixes with
>> your suggested adf-padding and the details, how a scanner handles
>> the paper size settings (if the latter is settable at all).
>
> This option teach the frontend where is the ADF relative to the flatbed.
> The padding is just an offset, teaching where is placed the document in
> the wide scan area.

OK, I understand "padding" meanwhile. Let's call it the offset of a
 page of a certain size from the the origin of the entire scan area.
"padding" sounds to me a bit like "pad bytes", i.e. some "fill-in
data" that you can discard.

>
>>>       * ADF padding
>>>               * name: "adf-padding"
>>>               * title: "ADF padding"
>>>               * desc: "Expose the padding of the document in the ADF,
>>>                 relative to scan area origin of the adf-side. If
>>>                 adf-centered is set to true, then the padding refer to
>>>                 the center of the document."
>>>               * type: Fixed
>>>               * unit: mm
>>>               * readonly
>> See above: The details, how the scan window coordinates are affected
>> by mechanical details of an ADF etc, are a bit more complicated, I
>> believe.
>
> Please explain.

See the "ASCII drawing" above and the text below the drawing.

>
>> More important might be a flag like "processing hints" for options:
>
> ACK.
>
> Thanks for your comments.
>
>
>
> This is how i see the problem :
>
> User has a scanner with an ADF and a flatbed. The ADF can be either on
> top/bottom/left/right of the flatbed. The ADF has a padding relative to
> flatbed : when a document is introduced, the document is not at top
> right corner of the flatbed. The ADF can center the document or align it
> to start or end of the side.
>
> User has a multipage document. This document can be simplex or duplex,
> portrait or landscape.
>
>
> Here is an example :
>
> User A has an all-in-one printer with flatbed and ADF.
>       * The feeder is at right side of the scan area.
>       * The feeder center the document.
>       * The center of the feeder is at 170mm from the top of the scan
>         area. adf-offset = 170mm
>       * Wide scan area (flatbed geometry) = 240x350mm
>
> User A has a multipage A4 document in landscape orientation with duplex
> printing.
>
>       * He sets source to "Automatic Document Feeder"
>       * He sets format to A4
>       * He sets orientation to landscape (in portrait/landscape/reverse
>         landscape).
>       * He checks duplex.
>
> The frontend computes the scan area and rotation and set various
> options. The scanner geometry does not allow to scan an A4 landscape
> without rotating the document.
>
>       * set source = ADF
>       * Since the document is landscape (not reverse landscape), the
>         images will naturally be rotated 90° clockwise for frontside and
>         counterclockwise for backside.
>       * Since the document is A4 landscape and rotated, the document
>         will be introduced by the 297mm long side. So scan area width =
>         210 and scan area height = 297mm.
>       * Since the feeder is at right of the scan area, set tl-x =
>         240-210.
>       * Since the feeder center document and feeder center is at 170mm,
>         set tl-y = 170-(297/2) = 21,5mm.
>       * set br-x = tl-x + 210
>       * set br-y = tl-y + 297
>
> According to this example, i don't really know if adf-duplex is usefull.

Why should it not be useful? As I understand you, this is basically
the same use case as for a "ordinary" ADF scanner intended for A4
size paper, where an A4 page is moved parallel to the long edge: If
you want to scan A5 pages, it is reasonable to let the scanner move
the A5 page parallel to the short edge. For many scanners, this will
be faster than to move the A5 page parallel to the long edge. But
you will need to rotate the scanned image by 90 degree, if the
"content" of the page is in "portrait orientation", and frontside
and backside images may need different rotation angles.

> Can device rotate the paper ?

The paper itself? Unlikely ;) The image? this is also unlikely --
RAM is too expensive as to be big enough to store a 600dpi RGB scan
inside a scanner, except for real high-end devices. More over, most
scanners do not have CPUs with a clock speed in the GHz range, so
rotation could easily slow down scanning.

Another viewpoint: If the scanner moves the paper "by default from
left to right", i.e., for example an A4 size ADF scanner that moves
the paper parallel to the short edge, shouldn't the backend simply
set the X range to 0...297mm and the Y range to 0..210mm?  Thinking
a bit more about this example, this is probably an A3 scanner,
having a Y range of something like 0..420mm ;) It is hard for me to
believe that an ADF scanner exists which limits the scan length (I
mean the direction of the paper movement) that is shorter than the
scan width... Either way - if this scanner (and you seem to have
access to a device that has at least some similarities to the one I
am trying to describe) is an A4 or A3 scanner: If the X range is
0..297mm, and you want to scan an A4 page so that the resulting
image is in portrait mode, you can do all necessary rotations within
the frontend, including the preview window.

> Another example :
>
> User B has a scanner with flatbed and ADF source.
>
>       * The feeder is on bottom of the flatbed, document are introduced
>         by the top (adf-side = top).
>       * The feeder center document.
>       * The feeder has two "handles" the user have to move to the
>         "press" the fit the document in. This handles teach the device
>         the width of the document. adf-offset is 0mm.

I am not aware of a scanner that has sensors for the paper guides,
but high end beasts might have them. The sensor readings will
probably be "mapped" to the page width.

>       * The flatbed geometry is 220x320mm.
>
> User B has a one page simplex A5 document.
>       * He set format to A4
>       * orientationto portrait.
>       * source to ADF
>       * Uncheck duplex
>
> Behind the UI, the frontend
>
>       * Compute that no rotation is needed (210 fit 220)
>       * adf-offset is 0, set tl-x = 0
>       * adf-side is top : set tl-y = 0
>       * set br-x = tl-x + 210
>       * set br-y = tl-y + 297
>       * sane_start () :)
>
> Please tell me what you think of.


Well, as I understand it, both cases you describe boil down to these
parameters and questions:

- alignment of the paper in the feeder: centered/corner 1/corner 2
  (other possible alignments should be considered broken...)
- "clever" support of the page width/length parameters by the
  frontend, which must be aware of a possible shift of the origin of
  the scan window coordinates to the top-left corner of the selected
  page size
- which information is missing for scanners that can move an A4 page
  parallel to its short edge?

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,

> No, page width and length are parameters for the firmware of some
> ADF scanners telling the device the size of the documents.

Interesting. So this make sense to add "paper-width" and "paper-height"
option as Alan suggests.

> A----------------- max scan/paper size--------------+
> |                                                   |
> |                                                   |
> |     B-----------  paper size ---------------+     |
> |     |                                       |     |
> |     |                                       |     |
> |     |      +-- scan window --+              |     |
> |     |      |                 |              |     |
> |     |      |                 |              |     |
> |     |      |                 |              |     |
> |     |      |                 |              |     |
> |     |      +-----------------+              |     |
> |     |                                       |     |
> |     |                                       |     |
> |     +---------------------------------------+     |
> |                                                   |
> |                                                   |
> +---------------------------------------------------+

> Scanners that allow to set the paper size may set the scan window
> coordinates relative to point A (top left corner of the max scan
> size) or relative to point B (top left corner of the selected paper
> size).

Thanks. This clarify things a bit :).

> > frontend must know how the feeder is aligned.
>
> Perhaps... well, this is probably useful, if you want to have a
> selection list with standard paper sizes (A4/A5...). But the
> frontend does _not_ need to care about the alignment, if the scanner
> allows to set the page width/length, and if it sets the scan window
> relative to the selected page size.

Absolutely. See GnomeScan 0.4. It ask user for paper size and
orientation, it then compute the right area, but currently, it assume
the document is centered in feeder, feeder centerd relative to head,
top-first-introduced, and without paper-size options. (This the case on
my HP OfficeJet 7100 series and HP OfficeJet 7300 series, but not the
OfficeJet G85).

For device that do not handle paper-size (HP ones seems to), we must
teach the frontend feeders infos in order to compute the right scan
window relative the max scan area.

> > ACK. However, some might allow ADF preview, we must support that. The
> > backend must teach the frontend if it can preview with ADF.
>
> Ummm, I would rather suggest to support a more general way to set
> the scan window that is useful for every ADF scanner: Let the user
> make a test scan with one page; display this page in a preview
> window; allow to set page size (if possible/reasonable) and the scan
> window; let the user insert the test page back into the ADF; let him
> make again a test scan and so on.

That's just crazy. Users are just fed up to walk trough the room just to
relaunch a preview. (In my case, my HP is networked and my mother has to
walk from the living room to my bedroom in order to feed the scanner,
that's quite long, and running the there and back trip more than twice
just makes user crazy).

In ADF, we must as far as possible avoid preview. The ideal workflow is
put the paper (carefully aligned), push the button, teach the file
name/…, click "scan" and that's all.


> > I think that this source usage is a confusion of two separate options.
> > That's a quirks common in various backend.
>
> Maybe. Actually, I don't care that much about these details, as long
> as we have the same options in all affected backends. If one or the
> other way to specify the ADF mode does not fit the GUI concept of a
> frontend, it is easy to use other GUI elements than suggested by the
> backend's options and to "map" the values selected in the GUI to the
> options.

I know. A lot of GnomeScanBackend is about mapping variable string from
variable backend into enum. :). I don't mean that GUI concept must
influence SANE design, however, SANE must allow GUI to choose there own
concept.

See : fujitsu backend merge source and duplex option, but hpaio backend
not. So the frontend has to take care of backend specific option
handling. That's no the purpose of a backend. All backends must expose a
as far as possible uniform API. Only adding specific options for
specific features. See SANE 2 draft : source values are
"Flatbed", "Transparancy Adapter" and "Automatic Document Feeder".
Nothing else.

> I was trying to figure out, how this "feed from the right side of
> scan area" device works, to which you obviously have access.
>
> The "average" ADF scanner works this way, perhaps you can explain,
> where your scanner works differently: […]

I own an HP OfficeJet G85 all-in-one printer which introduce paper
left-side-first in the flatbed, scan the paper, then eject it and while
feeder is no empty. The paper is moved left-to-right. I agree this is
not the fastest way, and new HP all-in-one printers do not work like
that. However, such device exsists and we must support it.

> > According to this example, i don't really know if adf-duplex is usefull.
>
> Why should it not be useful?

You're right. In fact, some backend has a duplex option (hpaio does). We
should add it to the well known option.

> Another viewpoint: If the scanner moves the paper "by default from
> left to right", i.e., for example an A4 size ADF scanner that moves
> the paper parallel to the short edge, shouldn't the backend simply
> set the X range to 0...297mm and the Y range to 0..210mm?

This mean that the backend rotate the picture in order to follow the
scan area rotation. That's a wrong idea. Backend must not rotate, they
just get data from device and drop them to frontend through sane_read
().

> Well, as I understand it, both cases you describe boil down to these
> parameters and questions:
>
> - alignment of the paper in the feeder: centered/corner 1/corner 2
>   (other possible alignments should be considered broken...)
> - "clever" support of the page width/length parameters by the
>   frontend, which must be aware of a possible shift of the origin of
>   the scan window coordinates to the top-left corner of the selected
>   page size
> - which information is missing for scanners that can move an A4 page
>   parallel to its short edge?
Yes. Adding a offset info for scanne that do not support paper-size.

So we should add to the standard :

 - paper-width (fixed mm)
 - paper-height (fixed mm)
or
 - adf-alignement (string) {centered, start, end}
 - adf-offset (fixed mm)
 - adf-side (string) {top,bottom,left,right}

Right ?

Thank for your very interesting comments :)

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Olaf Meeuwissen
In reply to this post by abel deuring
abel deuring <[hidden email]> writes:

> Hi all,
>
> Étienne Bersac wrote:
>
>> Thanks for you comments. There are very useful.
>>
>>>   - alignment of original to scan origin or not (centered feeds)
>>
>> That's an important point. SANE should provide a "adf padding" option or
>> similar.
>
> Some hints how the alignment of the paper width in the feeder
> affects the scan window settings may be useful, but I think this is
> too simple.
>
> I see several "scanner parameters" that can affect the scan window
> settings:
>
> (1) the paper can be centered/left aligned/right aligned in the
>     feeder
> (2) some scanners know about the parameters "page width" and "page
>     length"
> (3) the origin of the scan window coordinates is fixed, or it is at
>     the "corner" of the selected page size.
>
> Another question is, if a frontend really needs to know about all
> these details: If a user does not properly adjust the paper width of
> the  feeder, the scan results will anyway be a bit messy. And if we
> assume that the feeder is properly aligned, I think that (1) is no
> longer important.

In the most extreme case a frontend doesn't need to know anything:
just scan at the default settings.  The thing is that some users want
to do things that require access to the very last little bit of
configurability.  That doesn't automatically imply that every little
option should be in the standard, of course.

>>>   - limiting scan area to page size
>>
>> This can be done via {tl,br}-{x,y}. Isn't it ?
>
> right.

True, but I was thinking of an advanced boolean option where user
could turn this behaviour off if they want to.

>>>   - rotation of original
>>
>> Imo, this is post processing, device/sane/backend should not care this.
>
> right.

On second thought, this option is not limited to ADF.  However, if the
hardware can do rotation of the image data, there should be an option.
I know of several scanners that can do mirroring in hardware.  Why
have the backend or frontend do this if the hardware can?

>>>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>>>     scan area so the user can fiddle with whatever other options before
>>>     starting a scan of a 100 page document.  You may even want to allow
>>>     for repeating the preview with the same page.)
>>
>> That makes sense.
>
> ...only for some, if any, ADF scanners. Those ADF/flatbed scanners I
> know work a bit different in ADF mode: They do _not_ place the paper
> on the glass pane and then move the scan head across the pane;
> instead they acquire the scan data while the _paper_ is moving,
> while the scan head stays at a fixed position. This is faster, since
> the paper must be moved anyway in ADF mode, so first placing the
> paper on the glass pane and then scanning it in "flatbed mode"
> simply requires additional time.

I have experience with both types.  The higher end EPSON scanners (A3,
business market) pull the page onto the bed.  If you scan A4 oriented
so that two pages fit on the bed you get the situation where the first
page results in a single page on the bed and all following pages will
have _two_ pages on the bed.  Ideally, you would only scan the page
that was just put on the bed and ignore the rest.  Of course, media
size detection is a prerequisite to get this done.

Anyway, the idea is that if some ADF unit puts pages on the bed
instead of pulling them over the scan head then for those units
previewing might make sense.

>> So, I propose the following options add:
>>
>>       * simplex/duplex document
>>               * name: "adf-duplex"
>>               * title: "Duplex/simplex"
>>               * desc: "Wether the document in the ADF is duplex or
>>                 simplex."
>>               * type: string enum
>>               * values: none/long-edge/short-edge
>
> I think the options currently used by the Fujitsu and Avision
> backends (and perhaps others) are sufficient: source = flatbed | ADF
> front | ADF back | ADF duplex.

Hmm, I'm more in favour of limiting source to flatbed and ADF and have
extra options on the ADF source.  Anyone dealing with scanners that
have multiple ADF units?  I have some with "multiple" TPU units.  They
have two areas on the flatbed to scan transparencies.  The user has to
indicate which one should be used.

> [snip]

Hope this helps,
--
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
FSF Associate Member #1962           sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
Penguin's lib!       -- I hack, therefore I am --               LPIC-2

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Olaf Meeuwissen
In reply to this post by m. allan noah-3
"m. allan noah" <[hidden email]> writes:

> sorry for the weird forward from new account- having email troubles....
>
>> On Wed, 17 Jan 2007, Étienne Bersac wrote:
>>
>> >>   - "ADF preview" (feed first page, do a preview scan, leave it on the
>> >>     scan area so the user can fiddle with whatever other options before
>> >>     starting a scan of a 100 page document.  You may even want to allow
>> >>     for repeating the preview with the same page.)
>> >
>> > That makes sense.
>>
> but requires that the user understand that the page that has been
> previewed cannot be rescanned without reloading the hopper.

There are scanners that put the sheet on the flatbed and can leave it
there after a scan.  In that case, reloading the "hopper" is not
necessary.  This was the scenario I was thinking of when I suggested
the "ADF preview" option.  Of course, if the handware can't do that,
the backend won't have such an option and the frontend should not care
about that.

# Backends can not be made to do what the hardware doesn't support
# even if a frontend would like to provide the functionality.
# Frontends just have to deal with the options they get.  Knowing what
# each option stands for, however, goes a long way in writing a good
# frontend, though.

Hope this helps,
--
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
FSF Associate Member #1962           sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
Penguin's lib!       -- I hack, therefore I am --               LPIC-2

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
In reply to this post by Étienne Bersac-3
Hi,

sorry, i mis explain the end of my mail.

> So we should add to the standard :
>
>  - paper-width (fixed mm)
>  - paper-height (fixed mm)
> or
>  - adf-alignement (string) {centered, start, end}
>  - adf-offset (fixed mm)
>  - adf-side (string) {top,bottom,left,right}

I mean, SANE standard should state that :

A backend which provide "Automatic Document Feeder" source should
provide the following options :

      *  duplex (boolean)

and one of the following option set :

      * paper-width (fixed mm)
      * paper-height (fixed mm)

and

      * adf-alignement (string)  {centered, start, end}
      * adf-offset (fixed mm)
      * adf-side (string) {top,bottom,left,right}

Wish this is clearer.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

m. allan noah-3
On 1/17/07, Étienne Bersac <[hidden email]> wrote:

> Hi,
>
> sorry, i mis explain the end of my mail.
>
> > So we should add to the standard :
> >
> >  - paper-width (fixed mm)
> >  - paper-height (fixed mm)
> > or
> >  - adf-alignement (string) {centered, start, end}
> >  - adf-offset (fixed mm)
> >  - adf-side (string) {top,bottom,left,right}
>
> I mean, SANE standard should state that :
>
> A backend which provide "Automatic Document Feeder" source should
> provide the following options :
>
>       *  duplex (boolean)

it is not enough to have such a flag. most fujitsu adf scanners can
do: adf front, adf back, or adf duplex, so i would need a tri-state
option, and the name 'duplex' would be misleading.

many units have no flatbed. in those models, the 'source' option would
be useless, if it was always adf.

in models with both adf and flatbed, the 'duplex' option would be
enabled/disabled based on setting of 'source', requiring the user to
provide two inputs to change from 'flatbed' to 'adf duplex'.

and so, fujitsu and avision currently use the 'source' option to do
this in one step. think of 'source' not as which piece of hardware
will be used, but rather which 'location' in the scanner will have a
paper over it. this fixes the problem of epson units with two TPU
locations as well...

>
> and one of the following option set :
>
>       * paper-width (fixed mm)
>       * paper-height (fixed mm)
>

this pair makes sense to me :)

> and
>
>       * adf-alignement (string)  {centered, start, end}
>       * adf-offset (fixed mm)
>       * adf-side (string) {top,bottom,left,right}
>

i still do not understand the need for these, are they only for
scanners that use the flatbed as part of the adf path? do they not
have paper guides on the input chute?

i assume that if the user sets the paper guides properly, and tells
the backend what the paper size is (or backend auto detects), then it
is very easy for those backends that need it (those that dont do it in
hardware), to tell the scanner's flatbed portion to add the offset to
the window before scanning. for those that do this in hardware
(fujitsu/avision/etc), you dont have to do anything to the backend or
frontend.

i guess my big problem with this idea of exposing offsets is that it
requires front-ends to understand that when 'adf' is set, the values
of tl-x/y br-x/y are not 'real' anymore, but must be 'fudged' with
some offset. (which is not true for all adf scanners...) this
distinction between adf and fb will lead to errors when front-end
writers dont have one of the affected adf's to test with.

therefore, let the adf units simulate a 'virtual' flatbed of 'paper'
size as much as possible, even to the point of changing the maximum
br-x/y when the paper size changes, and always moving the tl-x/y as
required.

please help me understand the 'adf-side' option? it would seem that
this is not something that the backend can 'know' without asking the
user, because the concept of 'top' or 'bottom' depends on how the
paper was loaded, not how the scanner was built...

allan
--
"The truth is an offense, but not a sin"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,

> >       * adf-alignement (string)  {centered, start, end}
> >       * adf-offset (fixed mm)
> >       * adf-side (string) {top,bottom,left,right}
> >
>
> i still do not understand the need for these, are they only for
> scanners that use the flatbed as part of the adf path? do they not
> have paper guides on the input chute?

They are for scanner which do not handle paper-size. However, if backend
implement virtualy paper-size, this is better ; you're right.

So, everyone is ok to add paper-width and paper-height option ? If yes,
we then just have to "fix" the "duplex" option :)


> it is not enough to have such a flag. most fujitsu adf scanners can
> do: adf front, adf back, or adf duplex, so i would need a tri-state
> option, and the name 'duplex' would be misleading.

Ok, for an enum {front,back,duplex}, what name do you propose ?

> many units have no flatbed. in those models, the 'source' option would
> be useless, if it was always adf.

The backend does not have to implement source option if it's useless.

> in models with both adf and flatbed, the 'duplex' option would be
> enabled/disabled based on setting of 'source', requiring the user to
> provide two inputs to change from 'flatbed' to 'adf duplex'.

Yes, of course. That's two options.

> and so, fujitsu and avision currently use the 'source' option to do
> this in one step. think of 'source' not as which piece of hardware
> will be used, but rather which 'location' in the scanner will have a
> paper over it. this fixes the problem of epson units with two TPU
> locations as well...

You mean that on some devices, there is two ADF : one which introduce
paper frontside, and one which introduce backside ? Do "ADF duplex" and
"ADF front" be physicaly the same source ? I'll test duplex on my HP
(the backend propose a duplex option, but i don't know if the device
actually scan duplex paper).

The idea is : if the device has two ADF mouth (front and side), then
provide both in source option. However, keep a "duplex" option. (This
might even be useful for both ADF :P).

Thanks.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

m. allan noah-3
On 1/17/07, Étienne Bersac <[hidden email]> wrote:

> Hi,
>
> > >       * adf-alignement (string)  {centered, start, end}
> > >       * adf-offset (fixed mm)
> > >       * adf-side (string) {top,bottom,left,right}
> > >
> >
> > i still do not understand the need for these, are they only for
> > scanners that use the flatbed as part of the adf path? do they not
> > have paper guides on the input chute?
>
> They are for scanner which do not handle paper-size. However, if backend
> implement virtualy paper-size, this is better ; you're right.
>
> So, everyone is ok to add paper-width and paper-height option ? If yes,
> we then just have to "fix" the "duplex" option :)

only you and i are speaking now. that is not everyone :)

>
>
> > it is not enough to have such a flag. most fujitsu adf scanners can
> > do: adf front, adf back, or adf duplex, so i would need a tri-state
> > option, and the name 'duplex' would be misleading.
>
> Ok, for an enum {front,back,duplex}, what name do you propose ?

i propose not to use it at all, see below.

>
> > many units have no flatbed. in those models, the 'source' option would
> > be useless, if it was always adf.
>
> The backend does not have to implement source option if it's useless.
>
> > in models with both adf and flatbed, the 'duplex' option would be
> > enabled/disabled based on setting of 'source', requiring the user to
> > provide two inputs to change from 'flatbed' to 'adf duplex'.
>
> Yes, of course. That's two options.

but from the user's perspective, its only one action. for instance: i
was scanning the glass, now i want to scan the back of the paper in
the adf.

>
> > and so, fujitsu and avision currently use the 'source' option to do
> > this in one step. think of 'source' not as which piece of hardware
> > will be used, but rather which 'location' in the scanner will have a
> > paper over it. this fixes the problem of epson units with two TPU
> > locations as well...
>
> You mean that on some devices, there is two ADF : one which introduce
> paper frontside, and one which introduce backside ? Do "ADF duplex" and
> "ADF front" be physicaly the same source ? I'll test duplex on my HP
> (the backend propose a duplex option, but i don't know if the device
> actually scan duplex paper).

no, i mean that the scanner has two or three read-heads, and can use
any one of them, or even two of them at once. that is the 'source'
IMHO.

>
> The idea is : if the device has two ADF mouth (front and side), then
> provide both in source option. However, keep a "duplex" option. (This
> might even be useful for both ADF :P).

you see that it is not enough for sane standard to list the only
possible sources as adf, tpu, and flatbed. this is artificially
limiting. the standard could certainly suggest or require certain
spellings or abbreviations of 'ADF', but it cannot know what 'source'
some future scanner will offer (slide holder, negative strip, film
reel). i agree fully with the idea of well-known option _names_, but
do not see a need to also enforce a series of _values_.

once you have made this mental leap that 'source' is entirely under
the control of the backend, it makes for a much simpler design to use
'source' to distinguish between different read-heads in the scanner.

allan

--
"The truth is an offense, but not a sin"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,

> > So, everyone is ok to add paper-width and paper-height option ? If yes,
> > we then just have to "fix" the "duplex" option :)
>
> only you and i are speaking now. that is not everyone :)

This is a question. :)

> no, i mean that the scanner has two or three read-heads, and can use
> any one of them, or even two of them at once. that is the 'source'
> IMHO.

Ok. I think that a source is a combination of a feeders+read-head. How
does the backend handle two image at once ? How is this handled by
sane_read ?

> i agree fully with the idea of well-known option _names_, but
> do not see a need to also enforce a series of _values_.

Well knowm option types should also be considered. About values. The
problems with variable string for the same value are :

      * How to translate ?
      * How to make backend-independent code (real generic code) ?

Of course, If the device has more than three sources, then you must
extends the standard. I think we must redesign source standard in order
to handle such case. Using ADF is not bad :).

Frontend programmers should not read each backend documentation, only
SANE standard. That's the purpose of the standard.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

Étienne Bersac-3
Hi,

I tested duplex scan with hpaio backend with a HP OfficeJet 7140xi
all-in-one networked printer. It use the same source (ADF) but pass the
same paper twice over ther read-head, one for each side. This device is
quite tricky :). So, the "duplex" option makes sense.

However, if some fujitsu device has two adf, then add two sources : "adf
front" and "adf back" or "adf" and "adf back"; but please provide a
duplex option.

Can you point me a photo of the device ? It is possible to do duplex
scan whatever which adf is used ?

If there is two heads and one ADF, then i guess you should just expose
"ADF" and provide "duplex" option. Some users are clueless of how the
device works. Also, why using back read-head instead of front one ? That
may be just confusing for most users, and useless for the other.

Regards,
Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

abel deuring
In reply to this post by Étienne Bersac-3
Étienne Bersac wrote:

>>> ACK. However, some might allow ADF preview, we must support that. The
>>> backend must teach the frontend if it can preview with ADF.
>> Ummm, I would rather suggest to support a more general way to set
>> the scan window that is useful for every ADF scanner: Let the user
>> make a test scan with one page; display this page in a preview
>> window; allow to set page size (if possible/reasonable) and the scan
>> window; let the user insert the test page back into the ADF; let him
>> make again a test scan and so on.
>
> That's just crazy. Users are just fed up to walk trough the room just to
> relaunch a preview. (In my case, my HP is networked and my mother has to
> walk from the living room to my bedroom in order to feed the scanner,
> that's quite long, and running the there and back trip more than twice
> just makes user crazy).

well I didn't want to suggest these repeated previews as a
recommended procedure -- I only wanted to point out that previews
for ADF scanners are a bit tricky. Consider this "trickyness" -- no
way to automatically put a paper back into the feeder, and no way to
repeat scans with the same document without placing it into the
feeder -- simply as a challenge for a frontend.

>> I was trying to figure out, how this "feed from the right side of
>> scan area" device works, to which you obviously have access.
>>
>> The "average" ADF scanner works this way, perhaps you can explain,
>> where your scanner works differently: […]
>
> I own an HP OfficeJet G85 all-in-one printer which introduce paper
> left-side-first in the flatbed, scan the paper, then eject it and while
> feeder is no empty. The paper is moved left-to-right. I agree this is
> not the fastest way, and new HP all-in-one printers do not work like
> that. However, such device exsists and we must support it.
>
>>> According to this example, i don't really know if adf-duplex is usefull.
>> Why should it not be useful?
>
> You're right. In fact, some backend has a duplex option (hpaio does). We
> should add it to the well known option.
>
>> Another viewpoint: If the scanner moves the paper "by default from
>> left to right", i.e., for example an A4 size ADF scanner that moves
>> the paper parallel to the short edge, shouldn't the backend simply
>> set the X range to 0...297mm and the Y range to 0..210mm?
>
> This mean that the backend rotate the picture in order to follow the
> scan area rotation. That's a wrong idea. Backend must not rotate, they
> just get data from device and drop them to frontend through sane_read
> ().

ok, another attempt: How does an image file look like that is made
from an A4 page using scanimage (no "fancy" frontend!) and this
scanner that moves the paper from left to right, i.e., parallel to
the short edge of the paper? Is the image in landscape or portrait
format? See also my comment on the words top/bottom/left/right below.

Does this scanner move the document first and scans it in a second
step the same way as when it had been placed manually on the glass
pane, or does it scan while moving the paper? (Olaf convinced me
that the former type really exists ;)

>> Well, as I understand it, both cases you describe boil down to these
>> parameters and questions:
>>
>> - alignment of the paper in the feeder: centered/corner 1/corner 2
>>   (other possible alignments should be considered broken...)
>> - "clever" support of the page width/length parameters by the
>>   frontend, which must be aware of a possible shift of the origin of
>>   the scan window coordinates to the top-left corner of the selected
>>   page size
>> - which information is missing for scanners that can move an A4 page
>>   parallel to its short edge?
>
> Yes. Adding a offset info for scanne that do not support paper-size.
>
> So we should add to the standard :
>
>  - paper-width (fixed mm)
>  - paper-height (fixed mm)

...as a well-known (no a required) option for ADF scanners that
support it. Additionally, it might make sense to know, if setting
the page size affects the position of the coordinates origin for the
scan window.

> or
>  - adf-alignement (string) {centered, start, end}
>  - adf-offset (fixed mm)
>  - adf-side (string) {top,bottom,left,right}

"top,bottom,left,right" need to be clarified: The Postscript file of
the Sane1 standard http://www.sane-project.org/sane.ps has on page
11 a figure "transfer order of image data bytes". "ADF side top"
means that the ADF is positioned so that the paper is moved from
top/right/left/bottom, relative to the orientation of the output data.

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

abel deuring
In reply to this post by m. allan noah-3
m. allan noah wrote:

>>       * adf-alignement (string)  {centered, start, end}
>>       * adf-offset (fixed mm)
>>       * adf-side (string) {top,bottom,left,right}
>>
>
> i still do not understand the need for these, are they only for
> scanners that use the flatbed as part of the adf path? do they not
> have paper guides on the input chute?

I have too problems grasping these fine details ;)

>
> i assume that if the user sets the paper guides properly, and tells
> the backend what the paper size is (or backend auto detects), then it
> is very easy for those backends that need it (those that dont do it in
> hardware), to tell the scanner's flatbed portion to add the offset to
> the window before scanning. for those that do this in hardware
> (fujitsu/avision/etc), you dont have to do anything to the backend or
> frontend.
>
> i guess my big problem with this idea of exposing offsets is that it
> requires front-ends to understand that when 'adf' is set, the values
> of tl-x/y br-x/y are not 'real' anymore, but must be 'fudged' with
> some offset. (which is not true for all adf scanners...) this
> distinction between adf and fb will lead to errors when front-end
> writers dont have one of the affected adf's to test with.
>
> therefore, let the adf units simulate a 'virtual' flatbed of 'paper'
> size as much as possible, even to the point of changing the maximum
> br-x/y when the paper size changes, and always moving the tl-x/y as
> required.

The point is that some ADF scanners want to "know" the paper size
and others that "have no idea" about the paper size. For the former,
 some set the scan window relative to the paper size, like some
Fujitsu models, while others set the scan window relative to the max
scan size.

So we have the situation that either a frontend must be able to deal
with all cases or that the backends must "normalize" their options
to something defined for Sane2. I think it is better to leave the
details to the frontends -- it is too difficult to anticipate all
possible variants of ADF types and ADF related options as to try to
define something quite specific for the standard. Before Olaf
convinced me otherwise, I did not believe that ADF scanners exist
which do not acquire the scan data while the paper is moving...

> please help me understand the 'adf-side' option? it would seem that
> this is not something that the backend can 'know' without asking the
> user, because the concept of 'top' or 'bottom' depends on how the
> paper was loaded, not how the scanner was built...

Think about the scanners, where the feeder moves a document onto the
glass pane, and where the scanner make an "ordinary" flatbed scan.
Here it makes indeed sense to know, from which side a document is
moved onto the glass pane: If a frontend has a selection list for
document sizes, and if the the scanner's firmware has "no idea"
about paper sizes, the frontend must calculate the scan window
coordinates for the flatbed area.

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More device properties

abel deuring
In reply to this post by Étienne Bersac-3
Étienne Bersac wrote:

>> no, i mean that the scanner has two or three read-heads, and can use
>> any one of them, or even two of them at once. that is the 'source'
>> IMHO.
>
> Ok. I think that a source is a combination of a feeders+read-head. How
> does the backend handle two image at once ? How is this handled by
> sane_read ?

The typical situation is that the scanner sends one chunk of
frontside data, one chunk backside data, frontside data, backside
data... (Allan, yes, I know that some Fujitsu scanners caused you
some headaches because they work a bit more strange ;)

After the first call of sane_start, the backend returns the
frontside data and writes the backside data into a temporary buffer;
when the frontside data is completely transferred, the frontend call
sane_start again, and the backend returns the buffered backside data.

>> i agree fully with the idea of well-known option _names_, but
>> do not see a need to also enforce a series of _values_.

Perhaps not enforced, but encouraged ;) From Eikazo's file Widgets.py:

       # grepping the Sane backend sources, the following ways exist
       # to select and detect an ADF:
       #
       # option source has one of the values:
       #   'ADF'                       (avision, hp, microtek2,
       # sp15c)
       #   'ADF Rear'                  (avision)
       #   'ADF Duplex'                (avision, fujitsu)
       #   'ADF Front'                 (fujitsu)
       #   'ADF Back'                  (fujitsu)
       #   'Automatic Document Feeder' (bh, epson, mustek, nec,
       # pixma,
       #                                sharp, umax)
       #   'Document Feeder'           (snapscan)
       #   'Filmstrip'                 (microtek2)
       #     I'm not 100% sure about Filmstrip, but it could make
       #     sense to treat it similary to an ADF
       #
       # bool option 'adf': artec, ibm
       # bool option 'noadf': canon
       # string option 'feeder-mode', value 'All Pages': matsushita

I did not yet had a look into any external backend -- I might have
found even more variants ;)

We should strongly encourage the usage of options and option values
defined in saneopts.h (or its equivalent for Sane2) and we should
add new options/option values to this file more frequently. At
present, the file contains nothing related to ADFs...

Another point: Think about an ADF-only scanner, that has no duplex
capabilities. If a backend does not define the option "source" (or
whatever else), a frontend has no way to figure out, if the scanner
it is controlling is capable to make ADF scans or not. Hence we
should either require^H^H^H^H^H^H^Hrecommend the usage of the source
option with exactly one value, or we should add some "purely
descriptive" option telling the frontend that a scanner can make ADF
scans.

> Well knowm option types should also be considered. About values. The
> problems with variable string for the same value are :
>
>       * How to translate ?
>       * How to make backend-independent code (real generic code) ?
>
> Of course, If the device has more than three sources, then you must
> extends the standard. I think we must redesign source standard in order
> to handle such case. Using ADF is not bad :).
>
> Frontend programmers should not read each backend documentation, only
> SANE standard. That's the purpose of the standard.

ummm, in theory, yes. But in the real world it is quite difficult to
 anticipate all possible options that might be used by more than one
backend. Just consider how difficult our discussion is, if it makes
sense to add an option "adf-side". We have quite different concepts,
how many variants of ADFs exist/make sense/can be thought of, and
what formal descriptions are required to deal with all possible
devices properly. My crystal ball is defunct since a long time, so I
don't dare to predict that we will be able to cover today all
possible features that may become a standard for scanners produced
in five years ;)

When the Sane1 standard was developed, nobody thought for example of
an infrared channel, but quile many film scanners seem to produce
infrared data. Having an "open way" to respond to such features is
IMHO more important than to attempt to specify everything today.
(And, BTW, except infrared data, the Sane1 standard has proven that
is indeed "good enough" to represent quite many different scanner
features, which were probably not anticipated by the authors.)

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
123
Loading...