Short-circuit queue scan when no devices are ready

If no modem devices are available, then there is no point looking
for a job on the queue to send.

Because jobs are now always "Ready" and on the DestInfo list we
don't need to scan the entire queue to find them either.

Job timeouts/expiry are all handled by timers, so we don't need to
scan the queue to perform any of that work.

Check JobControlInfo before batching jobs together

This introduced the ability to make sure that jobs with different
"JobControl" options don't get batched together.

The initial compatibility is limited to the "args" that JobControlInfo
collects being the identical.  This could possibly be refined further but
most of the JobControlInfo members don't affect the actual faxsend
invocation so don't really matter for batching.

Make a Batch the unit of work, instead of a Job.

Instead of handling a "Job" through the prepare/send/done machinery, we
handle a "Batch".   The Batch can add jobs to itself from those that are in
the DestInfo's ready queue.  It adds these jobs as it finishes preparing
previous jobs.

As a batch works, it's very easy to see progress go through the Jobs.
Because we can see that, we can act on jobs as they finish, moving them
through the queue much more quickly.

Make the runq contain DestInfo instead of Job objects

This make the DestInfo readQ the primary source of "ready" jobs.  Any job
that is ready is in there.  The runq is a sorted list of DestInfo pointers
instead of Job pointers.  The readyQ inside each DestInfo is a sorted list
of the jobs (based on pri, just like runq used to be), and the DestInfo
pointers are sorted in runq based on their first job's sorting priority.

This means that the next job to send is *always* the first job in the first
DestInfo in the runq with jobs.

The runq can contain DestInfo objects that don't have any jobs on their
readyQ.  This happens they job is sending.  But since we know that the
number of these objects is bounded by the number of devices, which is tiny
in comparison.

Move to a single runq in faxQueueApp

The idea of multiple runqs was to split up the job priorities.  This
shortens the time to do the sorted insert into the runq.  But as it
happens, most people don't use priorities, and the "large queues" which are
the ones that the sort has the biggest impact on are almost always
submitted at the same priority anyways.

Moving to a single runq, though theoretically a bit slower, in reality
isn't a performance hit.

And it simplifies the code.

Add 'Z' FIFO showDebugState()

Remove useless JobControl::compare() function

It doesn't do anything

Add Job::higherPriority(const Job&) const

This allows us to consolidate the knowledge of how a job sorts
based on priority.

Make pickCmd take the jobtype, not the request

Refactor faxQueueApp to pull job send checking to isJobSendOK()

Pull out the checks to see if a job is actually good to send now.  These
used to all be inside the runSchedule() loop.  This brings them to their
own separate function, simplifying the runScheduler() loop, and possibly
allowing the checks to be used from other places.

Clean up faxq scheduler - return to 4.1.8 state

Clean up scheduler operation - removing batching and the
pointer-following associated with it.

This resotes the 4.1.8 state of the clean scheduler run
with no batching available.

Make faxq squeaky clean with valgrind --tool=memcheck

Fix suspend segfault on Job running JobControl

JobControl running is one of the few places in faxq where jobs were
*not* on a QLink list.  But because of the asynchronous nature of
jobcontrol (short as it is), it was possible to try and suspend a job
when jobcontrol is running.  We *need* it to be on a list in this case.

Earlier notify scripts used RETURNFILETYPE=original to return files in their
original format. We need to keep this possibility as equivalent to RETURNFILETYPE=raw.

raw TIFF files were emailed as application/PDF instead of image/tiff

Added the complete debian/ directory in order to create official
Debian packages. Since 4.3.3 the Debian package is very similar to
hylafax base code, i.e., many patches that were in Debian package have
been applied upstream.

Bug 287: RFE: More options available for the tagline generation

Adds the missing options for tagline generation

Here's a patch to add the missing options: (with documentation)
 %%a  subaddress
 %%c  sender's company name
 %%C  destination company name
 %%g  sender's geographic location
 %%G  destination geographic location
 %%I  group identifier
 %%S  subject
 %%v  sender's voice number
 %%V  destination voice number

Compensate for 1728 pixel data when they DCS signalled differently

Based on Lee's work:

|  commit f9624ee351f783144ab71671fb5ca455e40318c9
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Feb 8 05:55:43 2006 +0000
|
|    compensate for senders that signal one page width and send 1728 pels instead

and
|  commit 35ddc56ffcfa3632b301b177dffcb749f931713b
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Mar 3 17:10:34 2006 +0000
|
|    oops, don't let the mechanism let us slip other-sized lines through

Print page with in pixels as uint32 to match the %u specifier

Improve Class 1 handling when prologue frames fail after EOM

