Differences in HylaFAX+ compared to HylaFAX found at hylafax.org

HylaFAX+ includes fixes and features not found in the HylaFAX at hylafax.org. There are various bugfixes and other improvements including improved fax protocol, modem support, and support of some specific modem behaviors. The entire list of changes would be too long to be meaningful to most readers, and such a list is no longer actively maintained, but here is a smaller list of noteworthy differences.

1. support for sending and receiving color faxes (without patching libraries)

Versions of HylaFAX from hylafax.org do not support sending color faxes, and in order to enable color fax reception libjpeg and libtiff must be patched (which is usually a difficult process). HylaFAX+ supports both sending and receiving color faxes without patching by using the LittleCMS library found natively on most modern systems.

2. simplified default faxrcvd, notify, and pollrcvd for easier customization

Instead of following hylafax.org's path into mail templates as a solution for mail customization and translations, HylaFAX+ stays with the traditional approach for mail customization - customization of the faxrcvd, notify, and pollrcvd mailing shell scripts - and stays with the relatively recent "dictionary" approach for translations. However, these three mailing shell scripts have been simplified in their scripting to make them more readable and easier to customize.

Templating does not necessarily make mail customization any easier. Take for instance the administration of a HylaFAX server that services users of multiple languages. In the minimal-alteration case where mere wordings are being changed, with the traditional approaches the administrator would add a case statement to etc/FaxDictionary and within it set some DICT variables to modify the wordings found in bin/dictionary. With the template approach the administrator would be required to modify wordings in numerous mail templates for each language. In the full-customization case where customized mail content is dynamic and where mail wordings and formatting are being entirely rewritten, with the traditional approaches the mailing scripts are customized, and now the scripts have been simplified to allow that customization to occur within one single mailing function in each script. With the template approach the administrator would be required to learn and probably modify the templating functions within the mailing scripts themselves as well as then recreate all of the numerous template files for each language.

Templating does not make a translator's job any easier. With the "dictionary" approach the translator is merely required to translate a bunch of phrases or words in the bin/dictionary script. With the template approach the translator not only is required to translate but to also then duplicate that work numerous times.

Indeed, it is difficult to imagine a case where the templating approach actually makes customization or translation any easier for the administrator. The only conceivable benefit would be in cases where the administrator needs to make only the most simple alterations and would be prone to cause the mailing scripts to error-out in attempts to modify them without an ability to debug them afterwards.

See the HOWTO's Localization and Customization of E-mails for more a more detailed description of just how easy the HylaFAX+ method of mail customizations really is.

3. faxq batching support was not needlessly rewritten and includes greater protection against resource overutilization

Batching support for faxq was initially introduced into HylaFAX version 4.2.1. As it gained exposure a number of bugs were fixed in version 4.2.2 (note that this is prior to the creation of HylaFAX+); however, some developers at hylafax.org continued to dislike both the coding design used for the batching work as well as general disagreement about the validity of batching in the first place.

The end-result was that after the creation of HylaFAX+ those developers at hylafax.org took that opportunity to rewrite the batching support at hylafax.org to conform with their design preferences. A number of baseless claims have been made over the years by those developers with respect to the superiority of their work. The truth is that the scheduler (faxq) in current HylaFAX+ releases performs at least as well as the one in hylafax.org releases. Furthermore, there are a number of advantages to the HylaFAX+ scheduler:

4. extended presentation of CallID

CallIDLabel, CallIDDisplay, and CallIDRecord can be used together to present CallIDPattern match data in the modem status string and faxinfo output. So, for example, with these entries in a modem configuration file: 

  CallIDPattern:        "NDID="
  CallIDLabel:		"DID"
  CallIDDisplay:	yes
  CallIDPattern:        "NMBR="
  CallIDLabel:		"CID"
  CallIDDisplay:	yes
  CallIDRecord:		no
  CallIDPattern:	"NAME="
  CallIDLabel:		"CID"
