Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/FAX155O.ARJ/WHATS.NEW

Text File | 1996-06-10 | 27.4 KB | 545 lines

THIS IS A BETA VERSION
~~~~~~~~~~~~~~~~~~~~~~
The archive contains only files changed since BGFAX 1.55 was released.
That is why there is no documention included with these files.  It is
assumed that you have already downloaded a copy of BGFAX155.ARJ, and
extracted all the *.DOC and *.TXT files from it.

To use this beta version, simply overwrite all your old BGFAX files with
the files contained in this package.

Note that you can get online access to the BGFAX send documentation (in
HTML format), from my web page http://www.blkbox.com/~bgfax/

BGFAX 1.55 Rev O
  Mon 10 June 96
================

Oh my, yet another beta!  Will this program ever get released?  :-)

Hopefully, this will be the last beta so we can have a full release
next week.  (I think this is the 4th or 5th time I've said this now.)

1. VIEW.EXE will now automatically "flip" pages in a fax if you press
   Alt-F when viewing the first page.  This just saves you a keystroke
   on each page, since you will no longer have to hit Alt-F on any
   page except the first if someone sends you an upside down fax.

2. New BGFAX command line switch /NX
   This tells BGFAX that when sending faxes on Class 2 modems to "not
   wait" for the initial XON to be received.  This might be necessary
   on some older Intel(GVC OEM) fax modems.  Do not add this switch
   unless you notice things in BGFAX.LOG indicates "initial xon not
   received".

3. If any English-like characters are detected in Class 1 <NSF> frames,
   they will be logged.  Why?  While viewing a PMLM (Ray Gwinn's Poor
   Man's Line Monitor for OS/2) trace for a fax session, I noticed that
   when talking to my Murata fax machine, it would actually send MY name
   in the NSF frame preceeded by a "EU" pair.  I had no idea this was
   happening, but some other fax machines may do this as well.  Will have
   to see if this is truly Murata specific or not.  (Apparently, the Murata
   was getting my name from the fax page top-of-page header setup.)  Ex:

        03:38:43  ->[ATS11=70X4M2&K3DT8939320]
        03:39:00  f=[CONNECT]
        03:39:00  dial result [CONNECT]
        03:39:01  hr=NSF:[255.3.32.0.0.69.85.66.46.74.46.32.71.117.105.
                         108.108.111.116.32.32.32.32.125.203.16.3]
        03:39:01  f=[OK]
        03:39:01  <NSF> [ EUB.J. Guillot    ]

4. New switch for VIEW.EXE /PL:nnnn
   This lets you refine the "page length" of a piece of laser paper, in
   the number of laser-scan lines.  Normally, VIEW uses 3380 scan lines
   for a piece of A4 paper, but I was told some A4 printers very, i.e.:
   Deskjet 500C A4 /PL:3170 or /PL:3320 is performation skip
   Deskjet 500 A4 /PL:3234
   Oki Laserline 6 A4 /PL:3411
   If you are using US paper size, this switch should not be necessary!

5. BGFAX will now put a few extra spaces in the FAX.IDX file.  I was
   told Faxworks didn't like just one space, but required more.

6. BGFAX Class 1 send mode should no longer get confused if stray
   XON, XOFF, DLE, or DC2 characters somehow get injected into the
   receive command string.

7. New BGFAX command line switch /EM:nnnnn
   It has been reported that sometimes BGFAX will sit idle if a fax
   send attempt fails, with the elapased time counter still ticking
   down.  I have not been able to duplicate this, but people who use
   BGFAX sending hundreds of faxes have observed this.  This is more
   of a kludge than a bug fix, but it should work until I am able to
   duplicate the bug.  /EM:1000 for example tells BGFAX to abort after
   1000 seconds (about 16 minutes).  You probably will not want to use
   such small values, because a long 10-20 page fax could easily take
   16 minutes (/EM:1000 seconds) to transfer.  You should not use this
   switch unless you have personally observed BGFAX doing it's countdown
   to infinity.  This switch will not make a difference unless the actual
   elapsed time counter is moving.  (Maximum /EM:65535 seconds)


BGFAX 1.55 Rev M
   Tue 04 Jun 96
----------------

Well, it looks like it might be a little longer before the full release.
There are some minor problems fixed and some minor additions made, since
I want this next release to be as bug free and feature rich as possible.

This should take care of all known bugs except for one.  (The one bug that
is not fixed relates to sending faxes from an XT-class machine, in which
the top-of-page header is the only thing that is recevied.  It turns out
that the XT is so slow, the time it takes to close the temp banner file,
and then open the fax file to send, is enough for the remote fax machine
to think the connect was lost.  Since sending top-of-page banners can
be aborted with the /NB switch, and since most people do not own XT's,
and since it would require me to rewrite a major section of the code that
could cause other bugs to surface, I've decided to shelve this bug until
I have a little more free time to work on it.)

If no other bugs are found in this version of the software, then we look
good for a full-release to occur within one week.  That should be enough
time for people to play with it, and for me to update the documentation
and help files.  (Of course, this is the second time I've said that
recently, so you never know.)

1. BGFAX /SEND mode can now send TIFF-Class-F files!  This is a very nice
   addition, since it allows much greater flexible in what documents are
   sent.  I tested sending TIFF-Class-F files made from BGFAX, Faxworks/2,
   and Word Perfect 5.1+/DOS, and all the documents faxed correctly.
   (BGFAX has had TIFF-Class-F receive capabilities for nearly a year now,
   and VIEW has had TIFF-Class-F viewing capabilties for several months
   now, but this is the first time /SEND has been able to process them.)

2. MAKEFAX, when converting PCX and DCX files to FAX mode will now "guess"
   as to what resolution flag to put in the fax header, so that BGFAX knows
   what to tell the remote fax machine about the resolution of the upcoming
   document.  If the PCX or DCX file has a page with greater than 1200 scan
   lines, it will assume the fax is to be marked as high resolution.  If
   less than 1200 scan lines, it will be assumed low resolution.  MAKEFAX
   can be forced to put a high resolution flag in the header with a /HR
   switch, and a low resolution flag with the new /LR switch.

3. Electronic Counter Measure for "Batman hack".

4. BGFAX/2 would have trouble receiving faxes if storing in TIFF-Class-F
   mode if an existing BGFAX.$$$ file in the directory was bigger than the
   size of the incoming fax.  This should be fixed.

5. BGFAX/DOS and BGFAX/2 would have trouble receiving faxes if storing in
   TIFF-Class-F mode if using a Class 2 or 2.0 modem in which case a
   "Problematic Fax Reception (EOP)" error was encountered (i.e., +FHS:nn
   or +FHNG:nn abort where nn>0.)  This should be fixed.

6. BGFAX /SEND mode was not able to send faxes that were "read-only".  It
   can now do this, as it will use outgoing faxes in "read, deny none" mode
   instead of "read, write, deny none" mode.

7. Ditto for VIEW, when attempting to select "read-only" faxes for viewing.

8. Revision J and K were writing the log file times out to the hundred of
   a millisec.  I did not intend for that to leak out in the beta since I
   was using that for some internal Class 1 testing on my side.

9. BGFAX VESA view modes (e.g.) 1024x768 was not working properly with
   some video cards under Windows 95, but remained to work fine under DOS.
   I made a slight modification that might fix this in VIEW.


BGFAX 1.55 Rev K
   Thu 30 May 96
----------------

If all significant bugs are now fixed, expect to see the full release
of BGFAX out very soon (a week or less).  The only thing I have left to
do is to make some changes to the BGFAX.DOC, and also I have to make some
D'Bridge help files since I've promised several people that I would
personally type some up.

1. BGFAX /HOST mode now betters handles conditions in which the number
   of rings is greater than one (ri=2 or higher in BGFAX.CNF).  Before,
   BGFAX would wait up to 120 seconds before getting the two (or more)
   rings.  Waiting two rings to answer the phone is for Caller ID
   purposes.  What would happen is that someone would call, then hangup
   before two rings came, and this caused the Caller ID information for
   the next caller to not work properly.  Now, BGFAX /HOST will abort if
   a second (or third, or etc.) RING does not follow the previous RING
   without 10 seconds.  After the correct number of RING's are received,
   then the 120 second timeout is re-enforced.

2. VIEW.EXE will now double the number of scan lines of a low resolution
   fax during a PCX and DCX conversions so that it works better with OCR
   software that might be expecting more pixels to work with.  To override
   this feature so that PCX and DCX conversions provide a one-to-one pixel
   conversion, use the new /RH switch (retain height).

3. VIEW.EXE now handles /PCX conversions differently.  It seems that NOBODY
   liked my convention of converting multiple page fax files into PCX files.
   (If you had a 3 page fax, it would make HELLO.PCX, HELLO.P02, HELLO.P03
   in the old version of VIEW.)  It has been reported to me that most image
   editing software is brain dead and it will not acknowledge a file is PCX
   format unless it has a "PCX" extension, so here is how things work now:

   "VIEW 2letters.fax /pcx" will create PAGE0001.PCX and PAGE0002.PCX.
   Notice that the filename base is completely missing from the target
   files.  I did this because I just personally HATE fax software that
   does a truncation to the base filename in order to stuff the page
   number at the end.  So, how will the image editing software know about
   these funny PAGE*.PCX files?  Well, know, VIEW will create a DOPCX.BAT
   file that says:

        CALL EXEPCX PAGE0001.PCX PAGE0001
        CALL EXEPCX PAGE0002.PCX PAGE0002

   So, you can now put the name of your image editing or OCR software in
   the EXEPCX.BAT file that you will produce, and pass the filename via
   the %1 variable (or %2 variable if you are using even brain-deader
   software that croaks if a PCX extension is given when the extention
   is already known to be PCX).  Example using make believe OCR-THIS.EXE,
   EXEPCX.BAT would say "OCR-THIS %2.PCX" or just "OCR-THIS %1".  By
   executing the DOPCX.BAT file, the make believe OCR-THIS will will run
   for both pages.

   Okay, for those of you who already wrote programs to handle the old
   way VIEW worked, simply add the /RF switch (VIEW file.fax /PCX /RF) to
   work in "retain filename-base" mode.  This time,
   "VIEW 2letters.fax /PCX /RF" will make 2LETTERS.PCX and 2LETTERS.P02.
   The new DOPCX.BAT file will also be created, example:

        CALL EXEPCX 2LETTERS.PCX 2LETTERS
        CALL EXEPCX 2LETTERS.P02 2LETTERS

   Some people might like the /RF (original) method better.  The %2 variable
   in this case isn't really meaningful, but I kept it there to be
   consistant with the non-/RF case.

   These two methods should provide the ultimate in flexibility.

4. New program included in this archive: ATOTSR.COM
   This program is for those of you using RPI modems which only offer
   Class 1 fax capabilities.  These modems, while having adaptive answering
   features, could not previously have been used with BGFAX unless you were
   running in "BGFAX /HOST /ATO" mode, which meant no FidoNet mailers.  A
   little background: Some Class 1 fax modems, when in adaptive answer mode,
   will return a "DATA" response code if a data call is encountered.  Smart
   modems will also immediately return the "CONNECT nnnnn/xxx" result code.
   However, the RPI modems (and some others, like USR Class 1 mode) will
   require that an "ATO" command be sent to the modem so that it can resume
   data operations.  This is very stupid, but hey, they didn't bother to ask
   me when designing their modems.  The ATOTSR.COM file can be loaded in
   your AUTOEXEC.BAT file (don't forget to reboot).  This file will only
   interface with your FidoNet mailer if you are using a FOSSIL driver,
   because it is the only easy way to intercept inbound characters and to
   "trick" the FOSSIL into sending an "ATO" command to the modem if your
   FidoNet mailer does not.  Repeat: ATOTSR.COM will not function unless a
   FOSSIL driver is also present.  Most FidoNet mailers use FOSSILs, so
   this is not a problem.  If you are using Intermail, make sure you use
   FOSSIL mode instead of direct-comm mode.  Note that this TSR only works
   under DOS sessions.  It will not work in an OS/2 session with BGFAX/2.
   It might work okay in a Win95 DOS box, but I don't think it would work
   correctly in a Win95 32-console box.

5. Regarding low-speed (2400) data modem fix done in 1.55j, it allowed
   the sending of faxes normally, but when BGFAX tried to clean up and
   terminate, it was trying to send an "ATH0" command to the modem at 19200
   instead of 2400, and the low-speed modem would not respond.  Now,
   termination condition will have a 2400 DTE shift and this should fix the
   long wait caused by 1.55j on these low-speed modems.

6. MAKEFAX, when encountering a form feed in an ASCII -> FAX conversion,
   would not put any top margin on the next page like it was supposed to.
   This is now fixed.


BGFAX 1.55 Rev J
   Thu 23 May 96
----------------

This release is basically a hodge-podge of bug fixes.  If any major bugs
are found, I will probably have another quick beta release, followed by
the full release.  The last full release (1.55) was on January 8th, which
was a LONG time ago, and registrations have started to slack off a bit,
probably because people are afraid to register something they perceieve as
"stale", so I'm going to try to get the next full release out quickly.

Report any bugs to me via Fido 1:106/400, e-mail: [e-mail],
the Fido BGFAX support echo (tag "BGFAX"), BBS: [phone] or even
voice at [phone].

1. Some new PPI modems report "0,1,80" on the AT+FCLASS=? commands that
   BGFAX /SEND issues to determine what outgoing fax class to use when
   sending faxes.  BGFAX did not expect to see the "80", and it was
   assuming that the modem had Class 2 capabilities when it really did
   not.  It should now correctly use Class 1 on these new modems.

2. Reworked the Class 1 training sequence on fax sending slightly.  It
   eliminated problems sending faxes from Windows 95 dos-boxes with
   Sportster 14400 modems.  Also, reworked Class 1 image send sequence
   in OS/2 version--before BGFAX/2 had trouble sending to some machines
   in Class 1 at 12000 and 14400 bps.

3. MAKEFAX now supports DCX as a valid input file type.  (Recall DCX is
   a multi-page PCX file), e.g.,
       makefax sample.dcx output.fax
   or, makefax coverpg.pcx+notes.txt+document.dcx+signatur.pcx output.fax

4. VIEW was not allowing individual page print (ctrl-enter when viewing
   a specific page on screen) if conventional memory had been exhuasted
   (i.e., currently spooling to XMS or disk.)  Now, VIEW will reserve
   32K of conventional memory for the print buffer.

5. In abnormal terminate situations, VIEW was not releasing any used
   XMS memory back to the operating system.  Bug fixed.

6. VIEW now supports printing to 9-pin dot matrix printers.  Use VIEW /P9
   to set VIEW into 9-pin mode.  NOTE: In this mode, VIEW will print pages
   twice as long as they should be.  So, a 3 page fax will take 6 pages to
   print.  I've refused to support 9-pin printing in the past, because it
   is my opinion that faxes just are not worth printing to 9-pin printers.
   By printing one page as two, it allows us to get something printed that
   at least is readable.  If you still have a 9-pin printer you really need
   to go buy a 24-pin or laser.

7. Had a report that the FAXIN.LOG file was not always updated if a failed
   fax arrived.  This should be fixed now, but I was unable to test this
   fully, so if Warren Z. should try and see if it has been fixed.

8. Michel Ouellet reported the FAX.IDX file being created by BGFAX was not
   formatted in the same way as Faxworks wanted it to be.  This should now
   be corrected.  FAX.IDX represents the next index available, NOT the next
   index used.  (FAX.IDX is used in Faxworks file format storage)

9. DOBBS.BAT and DOBBS.CMD will now have the PID number appended to them
   when BGFAX is running in /HOST /PID:nnn mode.  i.e., /PID:4 will cause
   BGFAX to make DOBBS4.BAT files and BGFAX4.LOG files to keep things from
   getting "confused".

10. Minor cosmetic changes were made, as well as minor changes to prevent
    hacking.

11. For older 2400 data-modems with Class 1 or 2 fax modems, BGFAX /SEND
    mode was not always working correctly, because, even though these
    modems support a DTE rate of 19200, they "pretend" not to until the
    AT+FCLASS=1 (or =2) command is sent by BGFAX.  These dinosaur modems
     should now work properly in send mode. (sp=2400 should be set in the
    BGFAX.CNF file for this special operation mode to work)

12. Candian Caller ID decoding in /HOST mode that was added in 1.55g was not
    working properly.  Should be fixed in this beta.

13. BGFAX /HOST:nn idle timeout mode, makes BGFAX abort with an errorlevel 6
    after approximately nn minutes of non-activity.  This worked, but if
    midnight passed, BGFAX would get stuck and never exit until someone called
    into the system.  BGFAX /HOST:nn mode will now always exit at midnight to
    prevent this problem.  This does NOT affect regular /HOST mode.

BGFAX 1.55 Rev G
   Thu 18 Apr 96
----------------

(VIEW.EXE and FNTEDIT.EXE are unchanged since 1.55f)

1. BGFAX in /HOST mode was not saving faxes to disk if the fax failed
   without receiving all pages.  This should not have affected rear-end
   mode, but /HOST mode only.  Thanks to Warren Zatwarniski for finding
   this bug.

2. While working on the above bug, I found a new bug.  Apparently, if a
   "live abort" happens during fax receiption, this too would cause BGFAX
   to exit without saving any partial fax.  Now these too should be
   saved.  (A "live abort" means while working, BGFAX receives either a
   "RING" or an "ERROR" response code from the modem--both of which mean
   something very wrong has occured.)

3. Still received a few reports that BGFAX was not functioning properly
   under DesqView with BGFAX 1.55f.  I have made an additional change in
   the DV timeslice return logic, so let me know if this fixes the problem
   or if it is still broke.
   Vince Rifici and Glenn Fischer reported this.

4. Added new command line parameter for BGFAX, /IT
   /IT should only be used if you are having trouble with your modem
   occasionally stopping all image reception without notifying BGFAX
   that the image sequence has stopped.  /IT is for "image timeout"
   detection.  1.55e added IT detection, but many reported problems with
   it, so it was modified in 1.55f, but even this still results in
   problems on some fast machines, such as Richard Boychuk's Win95
   DOS box.  So, the IT detection will now be turned off by default.

5. Added a Canadian Caller ID filter for Supra modems at the request of
   Sylvain Lauzon for /HOST mode.  Let me know if it works, since I can't
   easily test it here.

6. MAKEFAX will no longer completely abort if one of the input files is
   missing.  i.e., the command...
        MAKEFAX cover.pcx+filename.txt+file2.txt output.fax
   will still work even if "filename.txt" file is missing or locked by
   another application.  MAKEFAX will alert the user on screen, and
   will also put a note on the fax file itself that the file was missing.

7. OS/2 version of BGFAX in /HOST mode was not responding to the keyboard
   when waiting for a call (i.e., <esc> to exit BGFAX was not working).
   This should be fixed now.

8. OS/2 version of BGFAX in /HOST mode will now turn the cursor off (like
   the DOS version) when it is waiting for calls, and will turn the cursor
   back on once activity starts.

BGFAX 1.55 Rev F
   Sun 31 Mar 96
----------------

1. MAKEFAX can now handle multiple input files!  Example...

        MAKEFAX cover.pcx+filename.txt+file2.txt output.fax
           or
        MAKEFAX @filename.lst output.fax

   Where "filename.lst" is a standard ASCII text file, with one filename
   per line.

2. MAKEFAX now supports 132-column mode.  Example:

         MAKEFAX filename.txt output.fax /132      132-column, font #1
         MAKEFAX filename.txt output.fax /132 /F0  132-column, font #0
         MAKEFAX filename.txt output.fax /132 /HR  132-col, font#1, high-res

   Remember that MAKEFAX will default to 100-column mode unless you use
   the /80 or /132 switch to override.

3. The VIEW.EXE Alt-G (or Alt-J), "jump to page number" bug should be
   fixed.  (This feature was introduced in the last beta.)

4. Had a report of BGFAX reporting a "fax image timeout" when trying to
   receive faxes on very fast machines.  I've made a slight change that
   might fix this, but don't know if it will since I was never able to
   duplicate this problem.  Only had one person report this problem, but
   it appears as if it could have been widespread.

5. FNTEDIT made more multi-tasking friendly.  It will now return time slices
   when waiting for input from the keyboard.

6. FNTEDIT was not always saving changes to the last character edited.  This
   should be fixed now.

7. MAKEFAX2.EXE (OS/2 version) now gives some time slices back to OS/2
   during the conversions.  This means the conversions will proceed slower
   than they have before, but it should not cause all the other applications
   to slow to a crawl as before.  Let me know if people think it runs too
   slow now, and I'll add a switch to either enable or disable this so-
   called OS/2 friendly mode.  The DOS version will still run at maximum
   speed.

BGFAX 1.55 Rev E
   Sun  3 Mar 96
----------------

1. Have optimized the communications/timeslice routine in the DOS version
   somewhat.  The DOS version should no longer take up 100% of the CPU when
   receiving or transmitting a page under OS/2.  Also, the DOS version
   should run more smoothly with both DesqView and Windows.  (CPUUSE.EXE
   for Windows 3.1 reported 4% usage when BGFAX/DOS is waiting for a call,
   14% during page receive, and 38% spikes during interpage negotation.)

2. Fixed a major bug relating to saving files in TIFF-F format.  Anybody
   telling BGFAX to save in Faxworks format should immediately upgrade to
   this beta version.  The problem was that many faxes were getting
   scrambled because the byte-alignment filter in BGFAX was not working
   very well, resulting in faxes containing 50% bad scan lines.

3. VIEW.EXE has a new feature when you are in page-view mode.  Alt-J
   and Alt-G will now allow you to jump ("goto") a specific page number.
   So, if you bring up page 1 and want to go to page 13, just hit Alt-J
   (or Alt-G, same thing) and type in "13" at the prompt.  Note that if
   you save faxes in ZFAX format, the first time you use the "jump"
   function, a quick analysis of the page will be performed.  On slow
   machines (less than 386), this may take a while.

4. The TIFF "filter" can also be turned on for ZFAX and QFX format with the
   /TF command line switch.  This just makes sure that the T.4 data in the
   fax image is byte-aligned.  This is of use mainly to me for testing
   purposes, or for developers who wish to directly manipulate the T.4 data.

5. Made some modifications to the Class 1 timeout parameters.  If anyone
   has problems with this version (1.55c) getting "stuck", let me know
   ASAP and provide me with a clip of the BGFAX.LOG.  I really want to
   get these "stuck" bugs fixed quickly.

6. Changed OS/2 version so that it answers the phone like the DOS
   version (i.e., waits for "RING" or "2"[numeric result] instead of
   waiting for the "ring indicator").  Some modems do not produce the
   "ring indicator" signal as well as some damaged serial cables, so that
   will help.

7. Changed OS/2 version so that it now works with IBM's stock COM.SYS driver.
   Previous versions of BGFAX2.EXE would only work with Ray Gwinn's SIO.SYS.
   Now, it can work with both.


BGFAX 1.55 Rev B
   Sun 25 Feb 96
----------------

1. MAKEFAX finally can convert ASCII documents using 80-columns per line!
   Before, MAKEFAX would always transfer the file into a 100-column per
   line fax.  I got numerous complaints about this, because the lettering
   looked a little too small on the received fax machine.  Now, using the
   /80 switch on MAKEFAX, you will get larger output on the outgoing fax.
   I am also including a new BGFAX.FNT font file, because a few changes
   had to be done to about two dozen characters in order for the dual
   80 and 100 char/line font to use the same 16x32 and 32x32 font
   defintions.  Example...
        makefax test.asc output.fax /80
   MAKEFAX will continue to default to using 100 columns per line to
   maintain compatibility with the older version of MAKEFAX.

2. I believe I have fixed the DesqView problem that was present in BGFAX
   1.54 and 1.55.  In the previous version, BGFAX would receive a one page
   fax under DesqView, but it come come in VERY slowly (300 cps instead of
   1200 cps, for example), and never receive the second page.  If you were
   one of the people that experienced that, let me know if this version
   corrects the problem.

3. BGFAX will now honor the FaxWorks's FAX.IDX file.  This is a standard
   ASCII text file that will be present in the receive fax directory.  If
   BGFAX finds it, it will find out the last fax number that FaxWorks thinks
   it has received, and use that as the maximum fax number.  BGFAX will
   also update the FAX.IDX file.

4. The DCE rate in /HOST mode is now stored as a long integer instead of a
   word (unsigned standard integer).  With people locking ports at 115200
   and not setting their modem to report the DCE speeds, and with all the
   ISDN TA's popping up with 128000 DCE speeds, this was a necessary thing
   (and quite easy to fix).  Before, BGFAX would report incorrect speeds
   if the DCE were higher than 65535 bps.

5. BGFAX /SEND mode will now create a SEND.DAT file after BGFAX finishes.
   The file will look like this:

FaxFilename 2pages.fax
FaxTelephoneNumber 7138939124
LastPageSuccessfullySent 2
TotalNumberOfPages 2

   This is a regular ASCII file, which contains information about the last
   fax sent, including (most importantly) the last page successfully sent.
   To use this information, you would need to write a program to examine
   and see if "LastPageSuccessfullySent" is equal to "TotalNumberOfPages".
   If not, this indicates a transmission failure, and you will need to
   resend the fax using the /SP:lastpagesuccessfullysent+1 logic, so that
   you need not resend the entire fax.

   This may also be useful on some of the buggier fax modems, where they
   (sometimes) do not return a successfully condition upon sending the
   last page, even though it was really sent.  What you would need to do,
   is see if the LastPageSuccessfullySent is one less than the
   TotalNumberOfPages, if so, you can "assume" (big assumption) that the
   last page might have actually gotten through even though the modem
   reports to BGFAX otherwise.

Regards,
B.J. Guillot