From: Erik H. <hen...@ho...> - 2001-03-01 16:09:15
|
<html><DIV> <P>Can I just first of all say : GREAT. It seems to me that thanks to this you will be able to provide better support for our printers in Linux. And I can only be happy about that.</P> <P>So my thanks go out to you, who I believe to have been pushing for this not to mention do development on your own to give us printing capabilities and to HP management who've decided on this.</P> <P> </P> <P>Since it seems that HP is warming up for Linux, might it be possible that HP will also start making the PPD files etc.. for printers? Or release more documentation for it so that someone with the right knowledge will be able to use this.</P> <P>I have a OfficeJet G55 and currently I'm using the cpdj500 filter. Which gives bad quality compared to what my printer can do.</P> <P>Now I understand one can use the 970 but having looked at it, there are a lot of steps there to do without clear English instructions. </P> <P>It would be nice if we would be able to just get a filter or so and put it on the system instead of having to go out, getting Ghostscript and the driver and then compiling, making changes etc...</P> <P> </P> <P>Thank you.<BR><BR></P></DIV> <DIV></DIV> <DIV></DIV>>From: "PASCHAL,DAVID (HP-Roseville,ex1)" <DAV...@HP...> <DIV></DIV>>I am pleased to report that I have gotten permission from my management to <DIV></DIV>>release the new user-mode I/O driver ("ptal-mlcd") I've been working on <DIV></DIV> <DIV> </DIV><br clear=all><hr>Get your FREE download of MSN Explorer at <a href="http://explorer.msn.com">http://explorer.msn.com</a><br></p></html> |
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2001-03-03 01:34:24
|
Hi, First of all, I'd like to thank everybody for their interest and feedback regarding the copyright and license on ptal-mlcd and hpoj in general. A lot of good points were raised, and I'll try to address them here. But before I do that, I'd like to address the concerns that were raised regarding the quality of print drivers, with which I can certainly sympathize. Actually, another division within HP is actively preparing better inkjet drivers. I'm not involved with that effort, but I took the liberty of forwarding a couple of the relevant messages to several managers and engineers who are involved. It's a work in progress and no code has been released yet, but you can get a sneak preview at http://hpinkjet.sourceforge.net. This driver was also demonstrated at LinuxWorld Expo last month in the "e-mail garden". I don't know exactly when it will be released, but once I find out that it has been released I'll be sure to make it known on the hpoj mailing lists. Regarding the LGPL: Although at first it might seem that the LGPL is the answer to this problem, there are several reasons why it isn't appropriate in this situation, particularly from an embedded systems perspective, which is where the new MLC/1284.4 code comes from. First and foremost is the fact that it would potentially benefit competitors' proprietary products, which is highly undesirable in the business I'm part of. By releasing this code, the intention for now is only to benefit free software, which is why the GPL seems most appropriate. The other problem with the LGPL is more of a practical nature. When linking with non-free software, there's a requirement to provide unlinked object files to permit re-linking with newer versions of the LGPL code. For an embedded system, it may be difficult or impossible to get the new code onto the device, especially if the firmware is burned into a ROM (which can't be upgraded). On the other hand, I have considered changing the license for PTAL (which serves as the "official" API in this package) from GPL to LGPL. At the moment there doesn't appear to be a need for this, but I'll revisit this question later if things change. Joe Piolunek wrote: > The IP 'transfer' plan reads like it was influenced by HP lawers attempting > to adhere to some general policy. If that's the case, maybe Bruce Perens > could have a chat with them. Actually, that was Bruce's suggestion, which was based on the example of Sun and OpenOffice. He also alluded to another possible strategy, where "the contributor grant[s] HP separate and individual copyright, while they keep their own copyright to the modification as well. That means that either party can do what they want with the code." I can look into this if people think it's better, but it may take more time to set up and consult with the lawyers. So to summarize what I currently have in mind: The new changes will be released under the GPL (as is the case with the existing hpoj code), but with an HP copyright. The leveraged MLC/1284.4 portion of ptal-mlcd has to have the HP copyright because I developed it on company time for actual products. The remainder of my changes for the hpoj project need to have the HP copyright because I'm now operating on behalf of HP, rather than myself, as I was when I first joined this project. I haven't yet decided whether to retroactively change my existing copyrights to HP or just apply it to new changes. For everything in the hpoj codebase other than the leveraged MLC/1284.4 portion of ptal-mlcd, there will not be any requirement to re-assign copyrights or otherwise give up any IP rights. (I apologize if I offended anybody by suggesting this as an option.) As long as I'm responsible for maintaining both the free and HP-proprietary versions of the MLC/1284.4 code, I'd like to keep them consistent (for the sake of my own sanity:-). To this end, if I accept contributions to this portion of the codebase, I need to have some mechanism in place (such as the various options already proposed) to permit me to incorporate contributions onto both sides. As the gatekeeper I would still have to scrutinize submissions pretty carefully to ensure they were OK for both sides. On the other hand, I could just side-step the whole issue by maintaining this portion of the code myself without any help. And if I ever changed my mind and decided to fork the code myself (i.e. if I changed jobs and no longer was responsible for both versions), then the issue of maintaining consistency would become irrelevant anyway. One other question I should probably research is whether small changes, such as a one-line bug fix, are different from large changes, and if so, what the threshold is. For Sun OpenOffice, I think the threshold is 10 lines. Keep in mind that the license is GPL throughout the hpoj package, in particular "version 2 or at your option any later version". This means that regardless of any difficulties imposed on submitting changes to the "official" version I maintain, one would be free to fork their own version from the GPLed "official" version (with or without any existing contributions) and maintain it separately, with no requirement to push the changes back to HP, as long as they abide by the GPL. Also, I should point out that in general, the copyright holders, whether HP or anybody else, have the right to unanimously choose to release the same piece of code under multiple licenses, as is the case here with the new MLC/1284.4 code. However, the GPL does not permit revocation of code that has been released under the GPL even if newer versions of the code have a different license, so there are no worries there. At this point, all I have left to do before checking in the new code is to finalize the details about the dual-licensing and consistency of the MLC/1284.4 code, and to finish rearranging the codebase and build process to integrate the new functionality. I look forward to any comments about what I had to say here. :-) David |
From: Joe P. <joe...@sn...> - 2001-03-04 16:55:01
|
On Saturday 03 March 2001 01:32, PASCHAL,DAVID (HP-Roseville,ex1) wrote: <...> > Actually, another division within HP is actively preparing > better inkjet drivers. I'm not involved with that effort, but I took the > liberty of forwarding a couple of the relevant messages to several managers > and engineers who are involved. It's a work in progress and no code has > been released yet, but you can get a sneak preview at > http://hpinkjet.sourceforge.net. This driver was also demonstrated at > LinuxWorld Expo last month in the "e-mail garden". I don't know exactly > when it will be released, but once I find out that it has been released I'll > be sure to make it known on the hpoj mailing lists. I didn't see support for officejets mentioned in hpinkjet web pages. Will they be supported by the new inkjet drivers? > (Bruce) also alluded to another possible strategy, where > "the contributor grant[s] HP separate and individual copyright, while they > keep their own copyright to the modification as well. That means that > either party can do what they want with the code." I can look into this if > people think it's better, but it may take more time to set up and consult > with the lawyers. > That might be more acceptable to independant contributors (if any), but each would have his own opinion. Since only a few people have contributed to the project so far, the IP 'transfer' plan may not even need to be applied for lack (or need) of independant contributions. If so, it would make the ownership issue less relevant, as long as the code remains GPL'd. > So to summarize what I currently have in mind: > > The new changes will be released under the GPL (as is the case with the > existing hpoj code), but with an HP copyright. The leveraged MLC/1284.4 > portion of ptal-mlcd has to have the HP copyright because I developed it on > company time for actual products. The remainder of my changes for the hpoj > project need to have the HP copyright because I'm now operating on behalf > of HP, rather than myself, as I was when I first joined this project. I > haven't yet decided whether to retroactively change my existing copyrights > to HP or just apply it to new changes. > > For everything in the hpoj codebase other than the leveraged MLC/1284.4 > portion of ptal-mlcd, there will not be any requirement to re-assign > copyrights or otherwise give up any IP rights. (I apologize if I offended > anybody by suggesting this as an option.) I wasn't offended, just disappointed in HP after having read some of their public statements supporting the open source / free software community. Perhaps in 3-5 years, Linux will become the default OS for most computing devices, even the desktop. Linux has nowhere to go but up, whereas windows can go almost nowhere but down. HP appears to have the upper hand now regarding its products' (lack of) compatibility with Linux, but in the not too distant future, HP could find itself needing support from Linux and its users. -- Joe |
From: <pa...@rc...> - 2001-03-05 00:41:40
|
Hi, Joe. Joe Piolunek wrote: > I didn't see support for officejets mentioned in hpinkjet web pages. Will > they be supported by the new inkjet drivers? I haven't had a chance to try it out yet. At the very least, the DeskJet 895C driver should work with the OfficeJet R and T series, and the DeskJet 970C driver should work with the OfficeJet G and K series. I'm guessing that the DeskJet 600-series driver should work with the OfficeJet [567]00 series, but I don't know for sure at the moment. > That might be more acceptable to independant contributors (if any), but each > would have his own opinion. Since only a few people have contributed to the > project so far, the IP 'transfer' plan may not even need to be applied for > lack (or need) of independant contributions. If so, it would make the > ownership issue less relevant, as long as the code remains GPL'd. After thinking about it some more I came to pretty much the same conclusion. As long as I can sufficiently maintain the code there won't be any need to accept changes to the leveraged MLC/1284.4 code (which is the only problem area). If that ever changes in any way, then the "problem" probably goes away. Others may choose to fork their own GPL projects that incorporate that code, possibly with their own changes, but that's OK as long as they comply with the GPL. So I won't worry any more about this issue for now, and instead will concentrate on finishing the remaining cleanups before checking in the new code. :-) David |
From: Chris J. <cjo...@sh...> - 2001-03-05 15:16:08
|
On Sun, 4 Mar 2001, David Paschal wrote: > Hi, Joe. > > Joe Piolunek wrote: > > I didn't see support for officejets mentioned in hpinkjet web pages. Will > > they be supported by the new inkjet drivers? > I haven't had a chance to try it out yet. At the very least, the DeskJet 895C > driver should work with the OfficeJet R and T series, and the DeskJet 970C > driver should work with the OfficeJet G and K series. I'm guessing that the > DeskJet 600-series driver should work with the OfficeJet [567]00 series, but > I don't know for sure at the moment. > Is there any parallel for the 11xx series? In particular the 1170. Which printer type should they be considered similar to, if any, and will a driver be developed for this machine? Thanks, Chris |
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2001-03-06 01:50:57
|
Chris Johnson wrote: > Is there any parallel for the 11xx series? In particular the 1170. > Which printer type should they be considered similar to, if > any, and will > a driver be developed for this machine? Hi, Chris. I'm not 100% sure here, but I'm guessing that the OfficeJet 1170/1175 is compatible with the DeskJet 890, and I'm guessing that the OfficeJet 1150 is compatible with either the DeskJet 850 and/or 870. I'm guessing based on the way the compatible ink cartridges correspond. There is no mention of any of those DeskJets, so they probably aren't being addressed, but you could always try the 600- or 800-series drivers anyway. David |
From: DG <dg...@um...> - 2001-03-07 23:26:13
|
From: pa...@rc... (David Paschal) >Joe Piolunek wrote: >> I didn't see support for officejets mentioned in hpinkjet web pages. Will >> they be supported by the new inkjet drivers? >I haven't had a chance to try it out yet. At the very least, the DeskJet 895C >driver should work with the OfficeJet R and T series, and the DeskJet 970C >driver should work with the OfficeJet G and K series. I'm guessing that the >DeskJet 600-series driver should work with the OfficeJet [567]00 series, but >I don't know for sure at the moment. How about the PSC500? -- 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: <pa...@rc...> - 2001-03-07 23:56:39
|
Daniel Gun wrote: > From: pa...@rc... (David Paschal) > >I haven't had a chance to try it out yet. At the very least, the DeskJet > 895C > >driver should work with the OfficeJet R and T series, and the DeskJet 970C > >driver should work with the OfficeJet G and K series. I'm guessing that > the > >DeskJet 600-series driver should work with the OfficeJet [567]00 series, > but > >I don't know for sure at the moment. > > How about the PSC500? The PSC500 should work with the DeskJet 895C driver as well. David |
From: Robert G. B. <rg...@ph...> - 2001-03-01 17:59:18
|
On Thu, 1 Mar 2001, Erik Hendrix wrote: > I have a OfficeJet G55 and currently I'm using the cpdj500 filter. Which > gives bad quality compared to what my printer can do. > > Now I understand one can use the 970 but having looked at it, there are a > lot of steps there to do without clear English instructions. > > It would be nice if we would be able to just get a filter or so and put > it on the system instead of having to go out, getting Ghostscript and the > driver and then compiling, making changes etc... Hear, hear! I definitely second this. I've spent a full ink cartridge pair and $20-30 worth of high-quality paper on this over three months and still get most unsatisfactory (nowhere near "photo-quality") results. I've gone through cpdj500 (with various gamma settings, color settings, and any other tunings I can figure out) and have even tried the new gimp printer driver, as it was rumored that this provides a ghostscript-independent device layer that can be carefully tuned for gamma and so forth, but neither of these come close to either the quality of the printer used as a color photocopier or the onscreen quality of the underlying jpeg (or etc.) photographs, even at pixel resolutions that should be 1:1 mappings of the onscreen image. Stippled images produced by some driver setups have annoying granularity and a lack of sharp images and still poor color, bitmap images produced by other drivers have better pixel granularity (although still nothing like I imagine I should be getting) but even worse color. The colormap problems aren't ones that can be resolved by monkeying with linear three-knob gamma -- I've turned those knobs pretty much every way they can turn and still get poor blue/whites, overemphasized reds and greens, and a consequently "muddy" image. They require a proper nonlinear map. Although I haven't taken the relatively drastic step of hooking the printer up to my one dual boot laptop and actually checking out the Windows photo-print resolution, I cannot imagine anyone buying the printer and attaching it to any linux box for the primary purpose of printing color photographs or images with the best I've achieved so far. Since they continue to sell, I imagine that the Windows drivers and gamma settings are pretuned for much better output. It would be truly nice if HP would help create a linux filter set that has a "perfect" colormap/pixelmap conversion for this kind of printer. I'd actually suggest that they go with the gimp plugin approach, as this seems a lot more portable than the yet-another-ghostscript-filter approach. It is great to have a good printer/kernel interface so that both scanning and printing "work" and to reduce the number and complexity of the driver modules that must be inserted, but at this point the burning need is clearly for improved color print quality. It would be nice for HP to both contribute the colormappings they must already have developed for e.g. WinXX (the core of which should be portable/reusable code, after all) and fund the several thousand pages of test printing required to build and fine-tune a gimp plugin or other portable filter package, possibly on a printer by printer basis for their various officejets (presuming that some might require different maps). A proper job of this should mean that they can eventually ship a build-ready package with their officejet (and probably other) printers and add the word "Linux" to the list of supported environments right their on the printer boxes. This will make them money for sure -- HP has an excellent reputation and the G55's and other color combo office printer/scanners/copiers are a great solution for many a University research group or small business department that relies on linux, including my own. Until this is fixed, though, there is no way I'm going to buy another one -- I'm even considering buying one of their inexpensive competitors (e.g. a Canon) just because their print drivers/filters are known to exist and work excellently well on photographs. (Sorry about the semi-rant, but this is a moderately serious problem and HP needs to become aware of it and direct some resources to it -- I cannot even recommend their printer/scanner to most of my friends at this point on the basis of the quality I've been able to achieve with 20-40 hours of my own time invested. This is in the "not ready for linux prime time" category and very definitely is costing them sales.) 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: Judd M. <ju...@jp...> - 2001-03-01 18:46:40
|
"Robert G. Brown" wrote: > > (Sorry about the semi-rant, but this is a moderately serious problem and > HP needs to become aware of it and direct some resources to it -- I > cannot even recommend their printer/scanner to most of my friends at > this point on the basis of the quality I've been able to achieve with > 20-40 hours of my own time invested. This is in the "not ready for > linux prime time" category and very definitely is costing them sales.) > Yes, it is costing them sales. I just bought my G95 after reading the hpoj sourceforge website and the HP website. I thought this was a fairly well supported printer. It certainly wasn't inexpensive. I'm currently using the ghostscript cdj970 driver and it just isn't acceptable. What is even more agrivating is that I also have some margin issues in Linux and Windows. I usually never use technical support, but decided to try HP. I told them I was using Linux and Windows. I got the typical "We don't support Linux" answer and was asked more questions. The next email from them was basically blowing me off and not bothering to answer my problems with the margins. I'm about ready to send the printer back and I'm sure a returned sale costs more than a lost sale. Are there any drivers out there that are better than the cdj970 and/or ghostscript? I really want to make this work if possible. Judd |
From: Robert G. B. <rg...@ph...> - 2001-03-01 19:06:00
|
On Thu, 1 Mar 2001, Judd Montgomery wrote: > Are there any drivers out there that are better than the cdj970 and/or > ghostscript? I really want to make this work if possible. I'm not sure about what you mean by "better". My current setup works perfectly well for text, and is a "faithful image" of color -- its just that the colors and dot resolution aren't right for photo quality output. It is fine for primary color fliers and the like, not so good if one has a 3.3 megapixel digital camera and had hopes/illusions of doing photo art (or even simple, adequate, photo portrature of your family). What linux distribution are you using? I'd be happy to share my "current best" printer filter setup, developed for Red Hat, if that is what you need. If it is just a stair-step effect type problem, the Red Hat printtool will fix that for you. If you're not using RH, then you'll have to take the filter setup and hack it and install it in your own filter arrangement. 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: Judd M. <ju...@jp...> - 2001-03-01 19:44:16
|
"Robert G. Brown" wrote: > > On Thu, 1 Mar 2001, Judd Montgomery wrote: > > > Are there any drivers out there that are better than the cdj970 and/or > > ghostscript? I really want to make this work if possible. > > I'm not sure about what you mean by "better". My current setup works > perfectly well for text, and is a "faithful image" of color -- its just > that the colors and dot resolution aren't right for photo quality > output. It is fine for primary color fliers and the like, not so good > if one has a 3.3 megapixel digital camera and had hopes/illusions of > doing photo art (or even simple, adequate, photo portrature of your > family). > I'd be happy with that. I'm using the duplex printing feature if that matters. When printing text (postscript), it prints more than an extra inch of margin at the top and the text then runs all the way to the bottom of the paper. Sometimes I've seen it print part of page 2 on the bottom of page one. If I use gv, or gs and look at the postscript it looks fine. So, it is the print driver doing this. > What linux distribution are you using? I'd be happy to share my > "current best" printer filter setup, developed for Red Hat, if that is > what you need. If it is just a stair-step effect type problem, the Red > Hat printtool will fix that for you. If you're not using RH, then > you'll have to take the filter setup and hack it and install it in your > own filter arrangement. > I use Slackware and just write my own filters in perl. I'm a programmer so I can hack what ever you have and will try that. Thanks. You can send it private if you don't want to clog up the list. Judd |
From: Robert G. B. <rg...@ph...> - 2001-03-01 22:15:52
|
On Thu, 1 Mar 2001, Judd Montgomery wrote: > "Robert G. Brown" wrote: > > > > On Thu, 1 Mar 2001, Judd Montgomery wrote: > > > > > Are there any drivers out there that are better than the cdj970 and/or > > > ghostscript? I really want to make this work if possible. > > > > I'm not sure about what you mean by "better". My current setup works > > perfectly well for text, and is a "faithful image" of color -- its just > > that the colors and dot resolution aren't right for photo quality > > output. It is fine for primary color fliers and the like, not so good > > if one has a 3.3 megapixel digital camera and had hopes/illusions of > > doing photo art (or even simple, adequate, photo portrature of your > > family). > > > > I'd be happy with that. > I'm using the duplex printing feature if that matters. When printing > text (postscript), it prints more than an extra inch of margin at the > top and the text then runs all the way to the bottom of the paper. > Sometimes I've seen it print part of page 2 on the bottom of page one. > If I use gv, or gs and look at the postscript it looks fine. So, it is > the print driver doing this. Actually, this might or might not be true. Check the paper type definition in your postscript setup. I have to leave just now, but when I get home I'll try to find just where that is stored. I'll bet that it isn't set to ordinary 8.5x11 paper. > > > What linux distribution are you using? I'd be happy to share my > > "current best" printer filter setup, developed for Red Hat, if that is > > what you need. If it is just a stair-step effect type problem, the Red > > Hat printtool will fix that for you. If you're not using RH, then > > you'll have to take the filter setup and hack it and install it in your > > own filter arrangement. > > > > I use Slackware and just write my own filters in perl. > I'm a programmer so I can hack what ever you have and will try that. > Thanks. You can send it private if you don't want to clog up the list. Will do, when I get home. Later. > > Judd > > _______________________________________________ > hpoj-devel mailing list > hpo...@li... > http://lists.sourceforge.net/lists/listinfo/hpoj-devel > -- 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: Jarl F. <ja...@di...> - 2001-03-03 22:08:25
|
Hi Judd. So we "meet" again, Judd :-) I am using SuSE and a G85, and just chose the cdj550 (600dpi) printer in the yast (a SuSE tool), and everything worked fine. I don't know what kind of quality I expected since I am not running Windoze and hence couldn't compare, but it definitely looked good and the margins also seem to be OK, though I havnt' measured with a ruler. I don't have the device around anymore since I only had it for a short time to set it up for my mother (indeed a computer/linux newbie). I have included what yast added to my /etc/printcap. I have only used it as the oj printer (second entry), so maybe the other entries are useless. I'll send you the aps filters private. Jarl -- The danish translator. cdj550-ascii|lp10|cdj550-a4-ascii-mono-600|cdj550 a4 ascii mono 600:\ :lp=/dev/ptal-printd/mlc_mlcpp0:\ :sd=/var/spool/lpd/cdj550-a4-ascii-mono-600:\ :lf=/var/spool/lpd/cdj550-a4-ascii-mono-600/log:\ :af=/var/spool/lpd/cdj550-a4-ascii-mono-600/acct:\ :if=/var/lib/apsfilter/bin/cdj550-a4-ascii-mono-600:\ :la@:mx#0:\ :tr=:cl:sh:sf: # oj|cdj550|lp11|cdj550-a4-auto-color-600|cdj550 a4 auto color 600:\ :lp=/dev/ptal-printd/mlc_mlcpp0:\ :sd=/var/spool/lpd/cdj550-a4-auto-color-600:\ :lf=/var/spool/lpd/cdj550-a4-auto-color-600/log:\ :af=/var/spool/lpd/cdj550-a4-auto-color-600/acct:\ :if=/var/lib/apsfilter/bin/cdj550-a4-auto-color-600:\ :la@:mx#0:\ :tr=:cl:sh:sf: # cdj550-mono|lp12|cdj550-a4-auto-mono-600|cdj550 a4 auto mono 600:\ :lp=/dev/ptal-printd/mlc_mlcpp0:\ :sd=/var/spool/lpd/cdj550-a4-auto-mono-600:\ :lf=/var/spool/lpd/cdj550-a4-auto-mono-600/log:\ :af=/var/spool/lpd/cdj550-a4-auto-mono-600/acct:\ :if=/var/lib/apsfilter/bin/cdj550-a4-auto-mono-600:\ :la@:mx#0:\ :tr=:cl:sh:sf: # cdj550-raw|lp13|cdj550-a4-raw|cdj550 a4 raw:\ :lp=/dev/ptal-printd/mlc_mlcpp0:\ :sd=/var/spool/lpd/cdj550-a4-raw:\ :lf=/var/spool/lpd/cdj550-a4-raw/log:\ :af=/var/spool/lpd/cdj550-a4-raw/acct:\ :if=/var/lib/apsfilter/bin/cdj550-a4-raw:\ :la@:mx#0:\ :tr=:cl:sh:sf: # |