RE: flexfax: Attachments in proprietary formats (i.e. Word)

["Bernd Proissl" <news@proissl.de>]

> > > 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
>From within what environment do you call ShellExecute()?
how do you temporarily change the default printer?

> 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.
Sounds good but i do not have knowlede how to make a transport agent.
Isn`t this very MS-depended? Is there MAPI on linux?


> 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.
i have a java client which displays the queues in a much end user friendlier
way than whfc. it has buttons like "view Fax" (via external viewer) or "send
fax
again". (no fax sending yet)

> 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?

- client sents first page of fax to smb-printer
- samba starts perl script
- perl script asks (windows) client about tel# and attachments
  problem: if client prints the attachmants to the same smb-printer another
perl script
  will be started from samba (i guess), maybe you just create another samba
printer
  which handles attachments (and talks to your client also over another
port)
  and somehow communicates with the first script?

  i gues it should also be possible to transfer a ps-file from client over
TCP to
  the perl script on the server (i cannot do it)

  how to print to ps-file iŽn windows without user interaction:
   create your PS-printer, connect it to a new local printer port,
   give this port the name of a file. e.g. c:\tmp.ps
   an the user will not be asked about a filename when printing.

> The disadvantage is of course that the client app has to be running the
> whole time.
yes. but if it does not, the job just breaks in the perl script, no
deadlocks in
communication (for me).
the user just starts the client and then starts printing/faxing again.


Bernd