Re: [hylafax-users] Real-Time Fax Compression Usage

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2004.07.07 15:24 Frank Peters wrote:
> A new firmware version 1.32H has been released for the MultiTech-ZPX
> modem and, compared to the earlier releases, RTFCC actually works
> without
> problems using HylaFAX.  Earlier versions would give disastrous
> results.
>
> My question is how to properly use the RTFCC capability.

As far as the end-user perspective on RTFCC goes, it's a toggle-switch: 
"on" or "off".  Most of my comments here and below go for Class 2 RTFCC 
as well as for soft-RTFCC available in 4.2.0.

> As far as I
> know,
> the HylaFAX documentation gives little information on RTFCC other than
> setting up the configuration file (i.e. Class2RTFCC: yes).

Explanations beyond the brief synopsis found in the hylafax-config man 
page of what RTFCC is and how it works and how HylaFAX utilizes it are 
left for T.32 and modem documentation.  I don't feel that a deeper 
explanation of RTFCC is of any value in the documentation.

> I have created a 1D MH fax file from PostScript using the ghostscript
> tiffg3
> device.  This 1D MH file was then given as a parameter to sendfax:
>
> sendfax -m -n -d'phone number' 1D-MH-fax-file

This merely delivers it to hfaxd, and then faxq finds it in the queue.  
faxq then prepares the fax image for transmission and triggers faxsend 
to do the modem work.  So, normally if you haven't faxed to a location 
before, faxq will prepare an MH (1D) image file.  If the remote 
supports something tighter than MH compresssion, then faxsend will (if 
RTFCC-enabled) utilize RTFCC to convert the image into a tightest 
compression supported by the receiver.

Anyway, unless you specify the -1, -2, or -3 options to sendfax, it 
doesn't guarantee that RTFCC will acutally be used.

> HylaFAX transmitted the file without problem.  The log file showed
> that the receiving fax machine wanted a 2D fax file and that the
> real-time compression was used to create the 2D fax file.

Receiving equipment really doesn't "want" any particular format.  
Rather, receiving equipment presents a range of "supported" options to 
the sender, and the sender is allowed to pick the session parameters 
from among those options.  So the fact that MR (2D) was used was more a 
result of RTFCC being enabled (faxsend knowing that it could convert it 
on-the-fly), otherwise MH would have been used instead, and MR wouldn't 
likely be used until the next call.

> Is this the proper procedure for using RTFCC?

Sure.  It shouldn't take any concious effort like this, though.  
HylaFAX will use it when necessary and won't use it when not.

> Will any kind of
> fax file (1D, 2D, or 2D MMR) that is submitted to sendfax be
> converted by RTFCC?

If RTFCC is enabled then faxsend can use it to convert whatever image 
format faxq selected into the tightest compression supported by the 
receiver.  Again, unless a specific -1, -2, or -3 option is used, the 
"submission" type doesn't necessarily dictate the faxq-format type.

> Also, after installing the 1.32H firmware, my MultiTech-ZPX modem
> gives
> the following result for the FCC=? command:
>
> at+fclass=2.1
> OK
> at+fcc=?
> (0-1),(00-0D),(00-02),(00-02),(00-01,03),(00-01),(00),(00-07),(00-7F)
>
> What do these numbers mean?

The modem manual should say.  The full explanation is in T.32 (table 
21).  In short, it is of the form: VR,BR,WD,LN,DF,EC,BF,ST,JP where...
  VR = resolution (0-1) means normal and fine are supported
  BR = bit rate (00-0D) means all bitrates from 2400 to 33600 baud
  WD = page width (00-02) means A4, B4, and A3 page widths
  LN = page length (00-02) means A4, B4, and unlimited page lengths
  DF = data format compression (00-01,03) means MH, MR, and MMR
  EC = error correction (00-01) means no ECM and T.30-A ECM supported
  BF = file transfer (00) means no file transfer support
  ST = time per scanline (00-07) means full support
  JP = color fax (00-7F) means all variations supported

Notes: superfine, hyperfine, and other extended resolutions are not 
supported
       Class 2x modems generally aren't going to ever support any file 
transfer options
       color fax is not supported by HylaFAX yet, and HylaFAX ignores 
this part

> I was not able to find anything about
> them
> in the HylaFAX documentation, although class 2.0 and class 1 result
> codes
> are described.

It is the same for Class 2.0 and Class 2.1 except for the BR values.

> Are there any web sites that would explain these codes for class 2.1?

I guess if someone explains it like this, yes.

> Class 2.1 operation seems very interesting but, probably because it is
>
> relatively new, has been poorly documented.

The only real change between Class 2.0 and Class 2.1 is V.34-Fax 
support (BR).  The fact that the modem provides a Class 2.1 and a Class 
2.0 is merely one easy way for the modem user to switch between having 
V.34-Fax support and not.  Otherwise the manufacturer could have simply 
had just a Class 2.1 (disabling it via setting the BR parameter to 5 or 
less)... or perhaps just a Class 2.0 (with V.34-Fax support, although I 
haven't seen it that way).

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*