Recent Changes to HTML TADS

<title>Recent Changes to HTML TADS</title>

<h1>Recent Changes to HTML TADS</h1>

This file lists the changes that have been made recently to HTML TADS.
This release also contains improvements to TADS itself, which
are documented separately in <a href='../tadsver.htm'>Recent Changes
to TADS</a>.

<p>
Note that we've tried to keep all of the documentation that accompanies
this release up-to-date with these changes.  This file is provided as a
quick overview for experienced TADS users so that you can quickly see
what has changed since the last version you installed.

<p>
<hr>
<h3>Changes in version 2.5.4</h3>
<ul>

<li>The Windows HTML interpreter now supports transparent PNG images.
Transparent PNG images can be used to show non-rectangular icons and
to superimpose images over backgrounds.  Check your PNG creation
tools for information on how to create images with transparency
information.  (Note that only simple transparency is supported;
"alpha blending," which allows images to be partially transparent, is
not supported.  Images with alpha information are treated as
having simple transparency: each pixel that is partially but not
completely transparent is treated as completely opaque.)  Note that a
new systemInfo flag, SYSINFO_PNG_TRANS, has been added to test for
PNG transparency support; systemInfo(SYSINFO_PNG_TRANS) will now
return true under the Windows HTML interpreter.

<li>In TADS Workbench on Windows, any sounds still playing when you
terminate the running game are canceled.  (In the past, sounds continued
to play even after terminating a game, until either the sounds finished
playing by themselves or you restarted the game.)

<li>On Windows, a bug prevented playback of MIDI files containing
certain sequences.  This has been corrected (The exact conditions
that caused the problem are complicated, but the bug involved long
MIDI messages occurring at certain boundaries within the file.)

<li>On Windows, a bug in MIDI playback caused a crash if playback
failed due to an error within the MIDI file.  This has been corrected.

<li>On Windows, if MIDI playback was cancelled in the middle of
certain types of operations (such as pitch bends), a new MIDI
playback started after the cancellation sometimes "inherited" the
channel settings of the interrupted file, resulting in incorrect
playback.  This has been corrected: all MIDI channels are now reset
to default conditions at the start of each new playback.

<li>For users running certain early versions of Windows 95, Workbench
crashed when the "Settings..." item was selected from the "Build"
menu, due to an incompatibility with a Windows system DLL.  This
problem apparently only occurred for Windows 95 version 4.00.1111;
the problem has been corrected.

</ul>

<p>
<hr>
<h3>Changes in version 2.5.3</h3>
<ul>

<li>The HTML interpreter's table layout algorithm has been improved
slightly in the way it calculates the layout for rows within tables
with explicit heights.  This will be particularly noticeable in tables
with HEIGHT=100%.  In the past, the table layout system apportioned the
extra vertical space in tables with specified heights according to the
total height of the table; it now counts only the <i>interior</i> heights
of the cells, which results in much more accurate layout when the table
is intended to stretch to the limits of the window height.

<li>The HTML interpreter for Windows now reformats the text on any
change to the window size, vertical or horizontal.  In the past, as
an optimization to avoid excessive redrawing, the system only reformatted
on a change to the horizontal size of the window.  However, it is possible
for formatting to depend on the vertical size, too; tables whose heights
are set to percentages of the window height, for example, must be
reformatted when the window is vertically resized.  So, this optimization
has been removed; changes to either the width or height of the main window
will now result in reformatting.

<li>When you build a stand-alone game with the HTML interpreter for
Windows, the stand-alone game executable will no longer display the
recent games section of the "File" menu, nor will it offer the
"load new game" command.  These menu items were not appropriate for
stand-alone games, so they've been removed.  This change doesn't
affect the HTML interpreter during normal use - only when used to
build a stand-alone game executable.

<li>The game installer has a new option, "readme", that lets you
specify a file to display to the user immediately after completing
an installation.  Specify an HTML or text file in this field, and
the installer will open this file after the install completes
successfully and the user dismisses the installation "wizard" dialog.

<li>The HTML interpreter did not properly update the display in some
situations where a game used repeated updates to animate a sequence
of graphics.  This problem affected the title sequence of Neil K. Guy's
<i>Six Stories</i>, for example.  This has been corrected.

<li>The HTML interpreter for Windows crashed if you closed the application
while a sound was still playing.  This has been corrected.

</ul>

<p>
<hr>
<h3>Changes in version 2.5.2</h3>

<ul>

<li>The Windows interpreter now allows you to use certain web
addresses in &lt;A HREF&gt; links.  The interpreter opens these links
using the user's normal web browser, so the user must have a Windows
web browser (such as Microsoft Internet Explorer, Netscape Navigator,
or Netscape Communicator) installed and configured as the default
browser in order to follow these links.  Any properly configured
Windows web browser should work.  If a web browser is installed,
the Windows interpreter will use it to show any link whose HREF
starts with one of the following prefixes:

<tt>
<ul>
<li>http:
<li>ftp:
<li>news:
<li>mailto:
<li>telnet:
</ul>
</tt>

Note that you can use the <tt>systemInfo()</tt> function to check
the interpreter to determine if these link types are supported,
using the new <tt>__SYSINFO_LINKS_HTTP</tt>, <tt>__SYSINFO_LINKS_FTP</tt>,
and related capability codes.  Refer to the
<a href='../tadsver.htm#tads252'>TADS 2.5.2 release notes</a> for
details.

<li>The Windows HTML TADS Interpreter now keeps a list of recent games
under the "File" menu.  The four most recently-played games will be
displayed under the file menu; to load one of these games, just select
it from the menu.  Similarly, the Windows Debugger keeps a list of
recent game projects, under the "Recent Games" submenu of the "File"
menu (the debugger uses a submenu to allow for the future addition
of a "Recent Files" submenu listing recently-opened source files).

<li>Workbench will now work properly with relative directory
paths in all build settings.  In the past, it was usually best to make
these paths absolute (i.e., including a full path specification with
drive letter prefix), because Workbench's working directory was
always the same as where the Workbench executable was stored.  This is
no longer the case; Workbench now sets the working directory to the
directory containing the project (".tdc") file each time a game is
loaded, so all of the paths in the build settings can specified relative
to the project directory.  This is especially helpful if you're moving
a project file between different computers with different drive letters
or directory layouts, because it allows a project's build settings to
be fully self-contained within the project directory.

<li>The Windows debugger now lets you control flushing output to the
game window.  In the past, the game window frequently did not show
any output that had occurred since the last user input; this
sometimes made it difficult to debug display code, because the
immediate effects on the game window could not be seen while stepping
through the code in the debugger.  A new menu command, "Flush Game
Window Output" on the "View" menu, lets you explicitly flush most
pending output to the game window.  In addition, another menu item,
"Auto Flush Game Window" (also on the "View" menu), lets you control
whether or not the debugger automatically flushes the game window
on entry; if this menu item is checked, the debugger will automatically
flush the game window's output each time you step through a line of
code or encounter a breakpoint.  Note that some types of HTML structures,
such as tables and banners, will not always display anything until fully
formed (that is, the entire structure, including the ending tag, has
been written to the output), so you will not always see all pending
text displayed even when explicitly flushing output.

<li>The Setup program (for installing TADS itself, as well as for
installing games using the installer created by MKSETUP or through
the Workbench "Compile Installer" command) now accepts bacsklashes
in the "Program Folder" setting that the user enters during the install
process.  In the past, Setup treated backslashes as invalid characters,
and simply converted them to underscores.  The installer now accepts
backslashes as path separators, allowing the user to place the
installed software in any submenu within the Start menu.

