Re: [hpoj-devel] ptal-mlcd ECP changes

[<pa...@rc...>]

Joe Piolunek wrote:
> The messages look slightly familiar, but I don't think they have appeared 
> recently. I seem to recall seeing "exClose" appear at stdout. It may have 
> happened only a couple of times.
exClose() is the function that gets called whenever something goes wrong in
the communication with the peripheral.

> Nothing like it is in /var/log/messages.
Nothing will show up there because currently ptal-mlcd doesn't use syslog.
I plan to change that eventually.


Bob Paddock wrote:
> Second scan at -300 came out ok, but it took about 3 minutes to scan it, it 
> was a black and white page, but it was probably still scanned as color since 
> I did change any thing besides adding the -300.
> 
> I loaded up the out.jpg image with KView then my machine started going so 
> slow it was useless, the mouse moved in great leaps and lunges.  Had to cycle 
> power.  Don't know if this is in any way related to scanning, for the moment 
> lets assume that it was not.  The scan did look fine.
A 300dpi JPEG image requires lots of RAM to process, because I think libjpeg
insists on decompressing it into RAM.  A high resolution setting like 300dpi
is overkill for most situations.

> Third scan of b&w page in color with the defaults got me:
> patlChannelRead returns 0!
> Broken Pipe.
It would be helpful to know if ptal-mlcd reported any error messages, because
chances are that something went wrong at that level.

> All pages looked like there where twice as long as they should have been when 
> viewing out.jpg in the viewer.  Last half was a blank gray looking thing, 
> probably scanned the color of the unit it self.
That's a known issue (mentioned briefly in SCAN-HOWTO and in the "Bugs and
TODO" list on the web) with certain models, including yours, where the
device doesn't report the image length.  For now, I put in a kludge where
the length equals twice the width, until I can figure out how to parse the
JPEG-compressed data just enough to count the lines so I can write it into
the JPEG header.  That's why you see the large gray area.

> What I could not figure out how to make it do was scan all of the loaded 
> pages?  Having a autofeed scanner is kind-of useless if you have to manually 
> intervene for each page.  Same complaint I have about the HP710 standard 
> windows software (I would not have bought the thing had I known that up 
> front).
I added an item on the TODO list to work on this before I release 0.8.
For now, you could try writing a script that calls ptal-hp in a loop.  I
neglected to document that ptal-hp has different exit codes depending on
whether the scan was successful and there are (1) or aren't (0) more pages
to scan.  I haven't actually tested this, however, so this functionality
will depend on whether each device properly reports whether a new page is
available.  Also, 2 means that there was no page to begin with, 3 means
command-line syntax error, and 4 means some sort of miscellaneous device
error.

> I do have (x)sane 1.0.4/0.76 loaded on here if you want any thing tested.  I 
> use it with my Epson scanner all of the time.
Currently SANE doesn't support your model.  "ptal-hp scan" is a temporary
scanning solution until I can get around to developing a proper SANE backend
that properly supports all of the models.

> This is my printcap file in its entirety:
> 
> HPOJ:
> 
> just those five chars.
That's really bizarre.  I guess CUPS has different methods of configuring
print queues, and this file only exists for compatibility with programs
that read it to try to find out what print queues are available.  Perhaps
the programs that you had trouble with printing got confused by this
minimalist format, and in the interest of "ease-of-use" and hiding complexity
from the user, neglected to provide a more generic way to print.  (I'm just
guessing here, mind you.)

Most Unix programs print by generating PostScript and sending it to the print
spooler.  Often they have some sort of option to save the PostScript to a
file without actually printing it right away.  That way, if all else fails,
you can just invoke something like "lpr filename.ps" from a shell prompt (or
whatever the CUPS equivalent is to lpr).  I frequently "print to a file"
just so I can inspect the output in ghostview before actually printing.

David