Recent Changes to HTML TADS

Interim build 2.5.8/3.0.6p: 4/25/2004

• In the past, the HTML interpreter didn't stop with a MORE prompt in a banner window if a long block of text was displayed, the banner was cleared, and then another long block of text was displayed. This could be seen, for example, in some "chapter list" menus in TADS 3 games, by stepping through a series of long chapters. This has been corrected.
• The HTML interpreter now accepts .JPE as a valid suffix for JPEG image resources. The suffixes .JPG and .JPEG are also still recognized, of course.
• The Windows HTML interpreter did not properly initialize the size of a new banner window that didn't yet have a size explicitly set or any text displayed, occasionally causing a new banner window to appear at a random size if the game didn't explicitly set the size soon after creation. This has been corrected; a new banner window is initially set to zero width and height, ensuring that it won't be visible until the game finishes setting it up properly.

Interim build 2.5.8/3.0.6o: 3/14/2004

• A problem with vertical spacing after a command line, caused by a change in 3.0.6n, has been corrected. In 3.0.6n, a &zwnbsp; character was added after each command line. This proved to be a problem if a "\b" sequence was displayed after a command line, because it caused two blank lines to appear in the display window (the extra line was the one containing the &zwnbsp; character). So, the &zwnbsp; has been removed. In its place, a refinement of the pre-3.0.6n mechanism is now used: after each command input line, and only after a command input line, the interpreter simply adds an extra line's worth of scrolling height to the window. This has the desired effect of scrolling up the window one line after each user input, which provides the user with immediate visual feedback that the command line has been accepted, while eliminating the undesirable side effects of both the 3.0.6n change and the pre-3.0.6n mechanism.
• The HTML interpreter now treats multiple calls to the T3 function inputLineCancel() as significant. This is important in cases where several calls are made with the "reset" parameter set to nil, and later a call is made with "reset" set to true. In the past, calls were ignored if an interrupted input was not still pending, so only the first call after an interrupted input was obeyed. This meant that it was impossible to reset the input buffer if the input had already been canceled but not reset. This has been corrected.
• TADS 3 Workbench for Windows now inherits the TADSLIB environment variable, if set, and passes it along to the compiler. This allows you to add directories to the library file search path globally. The library folder list you specify in the Workbench options comes before the TADSLIB environment variable in the search order; that is, the compiler will first look for a library file in each folder specified in the Workbench options, and then will turn to the folders listed in the TADSLIB environment variable.

Interim build 2.5.8/3.0.6n: 3/6/2004