From Lee's work:
|  commit cdaf7f3b41170a76e2717863514df6368e51de7c
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jul 27 19:36:20 2006 +0000
|
|    this improves the error-handling for situations where Phase B fails
|    following EOM... notably it gets emsg into the info array

Improve and extend JPEG parsing (13 Mar 2007)

A port of some of Lee's work:

|  commit 745554d522ef1cbd58c109d1bb2c89e491220fd4
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Mar 9 00:16:22 2006 +0000
|
|    improve and extend JPEG parsing

and
|  commit 9c6247539fe314ed14d06cf53cb276180fb60842
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Jun 2 01:04:20 2006 +0000
|
|    clength is a long but i is int... if clength gets too big (bogus comment marker)
|    then i will "wrap" and we end up in a mess.  This checks clength before adding
|    it to i

Restrict the usage of sending EOR, even when using MH and MR

From Lee:
|  commit 5047c9552d77be6d1ab22e0bb72f08d93a180c04
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Aug 26 16:57:51 2006 +0000
|
|    We really shouldn't send EOR if the receiver hasn't gotten enough data frames
|    in MH or MR.  If, for example, they haven't received any frames properly then
|    it's not a good idea to be EORing.  So for now we say half.

Fix send buffer when transmitting non-ECM data with a non-zero scanline-time value

From Lee:
|  commit c8555867d1f9c6db83851c08ecf941767c77b356
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Apr 19 05:27:12 2006 +0000
|
|    Guilio reported that non-ECM non-0ms sending was using too-small of a buffer
|    This fixes the problem that was introduced with JBIG support.  The problem
|    arises because correctPhaseCData does not decode the full image when using
|    MH or MR data.

* Flush modem input after NO CARRIER result in Class 1 Phase C send

From Lee:
|  commit eb8957a81476c7ffa890a67166098706e734fcb8
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jul 20 16:48:04 2006 +0000
|
|    I'm coming to more and more of an opinion that we should be checking for
|    modem responses during the entirety of Phase C data transmission - rather
|    than just waiting until after all of the data is transmitted.  But, until
|    we do that...
|
|    Some modems, like iaxmodem and Patton 2977s, are capable of detecting a
|    hangup, and so if that occurs during the middle of Phase C data transmission
|    the modem will respond/result with NO CARRIER before we ever get to end-of-data.
|    Consequently the remaining Phase C data that is sent to the modem can
|    potentially get interpreted as AT commands (if it coincidentally looks like
|    it) and will usually result in repeated ERROR messages.
|
|    We dont want those ERROR messages - or whatever the modem responses were
|    to the junk we sent to it - to be interpreted as responses to our subsequent
|    commands... so we need to flush the modem input.

* Improve sender-side RNR/RR flow control interaction (13 Mar 2007)

From a combinatin of Lee's work:
|  commit ea79977689a1f8d874f3a1c5562db60cf98fc386
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Oct 28 18:45:15 2006 +0000
|
|    this improves RNR/RR interaction... namely by ensuring for switching pauses
|    and by removing the usage of CRP from it

and

|  commit 41737a2d65274c95fb70f0fa8fbf37ad9dcea28e
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jan 11 20:05:11 2007 +0000
|
|    Make sure we don't use AT+FRS=n in V.34 mode.

Make sure the receiver can hear our DCN

From Lee:
|  commit 3eb457ebd5c9e2a17c5ee8118e815d469856c909
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Sep 8 17:12:27 2006 +0000
|
|    make sure the receiver can hear our DCN

Don't fallback to V.17 speeds on TCF retransmisions

From Lee's work:
|  commit 676fa100db3f3b24e513c69c25f895721ec8fb01
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Feb 16 17:43:23 2006 +0000
|
|    on TCF retransmissions don't fallback to V.17 9600 or V.17 7200 because
|    it won't likely succeed, and many receivers will give up after 3 failed
|    reception attempts.

and
|  commit 0edcf44be4cec9e5b07043544522f7158fdab4ea
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Jul 28 16:28:04 2006 +0000
|
|    if the modem is not supporting V.27ter then without checking the return value
|    for dropToNextBR we can end up in an infinite loop here

Prevent picking up again on the receiver's MCF signal when re-entering Phase B in a batch

From Lee:
|  commit 737c0ae2e32c2df792a68f8796c59f627c60b3d5
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Feb 10 02:24:10 2007 +0000
|
|    We need to make sure that the receiver's V.21 carrier that it used to
|    transmit MCF is down before we go looking for its Phase B signalling.
|
|    Doing this eliminates the need for that software pause.

