[sane-devel] Scanner Recommendation for long receipts?

[Marshall Jose]

As someone who made a hobby of scanning player piano rolls, I can tell you
that the generalized solution to imaging paper of arbitrary length involves
either the expenditure of much money, or else much effort. My journey ended
with a flatbed scanner (using SANE), a paper advance mechanism, and some
really ugly code to stitch successive images together; though
unsophisticated, it has scanned 4,500 rolls to date.

An example of a more elaborate scheme can be found at
http://semitone440.co.uk/scanner/ . Note the role of the encoder wheel in
providing essential information about the speed variations of the media
passing in front of the line scan camera.

The biggest problem lies in transporting many meters of flimsy or brittle
paper without damaging it, and I don't believe that has a general solution
to date.

Marshall


On Mon, Aug 21, 2023 at 12:17 PM Harvey Nimmo <harvey at nimmo.de> wrote:

> My Canon GX5060 seems to have no problem feeding, for example, the long,
> thin  British Birth, Marriage, Death certificates completely through the
> AFD (Feeder. The flatbed is A4 compatible)), but either the associated
> on-board software or the scanner drivers cannot scale the result onto a
> complete image. In other words, I suspect it is only a software limitation
> somewhere in the chain. ...and I would really appreciate a solution! :-)
>
> Cheers
> Harvey
>
> On Mon, 2023-08-21 at 11:00 -0400, m. allan noah wrote:
>
> Most ADF scanners need to be told how long the paper is, so they can do
> things like length-based double feed detection, buffering, blank page
> detection, etc. However, the maximum length should be fairly long on most
> machines I am familiar with. IIRC, some Canon and Fujitsu machines will go
> up to one meter in length? I'll try to look around for some examples.
>
> allan
>
> On Mon, Aug 21, 2023 at 9:11 AM Andy Bennett <andyjpb at ashurst.eu.org>
> wrote:
>
> Hi,
>
> I don't have a solution I'm afraid but can offer some solidarity below!
>
>
> > like CVS/Walgreens long
> >
> > Is there a scanner out there that can scan up to 24"? or 36?
> >
> > I've been folding and making a multipage PDF.  Is there a better way?
> >
> > Is there a reason scanners must have a maximum length or could
> > they just stream data back to the PC continuously until the scan
> > is complete.  like a toilet paper roll for example.
>
> I have wondered about this too but not found any good implementations in
> desktop scanners.
>
> My ix500 has a scanning length that's not quite long enough for some
> things
> such as certain kinds of official certificates that are A4 width but have
> extra long fold out bits at the end.
>
> I'd suggest cutting the reciept into pieces, but I always hate a solution
> like that when there seems to be No Good Reason why the product doesn't do
> it in the first place. Besides, there may be good reasons to not want to
> cut your document into pieces for the sake of a scan.
>
> For my scenarios it often suffices to scan it one way up and then the
> other
> because the documents are less than twice the length the scanner can
> handle.
> ...but that still leaves an annoying amount of post-processing to do. It's
> even harder if the documents are particularly thin (like reciepts) because
> you're more likely to get a wobbly horizontal registration between the two
> scans.
>
>
> > I have no problem scanning a 700 page document if I keep that
> > ADF feder hopper full and keep the exit tray from filling up on
> > my ADF scanners.  But what reasons are there, that a single page
> > can not be say, 100 feet long?
>
> I guess none in principle. This one (done with a line scan camera which is
> similar to the single pixel-wide CCDs a scanner would use) is as long as a
> train: http://elm-chan.org/works/lcam/g/Y0008.jpg
>
> (via http://elm-chan.org/works/lcam/report.html )
>
> I've seen others that document entire long distance train journeys.
>
>
> Good luck and please let us know if you find anything!
>
>
> Best wishes,
> @ndy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20230821/45e136f2/attachment-0001.htm>