<li>The Windows debugger now responds to the left and right arrow keys
while the local variable and watch windows are active.  In these
expression list windows, the left arrow key closes the sub-list of
the current item if it's open, otherwise moves to the parent item;
the right arrow key opens the sub-list of the current item if it's
closed, otherwise moves to the first child, if any, or the next
item, if not.  These keys provide a more convenient keyboard interface
to the expression list windows, and is more consistent with Windows
conventions for this type of window.

<li>The Windows debugger now responds to function key F2 in an expression
editor window by activating the currently selected expression or value
for editing, for consistency with Windows conventions.

<li>The Windows interpreter is now much less intrusive when
it discards old text during a long game.  In the past, whenever the
interpreter discarded old text to save memory, the interpreter
cleared the text window then re-drew all of the text after a short
delay.  Since this usually happens with a frequency of every thirty
to fifty turns after playing for a while, the screen clearing could
be quite annoying.  Starting with this version, the interpreter no
longer clears the screen while it's working.  In most cases, this
makes text disarding almost invisible; most of the time, you'll
probably notice nothing more than a brief flash of the "Working"
message in the status line.

<li>The interpreter now shows the active game file in the window title.
In the past, the interpreter's window title only changed when a game
explicitly set it using the &lt;TITLE&gt; tag.  The title now reflects
the ".gam" file name if the game doesn't specify a &lt;TITLE&gt; tag.
This is especially helpful if you're switching among different games
in the course of a single session.

<li>Fixed a bug in the &lt;TAB&gt; tag.  When &lt;TAB MULTIPLE&gt; was
specified, with no value specified or with a value of zero for the MULTIPLE
attribute, the Windows interpreter crashed.  This has been corrected;
an unspecified MULTIPLE value or a MULTIPLE value of zero is now treated
as through MULTIPLE were set to 1.

<li>Fixed a bug in the <tt>clearscreen()</tt> function.  In past
versions, if the game called <tt>clearscreen()</tt> after displaying
some text containing an HTML tag sequence near the end, and the text
did not end with a newline of some kind (a <tt>"\n"</tt> or
<tt>"\b"</tt> sequence), the interpreter occasionally would display
part of the HTML tag as plain text.  This should no longer occur.

<li>Fixed a bug in the Windows interpreter that caused a crash under
certain very obscure circumstances.  In particular, if you activated
another application while the interpreter was running, and brought up
a dialog (such as a file selector dialog) so that the dialog was
directly over the interpreter's main window, then did something to
dismiss the dialog that involved a mouse double-click (for example,
double-clicking on a file in the file selector dialog), the interpreter
would sometimes crash.  This has been corrected.

<li>Fixed a problem in Workbench for Windows that sometimes caused
compiler error messages in the Debug Log window to be split over two
lines.  When this happened with the line break in the middle of the
filename portion of the message, double-clicking on the message to
go to the error line in the source file didn't work: Workbench
couldn't read the complete filename from the log window, because the
filename was broken up over two lines.  This has been corrected; each error
message will now always appear on a single line.

<li>A bug in the Windows interpreter prevented a stand-alone game
executable from starting properly if the user set the preferences so
that the interpreter didn't ask for a game at startup ("ask for a
game to open on starting HTML TADS" on the "Starting" page of the
preferences dialog).  This has been corrected.


</ul>

<p>
<hr>
<h3>Changes in version 2.5.1</h3>

<ul>

<li>The Windows HTML TADS Interpreter now uses a fixed palette
(sometimes called a "rainbow" or "color cube" palette) when the video
hardware is set to display 8-bit (256-color) graphics.  In past
versions, the Windows interpreter dynamically set the hardware
palette according to the images that were displayed, allocating the
256 available palette colors according to the order in which the
images were displayed; while this optimized color fidelity for some
images, it sometimes gave poor results when multiple images with very
different color schemes were displayed simultaneously.  The new fixed
palette is designed to give reasonably good results for a wide range
of images; because the palette is fixed, the order in which images
are displayed will no longer affect their appearance.  Note that this
change only affects 256-color display modes; when the video hardware
is set to display 16- or 24-bit color ("65536 colors" or "True Color"
in the Display Properties control panel), the interpreter does not
use a palette at all, since it can display all of an image's colors
directly.

<li>On the Windows interpreter, keyboard focus now stays
in the main input panel more consistently.  In past versions, clicking
in a banner moved focus to the banner, making it necessary to
click back in the main input panel to enter a command.  Input focus
now moves back to the main panel after any click in a banner,
except when you select a range of text in the banner, in which case
focus stays in the banner until you explicitly click in the main
text panel or clear the selection in the banner.  (Focus stays in
a banner with a selection so that you can use the Ctrl+C keyboard
command to copy the selection.)

<li>The Windows interpreter in the past acted as though the player
had responded to a "MORE" prompt whenever the <tt>timeDelay()</tt>
function was used to pause the game.  This no longer occurs.

<li>Fixed a problem in the interpreter that omitted the
display of a game's closing message in certain cases.  When the
interpreter's preferences were set so that the interpreter continued
running after quitting the game, any message that the game attempted
to display after its last line of input was not visible (for example,
a closing message after a QUIT command was not shown).  This has been
corrected; any closing message from the game is now properly displayed.

<li>On the Windows interpreter, the <tt>systemInfo()</tt>
built-in function incorrectly reported that MPEG Audio was not
supported.  This has been corrected.

<li>On the Windows interpreter, the <tt>morePrompt()</tt>
built-in function incorrectly displayed the text "[More]" in the main
output window, rather than using the normal "More" prompt (as selected
in the preferences).  This has been corrected.

<li>The interpreter showed a horizontal scrollbar unnecessarily in
certain cases when a game displayed tables containing long lines of
text, even when the lines were wrapped within the table cells.
This has been corrected.

<li>Fixed a bug in the interpreter that prevented
&lt;BANNER REMOVALL&gt; sequences from working correctly under
certain conditions.  This has been corrected.

<li>On the Windows interpreter, if you displayed a banner
with its height set to 100%, the interpreter made the banner too tall,
so that it covered the status line.  This has been corrected.

<li>On the Windows interpreter, the "More" prompt is no longer
displayed if the main text panel is very tiny.  This will improve the
display behavior for games that use full-window banners to achieve
special effects (especially animation effects) by suppressing the
unnecessary "More" prompts that this type of effect generated in the
past.

<li>The mechanism that discards old text during long game sessions has
been improved slightly to make the text discarding more consistent.
In past versions, the system sometimes waited to discard any text until
the total text size was far over the limit set in the preferences, and
then discarded all or almost all of the old text.  The interpreter
should discard a much more reasonable amount of old text and do so
closer to the time the text starts exceeding the preferences limit.

<li>The Windows interpreter incorrectly discarded old text from
time to time even when the memory preference setting was "No Limit."
This has been corrected; all text is now retained with this setting.

<li>The Windows interpreter now displays the "Working" message in the
status line only during really long reformatting jobs.  In the past,
the "Working" message was displayed during any reformatting, so the
status line flashed a lot during game play, which was often distracting.
The "Working" message now only shows up after a couple of tenths of
seconds have elapsed during reformatting, which prevents the message
from flashing on and off during quick display operations.

<li>The Windows interpreter had a bug that caused various problems
if a new, non-HTML-aware game was loaded while an HTML-enabled game
was previously running.  This has been corrected.

<li>Fixed a debugger bug that caused a spurious error message
("attempting to free a locked object"), and in some cases a crash,
when the game used the <tt>delete</tt> statement to delete an object
which had at some point earlier been "opened" in an expression window
to show its property values.  This will no longer occur.

<li>Fixed a problem that made it impossible to terminate the game
by closing the main game window when the game was stopped at a "more"
prompt while running under the debugger.  In the previous version,
closing the game window at a "more" prompt made the debugger lock up
and stop responding; this no longer occurs.

