Implementation of fixed-width fonts in the main window

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I6 code containing a "font off" line in output to the main-screen
2.
3.

What is the expected output? What do you see instead?

Output should switch to a fixed-width font, which enables ASCII art in
games that need to display diagrams, etc. 

What version of the product are you using? On what operating system?

Firefox 2.0.0.14

Please provide any additional information below.

Original issue reported on code.google.com by jon.ing...@gmail.com on 27 May 2008 at 1:17

[GoogleCodeExporter]

Thanks for the bug report!  Do you have any examples of games that use the
fixed-width font, or sample Inform code that could be compiled to test it out?

Original comment by var...@gmail.com on 28 May 2008 at 1:16

[GoogleCodeExporter]

Quickest example to reach I can think of is in "Jigsaw" by Graham Nelson, which
requires getting inside the pyramid. I think the shortest route is

E
GET SPARKLER
W
TAKE PIECE
W
CLIMB PYRAMID
BURN CONDUCTOR
D
IN
IN
CLEAN DUST
PUT PIECE AT A1
X BOARD

Original comment by jon.ing...@gmail.com on 2 Jun 2008 at 9:45

[GoogleCodeExporter]

I investigated this yesterday for a while and I'm having trouble figuring out 
what
opcode the 'font on' and 'font off' instructions correspond to; I thought it 
might be
the set_font opcode, but that doesn't seem to be getting called.  Then again, 
looking
at Gnusto's code, it looks like Gnusto only supports one font, and it may be 
setting
bits in headers, etc. to ensure that the Z-file never executes the set_font 
opcode or
something.

I'll continue to look into this.

Original comment by var...@gmail.com on 17 Jun 2008 at 12:45

• Changed state: Accepted

[GoogleCodeExporter]

The following is the URL for a saved-game to the commands issued by jon in 
comment 2.
 Just type "x board" to see the flaw.

http://parchment.googlecode.com/svn/trunk/parchment.html?story=http://parchment.
toolness.com/if-archive/games/zcode/Jigsaw.z8.js#Rk9STQAAAvJJRlpTSUZoZAAAAA0AAzk
1MTEyOZWuAQJcAENNZW0AAAKfAB8ZUAD/AP8AzqwAAK0AAJUADBEACIYA/wD/AOSoAACpAAQIAAACAAK
vAP8A/wD/APwPAAiAAAYBAAqTAAySAASAAACAAAaVAAIIAASbAACQABoRAJKAAAoCAA6AAAYDAAikABa
AABTvAC6AAAaiAAoeAACvAAisAAYCAAEgAAGtAAJHAP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD
/AP8A/wD/AP8Ap2MA/wD/AP8A/wD/AP8A/wD/AGkBAD4CADkCAEECAEACAD8BAEMDAEMBAIYCAEABAEQ
BAEkCAEEBAEQDAEMBAP8A/wD/AP8A/wD/AP8A/wgA/wD/APUEvgD/AP8A/wD/AP8A/wD/AP8A/wD/AP8
A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8
A/wD/AP8A/wD/AOmtAAAXAAAy+mn//AAAAgAAAwAAEAAADwAKAwAIrAH/AAQPAACsAAAGAAQBAAwBAAY
BAAgCAAQBAAICAAABrCkAAAEACAEAAAEADgEAAgEAAAMABZpWAACvAACvAAQIAAgBAAoBAAABAAX//wA
EBgAOAQAOAQASAQAB//8AGAQAAAgAKAEATgEATAEAAKMAPQIAPwRzYXZlIGF0IGJvYXJkYTEAaAGsKQQ
CgGQCB4OOBQoAAQIPAC8GAP8AWAGsKQQCgGQCB4OOBQoAAQIPADOvABABAAdAA52/BAKAZAIHAACvAP8
AIX6gfwsAw0cAFQEAJAMAAAMAAAMAAAMAAAMAAAMAAAMAAAMA/wARA1cDNAEsBZMFQgK9AAECWQWHAWg
CRAKlBZEAAQSFBHcA/wCok46Tk5OYk5wAAZOeACcAU3RrcwAAACgAAAAAAAAAAAC8ZBQAAAAAAAAAFAA
AAAAA5E4QAAAAAADmMQD/AAAA

Original comment by var...@gmail.com on 17 Jun 2008 at 12:51

[GoogleCodeExporter]

Ok, I think I figured this one out.  I first wrote the following Inform 6 code:

  [ Main;
  font on;
  font off;
  ];

Using the Inform compiler's '-t' command-line option, I determined that 'font 
on'
corresponded to the following assembly code:

    2  +00009 <*> loadw        short_0 short_8 -> TEMP1 
                               0f 00 08 ff 
    2  +0000d     and          long_65533 TEMP1 -> TEMP1 
                               c9 2f ff fd ff ff 
    2  +00013     storew       short_0 short_8 TEMP1 
                               e1 5b 00 08 ff 

and 'font off' corresponded to this:

    3  +00018 <*> loadw        short_0 short_8 -> TEMP1 
                               0f 00 08 ff 
    3  +0001c     or           short_2 TEMP1 -> TEMP1 
                               28 02 ff ff 
    3  +00020     storew       short_0 short_8 TEMP1 
                               e1 5b 00 08 ff 

So in other words, the font on/off commands just twiddled the second bit of 
flags 2.
 Yet this wasn't triggering a GNUSTO_EFFECT_FLAGS_CHANGED effect in the code.  It
appears that this is because Gnusto was looking at the second bit of byte 0x10 
of the
Z-Machine's memory, which is where flags 2 is located--but the bytecode above 
uses
the loadw/storew instructions to write to flags 2, and as far as I can tell, the
Z-Machine appears to be big-endian (I couldn't find anything in the Z-Machine
Standards Document that explicitly said this, but Gnusto's implementation of
loadw/storew is big-endian, and Glulx and Quetzal are big-endian too, so 
evidence
points in that direction).  This means that the second bit of flags 2 is 
actually at
byte 0x11 of the Z-Machine's memory, not byte 0x10.

After making the appropriate changes in r66, viewing the Jigsaw pieces now 
seems to
work properly.

There are currently two quirks, though: the line height for fixed-width fonts 
in the
lower window isn't dynamically set the way it is in the upper window, which 
means
that it doesn't look ideal when used with reversed text, and on MSIE 6 
consecutive
spaces get collapsed for some reason, irrespective of whether I use 
'white-space:
pre;' as the CSS style or replace all space characters with non-breaking 
spaces. 
Guess I'll file these two as new bugs.

Original comment by var...@gmail.com on 18 Jun 2008 at 1:20

• Changed state: Fixed

[GoogleCodeExporter]

Added the two bugs mentioned in my last comment as issue 39 and issue 40, 
respectively.

Original comment by var...@gmail.com on 18 Jun 2008 at 1:28

[GoogleCodeExporter]

Ben Collins-Sussman just told me that the big-endianness of the Z-Machine is
specified in section 4.2.1 of the standards document:

"Large constants, like all 2-byte words of data in the
Z-machine, are stored with most significant byte first (e.g. $2478 is
stored as $24 followed by $78). A 'large constant' may in fact be a
small number."

So I believe the fix is correct.

Original comment by var...@gmail.com on 18 Jun 2008 at 4:16