White space cleanup in faxd/Class1Send.c++

V.34 requires ECM

From Lee's work:
|  commit 65540dc6a8b82326ab87673301d6b13beafddbf3
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Sep 12 21:28:24 2006 +0000
|
|    V.34 requires ECM

and

|  commit 39476859b097cf38fef6151dc8d9da4bef254a47
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Jan 13 01:11:33 2007 +0000
|
|    DIS_ECMODE is in "xinfo", not "dis" here.

Recognize DTMF as caller id when waiting for rings

From Lee's work:
|  commit d158d795f56be80498f21b542789e85ffb8893f0
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Jan 3 03:20:22 2007 +0000
|
|    Need to again recognize DTMF as a valid CallID indicator (for MT5634ZBA-DID).

Use DLE+DTX to help reseting when stuck in transmit (13 Mar 2007)

From a combination of Lee's work:
| commit 77e9b7a53716acae93a6d8205d10b0f6d706c574
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date:   Wed Sep 13 00:27:03 2006 +0000
|
|    This was noticed to be useful with SmartLink (soft) modems that could get
|    stuck after AT+VTX... but it may be useful for other wedged situations.

and
| commit d158d795f56be80498f21b542789e85ffb8893f0
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date:   Wed Jan 3 03:20:22 2007 +0000

Where sending DLE+DTX is troublesome on some modems.

This use makes us only do it when a reset is having trouble.

Adjust timeout waiting for responses.

From Lee:
|  commit f12b251834a2344b924dfe1c4f37ca9dec0edff3
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Aug 28 17:56:45 2006 +0000
|
|    this timeout needs to be longer ... well, it really needs to be configurable,
|    but for now just making it longer should be helpful

Add DTMF handling during call

From Lee:
|  commit 4658310b3fc3d70fa762cca60513971106a1bc38
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jul 27 20:57:06 2006 +0000
|
|    IAXmodem can report DTMF in the middle of the call ... this gets HylaFAX
|    to tolerate DTMF reception in unfortunate places

Don't make setModemVolume() wait 30 seconds

From Lee:
|  commit 87d9a1b6a26815e3bc0a9f2916411e3971cf98b5
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Jul 21 17:06:48 2006 +0000
|
|    waiting 30 seconds for the OK result to setVolumeCmd is silly

Adds a bit of missing logging

From Lee:
|  commit cfbee81666fd7a40b90d5c5d8b8f199995785026
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Oct 30 22:38:36 2006 +0000
|
|    adds a bit of missing logging

When dealing with JBIG/JPEG send PPR if we detect no frames received but we're still missing the last frame

From Lee:
|  commit f655d0d0d0977b4dba96976975e2acf6c3dfd9d7
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Apr 27 22:47:16 2006 +0000
|
|    the last frame is important in JBIG/JPEG, we can't let the sender get away
|    without delivering it... despite our reasons for ignoring it in other cases

Bug 811: child process should call _exit() instead of exit()

  Child processes call exit() at several places in hylafax, e.g. in
  FaxServer::notifyPageSent() in FaxSend.c++. This is dangerous, see
  http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC6
  I managed to get exit() to hang in notifyPageSent() when writing my own
  replacement for faxsend, although I can't tell you how to reproduce it in a
  regular faxsend.

Only save the page if there is data to be saved.

From Lee:
|  commit 2d0bc852218e989488fc97955bc044b172926786
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri May 12 22:38:58 2006 +0000
|
|    Only save the page if there is data to be saved.

Handle situation when sender is not using ECM after negotiating it.

From Lee:
|  commit de49a7b7b5dc5a2b704ef844fe90053d568dd0b8
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jun 29 16:27:15 2006 +0000
|
|    handle instances where the sender transmits MPS/EOP/EOM after a bunch of
|    garbage ECM data - indicating that the sender is not using ECM ... even
|    though we appear to have negotiated it

Fix a bit of flow logic in recvPage

From Lee:
|commit d609116f05c61d1aaffdb5a306ed611d40301524
|Author: Lee Howard <faxguy@howardsilvan.com>
|Date:   Mon Jul 17 18:17:40 2006 +0000
|
|    It's a very rare circumstance, apparently, but this fixes just a bit of
|        flow logic.

Better error handling

From Lee:
|  commit 9513fe485695d95f832827291fc57765631cbd14
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Aug 11 18:35:15 2006 +0000
|
|    better error handling here

Prevent unecessary timout messages

|  commit 852de7ebbc1e14b0b924bddb3f0832723ce8b3f9
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Nov 2 19:33:21 2006 +0000
|
|    this should prevent some unnecessary timeout messages

