HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
Re: Design for a portable Java hylafax clients: i want your opinions, please!
"Bernd Proissl" <news@proissl.de> writes:
> Hello to all hylafax users.
>
> I am currently developing a java hylfax client, there are some topics i
> am thinking about, maybe you can give me your opinions:
AFAIK the Java client is already created (by Suse people). They say it
even works under Windows. Have you evaluated it? (unfortunately I still
have not seen this piece of software). What is wrong with it? Which feature
is missed?
> 1. is java 2 widely availabe on your (client) platforms?
> or is it supposed to become availbe in the near future?
>
> 2. What is your prefered procedure for sending a fax?
>
> a1. redmon: capture the printout of an application on the client side
> and let the hylafax client process it: e.g. ask user for fax.nr.
> and the hand it to the hylafax server directly.
>
> advantage: faster than a2
> disadvantage: - firewall must be opened for ports use by hfaxd
> - if you want access for remote users you must open hfaxd ports
> to the public.
I think it is the only acceptable (working) solution.
> a2: same as a1, but client will send an eMail to some dedicated process on
> the server
>
> advantage: - no firewall problem if eMail is allowed
> - remote users can send faxes as if they where at the office
> disadvantage: slower than a1
and
- problems with attachments in the proprietary formats (MS Word etc.)
- how to protect the service from unauthorised use? Anyone can send a
message to your fax gate...
> b. printfax/repsond: capture the printout on the server side, make a "callback"
> to the client to get fax.nr. etc.
>
> advantage: protocoll between client server can be easily adopted by other
> developers
Changing the protocol is the *disadvantage* :-)
> disadvantage: - another port must be opened for client server communications
and the client software have to setup the "listening" service. But how this
is supposed to work on X-terminals (Windows termitals etc.)? And what clear
advantages we have (I don't see one)?
> Currently it is usual that a client transfers a PS file to the server for sending.
It's transparently converted to TIFF when sending.
> Receiving faxes are stored in TIFF.
> -> viewers for 2 different formats are needed on the client.
Why? Are you going to view jobs in the send queue? Is it really needed?
> Does anybody know a free printer driver which can produce TIFF files from
> the printout of an application?
I can speak of Windows world only. There is a number of shareware
TIFF/bitmap printer drivers, but none are free (at least I failed to find
one). E.g. see
http://www.slipstick.com/addins/fax.htm
> Can hylafax convert an arbitrary TIFF file to a TIFF file suitable for fax
> transmission?
Yes. You can submit TIFF file to Hylafax instead of PS. It will be
- sent "as is" if compression method & resolution are OK
(or)
- converted via tiffcp
(or)
- converted via tiff2ps | ps2fax (in harder cases)
Hope to hear from you soon,
Dmitry