Menu
▾
▴
hpoj-devel
|
From: <pa...@rc...> - 2000-12-20 09:58:39
|
Hi, Timothy. Thanks for providing this. I'm sorry the timing was such that I couldn't get it into 0.7. I'll play around with it in the near future, but in the meantime I would be interested in hearing what others think about it, especially how it works with distributions other than RedHat 6.2. I was going to do something like this eventually, but your implementation is much more clever than anything I would have been able to come up with. :-) I'm glad you used the .conf file to allow multiple instances of ptal-printd to be invoked. Hopefully the "killproc" function will be able to handle this properly. I probably should fix ptal-printd so it cleans up after itself when getting killed, including deleting the pipe. David |
|
From: Dag N. <da...@ne...> - 2000-12-21 07:51:22
|
> On Tuesday 19 December 2000 03:07, Timothy Lee wrote: > > >Hiya, all. > > >I'm using hpoj with RedHat 6.2. Instead of activating ptal-printd from > >rc.local, I thought it'd be easier to have a separate init script for it.? > >So I've written up the following script to load ptal-printd as a daemon: > <...> Please Timothy turn off the .x.x.x.x. HTML stuff, now my Exmh will not extract your script wo. a lot of handediting.... BRGDS -- Dag Nygren email: da...@ne... Oy NewTech Ab phone: +358 9 8024910 Trasktorpet 3 fax: +358 9 8024916 02360 ESBO GSM: 0400-426312 FINLAND |
|
From: <pa...@rc...> - 2000-12-24 04:14:33
|
Joe Piolunek wrote: > I think David would like users to be able to start a copy of the daemon, so > could you make that easier? /var/lock/subsys is only writable by root, so a > user's lock file would need to go somewhere else. Although I think it should be OK for non-root users to start ptal-printd, the init script and .conf file are special in that they indicate the "official" policy for a system, so I think it's OK that they are root only. Timothy Lee wrote: > The script was written with root in mind: to make administrating the > system easier. It doesn't stop the user from running a local copy of > the darmon. (But it *will* kill all daemons when stopped.) In other words, users can run the daemon directly, but not the init script. If the init script is called to stop ptal-printd, then all instances of the daemon are killed, even those started without the init script. Sounds reasonable to me. Timothy Lee wrote: > The script now checks for ptal-printd and the config file before > launching the daemon and reporting success. It's hard to check for > errors because the daemon doesn't fork itself and return. (Maybe it's a > feature David will consider adding??? <grin>) Yes, I'll fix that. Would it make more sense to fork or not fork by default (changeable by a command-line option)? David |
|
From: DG <dg...@um...> - 2000-12-29 03:05:14
|
From: pa...@rc... (David Paschal) >> My question: is the device list fixed for ieee12844.o during >> loading, or is it updated dynamically? If not, there'll definitely >> be a problem with OfficeJets that were not turned on during boot up (must >> remove modules by hand, or wait for cron to clean up autoload modules). >The device list for ieee12844pp (not ieee12844) comes from whatever was >connected and powered on when parport_probe was loaded. So if you forgot >to turn on your peripheral before booting, then you need to unload both >ieee12844pp.o and parport_probe, then reload parport_probe and ieee12844p.o. Does the device try to communicate with the computer when it is turned on? If so, the module could look for this signal and add the device when turned on. Windows can handle having the device turned on or off arbitrarily. How is it done? -- Daniel ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ (Remove the Z-'s to reply) ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup |
|
From: DG <dg...@um...> - 2001-01-02 19:20:08
|
> From: pa...@rc... (David Paschal) > Hi, Daniel. > > Daniel Gun wrote: > > Does the device try to communicate with the computer when it is turned on? > > If so, the module could look for this signal and add the device when turned > > on. > IEEE1284-compliant peripherals power up in compatibility mode with no such > peripheral-initiated communication that you suggested. In some cases you > might notice a change in the status (peripheral-to-host) lines, but it's > not guaranteed since different host and peripheral parallel ports have > different pull-up or pull-down resistors. > > > Windows can handle having the device turned on or off arbitrarily. How is > > it done? > Windows tries to read the device ID string from the peripheral when it > boots and when you invoke the "Add New Hardware" wizard, just as > parport_probe does when it is insmoded. I don't think Windows automatically > detects hot-plugging of devices on the parallel port the way it does with > USB devices. It may not detect hot-plugging, but my PSC500 is almost never turned on when I start the computer. I turn it on just before I am about to scan or print. So, either Windows polls it at print and/or scan time, or else it has some other way to know that the device was turned on. In the former case, the answer would be to have hpoj poll the device each time it is about to print or scan. -- Daniel ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ (Remove the Z-'s to reply) ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup |
|
From: David P. <pa...@rc...> - 2002-03-02 08:28:43
|
Joe Piolunek wrote: > It works here on the OfficeJet 600. Once everything was set up, it worked > surprisingly well. The only problem I ran into was during an attempt to scan > at 150x150 from xsane. The printer crashed, showing the message "SYSTEM > ERROR2252" in the LCD. The crash occurred when the one-page scan was about > half finished. Hi, Joe. Thanks for your report. This error number is the same thing you reported previously with "ptal-hp scan", and unfortunately I don't know if there's anything I can do about it. The list of "system error" codes linked from the "Useful links" page on the hpoj website says that this number falls in the "image processor error" category. One suggestion that just came to mind is to get to the "advanced options" and experiment with different values for the "JPEG compression factor" option. It defaults to 0, which yields the best image quality but least compression. Perhaps cranking up that value some will make this problem go away if it's due to some sort of buffer-overrun bug in the firmware when the compressed data for a part of the image is bigger than expected. In order to be scientific about this test, first find a particular document, scan mode (presumably color), and resolution where this problem hits fairly reliably. Then try increasing the JPEG compression factor gradually, keeping the other above-mentioned factors constant. If you can find a threshold value for this setting that makes this problem go away, then I could very easily special-case this model to have a different default value for the JPEG compression factor. I already had to put a lot of model-specific kludges into the code; a few more can't hurt. :-) David |
|
From: David P. <pa...@rc...> - 2002-04-25 07:16:49
|
Joe Piolunek wrote:
> Would there be a problem if an option identifier ('-dev') is required before
> the device name? I don't think there is a compelling reason to use one, but
> having it could result in a little less confusion on the user's part, and the
> result of using it in the command string would be more certain. In any case,
> it would not need to be used unless wanting to connect to a device other than
> the default, if one exists.
Hi, Joe. Since you don't otherwise have any parameters that don't start
with hyphens, my preference would be to not require a "-dev" switch, to be
consistent with the other applications, which in most cases assume that a
parameter that doesn't start with a hyphen is a device name. Feel free
to look in apps/cmdline/ptal-*.c to see how I did it. Search for the
string "ptalDeviceOpen" and then work your way back from there. You'll
find that I did each one a little differently, since I did them at
different times.
David
|
|
From: Joe P. <joe...@sn...> - 2002-04-25 19:12:30
|
On Thursday 25 April 2002 03:10 am, David Paschal wrote: <...> > my preference would be to not require a "-dev" switch, to be > consistent with the other applications, which in most cases assume that a > parameter that doesn't start with a hyphen is a device name. Ok. I should have a patch ready in a couple of days or so. -- Joe |
|
From: David P. <pa...@rc...> - 2002-04-28 07:03:48
|
Joe Piolunek wrote: > Attached is the patch for xojpanel. It automatically connects to the default > device, if one exists. Hi, Joe. Thanks for providing that. I have checked it into CVS with three small changes: - Added period at the end of "Try using \'-help\'". - Commented out "Using %s as deviceName." printf. - At line 217, added "if (dev)" before "ptalDeviceGetName(dev)" call, to prevent a segfault if a default device couldn't be found. David |
|
From: David P. <pa...@rc...> - 2002-05-05 08:13:23
|
Joe Piolunek wrote: > On Friday 03 May 2002 11:53 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote: > > - Fixed libsane-hpoj so xsane doesn't crash when you switch to "Copy" or > > "Fax" mode. As recommended by the xsane developer, I changed the geometry > > options from integers to fixed-precision. > > It works here. PC-controlled copying is a welcome addition. Simply by setting > options in xsane, I was able to click "Start" and have a page scanned and > printed by the OfficeJet, or scanned by the OffficeJet and fed automatically > to the second parallel printer I finally got working with this PC. Hi, Joe. Thanks for the report. I realize that in this case you were copying by scanning on your OfficeJet and printing on your laser printer. Assuming you wanted to print (presumably in color) on your OfficeJet instead, is xsane+hpijs a viable copying solution, seeing as how this and a few other models don't support standalone color copying? I always figured this would be rather slow, since xsane has to convert the raster image to PostScript and then ghostscript and hpijs have to convert it back to rasterized PCL3. But then again, you're using a brand-new gigahertz-plus machine and I'm still using my Pentium-133 from over six years ago. :-) BTW, for those of you with OfficeJet LX or 300 series products, I think I figured out why scanning wasn't working and checked in a change that should fix the problem. I tested it on a compressed image that I had captured from one of these models (I'm not sure which one), but I won't be able to test it on the actual hardware until I go back to work Monday. If anybody with these models tries it out before then (hint hint Mark Purcell:-), then please let me know how it goes and I'll update the Supported Devices page accordingly. (Mark: If you do happen to try it out, then note that I'd prefer that you not make a Debian package out of the CVS code just yet, but rather wait a bit longer until I've managed to stabilize things better and am close to releasing 0.90.) David |
|
From: Joe P. <joe...@sn...> - 2002-05-05 15:44:20
|
On Sunday 05 May 2002 04:14 am, David Paschal wrote: <...> > > It works here. PC-controlled copying is a welcome addition. Simply by > > setting options in xsane, I was able to click "Start" and have a page > > scanned and printed by the OfficeJet, or scanned by the OffficeJet and > > fed automatically to the second parallel printer I finally got working > > with this PC. > > Hi, Joe. Thanks for the report. I realize that in this case you were > copying by scanning on your OfficeJet and printing on your laser printer. > Assuming you wanted to print (presumably in color) on your OfficeJet > instead, is xsane+hpijs a viable copying solution, seeing as how this > and a few other models don't support standalone color copying? I always > figured this would be rather slow, since xsane has to convert the raster > image to PostScript and then ghostscript and hpijs have to convert it > back to rasterized PCL3. But then again, you're using a brand-new > gigahertz-plus machine and I'm still using my Pentium-133 from over six > years ago. :-) New PC prices are pretty low right now. Even with this newer machine (Athlon 1.3 GHz, 256 MB DDR SDRAM), the copy process is slow, but it works. Here is a timeline for a 300 dpi (seems to be the only choice) PC-assisted color copy on the OfficeJet 600: Settings: JPEG comp factor = 0 dpi : I tried to use a lower resolution, but it seems to scan and print at 300 dpi anyway. Scan area: Scanned once for preview and clicked "select visible area" before starting the stopwatch. Color settings: Clicked xsane "autoadjust" button after preview. Document to be copied: OfficeJet color print of 'Google.com' home page After clicking the start button to begin copying, the scan began almost immediately. The xsane progress bar reached the end (%100) at 0:1:18. After what seems like a long wait with nothing happening, initial print activity begins at 0:3:22. Two of the three tests finished at @0:7:00, but one was a little faster. I may have used a different set of options that time. Copy quality: The colors in the copy are lighter than in the original. In the tests I did, the printed area appeared higher on the page than in the original copy (about 13 mm. closer to the top). ---------------------------------------------------- The part of the process that *seems* longest is when nothing appears to be happening. A seeming lack of activity should be avoided, IMHO. The wait would seem a lot easier if the progress bar's behavior were changed so that it either moves slowly, finishing as the print begins, or even better (IMO), the progress bar moves faster, but restarts for each part of the process, accompanied by an informational text message. It would be nice if the process could be speeded up, but (depending on the case) the way it works now is better than making a trip to the copy center. -- Joe |
|
From: David P. <pa...@rc...> - 2002-05-05 23:11:07
|
Joe Piolunek wrote: > Copy quality: The colors in the copy are lighter than in the original. In the > tests I did, the printed area appeared higher on the page than in the > original copy (about 13 mm. closer to the top). Did it help to use xsane's brightness/contrast controls? > The part of the process that *seems* longest is when nothing appears to be > happening. A seeming lack of activity should be avoided, IMHO. The wait would > seem a lot easier if the progress bar's behavior were changed so that it > either moves slowly, finishing as the print begins, or even better (IMO), > the progress bar moves faster, but restarts for each part of the process, > accompanied by an informational text message. Unfortunately, I don't think there's much that can be done about this delay unless the ghostscript+hpijs step can somehow be made faster. I don't know how long it takes xsane to generate a PostScript version of the scanned image. I do know that there can be a long delay from the time the PostScript file gets to the print spooler to the time the page is done printing, and during that time xsane has no visibility on the status of that operation in order to display a realistic progress bar. One possible solution would be to write a command-line application that uses scanimage to scan the page(s), either calls hpijs directly (bypassing the time-consuming PostScript conversion steps) or links directly with the DJ6xx driver code, and sends the resulting output through libptal to the printer. It would really only need to support color copying on the DJ6xx-based models, because other models can handle standalone color copying and all models can handle standalone black&white copying. However, I won't be able to attempt this any time soon. David |
|
From: Joe P. <joe...@sn...> - 2002-05-06 16:43:11
|
On Sunday 05 May 2002 07:12 pm, David Paschal wrote: > Joe Piolunek wrote: > > Copy quality: The colors in the copy are lighter than in the original. In the > > tests I did, the printed area appeared higher on the page than in the > > original copy (about 13 mm. closer to the top). > Did it help to use xsane's brightness/contrast controls? After clicking xsane's autoadjust button, the copy is noticably, but not a lot lighter than the original. It's difficult to get the xsane color settings right because the copy seems to be printed lighter than the preview image. When I reduced only the gamma setting, the color match between original and copy improved, but the colors seemed duller, as if too much black had been used. After a few tries, I haven't been able to match the colors in a way that I would call 'very good'. I suppose it could possibly be a postscript conversion or hpijs issue (I'm using ghostscript-6.51-16, hpijs-1.0.3). > > The part of the process that *seems* longest is when nothing appears to > > be happening. A seeming lack of activity should be avoided, IMHO. The > > wait would seem a lot easier if the progress bar's behavior were changed > > so that it either moves slowly, finishing as the print begins, or even > > better (IMO), the progress bar moves faster, but restarts for each > > part of the > process, accompanied by an informational text message. > Unfortunately, I don't think there's much that can be done about this delay > unless the ghostscript+hpijs step can somehow be made faster. I don't know > how long it takes xsane to generate a PostScript version of the scanned > image. I do know that there can be a long delay from the time the > PostScript file gets to the print spooler to the time the page is done > printing, and during that time xsane has no visibility on the status of > that operation in order to display a realistic progress bar. If a progress bar isn't feasible, could an informational text message be presented? I think users would be more inclined to wait if they see some indication that the task will (probably) eventually finish. > One possible solution would be to write a command-line application that > uses scanimage to scan the page(s), either calls hpijs directly (bypassing > the time-consuming PostScript conversion steps) or links directly with > the DJ6xx driver code, and sends the resulting output through libptal to > the printer. It would really only need to support color copying on the > DJ6xx-based models, because other models can handle standalone color > copying and all models can handle standalone black&white copying. > However, I won't be able to attempt this any time soon. Bypassing the conversion steps would seem to be the ultimate solution, if it could be implemented. The 600's usability under Linux is already pretty good. I think people will like the next hpoj release. -- Joe |
|
From: David P. <pa...@rc...> - 2002-05-12 09:14:15
|
Joe Piolunek wrote: > Have you been working on the configure.in script? Hi, Joe. Not at the moment. Here's what's currently pending: M apps/cmdline/ptal-pml.c M include/ptal.h M lib/ptal/ptal-hpjd.c M lib/ptal/ptal.c M lib/sane/hpoj.c M scripts/ptal-init.in (Other than ptal-init.in, mostly PML<->SNMP bug fixes, which may require an additional small TBD change to ptal-hp.c and xojpanel.) > If not, I think I've fixed > most of the Qt-related problems mentioned in the "Bugs and TODO" list. Thanks for noticing. :-) > I can > send a patch if you like. It would need testing though, especially on BSD > systems, which I don't have access to. Sure, bring it on. > In order of priority, the commandline option "--with-qt=DIR", then (if set) > the QTDIR environment variable, then the result of a search. > > If Qt is installed in dislocated fashion (not in the standard tree form), a > commandline switch "--with-qt-includes=DIR" can be used. It won't have any > effect if the includes are found near libqt* in a standard tree-type > installation. The assumption is that the headers in the same tree as the > library would be correct, but headers found elsewhere may not be. > > To support cases where libqt-mt.so* is available, but libqt.so* is not, > configure.in and xojpanel/Makefile.in are modified to pass a variable > "LIBQT_CMDLINE". Sounds good to me. I can test it on RedHat 6.2, 7.2, and FreeBSD 4.5, as well as give it a look over for general saneness. Thanks, David |
|
From: Joe P. <joe...@sn...> - 2002-05-13 16:05:37
Attachments:
configure.in_05-13-02.patch
|
On Sunday 12 May 2002 05:14 am, David Paschal wrote: > > I can > > send a patch if you like. It would need testing though, especially on BSD > > systems, which I don't have access to. > Sure, bring it on. Here it is (attached). It seems to work pretty well for me, but it should get some serious testing. The patch improves the ability to find and use Qt tree-form installations, and can use a dislocated qt header directory if none is found in the Qt tree, but it doesn't deal with a situation where the Qt installation is completely scattered. It's still necessary for 'moc' to be located in a tree near libqt*. It also doesn't address the reported snmp problem. Some changes for the future could include letting the user specify the locations of all of the necessary Qt file types, by adding ./configure options like "--with-qt-library=<dir>" and "--with-qt-moc=<dir>". Checking for Qt headers is not as exhaustive as the libqt* search, but if they are not automatically found, the "--with-qt-includes=<dir>" option can be used. If libqt.so is missing, libqt-mt.so is used instead if available. The patch can be applied to current CVS with: hpoj ] $ patch -p1 <configure.in_05-13-02.patch -- Joe |
|
From: David P. <pa...@rc...> - 2002-06-22 03:03:29
|
Joe Piolunek wrote: > When building with gcc-3.1, some warnings appear when compiling xscale.c . > xscale.c: In function `weight_two_rows': Hi, Joe. Thanks for pointing that out. It should be fixed in CVS now. > xojpanel builds without warnings and runs afterward, but it has the LCD text > vertical alignment problem that I mentioned a while ago. It's related to Qt3, > not gcc-3.1 . I should have a patch for it in a few days, or sooner if > necessary. Thanks for the info. I updated the TODO list accordingly. David |
|
From: Joe P. <joe...@sn...> - 2002-06-22 13:22:58
|
On Friday 21 June 2002 10:59 pm, David Paschal wrote: > Joe Piolunek wrote: > > When building with gcc-3.1, some warnings appear when compiling xscale.c . > > xscale.c: In function `weight_two_rows': > Hi, Joe. Thanks for pointing that out. It should be fixed in CVS now. The build finishes now with no warnings regarding hpoj files. You should probably note that I haven't installed or tested (other than running xojpanel from the build directory) hpoj after building with gcc-3.1 . I hope the OS distribution (Mandrake, Debian, etc.) package maintainers are following hpoj development well enough to ensure that it works (and xojpanel doesn't look ugly) under their next release. -- Joe |
|
From: David P. <pa...@rc...> - 2002-07-05 06:21:32
|
Joe Piolunek wrote: > xojpanel is linked with OpenSSL only indirectly, through libptal. There is no > direct link. Does that matter? From a strict interpretation of the GPL, it does matter, because it looks at the derived "work" as the entire process in memory with all shared libraries linked in. In practice I tend to be a bit more relaxed than this personally, but I'm doing this to keep the Debian folks happy. Actually, for all practical purposes there's the additional level of indirection to libcrypto via libsnmp. I only had to explicitly link libptal with "-lcrypto" because libsnmp depends on libcrypto but for some reason wasn't itself linked with "-lcrypto" to formalize that dependency. IIRC you were the one who pointed this out in the first place. David |
|
From: David P. <pa...@rc...> - 2003-01-17 03:40:18
|
Joe Piolunek wrote: > I'm planning to visit the LinuxWorld C+E again this year. I'll drop by the HP > area, of course. Hi, Joe. Looking forward to seeing you again. > Will they be giving away those little rubber penguins again? Probably, but I can't make any promises. I just give out whatever the booth-coordinator people bring over. :-) > This time instead of driving all the way to the Javits Center, I'll make > greater use of the train/subway system. I got some needed experience with the > NYC subways last spring on a visit to the former WTC site in lower Manhattan. FWIW, last year I found the M-42 city bus to be pretty handy for getting between my hotel near Times Square and Javits. It runs more frequently than the LinuxWorld shuttle bus (which I kept "just missing"), and it's cheaper than a taxi ($1 in coins, but that could have changed by now). David |
×
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