The faxstat output could look like this: 

  Modem ttyIAX0 (+1.999.888.0000): Running and idle
  Modem ttyIAX1 (+1.999.888.0000): Answering the phone, DID:1000, CID:7776665432
  Modem ttyIAX2 (+1.999.888.0000): Receiving facsimile, DID:1001, CID:7776664321
  Modem ttyIAX3 (+1.999.888.0000): Receiving from "+1.777.666.3210", DID:1002, CID:7776663210
And the faxinfo output could look like this: 

      Sender: +1.777.666.3210
       Pages: 2
     Quality: Normal
        Page: North American Letter
    Received: 2006:10:29 09:00:40
  TimeToRecv: 0:17
  SignalRate: 9600 bit/s
  DataFormat: JBIG
  ErrCorrect: Yes
         DID: 1002
         CID: Lee Howard
Notice in this last case that "DID" and "CID" are used instaead of CALLID1 and CALLID2, making the information there more meaningful for those using raw faxinfo output and not requiring any translation of those in etc/FaxDictionary for meaningful presentation in the default faxrcvd notification mail.

Of course, the default behaviors for all of these options is for traditional output in both situations.

5. intelligent real-time format compression conversion (RTFCC)

Certain images do not compress well with Huffman encoding and consequently 1-D compression will actually be more-preferrable to 2-D compression on those images. When using ModemSoftRTFCC faxsend compares the compression performance of 1-D versus 2-D encoding, and if 1-D outperforms 2-D then 1-D will be used instead. This will save in communication times.

6. ModemSetOriginCmd, ModemDialCmd, FAXNAME job parameter, and -e "name" and -u "number" sendfax options

The ModemSetOriginCmd allows the administrator to set the outbound Caller*ID values for various modems that support setting the call origination information (for example IAXmodem and Eicon Diva Server). The new FAXNAME job parameter in conjunction with the FAXNUMBER job parameter allow the various client programs to specify these call origination values, and are then used if the administrator configures it. The sendfax client uses the 'sendfax -e "name"' and 'sendfax -u "number"' options for this purpose.

For example, on the Eicon Diva Server this configuration item will cause the modem to be initialized with the appropriate origination information provided by the administrator or user in the "FANUMBER" job parameter: 


  ModemSetOriginCmd:    AT+iO%d
On an IAXmodem this configuration item will cause the modem to be initialized similarly with information provided in the "FAXNUMBER" and "FAXNAME" job parameters: 

  ModemSetOriginCmd:    AT+VSID="%s","%d"
Similarly HylaFAX+ includes an extension to the ModemDialCmd feature that allows it to utilize a similar capacity in t38modem except that it is done in the dial command like this: 

  ModemDialCmd:         ATDT%sL%d
On a t38modem this configuration item will cause the dial command to include the calling number (where %d appears) provided to the server from the job information.

7. enhanced and improved fax image preparation

8. numerous faxmail enhancements

9. etc/FaxAccounting reliable event hook, particularly for adding xferfaxlog data to a database

If an executable file named ``etc/FaxAccounting'' exists in the HylaFAX spool directory then it will be executed every time a record is written to etc/xferfaxlog. The record fields will each serve as separate command arguments. This is designed to allow attachment to external databases and other accounting mechanisms. However, it also provides a reliable event hook for other purposes (unlike ``etc/FaxNotify'' which is only triggered if the user requested notification, for example).

10. xferfaxlog extensions (SUBMIT records and jobinfo field)

The information written to xferfaxlog (and thus also FaxAccounting) has been extended. Specifically there are now "SUBMIT" records that are written for each job submission, and there is a new "jobinfo" field that contains various pieces of information concerning job progression (totpages, ntries, ndials, totdials, maxdials, tottries, and maxtries).

11. inbound faxes can be configured to utilize info files for automated fax parameters configuration