• Workbench for Windows now remembers whether or not the source file window has been maximized (within the main work area in the Workbench window), and restores the same status when the project is reloaded in future sessions.
• Workbench for Windows now stores the debugging image file name using a directory path relative to the project directory, if possible, even if you enter the filename with an absolute path in the build settings dialog. This makes it easier to move the project from one machine to another, or relocate it to a different folder on the same machine. (In the past, this filename was stored with a relative path in most cases, but Workbench didn't force it to a relative path if you manually entered an absolute path. Workbench now automatically changes the filename to use a relative path even if you enter an absolute path.)
• In the past, the HTML interpreter always showed some extra blank space below the last line of text if the last line ended in some sort of line-breaking markup sequence (such as a paragraph break, or the end of a <TABLE> tag). This was intentional, to provide better feedback to the player when the player pressed the Enter key at the end of a command line, but had the undesirable side effect of leaving extra blank space when merely pausing for input. The extra space is no longer shown. If you want to show extra space at the bottom of a display when pausing, you can do so by displaying line breaks to the desired height, then displaying a "&zwnbsp;" character (a zero-width non-breaking space), which has no visual appearance of its own but forces the HTML renderer to immediately show all of the extra space preceding the character. The interpreter itself now uses this trick to achieve the effect that was formerly achieved with the now-defunct extra vertical spacing.
• In the Windows HTML interpreter, the hyperlinks in the "About" box are now shown even when the preferences are set to hide hyperlinks. Similarly, the hyperlink to return to the Game Chest page after a game has ended is now shown as a hyperlink, regardless of the preference settings. (In the past, these controls followed the preference settings for hyperlink visibility; since they're part of the interpreter user interface, not part of the game text, it makes more sense for these controls to override the preference settings and show as hyperlinks unconditionally.)
• The HTML renderer sometimes got the margins wrong on the initial layout if a "floating" image was at or near the start of the layout. The correct margins displayed on subsequent redraws in these cases, but the initial layout sometimes had negative margins, which left some text partially outside the main window. This has been corrected.
• In the past, TADS 3 games compiled into Windows executables (.exe files) didn't load bundled multimedia resources (images, sounds, etc.) properly. This is now fixed.

Interim build 2.5.8/3.0.6m: 11/15/2003

• The HTML interpreter now supports the BACKGROUND attribute in TABLE, TH, and TD tags. This attribute sets the background image for a table or a cell within a table. If the image is larger than the bounding rectangle of the table or cell, the interpreter clips the image to the table or cell size; if the image is smaller than the bounding rectangle, the interpreter "tiles" the image, drawing as many copies of the image across the width and/or down the height of the bounding rectangle as are needed to fill the space.
• In Workbench for Windows, if the game program was waiting for a keystroke (via inputKey() or the like), and you tried to terminate the program (by starting a new build, for example), Workbench got stuck in a loop trying to terminate the game. The game program will be terminate correctly now.
• The Windows HTML interpreter's "mute" button on the toolbar now uses two icons, one for when sounds are on and one for when sounds are muted, showing the current status. The old icon looked too much like a status icon indicating that the sound was always mute.
• The HTML parser now accepts closing </BODY> tags. Since the special TADS dialect of HTML doesn't treat <BODY> as a container, it's never necessary to include closing </BODY> tags, and if you do, they interpreter simply ignores them. In the past, though, the parser didn't accept </BODY> tags at all (it flagged an error), which caused some confusion among people who already know standard HTML, where <BODY> is a container.
• In Workbench for Windows, an incompatibility with Windows ME caused Workbench to crash under certain obscure conditions. The crash was due to a Windows API problem that appears to exist only in ME, and happened when using the "new project wizard" to create a new game, and then only when the Debug Log was the only window open. This problem has been corrected.
• The HTML interpreter had a problem that sometimes prevented a game's bundled resources from being loaded properly when several games were run in sequence in a single interpreter session. This is now fixed.
• A bug in the HTML renderer caused whitespace characters following a <Q> start or end tag to be ignored when a character entity (an "&" sequence) immediately preceded the tag. (This is a pretty rare combination of markups, so this hardly ever showed up in practice, but it's obviously perfectly valid.) The whitespace is now properly retained.

Interim build 2.5.8/3.0.6k: 8/17/2003

• Workbench for Windows now automatically converts any forward-slash characters ('/') to backslashes in filenames entered into the Build Settings dialog. (In the past, using forward slashes as path delimiters was allowed, but it caused odd behavior in certain cases, because Workbench treated forward slashes as distinct from backslashes for the purposes of comparing filenames and paths.)
• The HTML interpreter froze up if a table was displayed that contained no columns (no <TD> tags), but had a WIDTH setting for the table itself. This type of table is usually ill-formed anyway, in that the lack of any columns is probably due to missing table structure tags, but the interpreter will now gracefully accept such tables.
• The Windows HTML interpreter is a little better at deferring redraws when clearing the screen. This eliminates flicker in some cases, especially when a banner window is being added or removed right before or after the screen is cleared.
• The Windows HTML interpreter is better at handling MORE scrolling in very small windows. In the past, if a window was very small (around five or ten pixels high, for example), pressing the space bar could sometimes actually make the window scroll backwards. This has been corrected; even very small windows will handle MORE scrolling properly now.
• A bug in the HTML interpreter caused occasional drawing problems when first displaying certain tables. When a table had a large "cellpadding" or "cellspacing" value, one or two rows of pixels were sometimes not drawn when the table was first shown (but did redraw properly on subsequent refreshes, such as resizing the window). This is now fixed.
• A bug in Workbench for Windows caused a breakpoint marker (the little red circle in the left margin of a source file) to appear in the first source window when a global breakpoint existed. The spurious breakpoint marker will no longer appear.
• A bug in Workbench for Windows caused the program to open extra file handles open each time the application was activated. This has been corrected.

Interim build 2.5.8/3.0.6j: 8/2/2003

• Workbench for Windows now uses different window icons for the main Workbench window and for the game window, so that it's easier to tell which is which on the Windows taskbar or Alt-Tab window selector.
• Workbench for Windows has a new command (on the toolbar and in the Build menu) that terminates a build in progress. This is handy if you started a build accidentally and don't want to wait for it to complete. Note that interrupting a build can sometimes leave intermediate files (such as symbol and object files) incomplete, so if you interrupt a build, you might have to subsequently perform a full build to make sure everything is rebuilt properly.
• Workbench for Windows now offers the option of automatically clearing the Debug Log window before each new build. The option is on the Messages page of the options dialog ("View" menu, "Options..." command). Some people like to start each new build with an empty Debug Log window, to eliminate any clutter from past builds.
• TADS 3 Workbench for Windows now automatically clears the old list of Include files from the Project window when you use the "Scan for Includes" command. This ensures that the Include list contains all of the actual header files used in the project, and only those header files.
• The "New Project" wizard in TADS 3 Workbench for Windows now offers an option to create a bare-bones project that doesn't include the standard TADS 3 adventure library (adv3). This is convenient for creating special-purpose projects that don't require the full adventure library.
• In the Windows HTML interpreter, if the window was scrolled to the right, then resized so that the scrollbar wasn't needed any longer, then scrolled back all the way to the left, the horizontal scrollbar didn't always disappear as it should. It should now disappear reliably in these cases.
• A bug caused Workbench for Windows to crash when compiling a game, if the compiler wrote an extremely long message to the log window. This has been corrected.
• A bug in the HTML interpreter caused a crash when cutting and pasting long bits of text under certain circumstances. This is now fixed.
• The HTML interpreter now uses the <BODY> tag's BGCOLOR attribute even if a <BACKGROUND> image is also set. This ensures that the background color will show through any transparent sections of the background image.
• In the Windows HTML interpreter, right-clicking on a hyperlink will no longer follow the link; right-clicking now simply brings up normal context menu.
• In the Windows HTML interpreter, previous page viewing is more functional and flexible. The mouse wheel now works properly, you can use the Find command, and the window is properly refreshed if you change themes while viewing a past page.
• In Workbench for Windows, some of the keyboard accelerators (such as Ctrl+C for Copy, or Ctrl+Q for Quit) didn't work properly in the game window. This has been corrected.
• In Workbench for Windows, the "Windows" menu wasn't kept properly updated when source windows were maximized (so that the source windows took up the entire MDI "client area"). This is now fixed.
• A bug in the HTML interpreter occasionally left banner windows only partially redrawn; this was particularly apparent with things like hint menus. The problem has been corrected.
• In Workbench for Windows, the expression evaluation windows now accept a few more keystrokes, to make the keyboard interface a little more convenient. The Page Up and Down keys now scroll the window a page at a time, the Home key moves to the first row, and the End key moves to the last row. In addition, in the "watch" window, when no row is selected, starting to type an expression (or pressing Enter or F2) will automatically scroll to and select the empty last row; this saves a mouse click in the common case that you just want to add a new expression to the list when no other expression is selected.

Interim build 2.5.8/3.0.6i: 6/15/2003

• Due to a bug in a change made in the previous interim build, MORE mode didn't work properly in the Windows HTML interpreter. MORE mode works correctly again.
• Workbench for Windows didn't allow re-running the game if, in the course of running the game, a file selector dialog was used to navigate to a different directory. (On re-running, Workbench displayed an error dialog saying "VM Error: image file not found.") This is now fixed.
• The Windows HTML interpreter crashed on startup if the Game Chest file, as selected in the interpreter options, didn't exist. This crash has been fixed.
• In the Windows HTML interpreter, if you change the Game Chest file setting in the options dialog, and the new file you select doesn't already exist, the interpreter now automatically saves the current Game Chest contents to the new file. In the past, you had to copy your old file manually. If the new file you select does already exist, the interpreter will simply load the new file rather than overwrite it.

Interim build 2.5.8/3.0.6h: 6/7/2003

• The Windows HTML interpreter's user interface for setting display options (such as fonts and colors) has been slightly reorganized to make it more intuitive and easier to navigate. Some of the changes:
  • The term "Theme" is now used instead of "Profile"; this is more consistent with the prevailing Windows terminology.
  • The visual settings - fonts, colors, "MORE" style, media type enabling - have been separated into their own dialog, which can be accessed directly with the "Customize Theme" command on the new "Themes" menu, as well as from a toolbar button. This dialog is now called "Customize Theme," to make it more obvious that all of these visual settings are part of the current theme.
  • The main options dialog no longer has the tabs for visual settings, but it has a new tab, "Appearance." This tab lets you select the current visual theme, create new themes, and delete themes. This also has a button to open the visual settings dialog to customize the currently selected theme, and a button to reset the current theme to its "factory defaults" (but this button only works for the standard pre-defined themes, since only the built-in themes have defaults). The old dialog tab arrangement mixed the settings that are part of the visual theme and those that are simply global option settings; the new arrangement keeps all of the visual theme settings together in a separate dialog.
  • A new "Themes" menu has been added, and the theme-related items that were previously in the "View" menu have been moved to the new menu instead. This change is intended to make it more obvious which items are theme-related by grouping them on a single menu.
  • Several of the items formerly on the "View" menu (graphics, sound, music, link display mode) have been removed from the menu and added instead to the new "Media" page of the "Customize Theme" dialog. These options are all part of the theme; moving them to the dialog makes this much more obvious in the user interface. Most users hardly ever change these settings, so it seems unlikely that the extra step needed to open the dialog will noticeably inconvenience anyone.
  • The Windows HTML interpreter no longer uses the F5 key to toggle the hyperlink display mode. Some users found this keyboard shortcut to be too convenient, in it was too easy to hit the key unintentionally, resulting in an unexpected change in the link display mode; this was especially a problem for Workbench users, since the Workbench debugger uses F5 as the "go" button.
  • A new "Mute Sound" command (on the View menu and on the toolbar) lets you turn off all sound output. This doesn't actually disable playback of audio media types; it merely mutes the speakers temporarily. Playback or music and sound effects proceeds while muting is on, but with the volume control effectively turned all the way down. (In contrast, turning off sound or music on the "Media" tab in the Customize Theme dialog makes the interpreter behave as though it simply doesn't support the disabled media types. This is visible to games when they query the interpreter capabilities. Muting is not visible to games.)
• In the Windows interpreter, the list of recent games shown in the "File" menu now shows the title (instead of the filename) of each game that you've entered into your Game Chest favorites. Recent games that aren't in your Game Chest favorites list are still listed by filename.
• A bug in Workbench for Windows caused the "build for release" process to fail if the debug game file in the build settings was specified as going in a folder other than the main project folder (the one containing the .t3m file). (Yes, you read that right: the location of the debug game file caused problems creating the release game file.) This has been corrected; the release build should work properly now for any valid output directory settings.
• A bug in Workbench for Windows caused a spurious error code to be displayed in the release build process for the command that's included in the build sequence to delete the temporary directory created for the intermediate files created during the release build. The error code display was itself the error; the directory removal actually worked correctly, but Workbench showed an error anyway. The spurious error has been removed (but any actual errors that occur will still be displayed, of course).
• On Windows, a bug in the preference system caused preference settings to be saved incorrectly in certain situations. If more than one HTML TADS interpreter was running simultaneously, of if both the normal interpreter and Workbench were running simultaneously, and the games weren't all using the same profile (for example, if one game was using the standard "Multimedia" profile, and another was using "Plain Text"), then it was possible for the font and color settings of one of the profiles to be incorrectly saved over the settings for the other profile. For example, it was possible to make the Multimedia profile take on the settings of the Plain Text profile. These settings are saved in the registry, so once the wrong settings were saved, they stayed wrong until the user manually changed them back. This problem has been corrected; multiple interpreter windows won't interfere with one another (or with Workbench) any longer.
• When multiple HTML TADS interpreters are running simultaneously, if you make changes to the option settings in one interpreter window, the other running copies of the interpreter will automatically update with the same changes.
• Workbench for Windows now automatically selects the default "Multimedia" preferences profile on startup. In the past, the debugger simply used whatever profile was active in the game most recently played.
• A problem in the Windows HTML interpreter caused crashes under certain very rare conditions. In particular, if a game asked the interpreter (via the systemInfo() built-in function) if it supports any of the digital audio formats, and the user had previously closed the interpreter window (so the game was in the process of being terminated, but hadn't yet exited), the crash occurred. This has been corrected.
• Due to a bug, text-grid windows weren't being redrawn immediately after being cleared. This has been corrected.
• In the HTML interpreter, if a banner window was initially created with a size of zero, the interpreter showed the banner with an arbitrary small height (about 20 pixels) until the program explicitly set the window's size. New windows are now correctly created with zero height instead.
• The Author's Kit uninstaller for Windows no longer deletes your global Workbench configuration file; this is a file called "htmltdb3.t3c", located in the main Author's Kit install directory. The uninstaller leaves this file intact, because it contains option settings for Workbench, such as the font settings for source files. If you're uninstalling in preparation for installing a new version, and you install the new version in the same directory as the previous version you're uninstalling, this change will ensure that your option settings are retained. However, if you're uninstalling the Author's Kit permanently, this change means that you'll have to manually delete the "htmltdb3.t3c" file and the Author's Kit directory.
• A problem in the interpreter caused link underlines to fail to draw properly in rare cases. In particular, in some fonts, a link that appeared as the very last thing displayed sometimes was missing its underline, at least until the window was drawn again for some reason (due to resizing, for example). Links should now draw correctly all the time.
• In the past, the HTML interpreter didn't display typographical quotes for <Q> tags (using regular ASCII "straight" quotes instead) under certain localization conditions. For example, the Windows interpreter didn't display typographical quotes on systems localized to use a character set other than Windows US/Western Europe (code page 1252). The interpreter is now more flexible; it should now display typographical quotes on a localized machine as long as the machine has the proper character sets installed. (For Windows machines, this means that typographical quotes will be displayed regardless of the default system character set, as long as a cp1252 version of the selected font is also installed.)
• The Windows HTML interpreter now pays attention to the command script MORE prompt mode when playing back a command script (using the "@" syntax in TADS 2, or the new REPLAY command in TADS 3). In the past, the interpreter always showed MORE prompts, even when the game requested that the prompts be skipped.

Interim build 2.5.8/3.0.6g: 4/12/2003

• TADS 3 Workbench for Windows now lets you set the filename of the game file (.t3) compiled for debugging. In the past, this filename was always derived from the name of the project (.t3m) file, so it couldn't be set independently. The Build Settings dialog now allows you to change the filename. Note that this means that you are now free to use your project name for the release version of the game file, as long as you choose another name for the debug version. The New Project wizard takes advantage of this change: it sets the default debug game file to reside in a .\debug subfolder of the project folder (which the wizard creates for you automatically), and it sets the filename for the release build to use the same name as the project. (In the old scheme, since the project name was always reserved for the debug build, the release build had to have some other name, which by default used the project name plus a "_rls" suffix. Most people didn't want to actually distribute the released version with the "_rls" suffix on its name, so this convention created a manual file renaming step for most people when distributing their games. The new scheme saves you this trouble by letting you use any name you want for the release file. The only restriction is that the debug and release builds must have different names from one another.)
• The Windows HTML interpreter now draws thick table borders with diagonal joins at the corners. (In the past, the corner joins were squared, which didn't look great with border thicknesses greater than one pixel.)
• Workbench for Windows has a couple of new text editor interface parameters. First, you can now include the code "%c" to pass the target column number to your text editor. Second, the "%n" (line number) and "%c" (column number) parameters can be qualified with an inserted "0" (hence "%0n" and "%0c") to indicate that the line and/or column number should be passed to the editor using a 0 base - you should use this qualifier if your editor expects 0 for the first line (or column), 1 for the second, and so on. The Epsilon auto-configuration has been updated to take advantage of these new features.
• The Windows HTML interpreter has a new command-line option, -noalphablend, that lets you explicitly turn off alpha-blending support for semi-transparent images. By default, alpha blending will be used when it's supported by the underlying platform (it's supported on Windows ME, 2000, and XP). It might rarely be desirable to turn it off despite system support, such as when the system hardware is too slow with alpha blending enabled, or (more likely) if the local implementation is buggy, as it appears to be in WineX. Attention WineX users: WineX reportedly crashes when alpha blending is enabled, apparently due to a bug in the WineX graphics code. If HTML TADS crashes when you start it up on WineX, try running with the -noalphablend option.
• The Windows HTML interpreter handled the "Escape" key incorrectly when running some games. In particular, games that read individual keystrokes received two copies of each escape key press. This has been corrected.
• The HTML interpreter did not correctly calculate the contribution of some of the typographical spaces ("&emsp;" and the like) to the width needs of a table. This sometimes caused unnecessary line wrapping in tables containing these characters. The renderer now calculates the table widths of the typographical spaces correctly.
• The Windows HTML interpreters are a little smoother in drawing the window when the game has a pause for computation right after displaying some text that results in scrolling. In the past, the interpreter left a little bit of the old text at the bottom of the window, which created a slightly jumpy appearance. The interpreter now updates the exposed area more quickly after scrolling, reducing the apparent flashing.

Interim build 2.5.8/3.0.6f: 3/23/2003
This version has no changes related to HTML TADS.

Interim build 2.5.8/3.0.6e: 3/16/2003

• TADS 3 Workbench for Windows now allows only project makefiles (.t3m files) to be opened as projects; source files and executable (.t3) files are no longer openable as projects. This doesn't affect TADS 2 Workbench. (Opening source and executable files in TADS 3 Workbench was an historical carry-over from TADS 2, where there isn't a formal project file, but rather a "debugger configuration" file that Workbench maintains alongside a .gam file. In TADS 3, the project makefile is an important part of each project, regardless of whether the project was created with Workbench or with the command-line compiler or other tools. You can create project files manually with a text editor, or you can let Workbench create them for you using the New Project command on the File menu.)
• Workbench for Windows now knows how to auto-configure the Imaginate program editor. If you have Imaginate installed on your system, Workbench will include it in the list of known editors, and will automatically set up the necessary command options to invoke Imaginate when you want to edit a source file. Open the Options dialog with the View/Options menu, select the Editor tab, and click the "Auto Config" button to bring up the list of known editors.
• In the past, TADS 3 games sometimes caused the Windows HTML TADS interpreter to crash if the interpreter window was closed while the game was waiting at a "More" prompt. This has been fixed.

Interim build 2.5.8/3.0.6d: 2/23/2003

• Fixed a problem that prevented TADS 3 games from using the <ABOUTBOX> tag. The HTML parser was overly zealous in disallowing <BANNER> tags in TADS 3 games, and incorrectly applied this prohibition to <ABOUTBOX> tags as well. This has been corrected.
• The HTML interpreter didn't always properly calculate the range (or sometimes even the existence) of the horizontal scrollbar when a <TABLE> exceeded the width of the window. Tables are now properly included in figuring the range of horizontal scrolling.
• The Windows HTML interpreter uses a slightly different color scheme than it did in the past for displaying table borders. The top and left sides of each table border are now shown in the "button face" color (as set in the Windows system color scheme); in the past they were shown in the "highlight" color. This improves upon the old color scheme in that the highlight color is the same as the default system window background color in most Windows color schemes, so these portions of the table border were effectively invisible in many cases. This change makes borders visible with typical system settings.
• The HTML renderer's table layout algorithm has been improved to make table layout more controllable. There are two main changes, both relating to the way the renderer decides how wide to make the columns in a table. First, when the renderer is choosing the overall width of a table, it tries to ensure that the table will be wide enough that any columns specified with percentage widths can be laid out with the requested percentage. Second, when a column's width is specified in pixels, the renderer tries to match the requested width as closely as possible; in the past, the renderer used width specifications as hints but didn't attempt to match the requests exactly. These changes should have minimal impact on existing games; the old behavior didn't provide much control over column widths, so it's unlikely that any games were able to achieve particular effects that would be affected by the changes. A more detailed description of the new layout algorithm can be found in the Table Layout Rules documentation.
• In the Windows HTML interpreter, the keyboard event processing had a problem that prevented the end-of-file indication from being returned properly to TADS intrinsics in certain cases. This problem made it impossible in such cases for the game program to detect that the user intended to terminate the game by closing the main HTML TADS application window. This has been corrected.
• The HTML interpreter incorrectly calculated the width of banner windows under certain circumstances. In particular, if a vertical (left or right) banner contained only a table, the full width of the table wasn't properly counted to determine the natural width of the banner. This has been corrected.
• The interpreter had a problem that caused it to crash if an animated image (an MNG) was used as the background of a BODY tag. (The crash only occurred if the window was subsequently cleared.) This has been corrected.
• A problem in the HTML parser caused character entities ("&" sequences) to be displayed incorrectly in rare cases. The problem had to do with buffering of text output at higher layers of the system, and only showed up if an entity happened to be split up due to a buffer flush. This was most likely to occur when displaying large amounts of text at once, such as in a room description. This has been fixed; entities should display properly regardless of any higher-level buffering.

Interim build 2.5.8/3.0.6c: 2/1/2003

• The Windows HTML interpreter now adds an appropriate default extension when the TADS 2 askfile() function or TADS 3 inputFile() function is used to select the name of a file to write. The default extension depends on the type of file that the program requests. (In the past, the interpreter didn't add a default extension except for saved-game files. The lack of an extension was inconsistent with the behavior of askfile/inputFile on searching for an existing file to open, since the dialog by default only shows files matching the appropriate extension for the file type.) This change is limited to the Windows interpreter; it doesn't affect any other platforms.
• A bug in the HTML interpreter occasionally caused banners created with the <BANNER> tag to ignore an explicit WIDTH attribute. The behavior was unpredictable, and varied from session to session with the same game program. This has been corrected; the WIDTH attribute should now be reliably obeyed.
• The Windows HTML interpreter no longer accepts the <:BANNER> tag when running a TADS 3 game. TADS 3 games must use the new banner API instead of using <BANNER>tags. (The banner API is more powerful than the <BANNER> tag, and works not only on HTML interpreters but on many text-only interpreters as well. The new API cannot interoperate with the original tag-based banner mechanism, though, so to avoid confusion, the tag-based banners simply are not allowed in TADS 3 programs. If a TADS 3 program attempts to use a <BANNER> tag, the interpreter will show a message in the debug message window, if there is one, and will otherwise ignore the banner and its contents.)
• Fixed a problem that prevented multi-byte characters (primarily used in East Asian languages) from displaying under some circumstances. (This problem was introduced in the 12/15/2002 interim build, and has now been corrected.)

Interim build 2.5.8/3.0.6b: 12/15/2002

• The HTML renderer now provides the game with much better control over the way lines are broken during the text layout process. In the past, the formatter used simple word wrapping. By default, the line breaking process acts the same as it used to, but several new features let the game override the default behavior. These changes are described in detail in the Line Breaking chapter of the documentation, but here's a summary:
  • A new HTML tag is now supported: <WRAP> tag, which controls the line breaking method. <WRAP WORD> selects the default mode, word-wrapping mode, which breaks lines only at word boundaries (defined as spaces and hyphens). <WRAP CHAR> selects character-wrapping mode, which breaks lines between any two characters.
  • A new markup, the "zero-width non-breaking space," written as "&zwnbsp;", lets the game specify a point at which text cannot be broken, even if the line breaking rules would otherwise allow it.
  • A new markup, the "zero-width space," written as "&zwsp;", lets the game specify a point at which the formatter can insert a line break, even if the line breaking rules would otherwise forbid it.
  • The soft hyphen markup, "&shy;", is now recognized. This lets the game specify a point at which the formatter can optionally insert a line break by hyphenating a word. If the formatter does elect to break at a soft hyphen, the soft hyphen will be displayed as a regular hyphen; otherwise, a soft hyphen is invisible.
  • Several new "typographical space" markups give the game fine control over spacing.

Interim build 2.5.8/3.0.6a: 11/23/2002

• Whitespace between a <BANNER> tag and the first text within the banner's body is no longer significant. In the past, if any whitespace appeared between a <BANNER> tag and the first text in the body of the banner, the banner was displayed with a leading space. Leading whitespace is now ignored, so that a banner's body is treated as starting with a new paragraph. (If a game explicitly wants to show leading whitespace in a banner, it can use the &nbsp; sequence to add a non-breaking space, which the HTML renderer will display even where ordinary whitespace is suppressed.)
• A problem in the Windows HTML interpreter caused the main window's size and placement to be forgotten when the interpreter application was minimized and then closed from the task bar. The interpreter now correctly remembers its size as it was before being minimized.
• A problem in the Windows interpreter caused music playback to stop whenever the interpreter discarded the oldest text in the game window. (The interpreter periodically discards the oldest text to save memory, according to the "Text Memory Limit" setting in the options dialog.) This is now fixed.
• A problem in the Windows interpreter caused the "Profile" list (in the Profiles submenu of the Edit menu, and in the drop-down menu in the profile button on the toolbar) to be shown with no active profile selected in some cases. If the game had a Game Chest entry, and the entry's profile name setting was left completely empty, no profile was selected in the profile menu. This is now fixed; games with empty Game Chest profile settings will use the "Multimedia" profile by default, the same as a game whose Game Chest profile setting refers to any other non-existent profile name.
• In the Windows interpreter, it is now less visually intrusive when old text is discarded to save memory. In past versions, it was obvious that the window was being refreshed at these times. The interpreter is now a little better at hiding these updates, so they should usually be less noticeable now. When discarding old text, the interpreter must recalculate the layout of all of the remaining text in the window, to account for any change in paragraph flow or other layout features that result from discarding the old text. In most cases, the new layout matches the old layout for all of the text visible in the window, since the window usually shows the most recent text, which is the least likely to be affected by discarding the oldest text; the interpreter tries to take advantage of this to make the layout recalculation invisible.
• Fixed a problem that caused output to be hidden when the game opened a <TABLE> tag but never got around to closing it before reading a command line. This sort of thing isn't legal, but the interpreter didn't recover very gracefully from such input. The interpreter now automatically closes any <TABLE> tags left open when starting a new command line, ensuring that the HTML formatter won't get stuck waiting for a </TABLE> that the game accidentally omits.

Changes in version 2.5.7

• The Windows interpreter now keeps the display option settings (fonts, colors, and so on) in a "Profile," which is simply a named group of saved settings. Profiles let you switch all of your display settings at once, so they're especially convenient if you like to use one display style with some games, and a different display style with other games. Here's how profiles work:
  • At any given time, there's a current profile; you can change the current profile using the "Profiles" command on the "Edit" menu (there's also a toolbar button that does the same thing). Whenever you make changes to your display settings with the Options dialog, the settings are saved with the current profile.
  • Initially, the system automatically creates two profiles for you: Multimedia, and Plain Text. The system sets up these profiles with default settings, but you can customize the settings with the Options dialog any way you like.
  • You can also create new profiles of your own, using the "Manage Profiles" command (part of the "Profiles" submenu of the "Edit" menu, and also a toolbar button). Whenever you create a new profile, its initial settings will be copied from the current profile.
  • The interpreter remembers which profile was last used with each game, and automatically switches to the same profile each time you play the game. For games you've added to your Game Chest, you can change the profile setting for each game with the "Edit" link displayed next to the game's listing on the Game Chest page. The interpreter also remembers which profile was last used with the Game Chest page itself.
  • When you load a game for the first time, the interpreter checks to see if the game includes GameInfo metadata with a "PresentationProfile" setting. If the game does include that setting, the interpreter uses the setting to select an initial profile for the game, if there's a profile with the same name. This gives the game's author a way to recommend a display style for the game.
• The Windows HTML interpreter now allows you to set the size of each font individually in the Preferences dialog. Sometimes, two different fonts don't look quite right together when displayed at the same nominal point size; this new feature lets you adjust the individual point sizes of the fonts you're using to give a uniform visual size. On the Fonts tab of the dialog, each font now has a drop-down list that lets you specify the point size for the font. Note that this sets the "base size" for the font; whenever the game selects larger and smaller sizes via its formatting commands, the sizes are relative to this base size. In addition, if you set the "Text Size" item on the "View" menu in the interpreter to a size other than "Medium," all of the fonts will be scaled up or down from the base size you set in the preferences. Whenever the game displays a font by name, rather than using one of the fonts you select in the Preferences dialog, the interpreter will use the point size of the Main Game Font as the base size of the named font.
• The Windows HTML interpreter has a new page of Game Chest options in the Preferences dialog.
  • You can now select the location of the Game Chest database file, GameChest.txt, which stores your list of game and web site links. The file's default location is the "My Documents" folder (in a "TADS" subfolder), but you can use this new option to set a custom location. Note that if you change this option, you'll have to manually move the GameChest.txt file to the new location you choose, if you want to use the original copy; if you don't, Game Chest will create an empty new GameChest.txt file for you. Also, you'll have to change this setting again if you re-install the Player Kit in the future.
  • You can select a custom picture (using a PNG or JPEG image file) for the background image displayed on the Game Chest page, or you can choose to use no image at all.
• The new BODY tag attribute HLINK allows you to specify the color of hyperlinked text for "hovering," which means that the mouse cursor is positioned over the hyperlink but the mouse button isn't being held down. Note that not all systems use a special appearance for hovering over a hyperlink, and even on systems that do, the special appearance may be controllable through user preferences (it is on Windows, for example); this attribute won't have any effect in these cases.
• The Windows HTML interpreter no longer uses full alpha blending when running on Windows 98; only simple transparency is now used on Win98. This change was made because the alpha blending support built in to the operating system has some serious flaws in Windows 98; these OS bugs made it impossible for the TADS renderer to work reliably. This change does not affect any other Windows platforms: full alpha blending is still supported on Windows ME, 2000, or XP. (Thanks to Lukas Fichtinger for point out this problem.)
• A bug in Workbench for Windows caused Workbench to crash occasionally after performing build command steps that produced no output. This has bee corrected.
• A bug in Workbench for Windows caused sporadic crashes when making changes to source window formatting settings from in the Options dialog. This should no longer occur.
• Due to a bug in the combined TADS 2/3 Windows interpreter, double-clicking a saved game file from a Windows Explorer desktop window did not correctly start and restore the saved game. This is now fixed.
• A bug in the Windows interpreter caused the game to stop responding in some cases where the game used the morePrompt() function to wait for the user to acknowledge a display. This has been corrected.
• Due to a bug, the Windows HTML interpreter's Game Chest was unable to run a game listed in the "favorites" list when the game's directory path contained an apostrophe ("'") character. This has been fixed; Game Chest can launch a game from any valid path now.
• The Windows HTML interpreter's Game Chest showed some accented characters incorrectly when the characters were taken from GameInfo metadata embedded in TADS 2 games, and the GameInfo files were prepared using UTF-8 enabled text editors. This has been corrected. (Note that you might need to remove and re-add Game chest entries for any games with accented characters shown incorrectly, because the Game Chest will have already stored in the wrong accented characters in its configuration file. If you remove and re-add the entries, Game Chest will interpret the characters correctly when it stores the new entries.)
• The Windows HTML interpreter's Game Chest froze up when attempting to read GameInfo data stored in certain invalid formats (this showed up in particular when the GameInfo file was stored in the UCS-2 Unicode encoding). This has been corrected; the interpreter now tolerates invalid formats and shows a warning dialog when it detects one. (Thanks to Lukas Fichtinger for catching this.)
• Several of the third-party libraries that the Windows interpreter uses have released updates recently, so the interpreter has been updated to use the latest releases, as of this writing: MNG is now supported through mnglib 1.0.4 and zlib 1.1.4; and Ogg Vorbis playback now uses libvorbis 1.0.
• The HTML parser is now more tolerant of text written piecewise. In the past, if the game wrote out a partially-completed tag and then flushed the output stream or forced a redraw, the parser saw only the incomplete tag, and flagged an error. The parser now defers parsing an incomplete tag, even after an explicit buffer flush, saving the partial tag for later completion. The parser has a limit of 4k bytes for partially-flushed tags; if the source text of an incomplete tag exceeds this limit, the parser will assume the tag will never be completed and issue an error. This change will be mostly invisible to games; the only noticeable difference should be that the parser will gracefully handle unusual cases where a game flushes the output buffer explicitly in the midst of writing a tag. (Note this type of situation doesn't arise very often in normal game execution, but it can easily occur when stepping through a game with the debugger, since the debugger can be configured to flush output on every pause.)
• The Preferences dialog enabled and disabled the Apply button on the font selection page incorrectly in some cases. This is now fixed.
• A bug in the HTML renderer caused spurious "MORE" prompts in some cases when the game displayed a table with lots of cells. This has been fixed.

Changes in version 2.5.6

• The new ASRC and HSRC attributes of the <IMG> tag provide a way of implementing simple roll-over buttons. Refer to Roll-over Images in the documentation for details.
• Fonts can now specify a BGCOLOR (background color) attribute in addition to the COLOR attribute. When a font specifies a background color, the area behind any text displayed with the font is filled with the background color. The area filled with the background color is dependent on the font, but is a rectangle that is usually slightly taller than the tallest character in the font, and just wide enough to hold the displayed characters.
• The Windows HTML interpreter now supports Ogg Vorbis compressed audio in <SOUND> tags. Ogg Vorbis is an open-source audio format similar to MPEG audio but said to have superior compressions and fidelity. The Windows interpreter uses the Xiphophorus reference implementation, version 1.0rc3, for decoding. Ogg Vorbis files are identified by resource names that end with the suffix ".ogg". An Ogg Vorbis resource can be played in any sound layer. Refer to vorbis.com and xiph.org for information on the Ogg Vorbis format, and for links encoders and other Ogg Vorbis-enabled software.
• The Windows HTML interpreter now supports MNG (Multiple-image Network Graphics), on an experimental basis. MNG is an animated image format related to PNG, and, like PNG, is an open standard unencumbered by patents; MNG is said to be superior to animated GIF's in a number of ways. (HTML TADS doesn't support GIF images, static or animated, because of patent restrictions applying to the GIF format.) MNG is supported by several popular applications, including Jasc's Animation Shop (part of Paint Shop Pro). The MNG web site has information on the standard, including links to applications that can be used to create and manipulate MNG images. In HTML TADS, you can use an MNG file as the SRC of an <IMG> tag, an <HR> tag, or an <LI> tag. Note that MNG images can NOT be used as the main body background; only static images (PNG's and JPEG's) can be used as the body background.
• The new system information code __SYSINFO_OGG allows a game to sense whether or not the interpreter supports the Ogg Vorbis audio format.
• The new system information codes __SYSINFO_MNG, __SYSINFO_MNG_TRANS, and __SYSINFO_MNG_ALPHA sense whether or not the interpreter supports the MNG image format, transparency masks in MNG images, and "alpha channel" partial transparency in MNG images, respectively. In most cases, MNG transparency and alpha support will mirror PNG support for the same features.
• The Windows HTML interpreter now supports full alpha-channel (partial transparency) rendering of PNG images on Windows 98, ME, 2000, and XP. Alpha rendering is automatic. This functionality is not available when running on Windows 95 or NT 4, because these versions of Windows do not provide support for alpha rendering in their native graphics subsystems; on Windows 95 and NT 4, images with alpha channels are rendered against a fixed background (either the default background specified in the PNG itself, or a default chosen by the interpreter if the PNG doesn't specify one) as in past versions. For PNG's with paletted alpha, on 95/NT 4, the paletted alpha is treated as simple transparency. Note: the system information code __SYSINFO_PNG_ALPHA (introduced in version 2.5.4) indicates whether or not the system supports full PNG alpha channel rendering; this allows a game to include two copies of a graphic (usually, one optimized for full alpha and the other optimized for simple transparency), displaying one or the other according to the capabilities of the interpreter.
• The Windows HTML interpreter now includes an "Exit" command on the "File" menu. This is equivalent to closing the interpreter window. Similarly, the former "Quit" command in Workbench has been renamed to "Exit" for conformance with standard Windows user interface conventions.
• The Windows HTML interpreter features the "Game Chest" start page. The interpreter shows the Game Chest page when it first starts, and also offers a link to the Game Chest page whenever a game ends. The Game Chest page gives you a customized list of your favorite games; you can start a game on your list by clicking its title, saving you the trouble of finding the game file on your hard disk. The Game Chest page is easy to use and self-explanatory.
• The Windows HTML interpreter has a new "Find Text" command, which lets you search for text in the game window. This makes it easy to locate a passage that you remember seeing earlier and want to read again. To begin a search, select the menu item "Find text on current page" from the "Edit" menu; this will bring up a dialog box. Type the text you want to find and click the "Find Next" button in the dialog (or just press Enter). The interpreter will look for the text, and then highlight the first occurrence it finds. Select the "Find Next" item from the "Edit" menu to find the next occurrence of the same text, or just press the F3 function key.
• TADS Workbench for Windows has a new feature that lets you go to a selected line number in the active source window. To use the command, select the "Go to line number" item from the "Edit" menu, or type Ctrl+G. This will show a dialog asking for a line number; type the line number and click "OK" (or press Return). The cursor will be positioned on the selected line number in the active source window.
• In Workbench for Windows, the debugger log message window is now a "dockable" window. As with the other dockable windows, you can switch the window between document-style ("MDI") mode and docking mode by right-clicking on the window's title bar and selecting the new mode from the pop-up menu.
• The Windows HTML interpreter now includes a toolbar, for fast access to frequently-used commands. The toolbar is optional; if you want to hide it, un-check the "Show Toolbar" menu item on the "View" menu.
• The keyboard accelerators in the Windows interpreter have been changed slightly to better match the usual Windows conventions. "Restore game" is now on Ctrl+R, and "Open new game" is on Ctrl+O.
• The Windows HTML interpreter now continuously displays the elapsed time since loading the current game at the right side of the status line. The timer shows elapsed time for the current session only, so if you save a game, turn off your computer, then come back to the game later, the timer will be reset when you start your new session. If you find the timer distracting, you can hide it by un-checking the "Show Timer" menu item on the "View" menu. You can also choose whether to display hours, minutes, and seconds, or just hours and minutes: right-click on the status bar, and select your desired time display format from the pop-up menu.
• The Windows HTML interpreter now allows keyboard entry of character code 255. (This primarily affects users on machines localized outside of the US and Western Europe, since the Windows Western European character set doesn't use character code 255 for anything. In past versions, the interpreter incorrectly failed to allow keyboard entry of this particular character code.)
• In the Windows interpreter, the parameterized font named "TADS-Input" selects the text's color, bold, and italics attributes as well as the typeface, according to the settings that the player makes in the Preferences dialog. In the past, it was not possible to override the additional attributes, even with explicit <font> tags nested within the tag that selected the "TADS-Input" face. This has been changed so that <font color=xxx>, <i>, and <b> tags nested within a <font face='TADS-Input'> tag are obeyed. (Note, however, that any color attribute specified in the same <font> tag as a face='TADS-Input' attribute is still ignored: the preference color associated with the "TADS-Input" font still overrides any other color setting made in the same tag. This isn't necessarily the most intuitive behavior, but think of it as an arbitrary choice to resolve a conflict: since "face=TADS-Input" and "color=xxx" attributes in a <font> tag both select a text color, one of them has to be ignored.)
• The Windows interpreter now uses the TITLE attribute of an <A> tag as the "tip" text for the link. That is, if the mouse cursor hovers over a link for a few moments, the interpreter displays a small pop-up window showing the link's TITLE attribute text.
• Hyperlinks can now be displayed with explicit font colors. In the past, a <FONT COLOR=xxx> tag within an <A HREF> tag was ignored, and the hyperlinked text always displayed in the system hyperlink text color despite the explicit color setting of the interior tag. The renderer now obeys the color setting of a <FONT> tag enclosed within an <A HREF> tag, overriding the default system color settings. Note that when the color is explicitly overridden in this fashion, the explicitly specified color is used for all states of the linked text, so the link doesn't change its visual appearance in response to the mouse position as it does with the default colors.
• The following parameterized color names have been added:
  • link: hyperlink text
  • alink: "active" hyperlink text (on Windows, this is the color of a link while the mouse button is being held down with the mouse over the link; the meaning may vary on other systems)
  • text: the default text color
  • bgcolor: the default background color
• The Windows HTML interpreter now waits to attach to the DirectSound system (a part of Windows that handles sound playback) until a game first requires sound playback, rather than at interpreter start-up as it did in the past. This means that the interpreter won't attempt to use the DirectSound subsystem at all when the game or games played during an interpreter session don't use any sound effects. When an application connects to the DirectSound system, other applications are sometimes unable to use DirectSound simultaneously; although HTML TADS uses a "cooperative" sharing level for its DirectSound use, some other applications require exclusive access, and so cannot use DirectSound at the same time as HTML TADS. By waiting to attach to DirectSound until a game actually needs sound playback, the interpreter avoids unnecessarily locking out other, less cooperative applications.
• A bug in the Windows interpreter caused the interpreter to crash if a game attempted to display a JPEG image encoded in gray-scale (monochrome) format. This has been corrected.
• The Windows interpreter now shows more immediate visual feedback (by scrolling the window down a line) after a command is entered if the command takes a perceptible amount of time to process. (This is a purely cosmetic change. In the past, the interpreter didn't show any visual change until a command was finished; this was harmless, but looked a little weird for commands that took more than a few tenths of a second to complete.)
• The scrollbars in the main window in the Windows interpreter now track the mouse a little differently: when you click and drag the scrollbar's "thumb" to change the scroll position, the scrollbar will continue tracking the mouse as long as you hold down the mouse button, no matter how far you move the cursor away from the scrollbar. In the past, as is typical for Windows scrollbars, the thumb snapped back to its original position whenever the mouse strayed more than about the width of a scrollbar away from the scrollbar; some people (your present correspondent included) found this extremely irritating, since it's hard to keep the mouse lined up with the narrow little scrollbar area when moving the thumb any substantial distance.
• The Windows interpreter (and Workbench) now provide "native" mouse wheel support. In the past, it was necessary to use the mouse manufacturer's extra driver software for the scroll wheel to work in HTML TADS, but this was a problem for users who don't use the extra driver software; many people must disable the extra driver software because of incompatibilities with other applications. The new native mouse wheel support means the mouse wheel will work properly on any Windows 98/Me/NT 4/2000/XP system, even if the extra driver software is disabled. (Windows 95 and NT 3.1 users must still use the extra driver software, because those versions of Windows do not have native mouse wheel support.)
• Workbench for Windows has a new "auto configuration" dialog for text editors. When you're configuring a text editor (in the "Editor" panel of the main options dialog, reachable from the "Options" item on the "View" menu), you can click on the new "Auto Config" button to bring up the automatic configuration dialog. The new dialog lets you choose an editor from a list of pre-configured editors, plus any editors that you have installed that have registered Windows Explorer file associations for files of type ".c", ".h", ".cpp", or ".txt". If your preferred editor is included in the list, all you have to do is select your editor from the list and click the OK button; the appropriate settings will be entered automatically into the editor panel. If your favorite editor isn't on the list, please contact TADS's author to request adding your editor to the list in a future version. Sadly, text editor vendors have not yet been lining up with large cash offers for promotional consideration in the auto-config list; until they do, I'll add any editor to the list upon receipt of the relevant configuration parameters. Note: if you select a pre-configured editor (as opposed to one deduced from file associations), you might need to go the "Advanced" dialog after selecting your editor from the list to set the full path to the editor's executable file.
• The mechanism that searches for source files in the Windows debugger has been improved slightly to eliminate a problem that occurred in some cases where a header or source file was not in the working directory at compile time. In some such cases, the debugger managed to open the source file but did not properly show breakpoint and execution pointer icons. This has been corrected.
• The Windows TADS 3 Workbench debugger now automatically stops when the interpreter is about to throw a run-time error, allowing you to see the location in the code where the error occurs, and possibly to intervene manually. If you change the execution point and then step or go, the interpreter will not throw the error; if you leave the execution point unchanged, the interpreter will proceed to throw the run-time error as normal. In some cases, you may be able to correct the conditions that caused the error (by changing the values of variables, for example); in these cases, you might wish to avoid throwing the error by moving the execution point back a line or two in the source and retrying the operation.
• The Windows TADS 3 Workbench allows files in the Project window to be reordered, simply by clicking on an item with the mouse and dragging it to its new location. Files can only be reordered within a folder; a file cannot be dragged to a different folder.
• Workbench for Windows now provides the "Find" command within the Debug Log window, to search for text within the debug log text.
• The HTML renderer now flows text around tables with ALIGN=LEFT or ALIGN=RIGHT settings. This lets a table "float" in a margin in the same way that images can, which can be useful for a variety of text effects. Note: the renderer's treatment of such tables deviates slightly from the HTML standard, in that a left- or right-aligned table is effectively treated as an in-line item rather than a block item, so no paragraph break is visually displayed at the point where the table appears in the text. For strictly compliant HTML treatment, one can place a <P> tag immediately before and immediately after a table with left or right alignment. Tables with no explicit alignment and tables that specify ALIGN=CENTER are not affected by this change.
• The HTML interpreter did not correctly display PNG images that use a gray-scale format (one of the several PNG color storage formats); gray-scale images were displayed with random colors that changed unpredictably during redraws. This has been corrected; gray-scale images are now displayed correctly.
• The Windows HTML interpreter now uses libpng 1.2.2 (the latest version, as of this writing, of the reference open-source PNG library) for handling PNG files. This expands the range of PNG sub-formats supported on Windows.
• The Windows HTML interpreter is now faster at queuing digitized sound effects (the WAV, MPEG, and Ogg Vorbis formats). The interpreter's latency sensing the end of playback for digitized sounds has been reduced substantially, so loops and queues now proceed with a much smaller delay between adjacent effects.
• A bug in the HTML renderer caused list items (specified with the <LI> tag) to be indented improperly. In the past, the bullet or number of each list item was shown at the same indent level as the rest of the list text; instead, the bullet or number should be displayed in the left margin of the first line, with the text of each line left-aligned to the right of the bullet or number. This has been corrected.
• A bug in the HTML renderer caused unpredictable results when switching out of HTML mode (using "\H-") immediately following certain types of closing tags. This problem only appeared when an "\H-" sequence appeared immediately after an affected close tag with no other intervening text or tags. This is now fixed.
• A bug in the Windows HTML interpreter caused some font preference settings to change by themselves when brining up the Preferences dialog. In particular, if the originally selected font was the first font in the popup list for a given font type, the font switched upon bringing up the dialog to the second item in the list. This problem no longer occurs.
• A bug in the HTML renderer caused incorrect displays in certain cases where a <TABLE> tag was nested within a <BLOCKQUOTE> tag, and no text or markups came between the closing </TABLE> tag and the closing </BLOCKQUOTE> of the enclosing structure. Typically, some of the text immediately following the </BLOCKQUOTE> was not displayed at all or was displayed with incorrect margins. This has been corrected.
• The Windows installer now automatically looks up the local "Program Files" path and uses it to select the default installation directory. This applies to the system installer as well as to game installers you create using Workbench. When you're creating an installer for your game, you should use only a relative path for your "Default Program Directory" setting (in the Installer Options subdialog of the Build Settings dialog); the installer will automatically insert the correct prefix for the local computer at installation time. For example, rather than typing "C:\Program Files\My Game" into the Default Program Directory text box, you should type simply "My Game"; the installer will expand this to "C:\Program Files\My Game" or "C:\Programme\My Game" or whatever is appropriate on the local system at install time.
• A couple of bugs in the HTML renderer caused crashes in some cases when <BANNER> tags were not closed before reading text input from the keyboard. The effects of unclosed <BANNER> tags varied according to the banner's contents, but several common types of contents, including <FONT> and <TABLE> tags, sometimes caused interpreter crashes. The renderer should now be tolerant of unclosed <BANNER> tags (at the very least, it should no longer crash when confronted with such things).
• The <CAPTION> sub-tag of a <TABLE> is now implicitly closed by a <TR>, <TD>, or </TABLE> tag. In the past, the HTML parser complained if a <CAPTION> was not closed with an explicit matching </CAPTION>; the parser now implictly closes a <CAPTION> at the end of a table or at the start of any other table structure sub-tag.
• Tables that had explicit WIDTH settings but contained no data are now displayed at the given width. In the past, a table without any contents was shown with zero width, even if an explicit WIDTH attribute was given.
• On Windows, the HTML interpreter did not always correctly choose fonts on systems localized for locales other than Western Europe/US. In the preferences dialog, the font selector pop-up controls sometimes showed the same font several times (possibly with suffixes on the name) when several different character set versions of the same font were installed on the system. Furthermore, the interpreter sometimes showed characters from the incorrect character set when displaying HTML entities. This has been corrected; the list of fonts should now show only one instance of each typeface name, even when several different character sets of the same typeface are installed, and the interpreter should show the correct characters for all HTML entities that can be displayed.
• Due to a bug in HTML TADS, if the player terminated a game by closing the interpreter window while the game was specifically pausing for some amount of time (for example, to allow a sound to finish playing), the interpreter did not immediately exit, but continued waiting for the interval specified by the game. In the case of long delays, this could leave the interpreter process running for some time after it was ostensibly terminated. This was mostly harmless, but unnecessarily consumed system resources. This has been corrected.

Changes in version 2.5.5

• Fixed a problem in the Windows HTML interpreter that eventually stopped MIDI sounds that were intended to loop infinitely. (The problem was that the MIDI player was unnecessarily re-opening the MIDI file after each repetition; this eventually consumed all available file handles, at which point the looping stopped because the MIDI player couldn't open the file again.) This has been corrected.
• Fixed a problem in the Windows HTML interpreter that prevented playback of very short MP3 audio files. In the past, MP3 files under about half a second in total duration did not play back. This has been corrected.
• Fixed a problem in the HTML interpreter that sometimes caused crashes when certain font-related tags were not properly balanced (i.e., begin and end tags were not matched up correctly in the HTML). While these sorts of sequences are still invalid HTML and hence might still confuse the renderer and result in strange displays, they should no longer cause crashes.

Changes in version 2.5.4

• 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.
• 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.)
• 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.)
• 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.
• 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.
• 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.

Changes in version 2.5.3

• 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 interior 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.
• 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.
• 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.
• 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.
• 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 Six Stories, for example. This has been corrected.
• The HTML interpreter for Windows crashed if you closed the application while a sound was still playing. This has been corrected.

Changes in version 2.5.2

• The Windows interpreter now allows you to use certain web addresses in <A HREF> 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:
  • http:
  • ftp:
  • news:
  • mailto:
  • telnet:
  Note that you can use the systemInfo() function to check the interpreter to determine if these link types are supported, using the new __SYSINFO_LINKS_HTTP, __SYSINFO_LINKS_FTP, and related capability codes. Refer to the TADS 2.5.2 release notes for details.
• 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).
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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 <TITLE> tag. The title now reflects the ".gam" file name if the game doesn't specify a <TITLE> tag. This is especially helpful if you're switching among different games in the course of a single session.
• Fixed a bug in the <TAB> tag. When <TAB MULTIPLE> 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.
• Fixed a bug in the clearscreen() function. In past versions, if the game called clearscreen() 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 "\n" or "\b" sequence), the interpreter occasionally would display part of the HTML tag as plain text. This should no longer occur.
• 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.
• 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.
• 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.

