Re: [Printing-user-general] LPR control file - RFC1179 clarification

Ryan,

Thank you for the comments, I'm not sure why thinprint uses the full pathname,
but I can certainly explain why the Ricoh Doesnt like it...  Ricoh attempts to
follow the RFC as much as possible.  There are many situations where the RFC
and  industry actions or practicalities begin to conflict.  A good Example is
the "L" option of the Control file.  This states that this entry should "Cause"
a banner page to be printed. Well if the control file is last instead of first,
you get a trailer page... the RFC doesnt account for internal LPD's that have
limited spooling space... or the dfA file size parameter sent from windows if
byte counting is turned off.. Receive Data File ------> [0x03]125899906843000
dfA005L61544 (Notice file size is extremely large 125,899,906,843,000 bytes),
crazy...

If you need more assitance from the Ricoh side please don't hesitate to send me
an email...

Christopher Story
Ricoh Corporation
[email protected]



In article <[email protected]>, [email protected] (Ryan)
writes:
> 
> Dear Christopher,
> 
> Thank you for your thoughts. It seems most other people I have talked to
would
> agree with you.
> I asked because I am troubleshooting an issue printing from program called
> thinprint that seems to print properly to the HP LPD but not to the Ricoh
one.
> Through testing it was determined that the cause of the problem was the
control
> filename was being sent with the full path.
> I do not need to fix the problem. I just need to be able to explain why the
> problem is happenning and what product (if any) is at fault.
> To be honest, I wasn't really sure if having the full path might be
> advantageous in some situations and thats why thinprint was including it. I
> can't help but wonder why thinprint has decided to include the full path with
> the filename, but it sounds as though that is something that should be taken
up
> with them.
> 
> 
> Thanks again,
> Ryan
> 
> 
> In article <[email protected]>, [email protected]
> (Christopher Story) writes:
> > 
> > Ryan,
> > 
> > there are three reasons why i believe the RFC / Industry does not mean the
> full
> > path...
> > 
> > 1) The RFC states that the "name" of the control file is sent, not the
"path"
> > is sent.
> > 
> > 2) The receiving LPD has absolutly no use for the path, in UNIX to UNIX Lpd
> the
> > file can be used for formating, but the path is again worthless to it... In
> an
> > internal Printer LPD the control file is of little use, especially if it is
> > sent last.
> > 
> > 3) What OS currently sends the full path?  I work daily with many systems
and
> > have NEVER seen one send the whole path as the cfA request...
> > 
> > Is there a specific reason why you want the path in the name?
> > 
> > Christopher Story
> > Ricoh Corporation
> > 
> > 
> > 
> > > RFC1179 says:
> > > 
> > > 6.2 02 - Receive control file
> > > 
> > >       +----+-------+----+------+----+
> > >       | 02 | Count | SP | Name | LF |
> > >       +----+-------+----+------+----+
> > >       Command code - 2
> > >       Operand 1 - Number of bytes in control file
> > >       Operand 2 - Name of control file
> > > 
> > >    The control file must be an ASCII stream with the ends of lines
> > >    indicated by ASCII LF.  The total number of bytes in the stream is
> > >    sent as the first operand.  The name of the control file is sent as
> > >    the second.  It should start with ASCII "cfA", followed by a three
> > >    digit job number, followed by the host name which has constructed the
> > >    control file.  Acknowledgement processing must occur as usual after
> > >    the command is sent.
> > > 
> > > 
> > > 
> > > Can the full path to the control file (ie. /var/spool/lpd/blah/cfA###XXX)
> be
> > > included in the "Name" field? Or just the file name (ie. cfA###XXX)?
> > > 
> > > Personally, I think the RFC doesn't really seem clear on this as it only
> says
> > > the file name should start with "cfA". Even if the path is included, the
> > > argument can be made the the file name begins with "cfA".
> > > 
> > > It seems some daemons will produce an error if the full path is included
> > (Ricoh
> > > Aficio 2045), but others will not (HP5550).
> > > Any thoughts?