HylaFAX The world's most advanced open source fax server

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

Re: Attachments in proprietary formats (i.e. Word)

Hi Bernd,

> > And the other viable option is making a complete MAPI transport agent
> > renders each file given to postscript (or TIFF, preferrably), via the
> > shell extensions. I know the method for printing a random file to a
> > certain printer via windows (done some reading),
> Can you give me more info how you do this? Thanks!
Uhm, first you build a port monitor. Then you temporarily set the default
printer to a postscript printer with your port monitor, and call
ShellExecute() with command "print" on the file you want to print. If the
application registered a way of printing, the shell will make it print (with
user interaction if you're unlucky, Office apps don't ask anything AFAIK).
You receive the output with the monitor and everything is jiffy :). So you
see, it would be /relatively/ simple to add to WHFC, since it already has
the port monitor. Does anybody know the writer somewhat? He did not reply to
a mail I sent (some time ago).

> > If anybody wants to help me with that transport agent or any other
> > give me a holler, OK?
> What do you mean with transport agent?
Well, MS made the MAPI, (Mail Application Programming Interface), and lots
of programs use it. It's meant to provide a uniform interface to all sorts
of messages, like e-mail, microsoft mail etc and of course faxes.
It can send and receive faxes via the FAX: protocol (only thing it changes
is the e-mail address). It does that by sending the data to the appropriate
transport agent, which sends it on. And that's as far as my docs go :(. But
you see that if we could make a transport agent, all programs that have some
fax support via MAPI are magically compatible with HylaFax, furthering the
noble cause of bringing Linux to the office and beyond.

> I have experience in communicating with the Hylafax-Server from Java
> and there is also a solution whitch needs samba on the machine where
> runs:
> You app prints to a samba-printer, samba starts a perl-script which talks
> via TCP with
> you own process (not necesarilly the process which printed the file), your
> process
> can then give all the parameters you want for sendfax to the perl script
> then this
> perl script will start sendfax. there must be a link to response and/or
> printfax.pl
> on the hylafax contrib page. i have a modification of printfax.pl which is
> more
> flexible than the original one.
COOL! Byebye port monitoring garbage, and you could even do some stuff with
the $PRINTER share to auto-install the fax programs remotely! Now that's

So, if WHFC development is dead, it could still be used to check out the
queues. Printing would go directly to the printer on the server, which
connects to a client on the windows box for telephone # info. If there are
attachments, they are also printed, and the script should add those to the
current job. Then the client says go and the fax is queued.
Does that sound ok?
The disadvantage is of course that the client app has to be running the
whole time. Which brings us back to writing a port monitor :) (fires up the
client) Hello port monitoring garbage :*)

Thoughts, anyone?


Project hosted by iFAX Solutions