<li>Fixed a bug in the debugger that caused Workbench to crash when
a game running in HTML mode caused an HTML parsing error, and the source
text near the error contained a "\)" sequence (to turn off highlighting,
using the traditional non-HTML formatting codes).  This has been
corrected.

<li>Fixed another debugger problem that caused a crash when breakpoints
were set in a source file containing no executable code at all.

</ul>

<p>
<hr>
<h3>Changes in version 2.5.0</h3>

<i>Released on July 10, 1999</i>

<ul>

<li><b>Important programming note:</b>
The Windows debugger now requires that you compile your game with
the new <tt>-ds2</tt> option.  Use this option instead of the 
traditional <tt>-ds</tt> option.  (The only difference between
<tt>-ds</tt> and <tt>-ds2</tt> is that the <tt>-ds2</tt> option instructs
the compiler to generate a new style of debugging information in your
game; the Windows version of the debugger, starting with version 2.5.0,
requires this new style of information, and will not work with games
compiled using the <tt>-ds</tt> option.)

<li><b>Another important programming note:</b> On Windows, the TADS
Debugger is now called "TADS Workbench."  I've changed the name
because the program is now more than just a debugger: TADS Workbench
is an integrated environment that lets you build your program as well
as debug it.  Refer to the <a href='wb/tadswb.htm'>TADS Workbench
help page</a> for details on the new features.

<li>The Windows HTML TADS interpreter now lets you load a new game
without exiting and restarting the interpreter.  You can select the
"Load Game" item from the "File" menu at any time to start a new
game.  Loading a new game immediately ends the current game,
so the interpreter displays a confirmation dialog when you select
this menu item if a game is already underway.

<li>The Windows HTML TADS interpreter offers new option settings
for the interpreter's action when first launched.  The new "Starting"
tab in the options dialog has these options:
   <ul>
   <li>Ask for a game to open on starting.  If this box is checked,
   when you launch the interpreter, it immediately displays an "Open"
   dialog asking you to select a game file.  If you uncheck this box,
   the interpreter will display the main game window, but take no
   further action on its own; to load a game, select "Load New Game"
   on the "File" menu.

   <li>Initial game folder.  This text field lets you choose the folder
   on your hard disk where the interpreter start the first time
   it displays an "Open" dialog.  If you usually store your TADS
   game files in a particular location on your hard disk, you can
   enter that folder here; whenever you start HTML TADS, the interpreter
   will automatically initialize the "Open" dialog to start in this
   location, saving you the trouble of navigating to the folder each
   time you run the interpreter.
   </ul>