Handle MPS/EOP/EOM/CRP when expecting DCS, i.e. after RTN

From Lee:
|  commit 937948c65313124618439ec40bcae8197cac406d
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Dec 21 22:07:30 2006 +0000
|
|    It's probably rare (as I don't recall seeing it before), but if a sender
|    doesn't hear our RTN signal then we may hear MPS again, and we should
|    repeat RTN.

Handle V.8 bit correctly in DIS when in V.8

From Lee:
|  commit cad06bd3bc74601bc0a1d257646073f8e97c10a3
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jan 11 20:38:02 2007 +0000
|
|     V.8 handshaking occurs before we see DIS.  So if we get DIS and it indicates
|     no V.8 bit, then let's fill in that blank.

Add more intelligence to the Class 1 receiver in sending RTN

From Lee's work:
|  commit 2fdb9f1d671d5f378bd66e9222707f66fa4be118
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Nov 4 00:38:58 2006 +0000
|
|    If, without receiving any Phase C data, we get PPM very quickly after we
|    last sent MCF... well, we can rest assured that the sender didn't get our
|    MCF signal ... and it wasn't that we missed an extremely short page.
|
|    So instead of sending RTN let's send MCF again... helping prevent retrains
|    and slow progress, etc.

and

|  commit 45f8d9cb46b5db27dc2c845a5975e6eab5a52f23
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Nov 4 02:19:37 2006 +0000
|
|    Sys::now() is seconds not ms... plus it needed to be longer than 3100 ms anyway.

Restart the Class 1 TCF reception timer after zeros start

From Lee:
|  commit ea69a971a4bbfe2bed7eab414927e609f6a7f874
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Sep 20 16:44:02 2006 +0000
|
|    restart the Class 1 TCF reception timer after zeros start

Remove timeout setting after we timeout and abortReceive

From Lee's work:
|  commit 209f80ecfd684cc4b30a7007219aacf124e4755f
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Aug 15 16:23:34 2006 +0000
|
|    after a timeout and we abortReceive we need to remove the timeout true setting

Handle +FCERROR after most +FRH=3 command

Based on lee's work:

|  commit 59402ed3aa2b67f9472138542edb5f110bb1a753
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Jun 26 16:56:53 2006 +0000
|
|    this gets us to handle most cases where +FCERROR would be received in response
|        to +FRH=3 from an inconsiderate modem

|  commit 22a62e0ac61594c3b408dba8d8529242111d70be
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Jun 30 15:25:34 2006 +0000
|
|    slow down the speed of the loop in the +FRH=3/+FCERROR loop

We can't rely on the timeout value to know if CONNECT has been seen

Based on Lee's work:
|  commit 20678e9f4e755bcb192b93dfb6298d971d261b19
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Sep 30 15:56:55 2006 +0000
|
|    this should handle the non-ECM case for gotCONNECT usage

|  commit de6ff8aa35e95d99cec03b46b8cf8f827f56db36
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Sep 30 02:19:11 2006 +0000
|
|    On Sep 8 a change was made to recvFrame which caused (correctly so) the timeout
|    value to be cleared after a successful abortReceive.  However, the side-effect
|    of this was that the "recv pps" portion of the ECM code was depending on that
|    timeout value to know if CONNECT was even seen in the attempt or not.
|
|    So this fixes that condition by creating a global flag specifically for this
|    purpose.  I hesitate a bit in doing it this way (I'd prefer to change recvFrame's
|    exit value to int instead of bool), but right now it seems to most straight-
|    forward approach.

Calculate PPM/PPS waiter instead of using T1

This rolls up lee's initial work on this, and the various fixes
he applied in getting it right:

|  commit cbe43053d8a12cc36a3b61dcaebabb0f613ce01f
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Jul 29 16:13:49 2006 +0000
|
|    A full block is 64KB, and at 14400 that will come in at just under 60 sec.
|    Even at that speed T1 doesn't well-suit us if the premature carrier drop
|    detection occurs early-on in a full block.
|
|    So we calculate the waiter instead, which helps even more with slower speeds.
|
|    With non-ECM we really don't know how much data could possibly be coming in.
|    So we'll just estimate with 64KB as well, which I believe should suit most
|    occassions.

|  commit 3adff9192569117abf6190863bf1b7a44d331ce9
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Jul 29 17:12:15 2006 +0000
|
|    oops.  the waiter is ms, not sec

|  commit 66351ae1eb2c540a16309a2f03d8f250c0b3a982
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Aug 30 00:58:43 2006 +0000
|
|    oops.  curcap is not useable in v.34

