Stacey Roberts on Sun, 17 Nov 2002 20:01:35 +0100 (CET)(envelope-from owner-apsfilter-help@apsfilter.org)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Your problem with apsfilter


Hi James,

On Sun, 2002-11-17 at 17:52, James B. Hiller wrote:
> > This *is* installed:
> > hpijs-1.3                           =   up-to-date with port
> 
> Ok.
> 
> > The above bit is not something that I'd say I'm terribly knowledgeable
> > about. I would have thought that following the apsfilter-documented
> > installation instructions, would have sufficed in getting this printing
> > solution implemented. 
> 
> Maybe that's where some of the disconnect comes from.  Remember that
> apsfilter is a filter that oversees the conversion of ASCII to Postscript
> so that ghostscript or some other tool can turn the Postscript into
> whatever it is that a given printer wants to see (in this case, HP PCL
> for your HP 845).  The ASCII has to be in the print queue, and apsfilter
> has to know how to get it; thus, lpr/lpd must be up and running correctly,
> and the printcap file is the thing that actually invokes apsfilter in
> the first place.  Then apsfilter uses a2ps to convert the ASCII stream to
> Postscript.  It then builds a good ghostscript command to submit the
> Postscript to ghostscript to convert it to an appropriate printer language
> (in this case, some HP PCL dialect for your particular printer).
> Ghostscript uses one of its "devices" to do this task, and then the output
> is piped to the system low-level printer device (/dev/lpt0 or whatever).
> 
> > At this point, I'd say that we're both on the same page here. For each
> > print job I submit, apsfilter isn't doing anything.
> 
> Right.  That's why I think one of the linkages above is broken in some
> small way, and based on those errors you reported before, my thought is
> that it's the formation of the ghostscript command with slightly incorrect
> parameter names or values.  And that's why I suggested getting the
> verbose output, since that shows exactly what ghostscript command is
> being formed.  With that, you can examine the apsfilter "driver" that
> is being selected to form it, and if necessary, modify it to fix the
> problems.
> 

Not much help, as from my earlier post, nothing is being outout to the
log file.

> But for the moment, seems like you're stuck at the point of not being
> able to find that silly output log.
> 
> > Thanks for time and effort you're investing in this. I always knew that
> > this won't be easy to solve (hence my uninstalling apsfilter before), as
> > I truly believe that something else is at work here, and to be honest, I
> > think that the apsfilter people aren't being up front about what really
> > is tested at SETUP. 
> 
> Well, there are some things outside apsfilter's control that aren't tested.
> At the moment, I forget what they are, but it's along the lines of, "the
> print queue system is bypassed" or some such.
> 
> > I had one of the apsfilter hackers actually tell me that up to the time
> > (during SETUP) that the test page gets printed, everything must have
> > been fine, and that *I* must have messed something else up in the
> > installation stage for this to be failing like this.
> > 
> > Well., after electing to print the test page there's only selecting:-
> > "I" to install,
> > "Q" to finish the apsfilter installation, then 
> > "lpc restart all" to restart lpd.
> > 
> > If there is something that I've missed out, then fair enough. I believe
> > that there is (at least) something else that's been missed out here, and
> > its not in the apsfilter docs.
> 
> It's tempting for both sides to point a finger in things like this.  Since
> there are so many pieces glued together, it really could be anywhere.
> 
> I don't know if you've taken the following approach yet, but here's what
> I would recommend to reduce some of the complexity and get things going:
> 
> 1.  For the time being, hook the printer up without going through the share.
> Just make it local and get it going that way first - removes another
> variable.
> 
> 2.  Uninstall apsfilter (again) and the printcap it generated, and the print
> queue dirs, and all that.
> 
> 3.  Make sure you have ghostscript set up correctly (or whatever other
> final filter you're using) without regard to apsfilter.  To do that,
> simply form a good gs command and give it a simple text file to print,
> and enter all that from the command line (this is more or less what
> the apsfilter test page is doing).
> 
> If this generates the expected results, THEN install apsfilter with the
> appropriate settings.
> 
> 4.  Now if lpr filename doesn't work, you're certain it is a broken
> gs command getting built by apsfilter, and it's time to look at the
> parameters being set by the specific "driver" file.  With those, you
> can build the exact gs command yourself (though it would be easier if
> you could find that log file), and submit that from the command line
> to see what is breaking (the feedback will be immediate).  Then you can
> (hopefully) modify the driver file to generate a correct option set,
> check it out, and all is done.
> 
> 5.  Then you can re-configure apsfilter to go over to the remote printer.
> Make sure you know what files SETUP is rewriting, so that any changes
> you made in the "driver" file aren't either overwritten or ignored.
> 
> This is the approach I had to take to get everything working with my
> HP OfficeJet 1170C all-in-one, which also has the added layer of using
> the hpoj package for computer-to-printer comms.

I understand the logic behind this, and had already thought of and
implemented another procedure, namely - install CUPS instead. In case
you don't understand, I'll explain:

I had another team also researching a solution for this scenario. They
looked at CUPS over samba, and I, apsfilter. CUPS won.

CUPS just worked. On four different boxes, two exact clones of two specs
each - CPU difference only (of which my role was to get an apsfilter
solution up and running on one of each clone set), printing to the Win2K
attached printer from both FBSD boxes was successful using CUPS.

 Not as fast to the printer as apsfilter's test print (but I've not even
got to see apsfilter actually work as yet, so..,), but it prints, and it
prints in colour with the functionality that is expected. As a result,
CUPS was deployed at work.

I'm now using one those very CUPS-tested boxes to try and see what went
wrong with apsfilter.

Stacey
> 
> jbh
-- 
Stacey Roberts
B.Sc (HONS) Computer Science

Web: www.vickiandstacey.com