<li>The Windows HTML TADS interpreter now offers option settings for
the interpreter's action after you quit the game (normally by entering
a QUIT command at the game's command prompt).  You can choose this
option in the "Quitting" tab of the options dialog.  The options are:
   <ul>
   <li>Wait for a keystroke, then exit.  This is the traditional
   action: after the game ends, the interpreter waits for you to
   press a key, then the interpreter program exits.  (The interpreter
   waits for you to press a key, rather than exiting immediately,
   so that the game window doesn't disappear before you have a chance
   to read any messages that the game displays as it ends.)

   <li>Keep running.  When you select this setting, the interpreter
   simply keeps running even after the game has ended.  To exit the
   interpreter, close the game window (by clicking on the game window's
   close box, or by selecting "Exit" from the game window's system menu).
   This setting allows you to start another game, using the "Load Game"
   item on the "File" menu, after a game has finished.
   </ul>

<li>The Windows HTML TADS interpreter now offers different option settings
for the interpreter's action when you close the game window (by clicking
the close box on the game window's title bar, or selecting "Close" in
the game window's system menu).  You can select the close action in
the "Quitting" tab of the options dialog.  The options are:
   <ul>
   <li>Send QUIT command to game.  This is the traditional action: when
   you close the game window, the interpreter simply acts as though you
   had typed QUIT into the game.

   <li>Prompt before closing window and exiting.  The interpreter will
   display a dialog box asking for confirmation that you really want to
   quit.  If you click "Yes," the interpreter will terminate the game,
   bypassing any prompt that the game would normally display at this point.

   <li>Close window and exit without prompting.  The interpreter will
   immediately close the game and exit when you click the game window's
   close box.  The interpreter will not prompt for confirmation, and will
   also bypass any prompting that the game would normally do upon quitting.
   </ul>

<li>The &lt;BANNER&gt; tag now accepts percentage values for the WIDTH
and HEIGHT attributes.  If you put a percent sign ("%") after the
WIDTH or HEIGHT value, the size will be a percentage of the main window
size.  This lets you scale a banner to the size of the main window.
Refer to <a href='htmltads/banners.htm#size_attrs'>Banner Size Attributes</a>
for full details.

<li>When a game is running in HTML mode, the <tt>yorn()</tt> built-in
function now displays the player's input in the input font set in the
preferences.  (In the past, the Interpreter did not switch to the
input font for <tt>yorn()</tt> in HTML mode.  The Interpreter has
always switched to the input font for <tt>yorn()</tt> as well as for
<tt>input()</tt> when the game was not in HTML mode, and continues to
do so.)

<li>"$$ABEND", the emergency abort command, now works properly in the
Windows HTML TADS interpreter.  This command was ignored in past
versions.

<li>The Windows debugger, now part of TADS Workbench, has a number of
new user interface features that make it easier and more convenient
to use:

<ul>

<li>You can now add or remove a breakpoint simply by clicking in the left
margin of a source line (the gray area to the left of the text).

<li>You can now reload your game file from disk
without quitting and restarting the debugger.  The "Reload Game File"
item on the "File" menu terminates the current debugging session and
reloads the game from disk.  If you're making numerous small changes
to your game as you run through it in the debugger, this new reload
option can be convenient, since it allows you to edit the source,
recompile the game, and reload it in the debugger without having to
exit and restart the debugger. Note: you should not attempt to
recompile your game at the same time that the game is running in the
debugger, since this could result in a file sharing conflict (the
compiler would attempt to overwrite the game file while it's in use
by the debugger); instead, you should quit the game first.  You can
leave the debugger itself running during compilation, but you should
be sure the debugger's title bar shows the "[game terminated]"
status; this indicates that the debugger is not using the game file.
After recompiling, use the "Reload Game File" command to load the
game back into the debugger for another run.

<li>You can now load a new game file without
quitting and restarting the debugger.  The "Load Game" item on
the "File" menu terminates the current game (if any) and loads a
new game.

<li>The special debugger windows that display the stack, local variables,
watch expressions, and call history now feature "docking" support, which
means that these windows can be attached to an edge of the main debugger
window.  This new feature gives you substantially greater power to customize
your display layout.  Look <a href='wb/dockwin.htm'>here</a>
for more information.

<li>The debugger now checks for modified source files each
time the main debugger window is activated.  If you edit and save a
source file with another program (your text editor, for example)
while the file is open in the debugger, the debugger will now offer
you the option to load the updated source file when you switch back
to the debugger window.  The debugger will display a prompt for each
source file that has been modified; you may choose to keep the old
version in memory or load the updated version.  Note that you'll
generally only want to load the new version of a source file if you've
also recompiled the game and then reloaded the game into the debugger;
if you merely edit a source file, but continue debugging the old version
of the compiled game, the source and compiled game would no longer be
synchronized, hence you wouldn't want to load a new source for the old
compiled game.

<li>Right-click on the background area of the main debugger frame window
(the "MDI client area") to pop up a menu of the special debugger windows.

<li>The debugger now has preference settings that let you control
which confirmation and notification dialogs that the debugger displays.
Some people like to be prompted for confirmation when a
command would have a possibly dangerous side effect, while others
would prefer the debugger to assume they know what they're doing.
The "Messages" tab in the debugger's "Options" dialog lets you turn
many of the debugger's notifications and confirmations on or off to
suit your working style.

<li>When you close the debugger (by closing the main debugger window
or by selecting the "Quit" item on the "File" menu), the debugger no
longer waits for a keystroke before exiting.  This extra pause at
exit served no useful purpose for the debugger, so it has been
removed.

<li>The debugger now obeys accelerator keys for debugging
commands (such Ctrl+F for "Find") when the debugger's main window is
active, even while the game is running.  (In past versions, the game's
accelerator keys were active at all times while the game was running
(rather than being paused in the debugger at a breakpoint or in
single-step mode), even when the debugger's main window was on top.
This was confusing and inconvenient.  The debugger's accelerator
keys now work any time the debugger's main window is active, whether
the game is paused in the debugger or is running, and the game's
accelerator keys are active any time the game window is active.)

</ul>

<li>Fixed a bug in the MKSETUP program (which builds an installer for
a game).  If the setup configuration file contained a FILE option (to
include an extra file in the installation file set), MKSETUP got stuck
in a loop adding the file over and over.  This has been corrected.

</ul>

<p>
<hr>
<h3>Changes in version 2.4.0</h3>

<ul>

<li>On Windows, in the "Options" dialog, the settings formerly
in the "Command Font" panel now appear in the "Fonts" panel, and the
"Command Font" panel has been removed.  In addition, the "Command
Font" popup list now offers a selection for "(Main Game Font)"; this
allows you to use the normal game text font, but still set the style
of the command input font (color, bold, italics) specially.  (The
separate checkbox for using the default game font has been removed,
since it's redundant with the new popup entry.)

<li>In version 2.3.0 on Windows, a bug in the "Options" dialog caused
the interpreter to crash if the "Command Font" tab in the dialog was
selected and the dialog was subsequently dismissed with the "Font"
popup showing no selection.  This has been corrected.

<li>In the Windows version, a new "Options" dialog page allows
setting the memory limit on previously-displayed text.  As text
scrolls off the top of the window, the interpreter keeps the text
in memory (and any related information, such as graphical images)
so that you can scroll the window back to review the old text.
During long game sessions, this can use up an excessive amount of
memory.  In version 2.3.0, the interpreter started automatically
limiting its memory usage to keep memory usage under control; the
interpreter had a fixed limit of 128 KBytes for the text buffer.
In version 2.4.0, the default limit has been reduced to 64 KBytes,
but you can now control this limit with the new "Memory" options
page.  This new options page allows you to select a lower setting.
If you frequently run low on system memory during long game sessions,
try setting a lower memory limit with this option page.

<li>On Windows, displaying PNG images in 256-color display modes is
now much faster.

<li>Fixed a bug in the pop-up evaluation system ("tooltip evaluation")
for the Windows debugger.
In version 2.3.0, multiple evaluation pop-ups sometimes appeared, and they
didn't all disappear correctly.  This should work correctly now.

<li>The Windows version is now somewhat smarter about adjusting the
scrolling position after the window is resized or reformatted.  In
particular, when the text is scrolled all the way to the bottom (as it
tends to be most of the time during play), and you resize the window,
the interpreter will keep the window scrolled to the bottom after the
resize.

<li>A bug caused the interpreter to fail to display any text after a
game program displayed an empty &lt;TITLE&gt; tag.  This has been
corrected.

</ul>

<p>
<hr>
<h3>Changes in version 2.3.0</h3>


<h4>Changes of interest to both players and authors:</h4>

<ul>

<li>The interpreter now produces a much more usable transcript (a
"script" or log file) for games that use HTML.  Script files are now
created as plain text files, with all of the HTML codes translated to
plain text where possible or removed entirely where not; the effect
is exactly the same as when the game is played through the text-only
version of the TADS interpreter.  In past versions, HTML codes were
passed through to the script file, which made the script file very
difficult to read.

<li>In the Windows version of HTML TADS,
the "Options" dialog has a new tab, "Command Font," that lets
you set the typeface, color, and style for text entered on
command lines.  If you click the checkbox for "normal game font,"
command lines will use the same typeface as the rest of the game;
if you uncheck this box, you can select the type style for commands.
Non-HTML games will always obey your settings; note, however, that
HTML-enabled games can override the input font, so some games may
not always use the preference setting.

<li>In the Windows version, when the mouse is hovering over an image,
the system now displays a small pop-up label (sometimes called a "tool
tip") showing the ALT text for the image.  Game authors can supply text
for the ALT attribute of each image to provide a textual description
of the image.

<li>The Windows version now limits the amount of old text that the game
keeps around during a session.  In the past, all of the text ever displayed
during a session stayed around until the end of the session, consuming
memory.  HTML TADS now discards the oldest text periodically, which
helps keep memory consumption under control.  The system still keeps lots
of old text, so players will continue to be able to scroll back through
the game transcript, but the amount of old text retained is now limited
to about 128k (which is, for example, enough to play all the way
through <i>The Plant</i> once, and then restart and play about
halfway through again).

<li>In past versions, HTML TADS did not obey the traditional highlighting
escape codes, "\(" and "\)", when not running in HTML mode (i.e., when
the game didn't display the "\H+" sequence to activate HTML).  This has
been fixed; standard TADS games that don't activate HTML mode will now
display highlighted text correctly.

<li>HTML TADS did not show tab sequences ("\t") correctly for non-HTML
games.  Rather than skipping to a tab stop, the system simply displayed
a few spaces, which in most proportional fonts did not create the
right effect.  This has been fixed; standard text-mode games will now
show proper tabs when played with the HTML TADS interpreter.

<li>Fixed a bug that caused old pages to display with an incorrect
background image.  In some cases, if clearscreen() was called, then
a background image was displayed (with &lt;BODY BACKGROUND=xxx&gt;),
then clearscreen() was called again, and after all of this the player
used the "Previous Page" command (on the "Go" menu) to look at the old
pages, the background image from the middle page could be displayed as
the background image of other pages in the history, even though those
pages were originally displayed without a background image.  This
has been corrected; old pages are now displayed with the correct
background image (or lack thereof).

<li>In past versions, when a banner was re-used for new contents, the
old contents weren't always completely erased from the window.  If the
new contents took up less space than the previous contents of the banner,
this left garbage on the screen.  This problem has been corrected; a
banner window is now completely erased when a new BANNER tag replaces
the contents of an existing banner window, leaving only the new contents
in the window.

<li>Fixed a bug in MIDI playback that caused problems with looping
MIDI sounds.  Symptoms of the problem were sporadic; in some cases,
the MIDI sound simply wouldn't repeat, and in other cases TADS caused
a GPF.  This problem has been corrected; looping MIDI sounds should
now play back reliably.

<li>WAV file playback occasionally "glitched," causing stuttered 
playback, looping playback, or random noise, or sometimes causing
sounds not to play at all.  These problems should now be corrected.

<li>Fixed a bug that occasionally caused problems displaying vertical
banners (that is, banners along the left or right edge of the main window).
In some cases, if the player restored a game, and the restored game
immediately displayed a left or right banner, the system incorrectly
set the size of the banner so that it took up almost the entire width of
the display window, leaving no space for the main text area.  This
has been corrected.

<li>On the Windows version, the entities &amp;Odblac; and &amp;odblac;
were reversed, so that &amp;Odblac; displayed a lower-case "o" with
double acute accent, and &amp;odblac; displayed an upper-case "O"
with double acute accent.  This has been corrected.

<li>The "MORE" prompt's wording on the Windows version has been changed
slightly; the prompt now advises players to press "the space bar" rather
"any key," because the "MORE" prompt did not in fact respond
to just any key, but only certain keys.  (The "MORE" prompt actually
responds to a few keys besides the space bar, such as the Return key and
the Page Up and Page Down keys, but the new prompt text is considerably
less misleading.)

</ul>

<h4>Changes of interest to authors:</h4>

<ul>
<li>The Windows version now supports MPEG 2.0 audio layers II and III
(usually referred to as MP2 and MP3 files, respectively).  For
more details refer to the <a href='htmltads/sound.htm#mpeg'>sound documentation</a>.

<li>Because the Windows version supports MPEG 2.0 audio layers II and III,
the <tt>systemInfo()</tt> function returns <tt>true</tt> for the new
feature codes related to MPEG: <tt>__SYSINFO_MPEG_AUDIO</tt>,
<tt>__SYSINFO_MPEG_AUDIO_2</tt>, and <tt>__SYSINFO_MPEG_AUDIO_3</tt>.

<li>The &lt;A&gt; and &lt;AREA&gt; tags now accept two additional
attributes that let you control how they enter their HREF commands.
See the section in "Deviations from Standard HTML"
on <a href='htmltads/deviate.htm#Achanges'>&lt;A HREF&gt;</a> for details.

<li>A new parameterized font, <tt>TADS-Input</tt>, lets the player
specify the typeface, color, and style for text entered on command
lines.  If you're not trying to achieve a special effect of some
kind during command entry, you're encouraged to use <tt>TADS-Input</tt>
as the font for all commands.  By default, std.t now activates this
font in the <tt>commandPrompt</tt> function; you can replace this
function definition with your own if you want to override this
behavior.  See the documentation on <a href="htmltads/deviate.htm#param_fonts">
parameterized font names</a> for details.

<li>The treatment of whitespace following &lt;P&gt; and &lt;BR&gt; tags
is now slightly different than it was in past versions.  In the past,
if a &lt;P&gt; or &lt;BR&gt; tag occurred at the end of a line of
source code, and more text followed on the subsequent source line,
HTML TADS rendered the text with a leading space on the second line.
This no longer occurs; HTML TADS now omits any spaces between these
tags and the subsequent non-blank text, so that the new line after
a &lt;P&gt; or &lt;BR&gt; tag starts without a leading space.  This
new behavior is more consistent with the way that TADS handles the
"\n" and "\b" sequences, and is also consistent with the way popular
web browsers render similar HTML mark-ups.

<li>HTML TADS now includes the normal bottom margin spacing in horizontal
banners.  In past versions, horizontal banners were too compressed
vertically because this space wasn't included in the way the formatter
calculated banner heights.  (If you've written a game that compensated
for this problem by adding some extra padding of your own, you might want
to remove the padding in future versions of your game.)

<li>The &lt;BANNER&gt; tag accepts a new attribute, REMOVEALL, that
indicates that <i>all</i> banners should be removed.  REMOVEALL does
not take a value; when this attribute is specified, no other attribute
(not even ID) is needed.

<li>If the &lt;BANNER&gt; tag was used to replace an existing banner, and
the new banner had different ALIGN or BORDER settings than those of the
original banner, the new settings were ignored.  This has been corrected;
the new banner's settings now replace any settings that were previously
in effect.

<li>In past versions, alignment settings in &lt;TD&gt; (table cell)
tags propagated to the first block within the cell, but not to any
additional blocks.  So, if you created a table cell which contained
more than one paragraph, the first paragraph was aligned correctly,
but subsequent paragraphs were aligned according to the enclosing
division's block alignment.  This has been corrected; any &lt;TD&gt;
alignment setting now affects every block within the cell.

</ul>

<p>
<hr>
<h3>Changes in version 2.2.6</h3>

<ul>

<li>The interaction between the <tt>inputkey()</tt> built-in function and
the automatic "MORE" prompt has been changed slightly to correct a problem.
In the past, the <tt>inputkey()</tt> function could retrieve keystrokes
even when a "MORE" prompt was being displayed, which could create confusing
situations when the text prompting for the keystroke had not yet been
scrolled into view itself.  This has been corrected; <tt>inputkey</tt>
will never retrieve a keystroke until any after pending "MORE" prompt has
been acknowledged.

<li>Very long sequences of characters with no intervening spaces sometimes
caused incorrect formatting in past versions.  This happened in particular
when long sequences of HTML entities appeared, such as twenty consecutive
<tt>&amp;nbsp;</tt> sequences with no intervening spaces (note that using
the backslash-space sequence instead of <tt>&amp;nbsp;</tt> produces the
same result).  This has been corrected.

<li>A bug that occasionally crashed the HTML TADS debugger has been fixed.
The crash sometimes occurred as the debugger attempted to take control
when a run-time error occurred in the game.

</ul>

<hr>
<h3>Changes in version 2.2.5</h3>

<ul>

<li>The &lt;A&gt; tag accepts a new attribute, PLAIN, that specifies that
any text within the link should be rendered as ordinary text, rather than
using the normal link attributes.  Refer to <a href='htmltads/deviate.htm#Achanges'>
&lt;A&gt; changes</a> for more information.

<li>In the preferences dialog, players can now select a fixed-width font,
if desired, for the main game font.  In the past, the main game font popup
only offered proportional fonts; there was no particular reason for this
restriction other than to reduce the size of the list to make it more
manageable; some people didn't like the restriction, so fixed-width fonts
are now included in the list as well.

<li>In past versions, the HTML interpreter did not always work properly when
started from a DOS command prompt.  In particular, if the command line
was specified using a <i>relative</i> path to the game file (for example:
<tt>htmltads games\mygame.gam</tt>), the interpreter did not properly load
resources (JPEG images, WAV sounds, etc.) bound into the .GAM file or
bound into a .RSn file.  This problem has been corrected; starting the
HTML interpreter from a command prompt should work properly now, regardless
of whether the .GAM file is in the current directory or a different
directory specified with a relative or absolute path.

<li>The <tt>inputkey()</tt> built-in function did not work correctly in
past versions of the HTML interpreter.  Although the function did wait until
the user pressed a key, the function did not return the correct value for
the key.  This has been corrected.

<li>In past versions, table cell tags did not accept WIDTH attributes
with percentage values.  Percentage-based cell WIDTH values are now
supported.

<li>Tables with empty cells (specified by a <tt>&lt;TD&gt;</tt> tag followed
immediately by another <tt>&lt;TD&gt;</tt> tag or a <tt>&lt;/TD&gt;</tt>
tag) were not always formatted correctly in past versions; these sequences
usually caused the entire table to be displayed at the wrong position.
This problem was particularly noticeable in banners.  This has been
corrected; empty cells are now handled correctly.

<li>A bug in the formatting of the &lt;BANNER&gt; tag caused a banner
to be displayed in certain situations even after a &lt;BANNER REMOVE&gt;
tag had been issued for the same ID.  This has been corrected.

<li>In the past, the traditional TADS non-breaking space sequence,
"\ " (a backslash followed by a space), did not work correctly in the
HTML TADS interpreter; in particular, multiple consecutive backslash-space
sequences were displayed as a single space.  This has been fixed.

<li>In previous versions, graphics placed in banners were not always
updated immediately after a palette change, which occasionally caused
brief drawing glitches.  This has been corrected.

<li>If the user selected "highlight on
hovering" in the link color settings in the options dialog, the interpreter
did not always remove highlighting from a link positioned very close
to the edge of a banner if the mouse was moved off of the link and into
another banner (or the main text window).  This works correctly now.

<li>A bug in past versions caused a crash on exit under obscure
circumstances: if the status line (or any other banner that was updated
after each turn) contained a link, and the mouse was positioned over the
link when the user typed "quit" and then left there, a crash sometimes
occurred.  This has been corrected.

<li>See <a href='../tadsver.htm'>Recent Changes to TADS</a> for
information about several generic TADS interpreter improvements and
corrections that affect the HTML interpreter as well:

 <ul>
   <li>A new parser feature lets you define new methods, <tt>dobjCheck</tt>
       and <tt>iobjCheck</tt>, that are <i>always</i> called before the
       verb handlers (<tt>verIo</tt><i>Verb</i> and so on).
   <li>The HTML interpreter now supports external (native code) functions;
       you can place native code into a DLL and call the code from within
       your TADS program.
   <li>A parser bug, involving using AGAIN with a command directed to an
       actor that is no longer present, has been fixed.
   <li>A parser bug caused incorrect prompts to be displayed when an unknown
       word was entered in a command that required an additional object;
       this has been corrected.
   <li>A parser bug that caused <tt>doSynonym</tt> and </tt>ioSynonym</tt>
       handling to work incorrectly with overridden methods is now fixed.
   <li>The <tt>init</tt> function is no longer incorrectly invoked prior to
       <tt>initRestore</tt> when restoring a saved game during start-up
       (for example, when you double-clicked the saved game from Explorer).
   <li>Backslashes in text captured by the <tt>outcapture()</tt> built-in
       function are now handled correctly.
   <li>An incompatibility with games compiled by old (pre-2.2.0) versions
       of the compiler has been corrected.
 </ul>

</ul>

<hr>
<h3>Changes in version 2.2.4</h3>

<p>
Here's a quick index to some selected highlights in
this release:

<ul>
<lh><a href="#OfInterestToPlayers">Of interest to players:</a>
<li><a href="#Installer">Automatic installation</a>
<li><a href="#AutoRestore">Restoring a saved game from the desktop</a>
<li><a href="#LinkHilite">New link highlighting preferences</a>
<li><a href="#NoGraphics">Turning off graphics</a>
<li><a href="#FileSafety">File safety levels</a>
<li><a href="#DirectX3">DirectX on Windows NT</a>
</ul>

<ul>
<lh><a href="#OfInterestToAuthors">Of interest to game authors:</a>
<li><a href="#charsets">Using extended characters</a>
<li><a href="#Banners">Banner enhancements</a>
<li><a href="#GameInstaller">Building a custom game installer</a>
<li><a href="#ExtResources">External resource files</a>
<li><a href="#ExeIcons">Changing stand-alone executable icons</a>
<li><a href="#SystemInfo">Getting system information</a>
<li><a href="#TypoChars">Typographical character changes</a>
<li><a href='#MdiTdb'>Debugger now uses MDI</a>
<li><a href="#Diags">Improved resource diagnostics</a>
<li><a href="#ParamFonts">Parameterized font names</a>
<li><a href="#ParamColors">Parameterized color names</a>
<li><a href="#StatusLine">Status line changes</a>

</ul>

<a name="OfInterestToPlayers"></a>
<h4>Changes of Interest to Players:</h4>

<ul>

<li><a name="Installer"></a>HTML TADS
is now distributed with a self-extracting installer.
Simply download the installer executable and run it; the setup program
will lead you through a brief series of dialogs to gather information
on how you want HTML TADS installed, and then will install the files
on your computer.  The setup program will automatically create file type
associations that will let you double-click on a .GAM file to start
it at run-time, and will also create associations that let you
double-click on a .SAV file to start the associated game and restore
the saved position.

<li>As part of the new setup procedure, the installer creates an
uninstaller program that you can use to remove HTML TADS from your
computer.  The uninstaller will remove all of the files, directories,
"Start" menu folders, and registry settings associated with HTML TADS.

<li><a name="AutoRestore"></a>The interpreter can now
automatically restore a saved game immediately
upon starting.  If you double-click a saved game (.SAV) file, the HTML
TADS interpreter will attempt to find the game that created the saved game
file, start the game, and immediately restore the saved position.  Refer
to the description of the new interpreter command line option "-r" in
<a href='../tadsver.htm'>Recent Changes to TADS</a> for more information.

<li>The "Preferences" dialog now provides an option to set the status
line color scheme.  This setting will control the status line colors
for all non-HTML games, and for HTML games that use the default status
line color scheme.  Some HTML-enabled games may not use the default
status line colors, and some may not have a traditional status line
at all, so the status line color preference settings will not affect
all HTML-enabled games.

<li><a name="LinkHilite">You can now
set hyperlink highlighting so that links are only
highlighted temporarily while you're holding down a key.  Some people
find links distracting if they're visible all the time, but still
want an easy way to see links at certain times.  The "View" menu now
has a "Link Highlighting" submenu for setting the visibility of links.
You can turn link highlighting entirely on or off as before, and in
addition you can set links to highlight only when the Ctrl key is
being held down.  Note that you have to hold down the Ctrl key a short
time before the links are highlighted; this slight delay is intended
to avoid distracting redrawing when you're just pressing the control
key to activate an accelerator command.

<li>In addition to providing momentary spring-loaded link highlighting
via the control key as described above, you can now quickly switch back
and forth between having link highlighting on and off via the F5 key.

<li>The interpreter now allows you to click on a link even when the game
is in "MORE" mode (which means that the game has displayed too much
text to fit in the window, and is waiting for you to press a key to
scroll down through the extra text).  In the past, the interpreter disabled
links while in "MORE" mode, because we felt that it could be confusing
to let the user click on a link when no command prompt was showing.
Unfortunately, visible but inactive links have proved to be even more
confusing.  Now, the interpreter keeps links active even while in "MORE"
mode.  If you click on a link while in "MORE" mode, the interpreter
scrolls to the bottom of the pending text, then enters the link command
as normal.

<li><a name="NoGraphics"></a>For
players who prefer the traditional text game experience
and find graphics distracting, but still like the text
formatting power of HTML, the interpreter has a new option that
lets you turn off graphics.
The "Graphics" item on the "View" menu lets you toggle graphics on
and off.  When the "Graphics" menu item is unchecked, HTML TADS
will display only text.  Any &lt;IMG&gt; tags that include an ALT
attribute will be displayed as text using the value of the ALT
attribute; other &lt;IMG&gt; tags will simply not be displayed
at all.  Other tags that can optionally incorporate graphics, such
as &lt;LI&gt; and &lt;HR&gt; will be displayed in their normal
non-graphical format, and background images (specified via
the &lt;BODY BACKGROUND&gt; tag) will not be displayed.

<li><a name="FileSafety"></a>The interpreter now provides a "file
safety level" setting, which allows the player to specify exactly
what types of explicit file I/O operations a game can perform.  This
setting is available from the command line, and is also available
through the "Preferences" dialog.  Refer to <a
href='../tadsver.htm'>Recent Changes to TADS</a> for details about
this new setting.

<li>The interpreter now provides a preference setting controlling how
the Alt+V keystroke is interpreted: you can set Alt+V to scroll up
a page (as some Emacs and similar editors behave), or to use the
normal Windows treatment as a menu shortcut.  (In the past, the HTML
TADS interpreter always interpreted Alt+V as an Emacs-style "page up"
key, which non-Emacs users didn't like.  The new default setting
treats Alt+V as a conventional Windows menu shortcut key.)

<li>While playing a game, the F1 key now enters the command "help"
on the command line, for processing by the game.

<li>The HTML TADS interpreter now uses large
memory settings (for -mh and so on) by default.  This allows you
to play extremely large games without having to use special memory
options when starting the interpreter.  The new default settings for
the HTML TADS interpreter are:

  <ul>
    <li>-mh 65535 (heap size)
    <li>-ms 512 (stack size)
    <li>-u 60000 (undo size)
  </ul>

The debugger limits have been similarly increased.

<li><a name="DirectX3"></a>HTML TADS
now supports DirectX version 3 for digitized sound
playback (version 5 was previously required).  This is especially
important for Windows NT version 4 users, because DirectX 3 is the
latest version available for Windows NT 4, and Microsoft has not
announced plans to support a higher version for NT users until NT 5
is released.  Windows 95 users are still encouraged to upgrade to
DirectX 5 if possible, because it provides more efficient sound
playback; however, all features are supported using DirectX 3.

<li>On startup, HTML TADS now displays a warning dialog if
DirectSound initialization fails (which usually simply means
that DirectX isn't installed), to clarify why
sound isn't working.  The dialog provides a checkbox to indicate
that you don't want to see it on startup in the future, so that
you can skip the warning if you're never planning to install DirectX.
If you select the View/Sound Effects menu item after DirectX
initialization failed, the interpreter will display the dialog
again (even if you've selected the checkbox to hide it on startup).

<li>On startup, HTML TADS checks to ensure that you have the correct
version of a required system file, ComCtl32.DLL, installed on your
system.  (This file is included with Windows 95 and NT, but some
versions of the operating systems included an older version of
this file that is incompatible with HTML TADS, which requires
version 4.70 or later.)  If the incorrect version of the DLL is
installed, HTML TADS displays a warning dialog; the dialog allows
you to proceed despite the problem, but this will usually make
HTML TADS work incorrectly (and the program will probably crash).
If you see this warning, you should upgrade your DLL by downloading
and running this file from the Microsoft web site:
<a href='ftp://ftp.microsoft.com/softlib/mslfiles/com32upd.exe'>
ftp://ftp.microsoft.com/softlib/mslfiles/com32upd.exe</a>.
I'd like to thank Klywarre (The Avatar) [aka: James Mallette]
for discovering the DLL incompatibility and tracking down the
solution.

<li>This version corrects several problems related to the "Next Page"
and "Previous Page" navigation items on the "Go" menu.  The following
are all fixed:
<ul>
<li>A bug caused crashes in some games when
using the "Next Page" and "Previous Page" navigation items on the "Go"
menu.
<li>There were a couple of small problems involving
the placement and visibility of the insertion point (the text caret) when
using these same navigation items.  
<li>After clearing the screen, if the game immediately displayed a large
amount of text on the new page, the "More" prompt was not properly
displayed.
<li>When returning to a page with the "Previous Page" navigation command,
the window always displayed the page scrolled to the top.  The window now
remembers the scrolling position that was in effect when the page was last
viewed and restores that position.
</ul>

<li>The title bar now displays "HTML TADS" for games that don't explicitly
set the window title (it was "TADS HTML").

</ul>

<a name="OfInterestToAuthors"></a>
<h4>Changes of Interest to Game Authors:</h4>

<ul>

<a name="charsets"></a>
<li>TADS now offers improved support for localized character sets.
In particular, TADS provides a way to use extended (non-ASCII) characters
in a game while retaining game portability.  This new TADS feature is
supported in HTML TADS as well.  Refer to the
<a href="charmap.htm">character set notes</a> for more information.

<li><a name="Banners"></a>The
BANNER tag has been extended to allow banners to be placed
at the top, bottom, left, or right edges of the window.  Refer to
the new <a href='htmltads/banners.htm'>banner documentation</a> for details.

<li><a name="GameInstaller"></a>A new utility lets you build a
custom installer for your game, without any programming.
Refer to the <a href='htmltads/dist.htm#build_setup'>game distribution
documentation</a> for details.

<li><a name="ExtResources"></a>A
game author can now optionally create multiple resources bundle
files, separate from the .GAM file, for distributing a game and its
resources separately without having to distribute the individual
JPEG, WAV, and other files.  This new mechanism allows game authors
to distribute their games in multiple configurations, so that players
can choose how much of a game they want to download and install.
This new mechanism is described in the
<a href='htmltads/res.htm#ExternalResfiles'>resource file documentation</a>.
Note that this new feature requires the TADS resource manager
(<tt>tadsrsc</tt>) version 2.2.4 or higher; the resource manager
accompanies the TADS compiler and tools distribution.

<li><a name="ExeIcons"></a>If
you build a stand-alone executable version of your game based
on the HTML TADS interpreter, you can now specify the desktop icon that
your executable uses.  You specify this with the <tt>maketrx32</tt>
command when you build your stand-alone game.  Refer to the
<a href="htmltads/dist.htm#maketrx32">game distribution documentation</a> for
more information.

<li>If you build a stand-alone executable version of your game based
on the HTML TADS interpreter, you can now specify a custom filename suffix
(extension) to use for saved game files created by your game.  If you
do this, the stand-alone game will automatically create system registry
entries that associate the saved game files with your stand-alone game
executable, allowing the player to start your game and restore a saved
position in a single action by double-clicking on a saved game file.
Refer to the <a href="htmltads/dist.htm#save_suffix">game distribution
documentation</a> for more information.

<li><a name="SystemInfo"></a>The new
TADS <tt>systemInfo()</tt> built-in function provides a way for
you to determine in your game code whether the interpreter which is
executing your game has certain capabilities, including whether
HTML can be used to format text.  This function can
be especially useful if you want to customize your game for
different interpreter configurations.  Refer to
<a href='../tadsver.htm'>Recent Changes to TADS</a> for details.

<li>TADS has a new parser hook that gives you more control over how
the TADS parser handles unknown words in player commands.  Refer to
<a href='../tadsver.htm'>Recent Changes to TADS</a> for full details.

<li>TADS has a new language feature that lets you specify the
superclass from which you want a method to inherit when you use the
<tt>inherited</tt> keyword.  Refer to <a href='../tadsver.htm'>Recent
Changes to TADS</a> for information.

<li>TADS now allows you to change the object that represents the player
character dynamically, using the new <tt>parserSetMe</tt> built-in function.
<a href='../tadsver.htm'>Recent Changes to TADS</a> has details.

<li>HTML TADS now supports the &lt;Q&gt; tag from HTML 4.0.  This
tag encloses a passage in quotation marks.  &lt;Q&gt; automatically
uses typographical quotation marks if they're available in the
character set.  Nested &lt;Q&gt; tags alternate between double
and single quotes.

<li><a name="TypoChars"></a>The
typographical character extensions have been changed for
compatibility with HTML 4.0, which includes the same characters
with different names than were originally assigned by TADS.
The following character names have been changed to match the HTML 4.0
specification:

 <ul>
   <li>&amp;lsq; has been changed to &amp;lsquo;
   <li>&amp;rsq; has been changed to &amp;rsquo;
   <li>&amp;ldq; has been changed to &amp;ldquo;
   <li>&amp;rdq; has been changed to &amp;rdquo;
   <li>&amp;emdash; has been changed to &amp;mdash;
   <li>&amp;endash; has been changed to &amp;ndash;
 </ul>

Note that the old character codes are still allowed, but they're no
longer documented and should be considered obsolete.

<li>The following new special character codes from HTML 4.0 have been added.

  <ul>
    <li>&amp;sbquo; produces a single low-9 quote
    <li>&amp;bdquo; produces a double low-9 quote
    <li>&amp;lsaquo; produces a single left angle quote
    <li>&amp;rsaquo; produces a single right angle quote
    <li>&amp;dagger; produces a dagger
    <li>&amp;Dagger; produces a double-dagger
    <li>&amp;OElig; produces a capital "OE" ligature
    <li>&amp;oelig; produces a small "oe" ligature
    <li>&amp;Yuml; produces a capital "Y" with an umlaut (diaeresis)
    <li>&amp;Scaron; produces the capital letter "S" with a caron
    <li>&amp;scaron; produces the small letter "s" with a caron
    <li>&amp;permil; produces a per-thousand sign
  </ul>

<li>In addition to the special characters listed above, HTML TADS now
supports all of the HTML 4.0 named character entities listed in the
HTML 4.0 specifications as "symbols, mathematical symbols, and Greek
letters."  This list is not reproduced here because of its length,
but you can refer to the 
<a href="http://www.w3.org/TR/REC-html40/sgml/entities.html">HTML 4.0
specification</a> for the full list.  The only named character entities
that HTML TADS does not support are the spacing and joiner entities
(ensp, emsp, thinsp, zwnj, zwj), and the bidirectional markers (lrm, rlm).

<li>HTML TADS now provides an additional set of named character entities
to provide access to ISO Latin-2 characters.  ISO Latin-2 is a character
set designed for Eastern and Central European languages.  Standard HTML
does not yet provide named entities for these charaters, but HTML TADS
extends the standard entity list to support these additional characters.
Refer to the <a href="htmltads/latin2.htm">HTML TADS Latin-2</a> table for the
complete list.

<li>You can now enter hex digits in character entities by putting an
"x" after the "#"; for example, "&amp;#xF3" enters the hex value
F3.

<a name='MdiTdb'></a>
<li>The Windows HTML TADS Debugger now uses MDI (Multiple Document
Interface).  MDI is a common Windows application style in which all
of an application's windows are grouped together into a single container
window.  The MDI style is well suited for applications such as the
Debugger that have a large
number of related windows that share common user interface controls,
such as toolbars and menu bars.  Many users found the original Debugger
user interface to be unwieldy, because the various windows weren't
grouped together.

<li>The Windows version of the debugger will now ask you to locate
source files as it needs them, rather than requiring that all of the
proper include paths be specified on the command line.  Whenever
the Windows debugger needs to open a source file, and the file isn't
in the .GAM file directory or anywhere on the include path, the
debugger will display a dialog asking you to locate the
source file.  In addition, the debugger saves the list of directories
obtained in response to these prompts with the per-game configuration
information (in the game's .TDC file), so these settings are retained
in future sessions.
(Note that the DOS character-mode debugger still operates as before,
requiring source files to be on the include path at start-up.)

<li>The Windows version of the debugger now lets you access the
main debugger window's menu through the keyboard interface (using
the Alt key) even while one of the other debugger windows is active.

<li>The Windows version of the debugger now displays the game status
(running, paused, terminated) in the main debugger window's caption.

<li>In a source file window in the Windows version of the debugger,
certain keystrokes are now handled slightly differently, to make the
handling more consistent with other Windows programs.  The Home and
End keys now move the cursor to the start and end of the current line,
respectively; Control+Home goes to the start of the file, and 
Control+End goes to the end of the file.  Page Up and
Page Down now move the cursor up and down a page; Control+Page Up and
Control+Page Down scroll the window without moving the cursor.

<li>To accomodate the editing key changes above, the Control+Home key
no longer goes to the current line, but now goes to the start of the
file.  The Alt+Keypad * key now goes to the current line.

<li><a name="Diags"></a>For
game developers' use, the interpreter now displays diagnostic
messages in the debug log window for resource loading problems.
Whenever a JPEG, PNG, WAV, or MIDI resource cannot be loaded or
encounters an error, the interpreter displays information about the
problem in the debug log window.  (Note that the debug log window
is only shown if you run with <tt>-debugwin</tt> specified on the command
line when invoking the interpreter.  These messages won't interfere
with the main game window.)

<li>This version corrects a few bugs with tables:
   <ul>
   <li>Under certain circumstances, using alignment attributes in TR
       or TD tags caused the alignment settings to continue beyond
       the table.
   <li>If a table was the very first item in a banner, the table was
       invisible.
   <li>If a table had an explicit height specified (with a HEIGHT attribute
       on the TABLE tag), the height was ignored.
   <li>A table whose WIDTH setting exceeded the maximum width actually
       necessary to display the table sometimes ignored the width setting.
       (This only happened when the table had simple contents, such as
       columns that only contained single words or pictures.)
   </ul>

<li>Some bugs involving banners are now fixed:
  <ul>
  <li>If you used multiple banners, the status line was not always
      updated properly when the player moved the mouse cursor over 
      a link.
  <li>A text link appearing in a banner did not always use the correct color.
  </ul>

<li>This version corrects a problem with the debugger that caused the
debugger to crash sometimes when you single-stepped through code at the
very end of a source file.

<li><a name="ParamFonts"></a>
The FACE attribute of the FONT tag now accepts a set of new "parameterized"
font names.  The new parameterized fonts do not directly select a system
font by name, but instead select a <i>style</i> of font that can be mapped
to an appropriate installed font on each system.  Because the parameterized
font names are mapped at run-time on each system, parameterized names are
much more portable than explicit system font names while still providing
you with some flexibility in specifying different styles.  In addition,
some systems allow the player to select the actual system font that will
be displayed for a given parameterized font, thus giving greater control
over the final presentation to the player while still giving considerable
control over the style to the game author.  Refer to
the <a href='htmltads/deviate.htm#param_fonts'>HTML deviations documentation</a> for
full details.

<li><a name="ParamColors"></a>In addition to the
standard HTML color names and numerical RGB values, the HTML parser now
provides a set of new "parameterized" color names.  The parameterized
values do not map directly to hard-coded colors, but instead use
system-dependent colors that the player can change at run-time on
some systems.  For example, the new color names "statusbg" and "statustext"
are system-defined colors for the status line background and status line
text, respectively; on Windows, the player can control the values of these
colors through the "Preferences" dialog.  You can use the new parameterized
color names in any of the tag attributes that take a color value.
Refer to the <a href='htmltads/deviate.htm#colors'>HTML deviations documentation</a>
for full details.

<li><a name="StatusLine"></a>The
HTML status line code in <tt>adv.t</tt>, which is enabled when
you compile your game with the preprocessor symbol <tt>USE_HTML_STATUS</tt>
defined, now automatically senses whether the game is running in HTML mode
or in standard mode, and generates an appropriate status line for the
current mode.  This makes it easier to write a game that will run under
both HTML and standard interpreter systems, while still taking advantage of
HTML features when they're available.  The enhanced status line code uses
the new <tt>systemInfo</tt> built-in function, described in
<a href='../tadsver.htm'>Recent Changes to TADS</a>,
to sense whether HTML featuers are available at run-time.  Note that,
even if you customize the status line, you may want to refer to the
new <tt>adv.t</tt> status line code and use similar logic in your custom
implementation, to support both types of interpreters.

<li>The default status line color scheme in <tt>adv.t</tt> now uses
the new "statustext" and "statusbg" parameterized color attributes,
which makes the status line colors controllable through the player
preferences (for platforms that provide a preferences mechanism).

<li>TADSERR.MSG (the TADS error message file) is now linked directly
into the interpreter, so the separate message file is no longer needed
when playing or distributing a game.

<li>Some small documentation problems have been fixed:
  <ul>
  <li>the link from the introductory page to the debugger page is fixed
  <li>the debugger page is now part of the normal interpreter distribution
  <li>the debugger page no longer has its last few paragraphs in boldface.
  </ul>

<li>Some cosmetic problems have been fixed:
  <ul>
  <li>The HTML TADS interpreter and debugger "About" boxes now display
      the TADS version number
  <li>The usage messages for the HTML TADS interpreter and debugger now
      display their correct executable names
  </ul>

</ul>