|  commit 4797712545a3c855695d87d6babb7c8d12602d16
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Aug 30 04:50:03 2006 +0000
|
|    wasn't quite right...

|  commit 9f8fa44261bcb2e2e0fd65ea0c3494d9eb01dacb
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Sep 8 19:38:00 2006 +0000
|
|    64K is actually too short - there is more to it than that - the framing and
|    the flags between frames and the initial flags and eofb - 80K should be
|    enough slack

Improve response handling of AT+FRH=3

From Lee:
|  commit e744814227bfe95326f7c88f7ba56cade1ef8e4b
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Jul 24 04:39:30 2006 +0000
|
|    This is somewhat experimental.
|
|    First off, getting ERROR in immediate response to AT+FRH=3 indicates
|    that we're on-hook.  No need to try AT+FRH=3 four more times before dying.
|
|    However, the check here for lastResponse != AT_NOCARRIER was essentially
|    for the same kind of thing:
|
|      <-- AT+FRH=3
|      --> NO CARRIER
|
|    But, the way that this is coded it would also catch on this kind of thing:
|
|      <-- AT+FRH=3
|      --> CONNECT
|      --> NO CARRIER
|
|    ... which technically may not mean that there was a disconnection, but could
|    merely mean that no HDLC data was received before the V.21 carrier dropped.
|
|    So, the idea is that in either of the above NO CARRIER situations that on
|    the next loop we'll see this:
|
|      <-- AT+FRH=3
|      --> ERROR
|
|    and then we know for-sure that a disconnection occurred.  If we don't see
|    that happen then we may need to further enhance Class1Modem::recvFrame to
|    better detect "eot" situations (with NO CARRIER).

and

|  commit c564e83d723043a2058e6e334d03f4337ce8be96
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Jul 24 21:38:59 2006 +0000
|
|    followup to yesterday's s/AT_NOCARRIER/gotEOT/ change

Improve ECM HDLC frame decoder to recover more quickly from data corruption  and possibly find frames where it couldn't before

This is based on  of 2 of Lee's patches:
|  commit 6edca4c323ac8a499ce6a2b832e2bc2c8ee6a38a
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Nov 7 00:51:20 2006 +0000
|
|    The ECM HDLC frame decoder would read the bitstream and would pull out ECM
|    frames from there.
|
|    Most of this change is directed towards removing the requirement that the
|    HDLC frame be immediately followed by an HDLC sync flag.  That way if the
|    data corruption occurs on the flag and not in the frame itself then the
|    data is still useable.
|
|    The way in which I've coded this, however, in merely counting the frame
|    size as it builds allows the decoder to recover from data corruption more
|    quickly than before.  So that's an added bonus, I guess. :-)

and

|  commit 94c3c2732b60f4aad41852f2a4fd17d03c43bda5
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Nov 7 16:58:37 2006 +0000
|
|    ECM frames are, unfortunately, not always full-sized

Extend "awaiting ECM synchronization" timeout

From Lee:
|  commit f3b5c635e9f548f6826a79526f0f842b21ac4cfd
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Jan 16 18:05:11 2007 +0000
|
|  Log posted on hylafax-users indicates a longer wait is needed here.

Add Class1PageWidthSupport modem config option

From Lee:
|  commit 90d38ac3ea1e2c79cb27d32c112c7c99e26ab8a0
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Jan 2 19:22:54 2007 +0000
|
|      add Class1PageWidthSupport modem config option

Add Class1PageLengthSupport config option

From Lee's work:
|  commit de0cb2e47f327cea2e639773505f30c46f142cdb
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Jun 5 19:12:55 2006 +0000
|
|    this adds Class1PageLengthSupport so that Class 1 modems can configure
|    the LN settings that they want for send+receive
|
|    faxsend wasn't checking modem page length support and therefore sending
|    would always use LN_INF - this buglet should apply to Class 2 as
|    well ... it should be fixed now

Simplify Class1SwitchingCmd code and prevent duplication of the command in-session

From Lee:
|  commit e152937c32a44a47e6e07f0ef98a2c6b979321de
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Sep 7 18:59:29 2006 +0000
|
|    okay, this should prevent the AT+FRS=7 duplication.  It simplifies all
|    Class1SwitchingCmd processing and it provides for an abort situation, too.

Replace Class1TrainingRecovery with Class1SwitchingCmd

From Lee:
|  commit 6b780af933a17e2d89a37179d1d5f5056182e1ea
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Aug 7 16:53:14 2006 +0000
|
|    this replaces Class1TrainingRecovery with Class1SwitchingCmd
|
|    waiting a fixed period of time is an imperfect solution to simply trying
|    to avoid transmitting at the same time as the other end - using +FRS seems
|    to be a much more direct approach to that end
|
|    as for the modems that don't support +FRS ... well, I'm truly sorry.  In
|    any case 70 ms wait is not likely to be any worse than 1500 ms.

