![]() |
Hi Bernd, > > And the other viable option is making a complete MAPI transport agent that > > 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 option, > > 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 direct > and there is also a solution whitch needs samba on the machine where hylafax > 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 and > 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 progress! 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? Wout.