Changes in version 2.5.1

• 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.
• 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.)
• The Windows interpreter in the past acted as though the player had responded to a "MORE" prompt whenever the timeDelay() function was used to pause the game. This no longer occurs.
• 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.
• On the Windows interpreter, the systemInfo() built-in function incorrectly reported that MPEG Audio was not supported. This has been corrected.
• On the Windows interpreter, the morePrompt() 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.
• 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.
• Fixed a bug in the interpreter that prevented <BANNER REMOVALL> sequences from working correctly under certain conditions. This has been corrected.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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 delete 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.
• 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.
• 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.
• Fixed another debugger problem that caused a crash when breakpoints were set in a source file containing no executable code at all.

Changes in version 2.5.0

• Important programming note: The Windows debugger now requires that you compile your game with the new -ds2 option. Use this option instead of the traditional -ds option. (The only difference between -ds and -ds2 is that the -ds2 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 -ds option.)
• Another important programming note: 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 TADS Workbench help page for details on the new features.
• 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.
• 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:
  • 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.
  • 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.
• 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:
  • 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.)
  • 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.
• 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:
  • 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.
  • 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.
  • 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.
• The <BANNER> 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 Banner Size Attributes for full details.
• When a game is running in HTML mode, the yorn() 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 yorn() in HTML mode. The Interpreter has always switched to the input font for yorn() as well as for input() when the game was not in HTML mode, and continues to do so.)
• "$$ABEND", the emergency abort command, now works properly in the Windows HTML TADS interpreter. This command was ignored in past versions.
• 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:
  • 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).
  • 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.
  • 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.
  • 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 here for more information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.)
• 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.

Changes in version 2.4.0

• 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.)
• 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.
• 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.
• On Windows, displaying PNG images in 256-color display modes is now much faster.
• 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.
• 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.
• A bug caused the interpreter to fail to display any text after a game program displayed an empty <TITLE> tag. This has been corrected.

Changes in version 2.3.0

Changes of interest to both players and authors:

• 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.
• 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.
• 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.
• 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 The Plant once, and then restart and play about halfway through again).
• 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.
• 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.
• 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 <BODY BACKGROUND=xxx>), 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).
• 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.
• 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.
• 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.
• 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.
• On the Windows version, the entities &Odblac; and &odblac; were reversed, so that &Odblac; displayed a lower-case "o" with double acute accent, and &odblac; displayed an upper-case "O" with double acute accent. This has been corrected.
• 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.)

Changes of interest to authors:

• 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 sound documentation.
• Because the Windows version supports MPEG 2.0 audio layers II and III, the systemInfo() function returns true for the new feature codes related to MPEG: __SYSINFO_MPEG_AUDIO, __SYSINFO_MPEG_AUDIO_2, and __SYSINFO_MPEG_AUDIO_3.
• The <A> and <AREA> 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> for details.
• A new parameterized font, TADS-Input, 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 TADS-Input as the font for all commands. By default, std.t now activates this font in the commandPrompt function; you can replace this function definition with your own if you want to override this behavior. See the documentation on parameterized font names for details.
• The treatment of whitespace following <P> and <BR> tags is now slightly different than it was in past versions. In the past, if a <P> or <BR> 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 <P> or <BR> 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.
• 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.)
• The <BANNER> tag accepts a new attribute, REMOVEALL, that indicates that all banners should be removed. REMOVEALL does not take a value; when this attribute is specified, no other attribute (not even ID) is needed.
• If the <BANNER> 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.
• In past versions, alignment settings in <TD> (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 <TD> alignment setting now affects every block within the cell.

Changes in version 2.2.6

• The interaction between the inputkey() built-in function and the automatic "MORE" prompt has been changed slightly to correct a problem. In the past, the inputkey() 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; inputkey will never retrieve a keystroke until any after pending "MORE" prompt has been acknowledged.
• 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 &nbsp; sequences with no intervening spaces (note that using the backslash-space sequence instead of &nbsp; produces the same result). This has been corrected.
• 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.

Changes in version 2.2.5

• The <A> 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> changes for more information.
• 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.
• 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 relative path to the game file (for example: htmltads games\mygame.gam), 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.
• The inputkey() 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.
• In past versions, table cell tags did not accept WIDTH attributes with percentage values. Percentage-based cell WIDTH values are now supported.
• Tables with empty cells (specified by a <TD> tag followed immediately by another <TD> tag or a </TD> 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.
• A bug in the formatting of the <BANNER> tag caused a banner to be displayed in certain situations even after a <BANNER REMOVE> tag had been issued for the same ID. This has been corrected.
• 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.
• 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.
• 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.
• 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.
• See Recent Changes to TADS for information about several generic TADS interpreter improvements and corrections that affect the HTML interpreter as well:
  • A new parser feature lets you define new methods, dobjCheck and iobjCheck, that are always called before the verb handlers (verIoVerb and so on).
  • 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.
  • A parser bug, involving using AGAIN with a command directed to an actor that is no longer present, has been fixed.
  • 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.
  • A parser bug that caused doSynonym and ioSynonym handling to work incorrectly with overridden methods is now fixed.
  • The init function is no longer incorrectly invoked prior to initRestore when restoring a saved game during start-up (for example, when you double-clicked the saved game from Explorer).
  • Backslashes in text captured by the outcapture() built-in function are now handled correctly.
  • An incompatibility with games compiled by old (pre-2.2.0) versions of the compiler has been corrected.

Changes in version 2.2.4

Here's a quick index to some selected highlights in this release:

Of interest to players:
• Automatic installation
• Restoring a saved game from the desktop
• New link highlighting preferences
• Turning off graphics
• File safety levels
• DirectX on Windows NT

Of interest to game authors:
• Using extended characters
• Banner enhancements
• Building a custom game installer
• External resource files
• Changing stand-alone executable icons
• Getting system information
• Typographical character changes
• Debugger now uses MDI
• Improved resource diagnostics
• Parameterized font names
• Parameterized color names
• Status line changes

Changes of Interest to Players:

• 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.
• 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.
• 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 Recent Changes to TADS for more information.
• 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.
• 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.
• 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.
• 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.
• 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 <IMG> tags that include an ALT attribute will be displayed as text using the value of the ALT attribute; other <IMG> tags will simply not be displayed at all. Other tags that can optionally incorporate graphics, such as <LI> and <HR> will be displayed in their normal non-graphical format, and background images (specified via the <BODY BACKGROUND> tag) will not be displayed.
• 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 Recent Changes to TADS for details about this new setting.
• 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.)
• While playing a game, the F1 key now enters the command "help" on the command line, for processing by the game.
• 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:
  • -mh 65535 (heap size)
  • -ms 512 (stack size)
  • -u 60000 (undo size)
  The debugger limits have been similarly increased.
• 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.
• 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).
• 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: ftp://ftp.microsoft.com/softlib/mslfiles/com32upd.exe. I'd like to thank Klywarre (The Avatar) [aka: James Mallette] for discovering the DLL incompatibility and tracking down the solution.
• This version corrects several problems related to the "Next Page" and "Previous Page" navigation items on the "Go" menu. The following are all fixed:
  • A bug caused crashes in some games when using the "Next Page" and "Previous Page" navigation items on the "Go" menu.
  • 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.
  • 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.
  • 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.
• The title bar now displays "HTML TADS" for games that don't explicitly set the window title (it was "TADS HTML").

Changes of Interest to Game Authors:

• 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 character set notes for more information.
• 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 banner documentation for details.
• A new utility lets you build a custom installer for your game, without any programming. Refer to the game distribution documentation for details.
• 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 resource file documentation. Note that this new feature requires the TADS resource manager (tadsrsc) version 2.2.4 or higher; the resource manager accompanies the TADS compiler and tools distribution.
• 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 maketrx32 command when you build your stand-alone game. Refer to the game distribution documentation for more information.
• 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 game distribution documentation for more information.
• The new TADS systemInfo() 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 Recent Changes to TADS for details.
• TADS has a new parser hook that gives you more control over how the TADS parser handles unknown words in player commands. Refer to Recent Changes to TADS for full details.
• TADS has a new language feature that lets you specify the superclass from which you want a method to inherit when you use the inherited keyword. Refer to Recent Changes to TADS for information.
• TADS now allows you to change the object that represents the player character dynamically, using the new parserSetMe built-in function. Recent Changes to TADS has details.
• HTML TADS now supports the <Q> tag from HTML 4.0. This tag encloses a passage in quotation marks. <Q> automatically uses typographical quotation marks if they're available in the character set. Nested <Q> tags alternate between double and single quotes.
• 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:
  • &lsq; has been changed to &lsquo;
  • &rsq; has been changed to &rsquo;
  • &ldq; has been changed to &ldquo;
  • &rdq; has been changed to &rdquo;
  • &emdash; has been changed to &mdash;
  • &endash; has been changed to &ndash;
  Note that the old character codes are still allowed, but they're no longer documented and should be considered obsolete.