Fix error of sending a block twice, empty the 2nd time

From Lee:
    Silly logic error causing blockFrame to be invoked after it just was.

Don't trigger hasV17Trouble for pages other than the first

From Lee:
    If we're going to have true V.17 problems it will be in TCF or on the
    first page and not in subsequent pages.

Don't wait Class1TrainingRecovery when CRP was received

Lee says:
    There's no need to wait at all, PLUS waiting that long could possibly
    cause the sender to give up.

Adds BadPageHandling feature defaulting RTN-SAVE

From Lee:
|    commit 50a89a7c17355c046dc34e2d6a4f17f2f063fd9b
|    Author: Lee Howard <faxguy@howardsilvan.com>
|    Date:   Fri May 5 01:21:02 2006 +0000
|
|        adds BadPageHandling feature

Stop using CRP in Phase D in Class 1 sending - docrp

From Lee:
|  commit f2fdbde96f0bb3ce8cb7bae17334a978083af6e9
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Mon Jun 26 16:08:10 2006 +0000
|
|    This implements a "docrp" feature for Class1Modem::recvFrame for the intent
|    of defining when using CRP is or isn't appropriate.
|
|    CRP may actually not be appropriate when receiving responses and may only be
|    appropriate when receiving commands.  Yet, it has proven useful to use in
|    receiving CFR/FTT and DIS.  However, it does us no benefit to use CRP when
|    waiting for a response to PPM/PPS, and so we will start by not using it
|    in those cases.
|
|    This may actually help reported situations where DCN is received in response
|    to CRP following PPS.

Fix error of forgotton fxgetty child under flawed ECM

From Lee's work:
|  commit eb25447d9eefa95ccd6c9bc0dfa3dead705b8778
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Jul 27 00:40:34 2006 +0000
|
|    Let's say that in receive mode this happens:
|
|      --> Phase C ECM data
|      --> NO CARRIER
|      --> PPS-NULL
|      <-- MCF
|      --> strange V.21 signal (MCF, CFR, NSF, etc)
|
|    Then we'll have started a decoding child process, but the strange signal causes
|    a fallback to non-ECM behavior and (the error) is that we forget to take care
|    of the child.
|
|    This patch fixes that error of forgetting the child.
|
|    It also fixes an error where the same kind of thing would occur when
|    SaveUnconfirmedPages is set to false.  (In fact, that config option should probably
|    be removed entirely and always have the behavior in practice ... otherwise getting
|    the code right for both is a rather tricky scenario for so little benefit.)
|
|    The patch also fixes the saving of the page when the strang signal condition takes
|    place.
|
|    The patch also (finally) simplifies the repetitive coding for this abort procedure
|    into a function.
|

Add some comments as to why we don't want to use the modem's line count

From Lee:
|  commit b8062c0f76e3d3c37389aa07c950470bb41cec31
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Dec 23 00:31:40 2006 +0000
|
|      Add some more comments as to why we don't want to use the modem's line count.

Fix premature disconnection in Class 2 reception

Based on Lee's work:
|  commit a2b25eab88dc24b0a1375c560a2350a6d0be58be
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Feb 10 00:43:54 2007 +0000
|    The code was written to deliberately look for DCN, and I guess that's fine.
|    Better, we should be looking for +FHS (AT_FHNG)... this is Class 2, after all.
|
|    The way it was written before (this way since at least 4.0pl0) means that
|    when using +FBU=1 *any* response from the modem will cause recvEnd to return,
|    and depending on configuration the modem could hang up and depending on the
|    modem that may mean that it does not actually finish Phase D.
|
|    The receiver would think that it did everything fine, but the sender would
|    notice a "no response to..." situation and probably retransmit something over
|    and over.
|
|    The solution, of course, is to wait for AT_FHNG.

=?utf-8?q?Increase_the_wait_time_for_AT+FCLASS=3D=3F_response?=

This is Lee's work:
|  commit 724709e94d258c1f192b8eec2b8dc799dda5eb47
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Thu Dec 7 19:27:54 2006 +0000
|
|      Some reports that AT+FCLASS=? responses can time out.  And, looking at the
|      code, 500 ms is seriously not long enough anyway.
|

Pad TCS/CSI string to avoid Class2 modem bugs