Through using the modem configuration option of CallIDType "calling-number" a CallIDPattern may be associated with info files. This allows the info items of senderHasV17Trouble and senderSkipsV29 to be used together to determine when it may be advantageous to hide V.17 support from the sender in order to avoid apparent trouble using that modulation with that sender.

12. support for taglines using UTF-8 fonts

The TagLineLocale modem configuration option can be used to utilize PCF font files with UTF-8 encoding. (This Allows for UTF-8 character sets in the tagline.)

13. More feature support (i.e. JBIG, JPEG) in the Class 2/2.0/2.1 driver

With a Class 2/2.0/2.1 modem that supports these features, HylaFAX+ also supports JBIG compression (both sending and receiving) and JPEG (color fax, receive-only). Also supported are the capabilities to disable V.34 or V.17 on-the-fly when so-desired.

14. StaggerCalls feature for faxq

Some users have expressed a potential problem that occurs when a HylaFAX server has a small number of lines that are shared as both sending and receiving. If a large outbound send queue occurs then it can effectively cause the lines to be continually busy and impairs the receiving service. StaggerCalls permits the administrator to limit the frequency of the scheduler initiating an outbound call, and thus hopefully making the line available for some time to receive incoming faxes.

15. place non-ready ModemReadyState onto modem status string and add "exempt" option

The purpose in the ModemReadyState modem config option is to allow the administrator the ability to remove a modem from servicing outbound jobs even though it may initialize properly. An administrator may do this, for example, to temporarily use the line for another purpose, to indicate that the line is somewhat more permanently unavailable, or to indicate that the modem is configured for receive-only use. HylaFAX+ displays this state into the modem status string so that users and administrators can readily recognize it. HylaFAX+ also adds the "exempt" state which indicates that the modem is configured for receive-only use instead of it being temporarily busy or more permanently unavailable. 

  Modem ttyIAX0 (+1.999.888.0000): Running and idle (exempt)

16. direct LDAP authentication support (without PAM)

hfaxd authentication can be done with an LDAP server without doing that configuration through PAM.

17. -nointeractive option for faxsetup and faxaddmodem (like configure)

Some people have expressed a desire to script an installation or configuration of HylaFAX that does not involve user interaction. The -nointeractive option for faxsetup and faxaddmodem in HylaFAX+ operates like it does with the configure script and allows the scripts to run without user interaction.

18. no JobControlWait option

JobControl was a replacement for DestControls. Previously with DestControls the operations involving it would be sure to complete before execution would continue. Usually this did not cause much delay because DestControls were rather simple without any real method of causing a severe delay. However, with the added amount of control that JobControl gives to the administrator, there is also an increased risk that JobControl has in permitting the administrator to slow down the performance of faxq due to processing time in JobControl. This risk is mitigated by the code at hylafax.org through the JobControlWait feature. By disabling JobControlWait the administrator can permit fax processing to continue without blocking until JobControl finishes. HylaFAX+ does not have this feature for some important reasons.

* The chances of JobControl blocking for an amount of time that is at all noticeable is rather slim. And even in the remote chance that the administrator configured a JobControl that would block for a noticeably long time, the chances of that performance hit being a problem are also rather slim. Put those two remote possibilities together and you get something that's really never going to happen in normal, everyday scenarios.

* JobControlWait interferes with batching. Without the block and when using JobControl, it is relatively impossible to guarantee that any jobs will batch properly. And, in fact even an imperceptible delay in processing in JobControl will keep two jobs from batching. In the past HylaFAX users have been very concerned about guaranteeing job batching. Users have never expressed worry about faxq performace difference of the kind that JobControl could normally create.

* Disabling the block on JobControl makes it impossible to someday extend the JobControl RejectNotice to reject job submissions (or otherwise involve JobControl) in the client-server protocol (hfaxd communication).

* To characterize the disabling of JobControlWait as a means to achieve "maximum faxq performance" is only likely to mislead the administrator into doing exactly that.