This file is part of the TADS 2 Author’s Manual.
Copyright © 1998 - 2002 by Michael J. Roberts.
All rights reserved.
Edited by NK Guy, tela
design.
This document describes differences between multimedia TADS and the standard versions of HTML.
The HTML used in multimedia TADS is based on the HTML 3.2 reference specification, which is a W3C (World Wide Web Consortium) recommendation document that can be found at http://www.w3.org/pub/WWW/TR/. HTML 3.2 is a widely deployed “markup” language; it’s supported by most of the popular web browsers currently available.
The primary reason that multimedia TADS is based on HTML 3.2 is that HTML 3.2 is widely known and is reasonably powerful. Since copious documentation on HTML is available, game designers should have no problem learning how to use multimedia TADS.
While I’ve tried to follow the HTML 3.2 standard as closely as possible, so that game designers can readily apply their HTML knowledge to writing games, there are probably many existing web pages that won’t work properly with multimedia TADS. HTML is a quirky and somewhat nebulously-defined language, and the behavior varies substantially from one browser to another, all of which makes it difficult to implement a browser that will handle every web page. Fortunately, multimedia TADS is not a general-purpose Web browser, so it shouldn’t ever see most of these problematic pages.
In addition to HTML 3.2, there is also a proposal for a version called HTML 3.0. Surprisingly, while HTML 3.2 is a more recent version of the language, it’s not a superset of HTML 3.0; in fact, HTML 3.0 is considerably more powerful than 3.2. This is somewhat confusing, because a higher version number on a standard usually implies some degree of backward compatibility with the older versions. What happened in this case is that HTML 3.0 never became a “standard,” and was never widely adopted; while work on the proposal for HTML 3.0 was underway, the HTML 3.2 specification was developed based on the older 2.0 standard.
In the meantime, because HTML 3.0 has some very nice and useful features, I’ve incorporated a few of its features into multimedia TADS. These additions don’t interfere with normal HTML 3.2 behavior, so a game designer familiar with HTML 3.2 should be able to use multimedia TADS without having to learn about HTML 3.0. See the section on HTML 3.0 additions below for details.
In addition, multimedia TADS has a few extra features that are specific to the TADS implementation. These features don’t have any equivalent in normal HTML, so I’ve added extensions to the language to accomodate. See the section on TADS additions below for details.
Multimedia TADS does not incorporate the extended features of HTML 4.0, cascading style sheets or any of the variants of DHTML.
I have tried not to deviate from HTML standards capriciously or needlessly, which is why most of the extensions that I’ve chosen to implement are based on HTML 3.0 rather than being entirely unique to multimedia TADS. I’ve tried to keep multimedia TADS compatible with the HTML standards as much as practical to reduce the amount you need to learn beyond standard HTML to use multimedia TADS.
The following tags from standard HTML 3.2 are not implemented:
HEAD BASE ISINDEX STYLE SCRIPT LINK META NXTID FORM INPUT SELECT OPTION TEXTAREAEssentially, everything related to forms is not implemented. This probably isn’t a big loss, since forms wouldn’t be all that useful in most adventure games. In addition, the hypertext structure tags, such as HEAD, ISINDEX, and NXTID, are not meaningful with the non-standard page model that multimedia TADS uses. Style sheets aren’t supported (in fact, they’re not supported in HTML 3.2 either; the STYLE tag in HTML 3.2 is a placeholder for future versions.) Finally, scripting and applets wouldn’t be useful, since multimedia TADS is an entirely “client-side” system to start with.
In addition, note that FRAMESET and FRAME are not supported in multimedia TADS. (These are not actually HTML 3.2 tags, but they’re worth mentioning here because some of the browsers that use HTML 3.2 as a baseline support frames, hence many HTML authors think of frames as an HTML 3.2 feature.) However, multimedia TADS has a separate tag, BANNER, that provides substantially the same functionality as frames.
As noted, I’ve tried to keep multimedia TADS as faithful to the HTML 3.2 standard as practical. However, since multimedia TADS is a somewhat different application than the designers of HTML had in mind, I’ve had to take some liberties to adapt the language to use in adventure games. For the most part, the tags that directly pertain to formatting follow the standard; most of the exceptions are related to the structural differences between an adventure game’s displays and standard HTML documents.
The BODY element can appear multiple times per document, unlike with standard HTML renderers. Each time <BODY> appears, any attributes (such as the background color or text color) replace the previous settings for those attributes; these settings affect the entire window.
Note that the BODY tag does not require (nor does it allow) a closing tag.
The TITLE element is optional, and can appear multiple times (HTML 3.2 requires exactly one TITLE element per document). The text given in the TITLE element is applied at the point the TITLE element is reached for the first time in the course of actually drawing the page (so titles are not re-applied upon scrolling a previous title back into view); each new title simply replaces any previous title.
The WIDTH attribute is not supported for these tags, but it is accepted and ignored by the parser. (This isn’t really a deviation, since WIDTH is only a hint to the renderer, and its behavior is defined by each renderer.)
The COMPACT attribute is accepted but has no effect. (Since the COMPACT attribute’s meaning is renderer-defined, this is not actually a deviation from the standard).
The NAME, REL, and REV attributes are accepted but ignored. The HREF attribute is interpreted not as a URL, as it would be by a normal browser, but as a command to be entered if the player clicks on the link (see the section on <A HREF> changes below.)
The ISMAP attribute is accepted but ignored. (In normal browsers, this attribute is intended for use with CGI server programs; CGI servers are not applicable to multimedia TADS.)
The USEMAP attribute only works with local image maps; i.e., the image map name can’t be a URL referring to some other document, but must be part of your game’s text output. Note that this means that the attribute value must start with a pound sign (#):
<IMG SRC="images/navbar.jpg" USEMAP="#navmap"> <MAP NAME="navmap"> ... etc ...Note that multimedia TADS will assume that a pound sign should be present if you don’t include one, hence all URLs will be interpreted as local, but you should always use a pound sign anyway to ensure compatibility with future versions.
Finally, though this strictly isn’t an HTML issue, remember that multimedia TADS supports only JPEG and PNG format images. GIF images are not supported.
You can re-use a MAP element’s name in multiple maps. At any given time, the most recent occurrence of a map with a given name simply replaces any previous occurrences of maps with the same name. This allows you to generate output containing the map for an image each time you display the image, without worrying about whether the map was displayed previously.
The SHAPE=POLY feature of the AREA tag is accepted, but is currently ignored. An AREA defined with SHAPE=POLY will effectively be a null area, and will never be hit. For now, you should use AREA=RECT or AREA=CIRCLE instead, approximating the polygon with a set of these other shapes.
The APPEND and NOENTER attributes, described in the notes on the <A HREF> tag, work the same way for the AREA tag.
Since multimedia TADS is based primarily on HTML 3.2, tags, markups, and attributes which are not otherwise described as implemented in the following sections are not implemented. However, in the interest of completeness, this subsection notes most of the HTML 3.0 features that are not implemented in multimedia TADS; this list is not necessarily complete.
The following tags from HTML 3.0 are not implemented:
LANG AU PERSON ACRONYM ABBREV INS DEL FIG FNNone of the math-related tags or markups are implemented.
The ID, STYLE, and CLASS attributes, which apply to nearly every HTML 3.0 tag, are not implemented (except where otherwise noted below).
The rest of this section lists features of HTML 3.2 that are implemented in multimedia TADS.
BQ is a synonym for BLOCKQUOTE.
The CREDIT tag can be optionally placed at the end of the contents of a BLOCKQUOTE (or BQ) sequence. CREDIT is a container and requires an end tag; the contents are the source of the quote.
<BQ>Gnomon is an island <CREDIT>Trinity</CREDIT></BQ>
(This is actually only mentioned in the HTML 3.0 proposal as an extension implemented by a few of the popular browsers; it’s not clear if NOBR is actually part of the HTML 3.0 proposal.)
This is a container tag. Text between the <NOBR> and corresponding </NOBR> will not be word-wrapped, so the only line breaks within the text will be those that are made explicitly by <BR> tags.
The NOWRAP attribute can be used on a paragraph to indicate that text within the paragraph is not to be word-wrapped. The only line breaks within the paragraph will be at explicit <BR> tags. This is equivalent to enclosing the text of the paragraph between <NOBR> ... </NOBR> tags.
The NOWRAP attribute can be used on most block-level tags, in addition to <P>. NOWRAP works with P, DIV, UL, OL, DL, the heading tags (H1 through H6), ADDRESS, and BLOCKQUOTE.
The BANNER tag allows non-scrolling areas to be added to the window. Multimedia TADS uses BANNER to implement the status line (in the traditional text adventure game sense of the line at the top of the screen that shows, for example, the name of the current location and the score). Although the HTML 3.0 BANNER tag has a somewhat different purpose, its behavior is essentially the same as is needed to implement adventure game status lines, so I’ve used this tag rather than creating a new tag. However, multimedia TADS’s BANNER tag has some new attributes; refer to the full description for more information.
The TAB tag provides simple alignment capabilities without the more complex TABLE structure. <TAB ID=abc> defines a tab named ‘abc’ at the current horizontal position in the line; this can occur within ordinary text to indicate an alignment position that can be used in subsequent lines. <TAB TO=abc> adds horizontal whitespace in the current line up to the position of the previously defined tab ‘abc’.
The ALIGN attribute can be used with <TAB> to specify the type of alignment to use. ALIGN can be used on the defining <TAB ID=abc>, or on each use of <TAB TO=abc>; if no ALIGN is used in the TO tag, the ALIGN from the ID tag is used by default; LEFT is used if neither has an ALIGN attribute. ALIGN=LEFT aligns the material after the <TAB TO> with its left edge aligned at the tab; ALIGN=RIGHT aligns the material after the <TAB TO> and up to the next <TAB TO> or the end of the line, whichever comes first, flush right at the position of the tab. ALIGN=CENTER aligns the material up to the next <TAB TO> centered on the tab position. ALIGN=DP aligns at a decimal point (or at any other character specified with DECIMAL="c", where “c” is the character at which to align entries).
<TAB ALIGN=CENTER> or <TAB ALIGN=RIGHT>, without a TO attribute, align the material with respect to the right margin. This provides a simple way of aligning material against the right margin (ALIGN=RIGHT), or centered between the end of the text up to the <TAB> and the right margin.
<TAB INDENT=n> (where n is a number) indents by a given number of “en” units; it simply adds the given amount of whitespace to the line. <TAB MULTIPLE=n> indents to the next multiple of the given number of ens from the left margin. You can use <TAB MULTIPLE> to get the effect of tabs set at regular intervals across the page, without having to set up a bunch of named indent points and figuring out which one you’re closest to.
The FONT tag accepts the FACE attribute, which takes a comma-separated list of typeface names. If the first typeface listed is available on the system, that font is used; if the first isn’t available, the renderer checks the second font, and so on until it runs out of fonts in the list or one of the fonts is available.
In addition to accepting explicit system font names, the FACE attribute also accepts “parameterized” font names, which let you specify a style of font that will be mapped to an appropriate system font on each platform. Refer to the parameterized font documentation for full information.
The BASEFONT tag accepts the FACE and COLOR attributes; these behave the same as they do with the FONT tag.
Most block-level tags recognize the CLEAR attribute. CLEAR on a block-level tag works the same way it does on a BR tag. The additional tags that accept the CLEAR attribute are DIV, UL, OL, DL, all of the heading tags (H1 through H6), ADDRESS, and BLOCKQUOTE.
The UL and LI tags accept the PLAIN attribute to indicate that the list item (in the case of LI) or all of the items in the list (in the case of UL) should be displayed without a bullet. If <LI PLAIN> is specified for an item in an ordered list, the item is displayed without a number. <OL PLAIN> is also accepted, even though it probably isn’t very useful (although it could conceivably be used to specify a numbered list where most but not all of the items are listed without a number; each of those to be listed with a number would have to specify a TYPE setting to override the default plain style).
The UL (unordered list) tag takes the SRC attribute to specify the name of an image to use as the bullet for the items in the list. This image is displayed in place of the bullet that would normally be used; if provided, the TYPE attribute is ignored.
The LI (list item) tag also takes a SRC attribute; this overrides the SRC attribute of the enclosing list, allowing you to use a special bullet for an individual item in a list.
For the OL tag, the SEQNUM attribute is equivalent to the START attribute.
The CONTINUE attribute (no value) specifies that the list numbering should continue where the last list left off. For example, if the last item of the previous list was 5, the new list will start with item number 6.
Multimedia TADS supports the HTML 3.0 <LH> tag. This tag comes immediately after a UL or OL tag, and prior to the first LI tag in the list. LH is a container tag; the material between the open and close tags constitutes the list header. The list header is set in boldface, on a new line aligned left at the same indent level as the material immediately preceding the list.
The LH tag is implicit for any material between a UL or OL tag and the first LI tag; that is, if you put material inside a list but before the first list item, it will be treated as a list header. This behavior is consistent with most browsers.
The HR tag accepts a SRC attribute, which specifies the URL of an image to display in the rule. The image is repeated as needed to fill out the space. If a SIZE attribute is given, it specifies the height of the rule; otherwise, the height of the image is used as the height of the rule. The value that <HR SRC> provides beyond <IMG> is that <HR SRC> repeats the image to fill a horizontal area, which can scale in proportion to the window size, whereas <IMG> just draws the image once.
The rest of this section covers extensions to the HTML standard used solely in multimedia TADS.
Multimedia TADS lets you use a backslash to indicate an end tag, whereas normal HTML would only accept a forward slash. So, <\TABLE> is equivalent to </TABLE>. (Since backslashes have no special meaning in HTML normally, this extension shouldn’t create any ambiguity.)
BANNER is a tag from HTML 3.0 that allows a document to create a non-scrolling area on the screen, and display arbitrary HTML markups within this area. Multimedia TADS uses BANNER, with a few extensions, to implement the “status line” that traditional text adventure games display across the top of the screen to show, for example, the current location and score.
Refer the to full description of the BANNER tag for details on how to use this feature.
As described in the <A> section on HTML 3.2 tag behavior deviations above, <A HREF> allows you to set up a “hypertext link” of sorts. Instead of specifying a link to a web page with a URL, multimedia TADS interprets the HREF as a command. When the player clicks on a link, multimedia TADS enters the text in the HREF attribute as a command (replacing any text that was on the command line already, and immediately entering the command without waiting for the return key).
In addition, the PLAIN attribute (which takes no value) specifies that the link is to be rendered as though it were normal text. The text will still act like a link, so any other (system-dependent) visual cues that the text is a link will still be in effect; for example, the mouse cursor will still change to the link shape when the mouse is moved over the linked text. This attribute is not meant to be used to hide important links from the user, and should be used carefully to avoid obscuring information; the purpose of this attribute is to allow specific links that are provided for convenience, but which are otherwise not critical, to be rendered in an unobtrusive fashion.
Two additional attributes, unique to multimedia TADS, let you control how the command text in the HREF is handled. Normally, when the player clicks on a link, TADS deletes any existing text on the current command line, puts the HREF text into the command buffer, and then immediately ends the command as though the player had pressed the Enter key.
You can change this default behavior in two ways. First, if the <A> tag specifies the APPEND attribute (which takes no value), the system does not clear the existing command text, but simply adds the HREF text to the end of the current command text. Second, if the tag specifies the NOENTER attribute (which also takes no value), TADS does not enter the command, but simply puts the HREF text into the command buffer, and lets the player continue editing the command.
Note that APPEND and NOENTER can be used the same way with <AREA> tags, which specify links in image maps.
As described in the TAB section on HTML 3.0 Additions above, multimedia TADS supports the <TAB> feature of HTML 3.0. Note, though, that the <TAB MULTIPLE> feature is a TADS-specific extension of the HTML 3.0 extension.
The <TABLE> tag accepts a HEIGHT attribute that lets you set an explicit height for the table. (This extension is supported by some of the popular browsers, but is not part of either the HTML 3.2 or 3.0 specifications.) As with the WIDTH attribute, the HEIGHT attribute can be specified as a pixel size or as a percentage of the total height of the display window; this is be useful for achieving special vertical alignment effects.
Note that a percentage value of HEIGHT in an embedded TABLE tag (a table embedded within another table) still bases the table’s height on the window’s height, not on the enclosing table row’s height. This is different than WIDTH with a percentage value, which bases an embedded table’s width on the width of the column containing it.
The CAPTION tag takes both ALIGN and VALIGN attributes. If ALIGN is set to TOP or BOTTOM, CAPTION behaves as it does in HTML 3.2. However, ALIGN can also be set to LEFT, CENTER, or RIGHT. If you want to control both horizontal and vertical alignment explicitly, use ALIGN for horizontal alignment, and use VALIGN for vertical alignment. The defaults are ALIGN=CENTER and VALIGN=TOP. If ALIGN is specified as TOP or BOTTOM, this is equivalent to setting VALIGN to the same value and using ALIGN=CENTER.
The BGCOLOR attribute can be used to specify the background color of an entire table (TABLE tag), all of the cells in a row (TR tag), or of an individual cell (TD or TH tags). The cell BGCOLOR setting overrides any setting inherited from the row, which in turn overrides the setting inherited from the table.
Multimedia TADS provides support for sound and music through the <SOUND> tag, which is an extension to HTML. Refer to Multimedia TADS Sounds and Music for details on how to use this extension.
The new <ABOUTBOX> tag allows you to define the contents of an “about box” for your game. On most GUI systems, by system-dependent convention, applications provide a menu item called “About” that displays a dialog box showing the name, version, and other relevant details of the application.
Multimedia TADS lets you define an about box for your game using this new tag. To define an about box, display the <ABOUTBOX> tag to start the information you want to include in the dialog, then display any HTML text, then display the </ABOUTBOX> closing tag. You will probably want to put this display in your init function, since you’ll only need to display it once, at the beginning of the game.
Here’s an example of using the tag. Note that we put the about box code in the commonInit function, because we want to make sure that this text is displayed whenever the game is loaded, regardless of whether it’s loaded with a saved game or not. We assume in this example that your init and initRestore functions (one of which the system automatically calls at startup, depending on whether the player starts your game from the beginning or with a saved game) each call your commonInit function (which the system does not automatically call, but is merely a convention used in std.t).
commonInit: function { /* run this game in HTML mode */ "\H+"; /* set up the about box for the game */ "<AboutBox> <body bgcolor=silver> <H3 align=center>A Sample Game</H3> <center> This is a sample game that demonstrates some exciting new Multimedia TADS features. </center> </AboutBox>"; }The information within the ABOUTBOX tag doesn’t show up in the normal text window. Instead, TADS captures the information and stores it away, so that it can be displayed when the user brings up the “About this game” dialog. (The “About this game” command is on the “Help” menu in the HTML TADS for Windows, and under the Apple menu in HyperTADS for Macintosh. If the game never defines an about box, the menu item is disabled.) When the user displays the game’s about box, multimedia TADS opens a dialog box showing the ABOUTBOX information.
Multimedia TADS has a few character markups that aren’t in the normal set, to provide access to some typographical characters that normal HTML doesn’t provide. Note that these extensions are compatible with HTML 4.0.
Many of these characters map to their regular ASCII equivalents for systems whose character sets do not include the typographical characters. In particular, ‘ and ’ map to an apostrophe, “ and ” map to a double-quote character, and &endash; and &emdash; map to a hyphen. Other characters listed have no direct ASCII equivalent, and may render as a blank in character sets without these character.
In addition to the entities listed above, multimedia TADS supports all of the named entities in HTML 4 in the section “symbols, mathematical symbols, and Greek letters.” In fact, multimedia TADS supports nearly all of the HTML 4 named entities; the only entities not currently supported are the spacers and joiners (ensp, emsp, thinsp, zwnj, zwj) and the bidirectional markers (lrm, rlm).
Because the list of HTML 4 named entities is lengthy, it’s not included here; refer to the HTML 4.0 specification for the full list.
Multimedia TADS also supports the ISO Latin-2 named entities. ISO Latin-2 is a character set designed for Eastern and Central European languages. The Latin-2 named entities are not part of the standard HTML specification, but some provide this set of entities as an extension. Refer to the multimedia TADS supported entity table for the complete list.
The FONT tag’s FACE attribute (which is an HTML 3.0 extension) accepts, in addition to actual system font names, a set of “parameterized” font names. These parameterized names let you specify a style of font more specifically than you can with any of the HTML phrase-level style markups, while still retaining portability.
When you use a parameterized font, instead of naming a system font explicitly, you name a special pseudo-font. Multimedia TADS maps this name to an actual font at run-time according to the fonts available on the system. Because the mapping is done at run-time, the parameterized fonts are portable - the multimedia TADS interpreter chooses an appropriate mapping for the current system when the game is played.
In addition, on some systems, multimedia TADS allows the player to choose the mapping through a preferences mechanism, so parameterized fonts give both the game author and the player control over the presentation: the game author specifies the abstract style desired, and the player chooses the final display appearance.
Here are the available parameterized font names:
You should consider using parameterized fonts whenever possible rather than explicit system font names. Using explicit system font names creates portability problems not only to different types of computers, but even to the same type of computer, because you can’t always be sure of which fonts a player will have installed. Parameterized fonts provide much better portability, because multimedia TADS will determine which actual system font to use at run-time.
Note that you can also use parameterized font names as a fallback for an explicit system font for when the font is not installed. A common strategy that web page designers employ when specifying fonts is to specify a series of fonts that are common on various platforms as substitutes for a particular system font; for example, Arial on Windows is similar to Geneva on Macintosh, so Geneva is often used as a fallback for Arial. You can take this one step further using a parameterized font. Since the parameterized font lets you specify the style of font you want, you can use it to provide a good substitute when the font you really want isn’t present. For example, since Arial is a sans serif font, you might specify TADS-Sans as a fallback when Arial isn’t installed:
<font face='Arial,Geneva,TADS-Sans'>Here’s an example of selecting a script-style font using the parameterized font mechanism.
"The wedding invitation reads: <p> <center> <font face='TADS-Script'> Mr.\ and Mrs.\ Dimwit Flathead III <br>request <br>The Honour of Your Presence (etc.) </font> </center>";You’ll probably use the TADS-Input font a little differently than the others. This font is meant only for text entered by the player on command lines; the point is to allow the player to select the font and style (including color, bold, and italic settings) that should be used for entering commands. Normally, you should define a commandPrompt function and a commandAfterRead function like this:
commandPrompt: function(code) { "><font face='TADS-Input'>"; } commandAfterRead: function(code) { "</font>" }The commandPrompt function displays the usual prompt (“>”, using the HTML entity name for the greater-than sign, “>”), then establishes the TADS-Input font, which uses the font for text entered by the player. After the player finishes editing the command and presses Enter, the commandAfterRead function closes the <FONT> tag to restore the previous font.
Note that the standard library file std.t includes a definition of the commandPrompt and commandAfterRead functions as shown above, so if you don’t override these functions, you’ll get this new behavior by default.
Several tags have attributes that let you specify a color setting; for example, you can set the color of a run of text using the FONT tag with a COLOR attribute:
<FONT COLOR=RED>This is some red text!</FONT>For these settings, standard HTML defines a set of color names (BLACK, SILVER, GRAY, WHITE, MAROON, RED, PURPLE, FUCHSIA, GREEN, LIME, OLIVE, YELLOW, NAVY, BLUE, TEAL, and AQUA), and also accepts explicit hexadecimal RGB values (for example, COLOR="#203040" specifies a color with hex 20 intensity in red, hex 30 intensity in green, and hex 40 intensity in blue, with each intensity on a scale from zero to hex FF). Here are the color names:
Background Colours Text Colours on Black Text Colours on White black black black silver silver silver gray gray gray white white white maroon maroon maroon red red red purple purple purple fuchsia fuchsia fuchsia green green green lime lime lime olive olive olive yellow yellow yellow navy navy navy blue blue blue teal teal teal aqua aqua aqua While the HTML color attributes provide considerable flexibility and control in defining your game’s display characteristics, they also remove control from the player and from the operating system. On some displays, particular combinations of colors and fonts may produce unreadable text, and in many cases players may wish to choose certain settings for themselves because they prefer a certain color scheme.
Multimedia TADS provides an extension to the standard HTML color system that provides for some player customization and still lets the game author specify most of the display characteristics. These new colors are called “parameterized” colors, because they do not refer to hard-coded RGB values the way that other HTML colors do, but instead refer to specific parameters that are chosen at run-time.
On some systems, the player can set the colors through a preferences mechanism, while on others the system may choose appropriate colors for the display device.
To use the parameterized colors, simply use the parameterized color names in place of the ordinary HTML color names. For example, the default status line code in adv.t uses these settings for the status line:
<body bgcolor=statusbg text=statustext>The parameterized color names are listed below.
- statustext: status line text color.
- statusbg: status line background color.
Multimedia TADS supports the HTML 4.0 <Q> tag. This tag encloses a passage in quotation marks (by placing an open quote where the <Q> tag appears, and a matching close quote where the </Q> ending tag appears). <Q> uses typographical quotation marks (“”)if available on the interpreter platform, and automatically alternates between double and single quotes when <Q> tags are nested. It follows the North American convention of starting with double quotation marks and then using single, rather than the UK convention of the reverse.
| Appendix G | Table of Contents | Appendix I |