This is a port of Lee's work:
|  commit 1882007f525aed4f2d2eb2a80441fcbfa404ed7d
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Fri Dec 8 19:09:01 2006 +0000
|
|    Apparently some modems in Class 2 have a bug that causes it to introduce
|    garbage characters into the TSI/CSI string in the case that we do not
|    consume all 20 characters with our +LID= command.  So to prevent this
|    we now are padding the +LID= command ourselves to fit 20 characters.

Unify and simplify FCF tracing routines

This is based on Lee's work:
|  commit cb7d838711f3aefdb6d7832a782141fca8c008dd
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Tue Jul 18 18:52:55 2006 +0000
|
|    tracePPM and tracePPR do essentially the same thing - the first was intended
|    for tracing commands and the latter for tracing responses, however over time
|    we've learned that we can get just about any signal at any time and so we've
|    inevitably been putting all signals into both functions, and thus these two
|    functions have been looking more and more the same with an ever increasing
|    number of collisions to address
|
|    This change unifies tracePPM and tracePPR into traceFCF (which, in my opinion
|    is a long-overdue change).  Everything should work as before... the only
|    downside that I can tell, now, is that - as far as tracing goes - we're now
|    unable to distinguish between whether the expected signal was a command
|    or a response - but really, we weren't using the tracing feature this way,
|    anyway... and I don't see any value to tracing FCFs differently depending
|    on the expected signal.

Adds T.32 Addendum 1 Extended DF formats

This is a merge of 2 patches:

|  commit 21f0db5057eb6d75d4af42d887e964aa37913017
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Sat Jun 17 18:31:33 2006 +0000
|
|    This adds preliminary support for proprietary T.32 data format extensions
|    on new MultiTech modem firmware.
|
|    MultiTech appears to have done this work in order to add support for JBIG.
|
|    This commit gets partially into the JBIG-on-Class-2 work, but a lot more
|    will need to get done in faxd/CopyQuality.c++ ... probably restructuring
|    some things to get the JBIG/JPEG parsing out from specific use in Class 1
|    ECM situations.
|
|    The reason this is being committed now, however, is to "fix" parsing of
|    the initial +FIS response so that MR and MMR can be sent to JBIG-supporting
|    receivers.  Otherwise HylaFAX doesn't know what to make of the "F" in the
|    DF section of the +FIS response and limits us to MH.
|
|  commit c7d7c51af3c89e313a4286a55cbd7db1f8cc0d4a
|  Author: Lee Howard <faxguy@howardsilvan.com>
|  Date:   Wed Nov 15 06:09:01 2006 +0000
|
|    This doesn't change any functionality.  It merely changes the attribution
|    for the extended DF features to ITU T.32 Amendment 1.

Cleanup warnings in hfaxd/

Cleanup compiler warnings in faxd/

Cleanup warnings in util/

Warning cleanups in faxalter/

Warning cleanups in faxmail/

Cleanups in regex/

getopt cleanups from Lee

Add AuditHook feature to faxq

This adds an "AuditHook" feature to faxq

FaxQueuer already has generic "Trigger" mechanism in it, which allows
clients to get notification of any event as it happens in faxq already.

