internet fax tools

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

Russell Nelson wrote:
[..]
>  > No very basic difference.  Mainly the page format issue remains - tpc.int
>  > wants ASCII or Postscript, the mgetty fax queue has ready-made G3 instead
>  > of the original documents.
>  > 
>  > So I still think something in faxspool's place might be more useful - why
>  > spool it locally if you can directly put it into the mailer queue?
> 
> Because faxspool deals with all sorts of different formats.  It puts
> on header lines.  And it's structured to throw files into a queue
> directory.  And because knowledge about the queue is already fixed
> into three separate programs, faxspool, faxq, and faxrunq.  

OK, you have a good point here.

> Adding a
> fourth wouldn't make any of the three more complicated.  

Correct, except for faxrunqd, which would need to know about "tpc.int"
remote delivery.

(I just realized that I'm not sure whether I really understand your
proposal - do you want to have alternate deliveries via tpc.int and
local modems, or a *replacement* for faxrunq(d) that will *only*
do delivery via tpc.int? The latter would make things certainly a
lot easier, and no need to make faxrunqd tpc.int-aware).

> And converting from g3 to postscript is, um, trivial: g3topbm|pnmtops.

True, but I find this to be a waste of CPU and network bandwidth - 
postscript is a bad way to transmit bit mapped images.  (One could
optimize this by using Hylafax' optimized faxtops which uses font
elements for the different black run lengths, but still worse than
the original document).

On the other hand, if you count "implementation time", your proposal
certainly wins :-)

gert
-- 
Gert Doering
Mobile communications ... right now writing from *AWAY* :-)) 
... mobile phone: +49 177 2160221 ... or mail me:  gert@greenie.muc.de