Right, this is just about suggested filenames coming from zcode, especially in the context of unprompted saves.
§ 3.8.2.2 and § 3.8.2.4 describe the tab and sentence space characters, whitespace characters wider than the normal space. How should these display when a fixed-width font has been selected?
Probably as a single space? Even though this is V6 only, if they were used in a window mimicking the upper window of V5, a single space makes sense to avoid throwing off any other text layout. Iâm not fond of specifying 2 or more characters be substituted for one.
Edit: Tab is already specified to convert to a single space if it occurs in the middle of a sentence, so thereâs some consistency there.
1 Like
This is my assumption, too, but I thought it would be best to get a consensus of some sort since the Standard is currently a little vague.
1 Like
In §15, the descriptions for the save and restore, when describing the extra operands for auxiliary file access, include the text:
(Whether Infocom intended these options as part of Version 5 is doubtful, but itâs too useful a feature to exclude from this Standard.)
The Infocom spec document for xzip confirms that it was indeed a part of the design for v5 (and Beyond Zorkâs code has a commented-out routine to save the character data to a file).
2 Likes
I recall Beyond Zork actually doing this back in the day. Chalk it up to the Mandela effect I suppose.
Well, I think it does that to the saved macros (F1 to type "examine ", etc.), so maybe thatâs what youâre thinking of.
It looks like Zork Zero does that, but not Beyond Zork. If any Infocom v5 game had actually used auxiliary files, itâs unlikely the Standard would have been worded like it was.
2 Likes
Thereâs an actually, technically here. Barry Boone was the first person to reverse-engineer the Z-machine, and he extensively modified Infocomâs TI 99/4A terp and was sharing his version in '86. My understanding is that no one outside the TI 99/4A crowd knew about it at the time, and it had no influence on the InfoTaskforceâs work; their terp was originally published in the summer of '87.
4 Likes
Yeah, I know Beyond Zork doesnât do it, but I still remember it that way. You may have hit on the reason thoughâŚIâm probably conflating my memories of Beyond Zork with Zork Zero.
1 Like
§ 3.8.5.1 mentions the ConScript Unicode Registry, which was/is an attempt to use the Private Use Area(s) of Unicode to encode constructed/artificial scripts.
The website for the ConScript Unicode Registry is ConScript Unicode Registry. The registry itself appears not to have been updated since 2008. Relatively few scripts within it are in a finalised and completely stable state.
It seems unlikely at this point that any of this will ever be used by a z-code game, or indeed supported by a z-code terp. However, I do not think we should remove this from the Standard.
Instead, I think being a little more clear on what the Standard expects is a good idea.
I propose we add to the Standard a link to the Registry website, and a statement that only finalised scripts (those marked âregisteredâ on that website) are considered part of the Z-Machine Standard.
As new script become finalised in the ConScript Registry (if they ever do), they become part of the Z-Machine Standard. In theory, no finalised script should ever be removed from the registry.
None of this requires interpreters to support any part of the ConScript Registry, now or in the future. Interpreters are completely Standard compliant if they treat the whole area, or any part of it, as unprintable, unknown Unicode characters.
1 Like
I think itâs fine to leave in. The site seems pretty dead though.
I find it odd that the standard doesnât state that printing in the upper window always be fixed pitch for V3. It only mentions it for V4+ (except V6) in section 8.7.2.4.
1 Like
Itâs not a requirement in V3. See the screenshots from Infocomâs Mac interpreter:
Enchanter screenshots - MobyGames
The status line is Chicago, which is a variable-pitch font.
Since @set_cursor was not available in V3, there was no notion of drawing characters at specific horizontal positions. Just an object name on the left and the score/time display on the right. So there was no need to know where individual characters fell.
But the status line in V3 is not the upper window. As far as I know, the only game using the upper window in V3 is Seastalker, which definitely requires fixed pitch for the sonarscope display.
Edit:
Thinking about the various screen models in use can sometimes trip me up when Iâve been away from it for some time. My understanding is that -
V1, V2 - one window + simple status line
V3 (everything except for Seastalker) - same as V1, V2
V3 (Seastalker) - lower window + upper window + simple status line
V4, V5, V7, V8 - lower window + upper window
V6 - MOAR windows!
1 Like
Oh, well, thatâs why nobody ever remembers about that.
I think any discussion of this has to discuss Seastalker as a special case.
The standardâs entire section on V3âs screen model is pretty much specific to the upper window of Seastalker, without mentioning it by name. The only thing not mentioned is anything about fixed pitch, which really seems like an oversight.
The thing I mentioned about fixed pitch in V3âs upper window is really the tip of the iceberg. The standardâs rules on fonts and text styles are, um, confusing to say the least.
Section 8.1 says:
Text may be printed in any font of the interpreterâs choice, variable- or fixed-pitch: except that when bit 1 of âFlags 2â in the header is set, font 4 has been selected, or when the text style has been set to Fixed Pitch, then a fixed-pitch font must be used. The fixed pitch-bit is deprecated in Version 5 and later, and interpreter support in Version 6 is optional.
Seems simple enough except for the last sentence. In V5+ the flag is deprecated, but what does this mean practically, if it isnât optional to support it except in V6?
Later we get section 8.7.2.4 applying to versions 4+ (except 6):
An interpreter should use a fixed-pitch font when printing on the upper window.
Why V3âs upper window is not also required to have fixed pitch is a mystery. Maybe Seastalker always use bit 1 of Flags 2 when printing to the upper window and the standardâs authors felt it wasnât necessary to add another separate rule? The standard appears inconsistent.
In section 11.1, the entry for Flags 1 (V4+) allows an interpreter to claim to not support bold, italic, or fixed-pitch at all, but can not do the same for reverse style. It is clear this was designed for use by set_text_style (also V4+), but how does this interact with upper window printing, or printing triggered by bit 1 of Flags 2?
Next we come to the description of the set_text_style opcode:
Sets the text style to: Roman (if 0), Reverse Video (if 1), Bold (if 2), Italic (4), Fixed Pitch (8). In some interpreters (though this is not required) a combination of styles is possible (such as reverse video and bold). In these, changing to Roman should turn off all the other styles currently set.
[1.1] As of Standard 1.1, it is legal to request style combinations in a single set_text_style opcode by adding the values (which are powers of two) together. If the parameter is non-zero, then all the styles given are activated. If the parameter is zero, then all styles are deactivated. If the interpreter is unable to provide the requested style combination, it must give precedence first to the styles requested in the most recent call to set_text_style, and within that to the highest bit, making the priority Fixed, Italic, Bold, Reverse.
The first part mentions combinations being possible, but says support is not required. It is unclear if combinations are triggered by single calls with combined flags, or by separate calls with the styles being applied cumulatively. The section for 1.1 muddies the waters further in describing a priority system for handling combinations and mentioning âmost recent callâ as part of the decision process. All of this makes it very unclear what a compliant interpreter must actually do.
Next we come to V5+ and fonts:
Section 8.1.2 says:
An interpreter should ideally provide 4 fonts, with ID numbers as follows:
- 1: the normal font*
- 2: a picture font*
- 3: a character graphics font*
- 4: a Courier-style font with fixed pitch*
It then goes on to say:
Ideally all text styles should be available for each font (for instance, Courier bold should be obtainable) except that font 3 need only be available in Roman and Reverse Video.
This appears to imply all styles beyond the default: Roman, are optional for all fonts, with the possible exception of reverse for font 3. Is it saying reverse is required for font 3, or that reverse is optional, but styles other than reverse are unneeded (or invalid?) for font3?
Section 16 on font 3 makes it clear that this must also always be a fixed pitch font.
Section 8.1.3 makes all fonts other than 1 optional:
A game must not use fonts other than 1 unless allowed to by the interpreter
After this font 2 is effectively declared invalid in 8.1.4.
All this taken together:
In V3+ (except V6 where support is optional) fixed pitch can be forced by the game setting a header flag.
In V4+ fixed pitch is always used in the upper window. (Should be V3+, in my opinion)
In V4+ an interpreter can deny support for bold, italic, or fixed pitch styles through header flags, but not for reverse style.
In V4+ style combinations are supported but not required, although the exact mechanism for that is unclear.
In V5+:
Font 1 - required, all text styles recommended, but none required.
Font 2 - invalid
Font 3 - optional, Fixed pitch by nature, reverse style may be required but the text is unclear, others are optional or maybe illegal, again the text is unclear.
Font 4 - optional, Fixed pitch by nature, all text styles recommended, but none required.
âConfused? You wonât be after this weekâs episode of Soap.â
1 Like
Interpreters must support the flag in v5, but games shouldnât use it. Interpreters donât have to support it in v6, and games still shouldnât use it.
Honestly, I imagine this was just down to the upper window being a v4+ thing, before realising that v3 needs an upper window for Seastalker, and not updating all the text properly.
No idea.
If you set a single style, and then set another, the second style may either overwrite the first, or combine with it. Setting Roman style clears all styles. This is what the first paragraph means, although it may be worth making it explicit.
If you set multiple styles at once, and the interpreter can only support one style at a time, it uses the priority described to decide which style to set. As always, later calls can overwrite previous ones. This is what the second paragraph means.
Itâs saying sometimes interpreters canât support styles, but they should if possible. Font 3 doesnât ever support fixed pitch (because it already is) or italic (because no games ever used it and the fonts used didnât support it).
The section on fonts could do with being a little clearer in some ways. Font 4 is required, font 2 is undefined and invalid, font 3 has a very limited number of characters.
Ah, that makes sense. Deprecated applies to usage in games, not support from interpreters. The text could be a bit clearer I think.
Agreed.
Since fixed pitch in some form is clearly always required. It would be logical to assume these flags only apply to styles being set directly via set_text_style and have no impact on fixed pitch printing in the upper window or when being forced by header flag. That doesnât make them very useful, but in the face of style combinations and (in V5+) multiple fonts, theyâre marginally useful at best anyway. The omission of a flag for Reverse style is weirdly inconsistent too, implying it is always supported. A game could always ignore these flags and issue set_text_style instructions with unsupported styles anyway, so their only apparent use would be for a game to find alternative ways to display text given an interpreter claiming lack of support. This makes the omission of a Reverse flag even stranger, as not supporting Reverse printing seems infinitely more likely than not supporting fixed pitch.
Ok, after re-reading this many times I think I get it, at least partially. The part about giving preference to the most recent call is what was tripping me up. I see now the text means preference goes to the current call, not the most recent previous one, which is what I thought before.
So letâs do an example: A previous call sets style to Reverse+Fixed, which is supported. The current call sets Bold+Italic, but our hypothetical interpreter doesnât support all four at once, so preference is given to Bold+Italic and within that the priority is: Italic first, Bold second.
What isnât clear is given that Reverse+Fixed+Bold+Italic is not supported, should we try to partially combine the previous styles with the current call, e.g. Fixed+Bold+Italic and Reverse+Bold+Italic, or do we immediately discard all styles from the previous call in favor of testing combinations for just the current call.
Yeah, I get that. I just think it has some odd consequences. Making Font 4 required helps to resolve some.
1 Like