Z-code alphabet table

Technical Development Specifications
1

According to the spec:

3.5.3
In Versions 2 to 4, the alphabet table for converting Z-characters into ZSCII character codes is as follows:

   Z-char 6789abcdef0123456789abcdef
current   --------------------------
  A0      abcdefghijklmnopqrstuvwxyz
  A1      ABCDEFGHIJKLMNOPQRSTUVWXYZ
  A2       ^0123456789.,!?_#'"/\-:()
          --------------------------

(Character 6 in A2 is printed as a space here, but is not translated using the alphabet table: see S 3.4 above. Character 7 in A2, written here as a circumflex ^, is a new-line.) For example, in alphabet A1 the Z-character 12 is translated as a capital G (ZSCII character code 71).

I interpret this as saying that character 6 in A2 is not translated using the alphabet table, but character 7 in A2 is translated using the alphabet table.

A later paragraph says this also applies for version 5, with the addition that the alphabet table can be replaced by the story file.

So, to the question:

When replacing the alphabet table in an Inform game, it’s easy to make the mistake of writing a circumflex for new-line, since you write this as a set of strings and circumflex normally translates to a new-line in a string, but these strings are special and writing a circumflex will indeed put a circumflex in that position. And, quite possibly, no one actually ever tries to move the new-line character in the table.

What do you suggest an interpreter should do here?

(a) adhere to the standard and print whatever is in position 7 in A2
(b) be nice to Inform games and assume that position 7 in A2 is a new-line

EDIT:

DM4 has an example of a replacement alphabet table where position 7 in A2 is no longer a newline but a digit.

If Windows Frotz discovers a circumflex in this position, it is printed as a newline. I don’t know yet if this only goes for circumflex.

2

Section 3.5.5.1 seems pretty clear:

Such an alphabet table consists of 78 bytes arranged as 3 blocks of 26 ZSCII values, translating Z-characters 6 to 31 for alphabets A0, A1 and A2. Z-characters 6 and 7 of A2, however, are still translated as escape and newline codes (as above).

3

Thanks, yes this is clear. This means 3.5.3 is not very accurate. And it means the example in DM4 is broken.

4

Which example?

5

There’s just one I think, in “§36 Parsing non-English languages”. Find “alphabet table” in the index and it leads you there.

6

Alternatively, and provided no characters have so far been used at all, you can write a Zcharacter directive which sets the entire alphabet table. The form required is to give three strings containing 26, 26 and 23 ZSCII characters respectively. For instance:

Zcharacter "abcdefghijklmnopqrstuvwxyz"
           "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
           "0123456789!$&*():;.,<>@{386}";

Note that it says that the third line has less characters, so I think the zero should be character 8. I’m not sure why it says only 23 characters though, shouldn’t it be 24?

Oh wait, from earlier in that paragraph:

One of these is mandatorily new-line, another is mandatorily double-quote and a third cannot be used, leaving 75.

So does this mean Inform manually hardcodes A2 char 26 to be "? and it just inserts that into the string you specify?

Actually, no, it looks like if you replace the whole table, Inform will move " to A2 char 8: