Re: flexfax: Weird Phase B Error (with solution)

["Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us>]

On Sun, Apr 11, 1999 at 03:32:47PM +0200, Richard Kail wrote:
> > > ESC%-12345X@PJL
> > > @PJL ENTER LANGUAGE = POSTSCRIPT
> > > %!PS-Adobe-3.0
> > 
> > These are not Postscript files, they are Xerox printer files.  A Postscript
> > file would start on the third line.
> 
> These are not postscript files, sure. But what you see here is a PJL
> Header to switch the printer to postscript mode. Several postscript
> printer drivers do it this way, so I think it wouldn't be the badest idea
> to handle this. The PJL Header is defined and documented in the HP Printer
> Job Language Technical Reference Manual. Ghostscript can handle this
> kind of headers without any problem.

Hmmm... since Ghostscript is capable of ignoring it, I'd have to assume
that it's not getting it.  yeah, I'd think typerules might oughtta be
able to cope, but why don't you just switch to using the recommend PS
driver in Windows to begin with; this outght to be _much_ easier...

> > The proper fix is to use a sensible Postscript printer driver for your
> > fax printer.  There are some on Windows.  (If anyone has access to the right
> > documentation and tools, and the time to do it, it might be an idea to
> > create a hylafax/ghostscript printer driver for Windows - probably just
> > changing the names on one of the common ones.)
> 
> I know this and I know the printer drivers (the old Apple Drivers for
> example). But however, there may be reasons to use other drivers. For
> example, some Apple Postscript Drivers delivered with NTWS4.0 can get into
> a state where gs can't handle the postscript produced. Unfortunately, I
> lost the sampe of this. The advantage of the Xerox drivers, for example,
> is that the postscript produced is very readable.

How often do you need for humans to be able to read the postscript? :-)

> > That is fairly clearly documented - TIFF and PS are the only formats 
> > supported by the server; the client must convert to one of these before
> > submission.
> 
> This is ok - but I am unhappy about this. Converting documents to Tiff or
> PS is what unix tools can do very well. On other client plattforms doing
> this is not nice at all. There is also the problem that it is easier to
> manage one set of converter tools on the server that to manage them on
> zillions of clients.

No 'conversion' should be necessary; this is done by the Windows
printing machinery simply by your selecting the proper print driver.

> Therefor it would be very very handy to let the server convert the files
> also. Implement such a feature doesn't hinder you to convert at the client
> - it is just a option.

Least common denominators are used for a _reason_.  However, if you'd
like to code and contribute a module to perform server side conversions
for situations like this, we'd be more than happy to include it in the
distribution.  :-)

> Apr 11 14:56:31.97: [  589]: <-- [7:AT+FAP\r]
> Apr 11 14:56:32.00: [  589]: --> [5:ERROR]
> Apr 11 14:56:32.00: [  589]: MODEM Command error

That sounds like youv'e got the server configured to think it's talking
to some other sort of modem than it really is.

> Ok, what I think/suggest:
> 
> The fact that the user gets a "all things worked" notification while
> nothing was transmitted worries me. I think we should find a fix for this,
> regardless what the documentation says.

If you're seeing "ok" replies on errored sent faxes, then yeah,
something needs to be fixed, and I'd be surprised if the documentation
implies otherwise.  Is there a specific spot in the docos that you
could point to that "says" somethiing you think is wrong?

> I don't know what the send_data modus is used for, so this may be the
> right thing to do. My problem could be solved this way. (Maybe this breaks
> the IXO/TAP pagesend stuff ?)

Have you tried this patch?  It sounds like you have a pretty decent
idea where to go; try it and let us know if it works.  You certianly
don't need our permission; that's the whole point of OSS.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Buy copies of The New Hackers Dictionary.
The Suncoast Freenet            Give them to all your friends.
Tampa Bay, Florida     http://www.ccil.org/jargon/             +1 813 790 7592