• The following new special character codes from HTML 4.0 have been added.
  • &sbquo; produces a single low-9 quote
  • &bdquo; produces a double low-9 quote
  • &lsaquo; produces a single left angle quote
  • &rsaquo; produces a single right angle quote
  • &dagger; produces a dagger
  • &Dagger; produces a double-dagger
  • &OElig; produces a capital "OE" ligature
  • &oelig; produces a small "oe" ligature
  • &Yuml; produces a capital "Y" with an umlaut (diaeresis)
  • &Scaron; produces the capital letter "S" with a caron
  • &scaron; produces the small letter "s" with a caron
  • &permil; produces a per-thousand sign
• 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 HTML 4.0 specification 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).
• 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 HTML TADS Latin-2 table for the complete list.
• You can now enter hex digits in character entities by putting an "x" after the "#"; for example, "&#xF3" enters the hex value F3.
• 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.
• 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.)
• 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.
• The Windows version of the debugger now displays the game status (running, paused, terminated) in the main debugger window's caption.
• 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.
• 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.
• 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 -debugwin specified on the command line when invoking the interpreter. These messages won't interfere with the main game window.)
• This version corrects a few bugs with tables:
  • Under certain circumstances, using alignment attributes in TR or TD tags caused the alignment settings to continue beyond the table.
  • If a table was the very first item in a banner, the table was invisible.
  • If a table had an explicit height specified (with a HEIGHT attribute on the TABLE tag), the height was ignored.
  • 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.)
• Some bugs involving banners are now fixed:
  • If you used multiple banners, the status line was not always updated properly when the player moved the mouse cursor over a link.
  • A text link appearing in a banner did not always use the correct color.
• 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.
• 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 style 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 HTML deviations documentation for full details.
• 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 HTML deviations documentation for full details.
• The HTML status line code in adv.t, which is enabled when you compile your game with the preprocessor symbol USE_HTML_STATUS 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 systemInfo built-in function, described in Recent Changes to TADS, to sense whether HTML features are available at run-time. Note that, even if you customize the status line, you may want to refer to the new adv.t status line code and use similar logic in your custom implementation, to support both types of interpreters.
• The default status line color scheme in adv.t 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).
• 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.
• Some small documentation problems have been fixed:
  • the link from the introductory page to the debugger page is fixed
  • the debugger page is now part of the normal interpreter distribution
  • the debugger page no longer has its last few paragraphs in boldface.
• Some cosmetic problems have been fixed:
  • The HTML TADS interpreter and debugger "About" boxes now display the TADS version number
  • The usage messages for the HTML TADS interpreter and debugger now display their correct executable names