Potential problem with Frotz and text styles

[GoogleCodeExporter]

Although the Z-machine standard is slightly unclear on the following matter, I 
believe that what I'll describe is accurate.

Currently, Frotz sets the text style (as set via @set_text_style) separately 
for each window; changing the style while the upper window is the current 
window does not change the style for the lower window, and vice versa.

This is clearly the correct behavior for V6 (see §8.8.3.2.3), but there is no 
indication that it's correct for the other versions.  Rather, the text style 
for those should be global.  There is one very compelling reason to believe 
this is the intended behavior: Start up Border Zone, and select The Border.  
The text is bold up until the point that it turns italic; after the italic 
(which is bold italic), it goes back to roman.  The effect is certainly not 
what was intended, and by making styles global, the proper effect is achieved.

Another compelling reason to believe that styles should be global is that 
that's how Windows Frotz does it, and in my (fairly numerous) tests of arcane 
Z-machine functions, Windows Frotz has consistently been outstanding in being 
properly implemented.

I'm attaching a patch that implements global styles.  It's quite simple: window 
styles are no longer tracked, and every time @set_window is called, the style 
is updated via a call to z_set_text_style().  I've tested some other story 
files and everything appears to be in order; nevertheless, such a change should 
probably see some more testing.

Original issue reported on code.google.com by cspiegel@gmail.com on 10 Sep 2010 at 1:10

Attachments:

• styles.diff

[GoogleCodeExporter]

From ZSpec 1.0, section 8.8.3.2.3
http://www.inform-fiction.org/zmachine/standards/z1point0/sect08.html

"The text style is set just as in Version 4, using set_text_style (which sets 
that for the current window)."

So I do feel pretty confident that per-window styles are the correct behavior. 
But you're right that Border Zone isn't running properly. I logged all the 
calls to z_set_text_style and came up with these:

z_set_text_style    lower   2
checked fixed flag in header!
z_set_text_style    lower   f000
called z_erase_window with ffff!
z_set_text_style    upper   1
z_set_text_style    upper   0
<... lots of upper calls snipped ...>
z_set_text_style    lower   4
z_set_text_style    lower   0

It's that final call to z_set_text_style, lower window active, with a zero 
value that sets everything back to roman printing, after the very first call 
sets it to bold.

The upper window calls are a bit of a red herring since all they do is turn on 
and off reverse printing. By making styles global, it causes that earlier 0 
value to set everything back to Roman type, which in this case is the desired 
behavior.

What I think needs to happen is that the z_erase_window call (-1) should turn 
off active text styles. This is essentially the opposite of the way colors 
work, since those persist across window erasures, but consistency is after all 
the hobgoblin of small minds.

Original comment by bcressey@gmail.com on 10 Sep 2010 at 4:53

• Changed state: Accepted

[GoogleCodeExporter]

That parenthesized text in 8.8.3.2.3 is the reason I find this to be slightly 
unclear.  I read it as extending the V4/5/7/8 model, since 8.8 is the V6 
section, and it also includes window properties, including text style.  8.7, 
the V4/5/7/8 model, does not mention windows.  But then, 8.7 doesn't mention 
windows for fonts (apart from mandating a fixed font for the upper window), 
while the description of the set_font opcode explicitly says it changes the 
font for the current window (set_text_style says no such thing).  If we had 
some of Infocom's interpreters to test with, that would be very helpful....

Ultimately, as long as Border Zone works, and other games don't break, however 
this gets fixed is fine, I suspect.

Original comment by cspiegel@gmail.com on 10 Sep 2010 at 7:05

[GoogleCodeExporter]

After some more review, it seems like your first interpretation must be the 
correct one. As you say, Windows Frotz treats text styles as global except in 
the case of V6, so that must be the way to go.

Original comment by bcressey@gmail.com on 10 Sep 2010 at 8:25

[GoogleCodeExporter]

Original comment by bcressey@gmail.com on 10 Sep 2010 at 8:39

• Changed state: Fixed