This patch ties into the trigger calls to add the possible invocation of
a program.  This means that you have access to *any* of the events that
faxq triggers (see the faxwatch man page, or grep for Trigger::post in
faxQueueApp.c++.

This patch addes a config option for faxq something like:

        AuditHook:    <string>        -       specific a faxq hook for events

        AuditHook:
          Syntax is like  "program: spec", where program is the program
          to invoke, and spec is the specification, like J*M*S*R* as
          described in the faxwatch man page.

This means that putting
        AuditHook:            "bin/hook: J*S*M*R*"
into your faxq config file will cause it to run bin/hook on *every*
event.

The arguments passed to the hook program are:

$PROGRAM <class> <mask> <id> [info]

        <class> = JOB | SEND | MODEM | RECV
        <mask> = the specific event (see faxwatch man page)
        <id> = id of the job/modem the event is associated with
        [info] = extra info that faxq passes for the event.

I use the full names for <class> instead of just the J/S/R/M generally
used by triggers.

Also note that if you use an id in your specification in the config
file, that id will *not* be honoured.  All masks for the hook are
global.  I looked into making them id aware (because triggers are id
aware), but the mechanism for that is tied heavily to the HylaClient
class and the Job/Modem being monitored.  Jobs/Modems aren't created
when faxq sets up, and can be automatically associated unless they
exists at job time.  But generally, I think hooks want to be global
anyways...  If you want to just watch for an event for a period,
client-server triggers (faxwatch) are what you want.

With a simple hook script:
        #!/bin/sh
        logger -p local1.info -t "hook[$$]" "ARGS: $*"

You get results like this in syslog:
        Jan  4 14:14:22 espresso hook[24465]: ARGS: MODEM 0x0008 ttyds01
        Jan  4 14:14:30 espresso hook[24477]: ARGS: MODEM 0x0008 ttyds01
        Jan  4 14:14:39 espresso hook[24495]: ARGS: MODEM 0x0008 ttyds01
        Jan  4 14:14:51 espresso hook[24531]: ARGS: JOB 0x0001 33
        Jan  4 14:14:56 espresso hook[24535]: ARGS: JOB 0x0004 33
        Jan  4 14:14:57 espresso hook[24537]: ARGS: JOB 0x0020 33
        Jan  4 14:18:25 espresso hook[24679]: ARGS: JOB 0x0001 33
        Jan  4 14:18:25 espresso hook[24682]: ARGS: MODEM 0x0008 ttyds01
        Jan  4 14:18:30 espresso hook[24685]: ARGS: JOB 0x0004 33
        Jan  4 14:18:31 espresso hook[24687]: ARGS: JOB 0x0020 33
        Jan  4 14:24:30 espresso hook[24840]: ARGS: JOB 0x0001 33
        Jan  4 14:24:30 espresso hook[24843]: ARGS: MODEM 0x0008 ttyds01
        Jan  4 14:24:35 espresso hook[24846]: ARGS: JOB 0x0004 33
        Jan  4 14:24:36 espresso hook[24848]: ARGS: JOB 0x0020 33

Use SCRIPT_SH instead of /bin/sh

Moving forward

[Bug 854] Stop caching of DATE and VERSION by configure

4.3.3. Great work everyone!

Update CHANGES file to follow changes

4.3.3 release candidate 1

Fix faxq seqfault when logging strings with %s, etc

FaxQueuer was calling syslog with "external" strings as part of it's
"format" string.  If these external strings contained format sequences
(like %s), it caused syslog to go looking for more stuff on the stack to
interpret as the needed values.  Certain ones (like %s) are certain to
cause problems.

This patch makes faxq push the all "external" string parts as additional
values to the log functions, and uses %s in the format string to refer
to them.  Similar work was done in hfaxd in 2003 by the SuSE security
team (see bug 468).

This fixes segfaults such as those seen by Moritz Winterberg, who was
using JobControl to set modem options that contain %s.  This problem is
very old (going back to the initial CVS import), but recently became
apparent when people began using jobcontrol to set more config options.
Setting similar options with DestControls previously would have had the
same effect.

Update pollrcvd.1m man page to hint at PollDispatch

The pollrcvd man page had not hint at PollDispatch.  This puts in a
reference similary to the notify and faxrcvd man pages.

Bug 853: Add multiple file formats to notify/faxrcvd/pollrcvd emails

This patch allows to convert received faxes to multiple files, e.g.

FILETYPE="tiff pdf"                   # separated by whitespace

will create two attachments: one (original, unchanged) TIFF file, and a PDF
file. This is meant both as a safety belt to protect against failing
TIFF-to-something conversion, and as a convenience for users using different
fax readers.

From: Helge Oldach <hylafax@oldach.net>

Add Helge Oldach to CONTRIBUTERS

Update CHANGES file to follow changes

Bug 851: Fix SNPP authentication

Helge Oldach points out that authentication on SNPP is broken.

We weren't checking if a password was required, and were actually
authenticating the already known password, not the user supplied password.

Bug 852: use = instead of == in shell scripting

Helge Oldach points out that == is not a valid expression on all shell
implementations.

On 503 permission denied, hfaxd should not also give the success reply for boolean JPARM commands.

Thanks to vbargsten for reporting the problem on -devel.

Added all changes since 4.3.2

[bug 843] Removed unused (except for deprecated notify-4.2.sh) CHARSET setting

Also changed default value in notify-4.2.sh.in to UTF-8 which works with
most languages in the dictionnary file. Added a note about it not being
in setup.cache anymore.

Remove extra spaces at the ends of lines in the templates

[Bug 850] Include jobtag in Subject of notification emails

This is Simon Matter's patch to put jobtag information back into the
notification emails.  It's omission wasn't intended.

It sets and uses a $JOBINFO variable, which an admin can easily further
customize in FaxDispatch.

Bug 849: notify "rejected" templates are wrongly called notify-reject.txt

They should be called notify-rejected, because the state is "rejected",
not "reject".

Carl Carstenson correctly points out that ConvertFile needs to return the
file name even when there is nothing to do for PDF.  This is needed for
TIFF to.  PostScript already returned the name.

Prepping 4.3.2

Update for change committed yesterday