[I6] Word wrapping of string in source code

Technical Development Specifications
1

To make my source code more readable, I always cut my strings to 80 characters by a line break and a tab. But I realize that there is a difference in display between these two strings:

Array Messages–>
   “^Eat, Look, Open, Pick, Pour, Throw, Unlock, Read, Place, Give, Enter, Hit,^Go, Light/On, Off, Insert, Talk, Wait, Jump, Drink.”
   “^Eat, Look, Open, Pick, Pour, Throw, Unlock, Read, Place, Give, Enter, Hit,
   ^Go, Light/On, Off, Insert, Talk, Wait, Jump, Drink.”;

My strings are in an array.
Depending on the width of the interpreter (Frotz or Gargoyle Bocfel), I have an extra line break or not.

Eat, Look, Open, Pick, Pour, Throw, Unlock, Read, Place, Give, Enter, Hit,
Go, Light/On, Off, Insert, Talk, Wait, Jump, Drink.

Eat, Look, Open, Pick, Pour, Throw, Unlock, Read, Place, Give, Enter, Hit,

Go, Light/On, Off, Insert, Talk, Wait, Jump, Drink.

Am I clear?

2

Unless I’m mistaken, the Inform 6 mechanism of allowing you to put a line break anywhere in a string only works if you break where there should be a single space character. So these print statements are equivalent:

print "I am a jelly doughnut.";
print "I am a
    jelly doughnut.";

But these aren’t:

print "I am a jelly doughnut.";
print "I am a jelly dou
    ghnut.";
4

The display is correct with Ozmoo; both strings are equivalent but not with Frotz.

print "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^bcde";
new_line;
print "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
   ^bcde";
new_line;

Ozmoo:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bcde
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bcde

Frotz -w 40 (or WindowsFrotz):

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bcde
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

bcde

5

Whitespace followed by a newline is not the same thing as a single whitespace. Try doing it only at a point where the string contains a regular space, not a ^.

6

Ozmoo has a mechanism in place to use all 40 columns on the Commodore 64 screen without getting an extra linebreak when text ends in the last column.

The people who wrote Infocom’s own interpreters for the C64 avoided this problem by never using the rightmost column.

My guess is that the difference is there because Frotz doesn’t have this mechanism.

7

To the extent that the number of columns can be defined, the algorithm should take it into account. But this does not explain the difference in the display depending on whether the string is cut in the source or not. There should be an extra line in both cases.

8

What seems happens in the second example is that the line of “a” fills up the entire row. Then there’s a space, followed by a newline. I’m guessing Frotz thinks this space needs to be preserved, so it’s printed on the next line, before printing the newline. I guess Ozmoo doesn’t?

For instance, Unix Frotz has no problem word-wrapping this on an 80-column screen:

[ Main;
    "Some people say that it is madness to spend time endlessly writing
    and rewriting every word to try to get a text nicely aligned. Such an
    exercise, they say, is a clear sign of mental decline. However, since
    I have yet to see even the smallest piece of evidence that anyone
    would actually do something like that, I have come to the inevitable
    conclusion that those who spread such insane rumors are either trolling
    or sadly mistaken. We need to stop spreading these fairy tales at once!^";
];

But if I insert a “^” right before “every” (after the space), I get a blank line between the first and second rows.

I’m not sure which is the correct behavior.

9

Right. You could see it as Ozmoo being wrong here, or you could see it as Ozmoo being right in not preserving that space at the end. For normal text, I’d be hard-pressed to find a case where you want to preserve that space.

10

No, it is the same if the ‘a’ does not fill the whole row:

[ main key;
print "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa b c^d e f";
new_line;
print "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a c
   ^d e f";
new_line;
   @read_char 1 ->key;
];

frotz -w 40 test.z5:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa b c
d e f
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a c

d e f

It works correctly with Frotz -w 39 or 41.

11

The only case I can think of off-hand is if the space was printed in a different colour than the rest of the text… but that’s still hardly a sensible case.

For what it’s worth, when I fed the file into Infocom’s DOS interpreter from Sherlock, it broke the lines before the 80th character. So I guess both Frotz and Ozmoo are more clever than that. :grinning:

12

You still have a string that fills all the forty columns, followed by a space and a line break. As far as I can tell:

The first string is “aaa…aaa[space]b[space]c[newline]d[space]e[space]f”.
The second string is “aaa…aaa[space]a[space]c[space][newline]d[space]e[space]f”.

The space before the newline is probably what Frotz prints on the seemingly empty line. Though I have not actually verified this.

13

There is no space after the “c” of the second string?

14

I modified “txd” to print a “#” instead of " ". These are the two strings it found in your test program:

S001: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa#b#c
d#e#f"
S002: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa#a#c#
d#e#f"

And just to be sure of the order, this is the code that prints them:

Routine R0002, 1 local

       PRINT_PADDR     S001
       NEW_LINE        
       PRINT_PADDR     S002
       NEW_LINE        
       READ_CHAR       #01 -> L00
       RTRUE

So presumably Inform collapses the spaces before the line break of the second string into one space, not zero.

15

Or after a “^” character. Or if you don’t indent the next line. Or after a backslash.

These four statements are equivalent:

	print "foo, bar,^baz, quz.^";

	print "foo, bar,^
baz, quz.^";

	print "foo, bar,^
		baz, quz.^";

	print "foo, bar,\
		^baz, quz.^";

These are equivalent, but different from the above:

	print "foo, bar,
		^baz, quz.^";

	print "foo, bar,
^baz, quz.^";

The second pair will print a space before the newline.

EDIT: I added the backslash case above. The backslash before a code newline was needed in older versions of Inform. As you see, it’s no longer needed, but you can use it.

(The easiest way to see the difference is to compile with inform -a .)

1 Like
16

The fact that three different interpreters differ slightly on how to display “…[space][newline]” doesn’t surprise me! I try to avoid doing this in my games.

1 Like
17

It seems that this happens when the line is broken right where the newline in the string appears. Therefore you get two newlines in a row. I suppose the solution is to check if there’s a newline just before or just after a line break and drop that character.

18

I will use this statement, which seems to be the least ambiguous and most understandable (the compiler seems to agree with this):

print "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a c\
   ^d e f";
19

It seems to be the same as with the extra space character. This does not explain why the compiler concatenates the two strings differently.

WIDTH 8
'_' == ' '
string "abc_defg_hi"

false:
|abc_defg|
|_hi     |

true:
|abc defg|
|hi      |

string "abc_defg^hi"

false:
|abc_defg|      |abc_defg|
|^hi     |  ==> |^       |
                |hi      |
true:
|abc_defg|
|hi      |
20

I’m not quite sure what your false/true are trying to suggest there, but I would expect to always see the “false” output, never the “true” output. And the two strings are treated exactly the same way as each other in the “false” versions too.

1 Like
21

well, the backslash has a minor but curious back(s)lash :wink:

people like me, actually trained historians, separate the source archives into src/inf5, src/inf6 and src/inf7 and the backslash is still a precise giveaway (together with Nearby) of Inform 5 sources.

Best regards from Italy,
dott. Piergiorgio.