Menu
▾
▴
hpoj-devel
|
From: James K. <ja...@me...> - 2001-02-11 23:00:40
|
Hi David, I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION and then creating a viewable .pgm file with the data. Unfortunately, it only seems to work a few times in a row then it starts to hang each time during an MlcCon_read. Scanning GRAYSCALE_256/NO_COMPRESSION results in a hang everytime. Scanning COLOR_24_BIT/NO_COMPRESSION results in FixedHeaders with no RasterData and then hangs. It almost seems like there is a certain amount of data that will pass through the scan channel without problem. After that it starts to hang. This might explain why I can have a few successful scans at BILEVEL_THRESHOLD before problems occur, and not get through a full scan at GRAYSCALE_256 which would transfer 8 times the amount of data. Could you please explain the current problem with multi-channel communication? I am wondering if it is something I should look into or wait for/help with the new drivers. Do you have any idea when the new drivers you're working might be ready? Thanks, -James |
|
From: <pa...@rc...> - 2001-02-12 00:11:22
|
James Klicman wrote: > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION > and then creating a viewable .pgm file with the data. > > Unfortunately, it only seems to work a few times in a row then it > starts to hang each time during an MlcCon_read. > > Scanning GRAYSCALE_256/NO_COMPRESSION results in a hang everytime. > > Scanning COLOR_24_BIT/NO_COMPRESSION results in FixedHeaders with no > RasterData and then hangs. Hi, James. Congratulations on getting at least BILEVEL_THRESHOLD scanning working. :-) What exactly is a .pgm file? > It almost seems like there is a certain amount of data that will > pass through the scan channel without problem. After that it starts > to hang. This might explain why I can have a few successful scans > at BILEVEL_THRESHOLD before problems occur, and not get through > a full scan at GRAYSCALE_256 which would transfer 8 times the amount > of data. That's quite possible. You might be able to test that theory by cutting out a short piece of paper (still 8.5" wide) and doing an 8- or 24-bit scan on that, because the scan should stop when it reaches the end of page. Just don't make it too short, or it might get lost in the scanner and cause paper jams. You could also try taping several sheets together and doing a 1-bit scan on that, but again be careful when taping not to leave any sticky spots that could cause a jam. > Could you please explain the current problem with multi-channel > communication? I am wondering if it is something I should look into > or wait for/help with the new drivers. I never got around to looking into it, but you can also reproduce it by printing while running xojpanel, or vice versa. I'm fairly sure it's a bug in ieee12844.c, not ieee12844pp.c. You're welcome to look into it if you're interested in digging around in kernel space, especially if it's preventing you from making progress at the moment. > Do you have any idea when the new drivers you're working might be ready? It's working fairly well now (I can print and scan on a USB-connected K80). However, I'm still trying to negotiate release of this code with my management, because I leveraged a significant amount of HP-proprietary code. I'm optimistic that I'll be able to resolve it, but I can't say when at this point. On the technical side, I still need to finish adding PML support to PTAL and the new driver before PML scanning will work through it. David |
|
From: Gerhard F. <ger...@fu...> - 2001-02-13 10:20:25
|
David Paschal wrote:
>
> James Klicman wrote:
> > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION
> > and then creating a viewable .pgm file with the data.
A very simple, easy graphics file format.
Actually it is a whole family consisting of
"pbm" -> bitmap with depth=1, each pixel can be
black/white (-> e.g. a typical Fax)
"pgm" -> a grayscale picture
"ppm" -> a RGB color picture (truecolor with RGB
for each pixel, not with colormap/indexed
like a GIF)
"pnm" -> used to denote the family, i.e. any of
the above three
There also exist the pbmplus tools for manipulating
these file types, see /usr/X11R6/bin/*{pbm,pgm,ppm,pnm}*
Gerhard
|
|
From: Robert G. B. <rg...@ph...> - 2001-02-13 12:15:07
|
On Tue, 13 Feb 2001, Gerhard Fuernkranz wrote:
> David Paschal wrote:
> >
> > James Klicman wrote:
> > > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION
> > > and then creating a viewable .pgm file with the data.
>
> A very simple, easy graphics file format.
> Actually it is a whole family consisting of
>
> "pbm" -> bitmap with depth=1, each pixel can be
> black/white (-> e.g. a typical Fax)
> "pgm" -> a grayscale picture
> "ppm" -> a RGB color picture (truecolor with RGB
> for each pixel, not with colormap/indexed
> like a GIF)
> "pnm" -> used to denote the family, i.e. any of
> the above three
>
> There also exist the pbmplus tools for manipulating
> these file types, see /usr/X11R6/bin/*{pbm,pgm,ppm,pnm}*
>
> Gerhard
Indeed, a lot of those tools are already in place and automatically used
in the printer filters, at least for a RH system. Once you get it into
a p?m format, you have a number of tools for scaling, rotating, and the
like. RH's strategy appears to be "get an arbitrary format into pnm,
then convert pnm to ps, then print (usually using ghostscript printer
filters)." See:
rgb@ganesh|T:120>dir /usr/lib/rhs/rhs-printfilters/
bmp-to-pnm.fpi* gif-to-pnm.fpi* pnm-to-ps.fpi* tiff-to-pnm.fpi*
dvi-to-ps.fpi* jpeg-to-pnm.fpi* rast-to-pnm.fpi* troff-to-ps.fpi*
where in these filters many of the tools are demonstrated in pipes.
A single example. If you have a digital camera and take a lot of
pictures, you probably want to turn the hi-res jpegs into low-res,
rescaled, possibly rotated gifs to stick up on your website. Here is a
fragment from a little perl script I wrote to help me make this
conversion:
$command = "cat $INFILE | djpeg -pnm | pnmscale $scale | pnmrotate $rotate | ppmquant 256 | ppmtogif - > $OUTFILE";
if($verbose){ print "$command\n"; }
system($command);
djpeg converts jpeg to pnm (among others -- it will convert straight to
gif but not allow scaling and rotation). pnmscale and pnmrotate scale
and rotate the "pixel any map" (pnm). ppmquant fixes the colormap depth
-- useful if you don't want to exhaust the colormap of a low-res 8 bit
display on an unknown browser somewhere. Finally ppmtogif does the
final conversion to gif. Using a tool like this (with obvious perl
wrapping it and setting the variables, full program available on
request) allows one to convert a whole directory of jpegs with a simple
shell loop, and is often a lot easier and faster to use than cranking up
a whole GUI (e.g. xv or eeyes or gimp or whatever) just to do a simple
rotation and scaling.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rg...@ph...
|
|
From: James K. <ja...@me...> - 2001-02-12 02:39:28
|
Hi David, A .pgm file is a Portable Graymap. I used rawtopgm which is part of the pnm tools after converting the bits to bytes. I noticed that the SetReply exec_out is not always OK, sometimes it is ErrorActionCanNotBePerformedNow. The PML Protocol Specification refers to the PML Object Specification to determine why this happened and how to get the device into the correct state for the SetRequest. Can you please send me the PML Object Specification? Thanks, -James On Sun, Feb 11, 2001 at 04:12:23PM -0800, David Paschal wrote: > James Klicman wrote: > > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION > > and then creating a viewable .pgm file with the data. > > > > Unfortunately, it only seems to work a few times in a row then it > > starts to hang each time during an MlcCon_read. > > > > Scanning GRAYSCALE_256/NO_COMPRESSION results in a hang everytime. > > > > Scanning COLOR_24_BIT/NO_COMPRESSION results in FixedHeaders with no > > RasterData and then hangs. > Hi, James. Congratulations on getting at least BILEVEL_THRESHOLD scanning > working. :-) What exactly is a .pgm file? |
|
From: Randy J. Y. <ry...@me...> - 2001-02-12 02:56:14
|
Greetings, I'm wondering if anyone is currently working out the 2.4.x kernel issues? If not, I may take a crack at it myself. Now that the kernel is officially released people are going to start migrating in large numbers... -Randy Jay Yarger ry...@me... |
|
From: Burkhard K. <bu...@bu...> - 2001-02-12 12:19:48
|
Randy Jay Yarger > Greetings, > > I'm wondering if anyone is currently working out the 2.4.x kernel > issues? > If not, I may take a crack at it myself. Now that the kernel is > officially released > people are going to start migrating in large numbers... As David already wrote I was it me trying to look into it but I gave up - I was unable to resolve the timing issues. If you are interested I can send you my latest (non-working) patch and comment on my findings. Burkhard -- Burkhard Kohl bu...@bu... |
|
From: Randy J. Y. <ry...@me...> - 2001-02-12 13:03:34
|
Burkhard, Sounds great! I don't know that I'll fare any better, but more eyes never hurt. Thanks! Randy -- Randy Jay Yarger ry...@me... On 12 Feb 2001 13:23:05 +0100, Burkhard Kohl wrote: > Randy Jay Yarger > > Greetings, > > > > I'm wondering if anyone is currently working out the 2.4.x kernel > > issues? > > If not, I may take a crack at it myself. Now that the kernel is > > officially released > > people are going to start migrating in large numbers... > > As David already wrote I was it me trying to look into it but I > gave up - I was unable to resolve the timing issues. If you are > interested I can send you my latest (non-working) patch and comment > on my findings. > > Burkhard > -- > Burkhard Kohl bu...@bu... > > _______________________________________________ > hpoj-devel mailing list > hpo...@li... > http://lists.sourceforge.net/lists/listinfo/hpoj-devel |
|
From: Burkhard K. <bu...@bu...> - 2001-02-13 12:35:01
Attachments:
patch.new.gz
|
Randy Jay Yarger
> Burkhard,
> Sounds great! I don't know that I'll fare any better, but more eyes
> never hurt.
>
Find my patch attached. It is against hpoj-0.7 and compiles with
a 2.4.0-test12 kernel. After haven't looked at it for a long time
I found some silly bugs (introduced by myself) which prevented the
modules to work properly. It now works with 2.4.0-test12 on my
box (Non-SMP). If you have a 2.4.1 kernel handy, could you please
test them. I have not had time to look into the newer kernel.
It resolves the following issues
- it should correct for forcibly compiling with or without SMP
support.
- it takes care of changes in the parport interfaces (e.g.:
obsolete calls to lowlevel functions, uses parport_data_forward
and parport_data_reverse).
- it takes care of changes in the queue_task interface (i.E.
substitutes queue_task(..., &tq_scheduler) with schedule_task.
Burkhard
--
Burkhard Kohl bu...@bu...
|
|
From: Randy J. Y. <ry...@me...> - 2001-02-15 14:46:17
|
Truly wonderful! Works like a charm on 2.4.1(up)! Burkhard Kohl wrote: > Randy Jay Yarger > >> Burkhard, >> Sounds great! I don't know that I'll fare any better, but more eyes >> never hurt. >> > Find my patch attached. It is against hpoj-0.7 and compiles with > a 2.4.0-test12 kernel. After haven't looked at it for a long time > I found some silly bugs (introduced by myself) which prevented the > modules to work properly. It now works with 2.4.0-test12 on my > box (Non-SMP). If you have a 2.4.1 kernel handy, could you please > test them. I have not had time to look into the newer kernel. > > It resolves the following issues > - it should correct for forcibly compiling with or without SMP > support. > - it takes care of changes in the parport interfaces (e.g.: > obsolete calls to lowlevel functions, uses parport_data_forward > and parport_data_reverse). > - it takes care of changes in the queue_task interface (i.E. > substitutes queue_task(..., &tq_scheduler) with schedule_task. > > Burkhard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X