[Glk] Text styles and fonts

11 views
Skip to first unread message

Andrew Plotkin

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

My life is dull (with the usual moments of sheer terror), so I think I'll
start picking interface arguments.

I'm working on this Glk idea, which ideally will take care of all the
interface and porting problems for IF systems, at least for the next few
years. Optimistic, but I'm trying.

I'm still evolving the design. Here's one question: what kind of options
should be available for text styles and fonts?

For comparison, the Z-machine has normal, fixed-width, bold, and
underlined/italic styles. (It also has some provision for specialized
fonts, but this is only used for the rune font in Beyond Zork, and it's
not really defined past the point of "do what we need in this one game.")

One extreme answer would be: nothing. The game can only produce text; it
has no control over how the text appears; that's entirely the province of
the interpreter.

The opposite extreme is: everything. The game can specify a font (by
name), a font size, foreground and background color, left/right/center
justification, and individual character positioning for subscripts and
overstrikes.

I hope it's obvious that I'm looking for something in between these two
extremes. :-) On the one hand, it should be possible for interpreter
writers to handle the full range of game options without going insane --
and that includes interpreters running in terminal emulation windows. On
the other hand, this is intended to support existing IF systems and
future ones, and I don't want to cramp them.

Hm, this is a tricky post, because I can see some replies that go off
down the wrong track and I want to head them off.

"Why not use HTML?" No, that's not the question. HTML is a syntax for
specifying formatting. I want to decide what formatting should be
*specifiable*. (As it happens, I'm casting Glk as a programming API, not
a text-stream format. Although it would be perfectly possible to write
code to parse HTML or HTML-like text into Glk API calls. But, as I said,
that's not my topic here.)

"Why not say that you can specify any formatting, and the interpreter will
implement as much as it can?" This sounds great. In practice, it's gotten
us the Web, and "This page is best viewed with Interscape 5.9.9; the rest
of you can lick my pallid buttocks." There is also, for example, no
portable way whatsoever to specify fonts. (Every platform has its *own*
portable way, really. Grn.) And also -- this leaves no room whatsoever for
player preferences. I *like* player preferences.

Suggestion One:

Decide on a fixed list of display styles -- by *usage*, not by how they
look. For example:

Normal / body text
Emphasized
Fixed-width
Note
Alert
Heading / chapter title
Subheading / section title

That's seven styles, with a bit of variation, but still a group that you
can hold in your hand and look at. If you see what I mean. :)

It is entirely up to the interpreter to decide how these are
distinguished. "Heading" could be 18-point and "subheading" 14-point; or
it could be red versus green, or bold versus underlining. Different
indenting levels. Or so on. A polite interpreter will allow player
preferences to control all of this.

("Fixed-width" is of course an exception -- the interpreter has to
guarantee that it really is fixed-width -- but this is a practical
necessity.)

(It is quite possible that a particular interpreter will not be able to
display all seven styles distinguishably. A monochrome VT320 terminal only
*has* bold, underlined, and reverse text, and distributing the styles to
the combinations of those is more confusing than helpful. And of course
all the fonts on such a terminal are fixed-width, so "normal" and
"fixed-width" will look the same. If your game really needs the player to
be able to see particular styles, it's not impossible. There will be a Glk
API call to test which styles are distinguishable.)

Enough typing for now. What do people think? What do authors want? (I
know, I know, authors want everything. You know, most of the Web is
*ugly*.)

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Daryl McCullough

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

In article <erkyrathE...@netcom.com>, erky...@netcom.com says...

>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title

A different topic, but what I want to know is how you got the cool
lightning effects in _A Change in the Weather_. Pretty neat special
effect for a text game.

Daryl McCullough
CoGenTex, Inc.
Ithaca, NY

Joe Mason

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title

This sounds like the most interesting. I'm brought in mind of the TADS
"indentation vs. spacing" paragraph debate - I think the best solution to that
was to have the author mark "paragraph break" and let the interpreter pick how
to display it.

However, I'm a little worried that authors will start assuming that these look
the same on all systems. HTML has the same type of thing: instead of letting
the author pick font sizes directly, it has header sizes defined as "H1", "H2",
etc. The individual browser decides what size to make it. But as far as I
know, every browser except Lynx displays the different headers in the exact
same way, giving the temptation for authors to use them for formatting that
otherwise might not work on all browsers.

The obvious antidote to this is to make a couple of interpreters implement
these categories completely differently, so that authors simply couldn't
depend on them for formatting details.

Joe

David A. Cornelson

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

In article <erkyrathE...@netcom.com>,

erky...@netcom.com (Andrew Plotkin) wrote:
>
> My life is dull (with the usual moments of sheer terror), so I think I'll
> start picking interface arguments.
>
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
>

Hmmm, this is interesting. I believe formatting text is important and
although we're talking about strictly text games, there is a lot to be
desired. There are certainly platfroms that would allow more flexibility
than others so you're already faced with dual or mulitple standards.

For myself, highlighting and placement are probably the most important.
Easily formatting text to indent, left, center, right, making rows and
columns, using platform specific abilities (fonts) would be nice.

Other than that I would have to suggest a Pan-Galactic Gargle Blaster or
two to break up the monotony.

David A. Cornelson, Chicago

-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet

Andy Leighton

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

On Tue, 6 Jan 1998 07:28:14 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>"Why not use HTML?" No, that's not the question. HTML is a syntax for
>specifying formatting. I want to decide what formatting should be
>*specifiable*.

Well properly HTML does not specify formatting, it has nothing to
do with format it is content markup (pretty much as your 7 styles
below). However it has been sorely abused in the past and I
believe the fight to be already lost.

>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>

> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
>

>That's seven styles, with a bit of variation, but still a group that you
>can hold in your hand and look at. If you see what I mean. :)

How about a conversation style as well?

Well from what you have suggested I believe you are very close to
Berner-Lee's original idea for HTML. The problem is going to be
trying to stop people abusing the system, are we going to get games
with comments such as
"best played with body text set to Times New-Roman 12 etc etc."
or more likely "set Note style to Wingdings".

--
Andy Leighton => an...@azaal.dircon.co.uk
"... January is your third most common month for madness" - _Sarah Canary_


Algernon Petrofsky

unread,
Jan 6, 1998, 3:00:00 AM1/6/98
to

erky...@netcom.com (Andrew Plotkin) writes:
> "Why not use HTML?" No, that's not the question. HTML is a syntax for
> specifying formatting. I want to decide what formatting should be
> *specifiable*.

Okay, I'll rephrase the question, "Why not provide the same set of
markup elements as HTML?". The answer, I think, is that that set is a
little bigger than what you were thinking of providing. So my next
question is "Why not provide a simplified subset of the HTML markup
elements?", and that seems to be about what you proposed.

You might want to consider also allowing separate style commands a la
web style sheets. Then the game can specify that a piece of text
should be emphasized, and that the emphasis should preferably be
indicated by using the color red. The interpreter and/or player could
override one or both of these directives.

-al

Daniel Shiovitz

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>My life is dull (with the usual moments of sheer terror), so I think I'll
>start picking interface arguments.

Life: a semi-interactive parody
> Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.PANIC.
You win!

(with a little work, this game can be adapted to produce "Essay: an
interactive writing-a-term-paper")

[..]


>of you can lick my pallid buttocks." There is also, for example, no
>portable way whatsoever to specify fonts. (Every platform has its *own*
>portable way, really. Grn.) And also -- this leaves no room whatsoever for
>player preferences. I *like* player preferences.

[..]


> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title

As a player, yeah, I like player preferences, but as an author I hate
'em. Seriously, how much does it add to the playing experience to be
able to tell the interpreter "Display whatever text the author chose
to call 'Header' text in 18-point bold"? I don't want to try and hold
back the Formatting Revolution here, but IMO the reason the web looks
so crappy is because interpreters have so much freedom in how to
interpret code that it's impossible for designers to design anything
that looks nice cross-platform. Bleah. I would be perfectly happy to
stick with bold, italic, underline, fixed. If I want to emphasize
something, I'll make it bold, or if I want to emphasize it a different
want I'll italicize it. (Plus, if you let authors ask "does this
interpreter distinguish style X from style Y?" I bet you'll end up
with them effectively using bold-italic-fixed anyway. Oh, um, it does
occur to me it might be nice sometimes for authors to provide a font
with the game, and then be able to say "display this text in
MyFont". Is that feasible? This certainly wouldn't be terribly clean,
and I can see some formatting problems if the provided font is, say,
half the size of whatever the user's set the default text to, but
still ...

(The one thing that HTML gets right, which I hope makes it into GLK,
is being able to specify formatting tags that the interpreter doesn't
necessarily understand. That's a good thing.)

Other stuff:
Left/right/center/justify alignment seems pretty necessary. Er.. I was
going to ask about multi-column printing, but then I started thinking
that under the current setup, the proper way to handle this would be
wth multiple windows. Yes?

>--Z
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)

William R Sherman

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew Plotkin) writes:
> My life is dull (with the usual moments of sheer terror), so I think I'll
> start picking interface arguments.
[snip]

>
> ("Fixed-width" is of course an exception -- the interpreter has to
> guarantee that it really is fixed-width -- but this is a practical
> necessity.)
>
> (It is quite possible that a particular interpreter will not be able to
> display all seven styles distinguishably. A monochrome VT320 terminal only
> *has* bold, underlined, and reverse text, and distributing the styles to
> the combinations of those is more confusing than helpful. And of course
> all the fonts on such a terminal are fixed-width, so "normal" and
> "fixed-width" will look the same.

I just have this one small comment to this thread regarding the
previous statement:

Actually, back in the old everything was fixed-width days, there still
was a distinction between even and right-justified spacing, so the
implementor of an interpreter that used only fixed with fonts could
still differentiate between fixed-width and "normal" using these
two methods.

> If your game really needs the player to
> be able to see particular styles, it's not impossible. There will be a Glk
> API call to test which styles are distinguishable.)
>
> Enough typing for now. What do people think? What do authors want? (I
> know, I know, authors want everything. You know, most of the Web is
> *ugly*.)

Yep, I'm aware of that. I argued in the pre-Netscape days of Mosaic
that there should at least be some extra parameters for Images to
allow them to have captions, and even be able to specified their
relationship to how text flowed around them. I thought this would
be a good comprimise, but it didn't pan out (and I wasn't forceful
enough).

> --Z

Bill

/*************************************************************************/
/* Bill Sherman (wshe...@ncsa.uiuc.edu) */
/* National Center for Supercomputing Applications */
/* University of Illinois at Urbana-Champaign */
/* Og - "You want to do mankind a real service? Tell funnier jokes" */
/* Spinner - "but facts don't always reveal the truth" */
/* Robin - "Yeah, but I always figure that's the writers' fault" */
/*************************************************************************/


Christopher James Brown

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

> Decide on a fixed list of display styles -- by *usage*, not by how they
> look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title

I like this idea a lot...And someone mentioned a "conversation" style,
which I think might be useful. You could make it so the programmer can
define these styles, but the user has the option to override them. Also,
perhaps a utility could be created that would allow the programmer to test
their code on virtual displays of other computers/interpreters...A VT100
display, a XVGA display, and Amiga 640x200 16 colour display,
etc...therefore allowing the programmer to see with his/her own eyes how
their set-up will look on other machines...Lastly, perhaps you could put an
option for multiple setups as seperate files, therefore if the programmer
was lazy (or if a new interpreter arrives on a new machine later on), then
someone who has that particular computer/interpreter can create a display
set-up which works well enough for that platform...I don't know if I am
making any sense, but hopefully I am...

Jason Brown

Andrew Plotkin

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

Andy Leighton (an...@azaal.dircon.co.uk) wrote:
> On Tue, 6 Jan 1998 07:28:14 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
> >"Why not use HTML?" No, that's not the question. HTML is a syntax for
> >specifying formatting. I want to decide what formatting should be
> >*specifiable*.

> Well properly HTML does not specify formatting, it has nothing to


> do with format it is content markup

Sorry, I was unclear in making my point; I said "formatting" when I meant
"any text attributes".

HTML is a text-based syntax for specifying stuff. I want to decide what
stuff is specifiable; I'm not worrying about making a text-tag syntax to
specify it.

Andrew Plotkin

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

Joe Mason (jcm...@undergrad.math.uwaterloo.ca) wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >
> >Decide on a fixed list of display styles -- by *usage*, not by how they
> >look. For example:
> >
> > Normal / body text
> > Emphasized
> > Fixed-width
> > Note
> > Alert
> > Heading / chapter title
> > Subheading / section title

> This sounds like the most interesting. I'm brought in mind of the TADS


> "indentation vs. spacing" paragraph debate - I think the best solution to that
> was to have the author mark "paragraph break" and let the interpreter pick how
> to display it.

I was considering going that far myself -- but life is easier if there's
a pure text layer underneath the styles. And in the text layer,
newline or double-newline has to indicate a paragraph break.

It's not that I dislike the way HTML does it; I just want to make the
style mechanism purely optional.

> However, I'm a little worried that authors will start assuming that these look
> the same on all systems.

I'm hoping that forward momentum will prevent that. I get to release the
first display library, for the Mac, and that *will* have full player
control of style formatting. Plus, the *second* display library will be
for the generic terminal window (via curses.h), and that is limited to
underline/bold/reverse no matter what. Pilot and Newton versions are also
limited. Hopefully authors will understand that this is a major slice of
the market.

Andrew Plotkin

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:

> As a player, yeah, I like player preferences, but as an author I hate
> 'em. Seriously, how much does it add to the playing experience to be
> able to tell the interpreter "Display whatever text the author chose
> to call 'Header' text in 18-point bold"?

You'd be surprised. I really dislike colored text, for example; even when
I use it, I turn it to much more muted colors than the populace seems to
prefer. If the game controls color, I'm guaranteed to be pissed off.

Do you like IF room names to be printed in bold? (I'm thinking that would
be a common use for the "subheader" style.) Would you rather have each
game's author choose whether to make room names bold, or choose it
yourself for all games?

> Oh, um, it does
> occur to me it might be nice sometimes for authors to provide a font
> with the game, and then be able to say "display this text in
> MyFont". Is that feasible?

It's very, very hard. It certainly won't be in the first version. There is
no way to provide a font which can be used by Mac, Windows, X, Pilot
(assuming the Pilot even has fonts, I don't know.)

> (The one thing that HTML gets right, which I hope makes it into GLK,
> is being able to specify formatting tags that the interpreter doesn't
> necessarily understand. That's a good thing.)

Yes. The fundamental API call is glk_set_style(style, value), and if the
interpreter doesn't recognize style (or can't handle it), nothing happens.

> Left/right/center/justify alignment seems pretty necessary.

Why? I see that just about everybody is requesting it, and I'm not
unwilling, but what would you use it for?

The most obvious use is to center headers. But I think that should be
done by using the "header" style, and allowing that the player may decide
whether headers are centered or not.

> Er.. I was
> going to ask about multi-column printing, but then I started thinking
> that under the current setup, the proper way to handle this would be
> wth multiple windows. Yes?

Yes.

There's no way to have a single text stream that flows through multiple
columns, but I think that's too complicated to support.

Andrew Plotkin

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

Christopher James Brown (c.b...@utoronto.ca) wrote:
> I like this idea a lot...And someone mentioned a "conversation" style,
> which I think might be useful.

Huh. I'm antsy about it. There already are typographic conventions for
conversations, and this means that some authors will inevitably just use
them (as they do with TADS/Inform) and not bother with the "conversation"
style. Then you have inconsistency again.

> You could make it so the programmer can
> define these styles, but the user has the option to override them.

Right. Style sheets, or rather style hint sheets.

On the one hand this allows players the freedom to waive their freedom to
control the display. That accords with my principles.

On the other hand, if many interpreters default to following the style
hints, authors will learn to expect that they are controlling formatting
instead of content; this is *exactly* what happened to HTML. I'm afraid
that eventually this will lead to newbies asking "What does header style
look like?" and people answering "Eighteen-point, bold, and centered.
Except for weenie interpreters and you don't have to care about them."

> Also,
> perhaps a utility could be created that would allow the programmer to test
> their code on virtual displays of other computers/interpreters...

Good idea, but a tremendous amount of work. (Can you imagine trying to
write portable *virtual platform-native display* code? Eww.)

Someone else can do it. I want to concentrate on getting Glk itself defined
and then implemented.

Joe Mason

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>
>> Left/right/center/justify alignment seems pretty necessary.
>
>Why? I see that just about everybody is requesting it, and I'm not
>unwilling, but what would you use it for?
>
>The most obvious use is to center headers. But I think that should be
>done by using the "header" style, and allowing that the player may decide
>whether headers are centered or not.

Poetry comes to mind. In fact, the necessity of printing poetry (which I will
probably end up doing fairly often if I ever get around to writing more games)
will make me demand some sort of text control beyond specifying paragraph
styles: I like to play with spacing and indentation to play with rhythmic flow.

Joe

Damien Neil

unread,
Jan 7, 1998, 3:00:00 AM1/7/98
to

On Wed, 7 Jan 1998 19:00:22 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>> You could make it so the programmer can
>> define these styles, but the user has the option to override them.
>
>Right. Style sheets, or rather style hint sheets.

An idea just came to me.

Allow the author to define styles. If an author desires to print chapter
headings in a specific style, she may define a [header] style, with some
default definition -- a hint, as you say. The user may then reconfigure
the definition of the style to his heart's content.

Flexibility, extensibility, and freedom. The author may suggest, the
reader may object, and both can be happy.

>On the one hand this allows players the freedom to waive their freedom to
>control the display. That accords with my principles.

Same here. I'll go a step further: presentation makes a difference. I
would say that my enjoyment of _Freedom and Necessity_ was heightened by
the wonderful physical quality of the hardback edition I read it in, for
example. (Not that it wouldn't have been a staggeringly beautiful story
if read off of scribbled notes written on dirty napkins.) While
portability is vital, and the reader should always have the choice to
deviate from the author's preferences, the author should at least be
allowed to take a fair shot at typesetting her work to the best degree
possible.

>On the other hand, if many interpreters default to following the style
>hints, authors will learn to expect that they are controlling formatting
>instead of content; this is *exactly* what happened to HTML. I'm afraid
>that eventually this will lead to newbies asking "What does header style
>look like?" and people answering "Eighteen-point, bold, and centered.
>Except for weenie interpreters and you don't have to care about them."

This could be a problem, I will grant. On one hand, some the first Glk
implementations will be terminal-based programs with barely any formatting
abilities at all. On the other hand, the same can be said of HTML. On
the snout hand, the IF community is probably never going to grow to a size
where old hats will overlook newbies in need of a clue transfusion.

- Damien

JC

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

On Tue, 6 Jan 1998 07:28:14 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
[...]

>
>HTML is a syntax for specifying formatting.

HTML is, or at least was, intended to specify structure, not formatting.
Of course, hardly anyone uses it that way.


';';James';';

Patrick Kellum

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

In article <EMFKH...@undergrad.math.uwaterloo.ca>, Joe Mason was talking about:

>Poetry comes to mind. In fact, the necessity of printing poetry (which I will
>probably end up doing fairly often if I ever get around to writing more games)
>will make me demand some sort of text control beyond specifying paragraph
>styles: I like to play with spacing and indentation to play with rhythmic flow.

I'm not quite sure what the point of Glk is, but all these text formating
styles (yes, even centering and right-justification) are easy with
standard Inform.

Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Berry

Daniel Shiovitz

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

I think my general feeling on this stuff is that I don't like authors
making "suggestions" to the interpreter. As an author, this usually
doesn't give me enough power to control how it looks; as a player, I

have the same problem from the other side. That said:

In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:

>Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:
>
>> As a player, yeah, I like player preferences, but as an author I hate
>> 'em. Seriously, how much does it add to the playing experience to be
>> able to tell the interpreter "Display whatever text the author chose
>> to call 'Header' text in 18-point bold"?
>
>You'd be surprised. I really dislike colored text, for example; even when
>I use it, I turn it to much more muted colors than the populace seems to
>prefer. If the game controls color, I'm guaranteed to be pissed off.

Ok, so strike color from the list of things that the author can
set. This means I can't illustrate a game about the rainbow-colored
smurves of HappyLand properly, but that's a risk I'm willing to
take. Or here's an alternative that I could live with (which I think
is pretty similar to what we have now, and not at all similar to HTML):
let interpreters control whether or not authors can set color. If the
interpreter says "Yes, I'll use the game-provided color scheme" then
the game has total control over the color, including how bright to
make it and what precise shade of red to use. If the interpreter says
"No, I won't use the game-provided color scheme", then the game has no
control over the color, and all its "setcolor" commands are
ignored. This reduces the environments a programmar has to develop for
to two: with color, and without color. If the game supports color,
then the programmer can be sure that the color will adhere to the
following guidelines, and all the following functions will work
properly to modify the color. If the game doesn't support it, the
programmer can either deal or say "well, fine, you can't run my game
then".

I like this because it limits the views I have to code for, grants me
a lot of flexibility as a programmer, but also lets me as a player
turn off color if it looks horrid.

>Do you like IF room names to be printed in bold? (I'm thinking that would
>be a common use for the "subheader" style.) Would you rather have each
>game's author choose whether to make room names bold, or choose it
>yourself for all games?

In this case, I'd prefer to let the game author handle it, because
then they can do tricks with the highlighting if it makes the game
work better (dunno what.. maybe bold room names during daytime and
un-bold at night). But again.. I suppose you ould have an interpreter
flags "game controls formatting of subheader? Y/n"

[..]


>> Left/right/center/justify alignment seems pretty necessary.
>
>Why? I see that just about everybody is requesting it, and I'm not
>unwilling, but what would you use it for?

Er.. um.. what if I had a game set in mirror-land, and so I had two
parallel windows running up-down on the screen, and displayed the room
descriptions left-aligned in the left window, and did the same
descriptions but backwards and right-aligned in the right window?
Important, vital game issues like that.

It occurs to me also I'd like to be able to do concrete poetry ala the
mouse's tail poem from Alice in Wonderland. Is this doable currently?
(hmm.. you could almost do it with just fixed width, but what if the
display wasn't wide enough?)

Patrick Kellum

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

In article <691vma$h...@spool.cs.wisc.edu>, Daniel Shiovitz was talking about:

>I think my general feeling on this stuff is that I don't like authors
>making "suggestions" to the interpreter. As an author, this usually
>doesn't give me enough power to control how it looks; as a player, I
>have the same problem from the other side. That said:

I'm begining to have some serious probs with Glk. From the looks of it AP
wants all text adventures to look exactally the same. There goes
individuality. I personally like using colour in games, f Mr. Plotkin
doesn't like that then he can turn it off, I belive his interpreters don't
support colour anyway. I don't see why we need this added code to
interpreters, HTML is screwed up as it is, I would think we would all
learn from that mistake.

>Er.. um.. what if I had a game set in mirror-land, and so I had two
>parallel windows running up-down on the screen, and displayed the room
>descriptions left-aligned in the left window, and did the same
>descriptions but backwards and right-aligned in the right window?
>Important, vital game issues like that.

Simple in Inform but it looks imposable with Glk.

>It occurs to me also I'd like to be able to do concrete poetry ala the
>mouse's tail poem from Alice in Wonderland. Is this doable currently?
>(hmm.. you could almost do it with just fixed width, but what if the
>display wasn't wide enough?)

Using a combination of fixed font pieces and a few simple routines (check
out the example for centering text in the Designers manual for a good
start) and this is very doable. As long as the screen is as wide as the
longest piece of text (something that would be required anyway) this
should work just fine. (this is in Inform, I don't know enough about the
other languages to say).

Jeff Hatch

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

Andrew Plotkin wrote:
[snip]

> I'm working on this Glk idea, which ideally will take care of all the
> interface and porting problems for IF systems, at least for the next few
> years. Optimistic, but I'm trying.
>
> I'm still evolving the design. Here's one question: what kind of options
> should be available for text styles and fonts?

Time permitting, I'd like to make my system Glk-compatible. Beyond the
interface issues we've already discussed, I have just two concerns about
your Glk specifications.

1. Pop-up windows, such as quotations. These are fairly popular, and
they don't belong in the standard output stream. Do you have a way to
handle these?

2. Error message text. I think it might be nice someday to have an
interpreter that erases error messages (and the accompanying) commands
after the error's been resolved, leaving the persistent view of the game
unimpeded by misspellings. I'm not doing anything like that
myself--heck, I haven't even implemented a status line yet!--but a
different display type for errors seems like it could be a good idea,
just in case.

Come to think of it, though, I could already implement the second one
just by automatically undoing any error-causing move just before the
next move gets made, since my Undo feature scrolls the screen in
reverse. I'll have to think this over more.

-Rúmil

Andrew Plotkin

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

Patrick Kellum (pat...@syix.com) wrote:
> In article <EMFKH...@undergrad.math.uwaterloo.ca>, Joe Mason was talking about:

> >Poetry comes to mind. In fact, the necessity of printing poetry (which I will
> >probably end up doing fairly often if I ever get around to writing more games)
> >will make me demand some sort of text control beyond specifying paragraph
> >styles: I like to play with spacing and indentation to play with rhythmic flow.

> I'm not quite sure what the point of Glk is, but all these text formating
> styles (yes, even centering and right-justification) are easy with
> standard Inform.

Not centering and right-justification, not in the story window. Trust me
on this. :)

The point of Glk is porting games that aren't written for existing
portable systems (TADS and Inform.)

Joe Mason

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

In article <34B491...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>1. Pop-up windows, such as quotations. These are fairly popular, and
>they don't belong in the standard output stream. Do you have a way to
>handle these?

I'll second that!

>2. Error message text. I think it might be nice someday to have an
>interpreter that erases error messages (and the accompanying) commands
>after the error's been resolved, leaving the persistent view of the game
>unimpeded by misspellings. I'm not doing anything like that
>myself--heck, I haven't even implemented a status line yet!--but a
>different display type for errors seems like it could be a good idea,
>just in case.

This should be fairly simple - use the standard DOS/Unix convention of having
a "standard output" and "standard error" stream. Interpreters are free to
have a separate window to print errors, mix them with game text, ignore them,
print them in a different colour, log them to a file, etc.

Joe


Patrick Kellum

unread,
Jan 8, 1998, 3:00:00 AM1/8/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

>Not centering and right-justification, not in the story window. Trust me
>on this. :)

Subtract the length of the text (divided by 2) from the width of the
screen (in characters, divided by 2). To get the width of the screen in
proporational fonts take the width of the "0" character and use that as
the character width (standard practice).

There, you've got centered text. The only prob with proporational
characters is it mght be off center very slightly, but it still looks
fine.

Right-justifed and percentage-Justfied text s very east to work out from
there.

>The point of Glk is porting games that aren't written for existing
>portable systems (TADS and Inform.)

Oh, ok. I thought it was a proposed change in the text capabilities of
Inform and other already existing systems.

Mark J Musante

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Patrick Kellum (pat...@syix.com) wrote:
> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).

I beg to differ. In the two OSs I write code for (Windows & PalmOS),
there are functions available to tell you the *exact* width of a string,
no matter what font you're using. I have never used the technique you
describe above.


-=- Mark -=-

John Wood

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

[Delurking - hi all! I won't be around much, but I'm trying to get back
into recreational computing a little.]

Andrew Plotkin <erky...@netcom.com> wrote,


> I'm working on this Glk idea, which ideally will take care of all the
> interface and porting problems for IF systems, at least for the next
> few years. Optimistic, but I'm trying.
>
> I'm still evolving the design. Here's one question: what kind of
> options should be available for text styles and fonts?

[...]
> Suggestion One:


>
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look.

Sensible.

> For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title

These need to be organised into orthogonal sets. For instance, text
cannot be both a heading and a subheading, but it can be emphasised and
fixed-width. I'm not entirely clear on the meaning of "note" and
"alert", but one arrangement would be

Style
Normal / body text


Heading / chapter title
Subheading / section title

Note
Font
Normal
Fixed-width
Emphasis
Normal
Emphasised
Alert

So each piece of text would have one style, one font and one emphasis.
Once you have a draft list that you feel happy with, it's worth looking
back at existing games and checking you can handle them elegantly. For
instance, what options would an interpreter specify to display boxes
(like the Trinity quotes), or the status line, or the bold location name
present in most z-games?

A related issue is character sets, but you probably don't want to get
that discussion tangled with this one...

John

Patrick Kellum

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

In article <EMIs7...@world.std.com>, Mark J Musante was talking about:

>I beg to differ. In the two OSs I write code for (Windows & PalmOS),
>there are functions available to tell you the *exact* width of a string,
>no matter what font you're using. I have never used the technique you
>describe above.

And how does it do this (getting a common width for all characters in a
proporitional font)? I would guess it does the same thing I mentioned, I
don't see any other way. A "0" is the widest character in a font, any
other method would cause some characters to be partialy overwritten with
the following characters.

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Patrick Kellum (pat...@syix.com) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

> >Not centering and right-justification, not in the story window. Trust me
> >on this. :)

> Subtract the length of the text (divided by 2) from the width of the


> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).

> There, you've got centered text. The only prob with proporational


> characters is it mght be off center very slightly, but it still looks
> fine.

Well, you can do that in Glk; I am allowing you (with some misgivings.
:-) to measure the width of the window (measured in "0" characters.)

It's icky, and in proportional fonts it tends to be far off the
centerline, since spaces are much narrower than zeroes.

> >The point of Glk is porting games that aren't written for existing
> >portable systems (TADS and Inform.)

> Oh, ok. I thought it was a proposed change in the text capabilities of
> Inform and other already existing systems.

Well, that too, in a sense. I really want to get a Glk version of Hugo,
eventually. And if there is ever a serious update to the Z-machine --
32-bit memory and so on -- it should *not* stick with the existing
Z-machine I/O system (either V5/8 or V6.)

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Jeff Hatch (je...@hatch.net) wrote:
> Time permitting, I'd like to make my system Glk-compatible. Beyond the
> interface issues we've already discussed, I have just two concerns about
> your Glk specifications.

> 1. Pop-up windows, such as quotations. These are fairly popular, and


> they don't belong in the standard output stream. Do you have a way to
> handle these?

I'd do it by opening a new window, below the status window, and keep it
open until the next player input. That's easy in the current API.

> 2. Error message text. I think it might be nice someday to have an
> interpreter that erases error messages (and the accompanying) commands
> after the error's been resolved, leaving the persistent view of the game
> unimpeded by misspellings. I'm not doing anything like that
> myself--heck, I haven't even implemented a status line yet!--but a
> different display type for errors seems like it could be a good idea,
> just in case.

There's no backup-and-delete in a stream window; they're output only. But
you could have a second window for errors.

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:
> they can do tricks with the highlighting if it makes the game
> work better (dunno what.. maybe bold room names during daytime and
> un-bold at night). [...]

> Er.. um.. what if I had a game set in mirror-land, and so I had two
> parallel windows running up-down on the screen, and displayed the room
> descriptions left-aligned in the left window, and did the same
> descriptions but backwards and right-aligned in the right window?
> Important, vital game issues like that.

Yeah, it tends to wind up like that. Strained cases. *Yes*, they can have
legitimate uses -- but I'm more concerned with portability and ease of
implementation.

> It occurs to me also I'd like to be able to do concrete poetry ala the
> mouse's tail poem from Alice in Wonderland. Is this doable currently?
> (hmm.. you could almost do it with just fixed width, but what if the
> display wasn't wide enough?)

If the display isn't wide enough, you're screwed anyway, right?

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Damien Neil (ne...@zorg.hitchhiker.org) wrote:
> An idea just came to me.

> Allow the author to define styles.

Headache! Pain! Also, it cuts the player out of the loop. You don't ask
the player to set a bunch of styles options every time they start playing
a new game.

I'll stick with a fixed list.

I do believe I'll stick one or two "user" styles on the list, though.

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Patrick Kellum (pat...@syix.com) wrote:

> I'm begining to have some serious probs with Glk. From the looks of it AP
> wants all text adventures to look exactally the same.

I want them all to look the same when *I* play them. That's different.

> >Er.. um.. what if I had a game set in mirror-land, and so I had two
> >parallel windows running up-down on the screen, and displayed the room
> >descriptions left-aligned in the left window, and did the same
> >descriptions but backwards and right-aligned in the right window?
> >Important, vital game issues like that.

> Simple in Inform but it looks impossible with Glk.

Actually, if I can modify my earlier post, it's *not* safely possible in
Inform in the story window, because if the story window / status window
size differentiation which I've talked about before.

Andrew Plotkin

unread,
Jan 9, 1998, 3:00:00 AM1/9/98
to

Ok, let me explain what I'm getting at here.

I want a system which is *easy* to port. That's why I'm keeping all the
interface specifications abstract. I want something which can be
implemented with existing text objects (Java's text thingie, Mac's
TextEdit, curses.h, whatever thingies are used by the Pilot and Newton.)

This means that I do not want a system which allows the game author to do
anything. The more the author can do, the more the porter *has* to do.
Look at the V6 Z-machine. It has, what is it, arbitrary code which can be
run at each line break? I've never even considered implementing it.

Now, on the author hand -- I meant to write "other hand", but I'll leave
it :-) -- there's nothing wrong with style hints which the interpreter
can take or leave. That doesn't make porting harder.

Here's the current version of the plan.

There is a fixed list of styles:

Normal / body text
Emphasized
Fixed-width
Note
Alert
Heading / chapter title
Subheading / section title

Block quote
User style 1
User style 2

Note that each piece of text is in exactly one of these styles. You can't
have "fixed-width emphasized" text. This is a deliberate simplification.
I could have gone for a perfect disjunction between formatting
(fixed-width, emphasized) and structure (heading, block-quote.) I think
it would be too large a pain, and bring up too many icky questions. Just
pretend that all of these are structural attributes. (Maybe I should
rename "fixed-width" to "preformatted"?)

Some of these styles may wind up looking the same, and there is an API
call to detect this. In particular, the two user styles could be almost
anything, including identical to the "normal" style.

(Also note that in a status window, all of these styles are still
available -- the only difference is that you're guaranteed that they're
all fixed-width, with the same character width. Of course, in a status
window, the "normal" and "fixed-width" styles are probably going to look
the same.)

You (the game author) can provide hints on how the styles will look. The
hints can include color, justification, indentation, size (relative --
from -3 to +3, or something like that), weight (is it bold?), emphasis
(is it italicized/underlined?), and proportionality. Specifying a font by
name is way too uncertain, I'm afraid, and I think I won't touch it with
a long pole.

These hints are per window. If you have two windows, you can request that
emphasized text be red in one window and blue in the other. (Or left and
right justified, or whatever.)

This brings up a sticky problem -- what happens if you change a style
hint after some text has already been printed? Honestly, I may make this
illegal or let the results be undefined. (I want to allow interpreters to
use very simple print-and-forget I/O. That is, nothing in the Glk spec
forces interpreters to be able to redraw or reformat their windows.)

(In fact, it would be easiest to say that windows store their style hints
when they are created, and can never be changed thereafter. The problem
with this is that Glk starts up with the main window already created; I
wanted a standard output stream to be available, so that simple programs
wouldn't have to deal with window handling at all.)

Patrick Kellum

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

>> Oh, ok. I thought it was a proposed change in the text capabilities of


>> Inform and other already existing systems.

>Well, that too, in a sense. I really want to get a Glk version of Hugo,

?!?! So we're going to completly wipe out an entire system of text
adventures just to make it easer to port to Macs?

>eventually. And if there is ever a serious update to the Z-machine --
>32-bit memory and so on -- it should *not* stick with the existing
>Z-machine I/O system (either V5/8 or V6.)

What, if I may ask, is wrong with the existing Z-Machine I/O? It has
worked fine and it appears to support everything you want and much more.

Patrick Kellum

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

>Jeff Hatch (je...@hatch.net) wrote:
>> 1. Pop-up windows, such as quotations. These are fairly popular, and
>> they don't belong in the standard output stream. Do you have a way to
>> handle these?
>
>I'd do it by opening a new window, below the status window, and keep it
>open until the next player input. That's easy in the current API.

Goody, a screen full of windows. Why not just draw a quote box in the
current window like Frotz does with Informs "box" code?

Patrick Kellum

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrath...@netcom.com>, Andrew Plotkin was talking about:

>I want them all to look the same when *I* play them. That's different.

Well, why should I bother to create any adventures when I can't even be
allowed to say how they should work. Again, this is an interpreter issue,
not a language issue, not an author issue. If you don't want to allow
bold text then dont, if you want to use a large font then do. I don't see
any reason we should all switch to a more limited (read, lowest common
denominator) system of text output when a properly written interpreter can
do everything you're asking.

>> Simple in Inform but it looks impossible with Glk.
>
>Actually, if I can modify my earlier post, it's *not* safely possible in
>Inform in the story window, because if the story window / status window
>size differentiation which I've talked about before.

That was a problem with your interpreter, NOT with Inform. Your
interpreter can't set the header bits properly, fix the interpreter to
support version 1.0 (or even 0.2 for that matter) of the Z-Machine
standard and it will work fine. The method s OK, it works on all
standard-compatable interpreters.

Patrick Kellum

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

>This means that I do not want a system which allows the game author to do
>anything. The more the author can do, the more the porter *has* to do.

Now this is absured, why don't we just make all games work on a Commodore
Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
Common Denominator is not the way to go. Yes, games should be compatable
with a wide range of machines, but that is allready the case. Inform 5
games run fine on old C64 machines and I see no reason that with a few
edits to the C64 interpreter that V8 games couldn't be supported (or even
V6 with a total interpreter re-write). The porter should work at the
port, no one said programming was easy. Sacrificing author options is NOT
needed just to make a few lazy porters happy. In the end the porters will
be able to port to many machines but at a great cost, the games will be
limited. Currently, I could write Supper Mario Brothers in Inform, that s
how powerful the language s. If Glk becomes the standard then we might as
well just start writing games in Basic again, that s how constrained the
authors will be (even more so, I would thank).

>Look at the V6 Z-machine. It has, what is it, arbitrary code which can be
>run at each line break? I've never even considered implementing it.

This code is very important for creating fancy text layout. For instance,
if I had a christmas tree image on the screen and I wanted to flow the
text around the image I would use this great feature. Wth Glk I couldn't
do that, I would be stuck with some ugly seperate window with a tree in
it. Ugly and totally 80s.

Just because you can't be bothered to add support for it in your
interpreter doesn't mean everyone else doesn't want it. As I remember,
your interpreter doesn't even support set_colour, something that EVERY
other interpreter supports. Does this mean that we should all stop using
set_colour? Seems kinda aragent to me.

>Note that each piece of text is in exactly one of these styles. You can't
>have "fixed-width emphasized" text. This is a deliberate simplification.

Why not? What s so wrong with fixed-width + emphasized? It is easy to
write an interpreter that supports it. And if the interpreter doesn't
support it then it can ignore one.

[ very limited I/O system sniped ]

So, we should no longer support half of what the Z-Machine supports.
Before, if a machine didn't support bold text it could do something
different with the text. If emphisied text was to be printed, the
interpreter could print it in italics, underline it, or print it in a
different colour (or a hundred other things). AmigaFrotz allows the
player to choose fonts, emphisis style (underline or italics), screen
size, colours, etc. This does everything your standard does but still
allows everything the Z-Machine allows for. This can be done for ANY
interpreter on ANY system if the interpreter author was willing to spend a
few hours at the keyboard.

So, yes I do not care for the Glk standard. To me it's just a way to
limit IF authors just to make it easer to port to the Mac. If the Mac
doesn't allow editing on the text screen then so be it, that shouldn't
mean that every other system out there should be required to follow this
limitation.

Julian Arnold

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrath...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:

> Patrick Kellum (pat...@syix.com) wrote:
> > >Er.. um.. what if I had a game set in mirror-land, and so I had two
> > >parallel windows running up-down on the screen, and displayed the room
> > >descriptions left-aligned in the left window, and did the same
> > >descriptions but backwards and right-aligned in the right window?
> > >Important, vital game issues like that.
>
> > Simple in Inform but it looks impossible with Glk.
>
> Actually, if I can modify my earlier post, it's *not* safely possible in
> Inform in the story window, because if the story window / status window
> size differentiation which I've talked about before.

You could do it in Hugo. :)

Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"


Julian Arnold

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin

<URL:mailto:erky...@netcom.com> wrote:
> Ok, let me explain what I'm getting at here.
> [...]

> (Also note that in a status window, all of these styles are still
> available -- the only difference is that you're guaranteed that they're
> all fixed-width, with the same character width. Of course, in a status
> window, the "normal" and "fixed-width" styles are probably going to look
> the same.)

I'll go read your Glk specs later (meaning tomorrow), but for now, a
question. What do you mean by "a status window." Does Glk assume the
limited Z-machine approach to windows (where you can have two, one a
text stream and one non-word wrapping and fixed width-only, with the
first below the second), or would it allow a more flexible approach like
Hugo's (multiple non-overlapping windows, all word wrapping and
scrollable), or what?

Patrick Kellum

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

In article <34bf6906...@news.virgin.net>, Steve Waddicor was talking about:

>If the string is "This" it adds the width of the T to the width of the
>h to the width of the i ...

This is not the same thing.

>No, an M is conventionally the widest character in a font. That's why
>the unit for measuring widths in a font is an 'em'. The W is wider
>than the O too.

"0", not "O", i.e. Zero, not Ohhhh.

Andrew Plotkin

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

I'm combining my reponses to a few different posts here.

Julian Arnold (jo...@arnod.demon.co.uk) wrote:

> > (Also note that in a status window, all of these styles are still
> > available -- the only difference is that you're guaranteed that they're
> > all fixed-width, with the same character width. Of course, in a status
> > window, the "normal" and "fixed-width" styles are probably going to look
> > the same.)

> I'll go read your Glk specs later (meaning tomorrow), but for now, a
> question. What do you mean by "a status window."

You can have multiple non-overlapping windows. Each one can be a text
stream window or a text-grid window -- essentially the difference between
story and status windows in the Z-machine.

Eventually I'll define other types of windows, such as a graphics window.

Patrick Kellum (pat...@syix.com) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking
about:
> [quote boxes]


> >I'd do it by opening a new window, below the status window, and keep it
> >open until the next player input. That's easy in the current API.
>
> Goody, a screen full of windows. Why not just draw a quote box in the
> current window like Frotz does with Informs "box" code?

Because that puts all sorts of requirements on the capabilities of the
current window.

The way I have it set up, you can implement a text-stream window with
very little more than printf(). The interpreter never *has* to back up,
edit, redraw, or format. As I said, you can use a Mac TextEdit object.
The *only* methods of a text-stream window are "print some text",
"input a line", "input a key", "clear", "measure size", and "change
style". (And that last one is optional.)

If I added a requirement to be able to show quote boxes, then we're
talking about a much more complicated object. Overlaying a rectangle
of fixed-width text in a Mac TextEdit thing is hard -- you have to
store all the extra text yourself, scroll it along with the TextEdit
scrolling, and so on.

The same goes for the Win95 and Java text objects -- just so that you
don't think Macs are the issue here.

As to the rest of your posts, uh, I think you're *completely* missing the
point of what I'm doing.

I'm trying to design a system which includes as much as possible of the
Z-machine's interface, *and* expand it as much as possible, while *still*
being implementable on a C-64.

That means making all the fancy stuff (1) optional and (2) easy to factor
out -- so that it's not intertwined with the basic capabilities. You can
do quote boxes, but they're kept separate from the regular text stream.
You can do styles, but the formatting can be overridden or ignored by the
interpreter. You can do graphics, but (again) in a separate window, not
mixed in with text -- least in the first version. (If it becomes clear
that more is necessary, Glk can be extended without breaking existing
programs that use it.)

For heaven's sake, I'm implementing this with the same display engine I
used for MaxZip. I didn't remove *anything* from its capabilities; the
style system will be made considerably more powerful.

Miron Schmidt

unread,
Jan 10, 1998, 3:00:00 AM1/10/98
to

Patrick Kellum <pat...@syix.com> wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>
> >This means that I do not want a system which allows the game author to do
> >anything. The more the author can do, the more the porter *has* to do.
>
> Now this is absured, why don't we just make all games work on a Commodore
> Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
> Common Denominator is not the way to go.

Uh, but he isn't talking about any lowest common denominator: He's talking
about not allowing authors to do highly system-dependent stuff -- such as
specifying font names, or formatted-font-specific-colored styles etc.
The *user* on the other hand, may specify any options the port on his/her/its
system allows. That's the way I understood it, at least.

> The porter should work at the
> port, no one said programming was easy.

A porter is not programming anything -- he is porting a program from one
system to another. The whole point of the Glk specification is to make that
as easy as possible.

> Currently, I could write Supper Mario Brothers in Inform,

Now *there's* a game I'd really like to see! Will there be Dinner Mario
Brothers, too?

> that s
> how powerful the language s.

Well, I'm sure you know that isn't true. Action games with 10 fps suck. And
since the Z-Machine doesn't provide interrupts, 10 fps is the maximum you'll
be able to get. Write some complicated code between frames and you'll end at
1 fps.

> If Glk becomes the standard then we might as
> well just start writing games in Basic again, that s how constrained the
> authors will be (even more so, I would thank).

Glk is not an authoring system, or a programming language.

> Just because you can't be bothered to add support for it in your
> interpreter doesn't mean everyone else doesn't want it. As I remember,
> your interpreter doesn't even support set_colour, something that EVERY
> other interpreter supports.

Glk is not an interpreter, or a programming language.
The *author* suggests a text style, the *player* defines what this style will
look like in effect.

> So, yes I do not care for the Glk standard. To me it's just a way to
> limit IF authors just to make it easer to port to the Mac. If the Mac
> doesn't allow editing on the text screen then so be it, that shouldn't
> mean that every other system out there should be required to follow this
> limitation.

It seems to me that these reservations result widely from the fact that you
don't understand the Glk concept (either that, or I don't -- perfectly
imaginable).
Nobody is restraining anyone here. The central point to the concept is that
text games are, well, text games. Formatting text is something entirely
different than layouting text: it is not necessary to define the exact look
of the text; it is only necessary to stress some points. The author says,
"That one word is important: I emphasize it" -- the user in turn defines what
emphasis, to him, means. The author says, "Look, it's important that this
letter is written in a non-proportional font: There's a column code in it."
-- the user then gets to choose his own favourite non-proportional font. AND
she can set the color for that font, and that it should be printed in
italics.

Something like HTML, really. Only more restrained in order to *clarify* the
situation for the author.


--
Miron Schmidt <mi...@comports.com> PGP key on request

WATCH TV... MARRY AND REPRODUCE... OBEY... PLAY INTERACTIVE FICTION...


Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:

>Because that puts all sorts of requirements on the capabilities of the
>current window.

Seems to work fine on all the interpreters I use. The code is simple from
the looks of it. If you can't write the code then don't draw the boxs in
the window. But don't require every other system to follow this
limitation.

>The way I have it set up, you can implement a text-stream window with
>very little more than printf(). The interpreter never *has* to back up,
>edit, redraw, or format. As I said, you can use a Mac TextEdit object.
>The *only* methods of a text-stream window are "print some text",
>"input a line", "input a key", "clear", "measure size", and "change
>style". (And that last one is optional.)

So it's a Mac limitation? Why should a limitation on the Mac require
every other system (even possable on a C64) to drop a standard feature.

>The same goes for the Win95 and Java text objects -- just so that you
>don't think Macs are the issue here.

Then how are the Win95 interpreters doing it now? Amigas handle it OK.
C64 machines can draw them just fine.

>As to the rest of your posts, uh, I think you're *completely* missing the
>point of what I'm doing.

Not really, although I may not always speek (type) with much clairity, I'm
quite capable of understanding your standard and it's hazards.

>I'm trying to design a system which includes as much as possible of the
>Z-machine's interface, *and* expand it as much as possible, while *still*
>being implementable on a C-64.

If it doesn't include all of the Z-Machines features without making any
changes to the Z-Machine then it is a step backwards.

How should we be creating windows in a C64?

>That means making all the fancy stuff (1) optional and (2) easy to factor
>out -- so that it's not intertwined with the basic capabilities. You can
>do quote boxes, but they're kept separate from the regular text stream.
>You can do styles, but the formatting can be overridden or ignored by the
>interpreter. You can do graphics, but (again) in a separate window, not
>mixed in with text -- least in the first version. (If it becomes clear
>that more is necessary, Glk can be extended without breaking existing
>programs that use it.)

This is what I have a problem with. You'are assuming that all systems are
limited in the same way. On a Commodore 64 I can have text boxes,
graphics, scrolling text, whatever in the same screen. Macs don't appear
to be up to this level I guess (of course that's wrong, but I'm making a
point here.)

Have you seen the StdIO ports of Frotz for text terminals? They seem to
be handeling text boxes and all that other "fancy" stuff just fine. And
they're just using printf (or its equavilent, I'll have to check).
Nothing fancy, it gnores what it can't display. Glk is not needed, if a
system can't use a feature then just ignore it.

>For heaven's sake, I'm implementing this with the same display engine I
>used for MaxZip. I didn't remove *anything* from its capabilities; the
>style system will be made considerably more powerful.

MaxZip can't even handle colours and doesn't come close to supporting the
Z-Machine standard. It is not something we should base all text
adventures on.

Now before everyone claims I hate Macs (some nasty emails over night) I
personally love Macs. I mearly using them in examples because the Glk
standard seems to be based around the Macs limitations.

Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

In article <34B77CAD.MD-...@tfh-berlin.de>, Miron Schmidt was talking about:

>Patrick Kellum <pat...@syix.com> wrote:
>> Now this is absured, why don't we just make all games work on a Commodore
>> Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
>> Common Denominator is not the way to go.
>
>Uh, but he isn't talking about any lowest common denominator: He's talking
>about not allowing authors to do highly system-dependent stuff -- such as
>specifying font names, or formatted-font-specific-colored styles etc.

No, he wants to dis-allow authors from using features of the Z-Machine.
This is NOT system-dependent.

And he is talking lowest common denominator. If the Mac doesn't support a
feature then it is not allowed. That is the basis of Glk as I read it.

>A porter is not programming anything -- he is porting a program from one
>system to another. The whole point of the Glk specification is to make that
>as easy as possible.

Wrong! Have you ever ported something from one system to another? Unless
it uses a simple StdIO interface (printf and such) then it does require
massive programming. Take a look at the Amiga port of Frotz, the Amiga
specfic code is massive. When porting "The Night of the Vampire Bunnies"
to Inform I re-wrote almost every line of code. The only thing that
remains the same is the text. Same goes for all other game ports
(Adventure to Inform, I guess that only required a couple simple changes.
Nobody had to do any programming for that one.)

>> Currently, I could write Supper Mario Brothers in Inform,
>
>Now *there's* a game I'd really like to see! Will there be Dinner Mario
>Brothers, too?

Hah Hah :-) Ok, so typing while loaded with massive amounts of Caffine
isn't a good thing. BTW, my "i" key is brokin, so I can't be blaimed for
those errors :-)

>Well, I'm sure you know that isn't true. Action games with 10 fps suck. And

I started writting a Space Invaders port to Inform, got the alians moving
down at a steady pace and the player moving just fine. Only prob I was
having was reading the keys (had to only push one key at a time, I didn't
like that). The only reason I didn't finish it was I lost the source and
didn't feel like re-doing everything. Super Mario Bros. would be a lot of
work but it is possable. The original Mario Bros. would be even simpler.

>since the Z-Machine doesn't provide interrupts, 10 fps is the maximum you'll

Actually, in a way the V6 Z-Machine does.

>be able to get. Write some complicated code between frames and you'll end at
>1 fps.

I got about 10fps with Space Invaders. Not perfect but it worked. Free
Fall seems to play fine and it's the same basic idea.

>Glk is not an authoring system, or a programming language.

Acording to the author, he wants to incorporate Glk into Inform. That
makes it an authoring system.

>Glk is not an interpreter, or a programming language.
>The *author* suggests a text style, the *player* defines what this style will
>look like in effect.

This is already possable wthout Glk. Do you really belive that every
system out there handles bold text in the same manner?

>It seems to me that these reservations result widely from the fact that you
>don't understand the Glk concept (either that, or I don't -- perfectly
>imaginable).

I understand it, I just don't see a need for it. If I wanted to step
backwards I would use an 8088 machine.

>Nobody is restraining anyone here. The central point to the concept is that

No text boxes allowed in the same window. No pictures allowed except as
seperate windows. No editing of text in the window.

Nope, no restraints.

>text games are, well, text games. Formatting text is something entirely
>different than layouting text: it is not necessary to define the exact look
>of the text; it is only necessary to stress some points. The author says,
>"That one word is important: I emphasize it" -- the user in turn defines what
>emphasis, to him, means. The author says, "Look, it's important that this
>letter is written in a non-proportional font: There's a column code in it."
>-- the user then gets to choose his own favourite non-proportional font. AND
>she can set the color for that font, and that it should be printed in
>italics.

And the author is not allowed to say what colour the text should be.
Currently this is allowed in all properly-written interpreters.

>Something like HTML, really. Only more restrained in order to *clarify* the
>situation for the author.

This is my fear. I can just see it now "This game is for MaxZip. Go out
and get a real interpreter.".

HTML was great in the begining, but it has been perverted. HTML and
Interactive-Fiction are two totally different things. What happins when a
game written to ask for a "header font" is played on an older interpreter?

Brock Kevin Nambo

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

Patrick Kellum wrote in message <699ejb$l9u$1...@neko.syix.com>...

>HTML was great in the begining, but it has been perverted. HTML and
>Interactive-Fiction are two totally different things. What happins when a
>game written to ask for a "header font" is played on an older interpreter?

Nothing, because that should be the interpreter's setting...

Similar to HTML; the actual web page doesn't ask you what you want it to
look like, but you tell the browser, "show me what this page wants to look
like" or "I don't care what the page wants to look like, I want it to look
like this".. (ok, if you use lynx, you get less options. But Lynx's
formatting makes sense in "True" HTML.)

Uh, is that clear?

>>BKNambo
--
http://come.to/brocks.place | World Domination Through Trivia!
What games are on? Check out The Schedule!
http://members.xoom.com/mozilla/monster.html
oah123 (in chatquiz, 12/27/97): "did you guys know during the SPIN cycle the
clothes are like being spun really fast? LOL i just found that out!"


Damien Neil

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

On 11 Jan 1998 03:14:36 GMT, Patrick Kellum <pat...@syix.com> wrote:
>So it's a Mac limitation? Why should a limitation on the Mac require
>every other system (even possable on a C64) to drop a standard feature.

Hmm. Quote boxes are, unfortunately, the worst kind of feature: once
upon a time, there was a system which implemented things a certain way.
People took advantage of some of this system's idiosyncrasies. Now,
everyone is required to duplicate those same idiosyncrasies, even in
places where they make no sense at all.

Are you familiar with how quote boxes operate? To draw a quote box, one:
a) Resizes the status window to cover the area of the screen where the
quote box is to go.
b) Draws the quote box _in the status window_(!).
c) Resizes the status window back to its original size.

The assumption is that shrinking the status window is non-destructive.
Unfortunately, this is not going to be true in any system written for
a windowing environment, be it the Macintosh, MS-Windows, the X Windowing
System, or even lowly curses (assuming you use the curses windowing
features). Therefore, an interpreter writer is left with two choices:
ignore all windowing system support, and just write everything by hand,
or engage in nasty hacks involving status window size. (Xzip and (so
I hear) MaxZip take the latter approach, which appears to work tolerably
well.

> >The same goes for the Win95 and Java text objects -- just so that you
> >don't think Macs are the issue here.
>
>Then how are the Win95 interpreters doing it now? Amigas handle it OK.
>C64 machines can draw them just fine.

I have a strong suspicion that the Win95 interpreters are not using the
Win95 text objects. (I cannot say for sure, never having used a Win95
interpreter.) The C64 interpreters clearly are not using any native
text objects -- there aren't any. They also have a vastly simpler
situation to deal with, as they use only a fixed width font. Introducing
proportional fonts makes life vastly more interesting. (It also makes
using native windowing system services vastly more appealing, to reduce
the number of wheels that need to be reinvented.)

> >As to the rest of your posts, uh, I think you're *completely* missing the
> >point of what I'm doing.
>
>Not really, although I may not always speek (type) with much clairity, I'm
>quite capable of understanding your standard and it's hazards.

I'm a bit unclear on what these hazards are. As far as I can tell, Glk
offers a vastly more powerful output interface than the one currently
supported by the Z-machine (with the exception of graphics, which would
be easy enough to add into Glk's infrastructure). It seems that the only
Z-machine feature that anyone is using which Glk does not offer support
for is quote boxes overlayed onto a text window. Personally, I don't
consider this much of a loss -- I can recall playing Trinity, and having
quote boxes appear, covering text I hadn't read yet. Most annoying.
Furthermore, the manner in which a quote box should interact with a
scrollback buffer is most unclear to me.

>How should we be creating windows in a C64?

In, perhaps, the same fashion Infocom did? The concept of a window is
orthogonal to the concept of graphics. The Glk specification quite
clearly indicates that a window can be, for example, "the top two lines
of the screen".

>Now before everyone claims I hate Macs (some nasty emails over night) I
>personally love Macs. I mearly using them in examples because the Glk
>standard seems to be based around the Macs limitations.

You may wish to reexamine the Glk standard. After reading through it
several times (I'm still tempted to do a curses port -- however, today
I had _The Door Into Shadow_ to finish, and the copy of _Eight Skilled
Gentlemen_ I finally managed to locate arrived yesterday, so this weekend
is pretty much spoken for), I can see no aspect of it which seems to
cater to any Macintosh-specific limitations. Limitations of windowing
systems in general, perhaps -- but any such limitations apply equally
to Windows, Java's AWT, X, and others just as much as to the Macintosh.

- Damien

Bryan Scattergood

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

On 10 Jan 1998 05:18:32 GMT, Patrick Kellum wrote:
> >> Simple in Inform but it looks impossible with Glk.
> >
> >Actually, if I can modify my earlier post, it's *not* safely possible in
> >Inform in the story window, because if the story window / status window
> >size differentiation which I've talked about before.
>
> That was a problem with your interpreter, NOT with Inform. Your
> interpreter can't set the header bits properly, fix the interpreter to
> support version 1.0 (or even 0.2 for that matter) of the Z-Machine
> standard and it will work fine. The method s OK, it works on all
> standard-compatable interpreters.

No. No. No. You are reading guarantees into the standard which (IMHO) just
aren't there. Let me try and explain how I understand the screen model, and
how I ended up there.

The basic Z<6 model was based on fixed-width character-mapped displays.
Given such a display, the screen-size recorded in the header reflects the
screen size in characters. The height provides an upper bound on the size of
the upper window. The width indicates how many characters can be printed
across the upper window (in the status line, for example.) On such a
display, the extend-overprint-shrink behaviour used to do block quotes is
fairly natural: it just replaces the contents of some of the character cells
which 'really' belong to the lower window.

Now, come the early 1990s there were a number of DOS/UNIX based interpreter
cores around and folks were busy porting them to systems with proportional
fonts. It turned out that this wasn't too hard: use a proportional font for
the lower window where the interpreter controls the word-wrap, use a fixed
font for the upper window. The screen-size still represents the geometry in
terms of the fixed-font used for the upper window, because the the game
still needs to know (a) how tall it can make the upper window and (b) how
much it can print across the status-line. The size is *not* based on which
window is currently selected since some games expect to read the geometry
before selecting the upper window.

Block-quotes in this model are a pain because the upper and lower window are
using different fonts. A variety of solutions are possible. Putting the
status window in a separate host window is one. The proposed GLK-approach of
deferring the 'shrink' until character input is another. In my case I plot
the upper-window text over the flowed text in the lower window, keeping
track of which character cells in the upper window are transparent (having
never been printed.) It doesn't really matter which solution is used,
because the fact the two windows use different fonts is enough to break your
assumption that the screen-size tells you anything meaningful about the
lower-window.

Still not convinced? Even if you insist that I *have* to use the same basic
font for both windows, all you achieve is to make conformant interpreters
impossible on machines with small screens. (The Z-machine requires a minimum
upper window size of 64 columns by 16 rows. Some of the platforms which
currently have interpreters cannot meet that requirement, even using the
smallest font available. The only reasonable way to fake it is to make the
upper window larger than physical screen (which is larger than the lower
window) and to pan around the upper window. That breaks your assumption
again.)

Bryan

Bryan Scattergood

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

On 10 Jan 1998 05:11:24 GMT, Patrick Kellum wrote:
> >> Oh, ok. I thought it was a proposed change in the text capabilities of
> >> Inform and other already existing systems.
>
> >Well, that too, in a sense. I really want to get a Glk version of Hugo,
>
> ?!?! So we're going to completly wipe out an entire system of text
> adventures just to make it easer to port to Macs?

No. The GLK API (which is what Zarf is currently asking for feedback on) is
a layer which fits between an interpreter core and the host operating
system. If done properly that should allow an OS specific (GLK) module to be
written /once/ for each platform, after which any GLK-supporting interpreter
can be ported directly. And adding GLK support to an interpreter (Z-machine,
HUGO, TADS, AGT) also needs to be done only once. It is the classic benefit
from a suitable API; porting goes from an m*n to an m+n task.

Now, the API as it stands imposes one restriction on Z-machine interpreters:
block quotes can't be implemented quite as prettily as they are on some
current platforms (they have to disappear when input happens.) That may be a
shame, but as an interpreter maintainer I *can* tell you that the complexity
they add to the display code is considerable. Zarf has taken the decision
that the cost they add to porting GLK isn't worth the benefit.

> >eventually. And if there is ever a serious update to the Z-machine --
> >32-bit memory and so on -- it should *not* stick with the existing
> >Z-machine I/O system (either V5/8 or V6.)
>
> What, if I may ask, is wrong with the existing Z-Machine I/O? It has
> worked fine and it appears to support everything you want and much more.

If you need to ask ...

The Z-machine as-is provides two I/O models. The Z5 model is too
restrictive, with no scope for graphics or multiple text windows. The Z6
model is so complicated that I still don't understand it. I've considered
using it and given up on three separate occaisions, and I'm not the only
interpreter maintainer whose done that. Apart from that it also (AFAIK) has
the crippling restriction that it isn't compatible with resizing the display
window during play.

Neither is a sane choice for an intermediate API for use by other
interpreter cores, especially a (hypothetical) 32bit future virtual machine.

Bryan

Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

In article <slrn6bh6l...@zorg.hitchhiker.org>, Damien Neil was talking about:

>Hmm. Quote boxes are, unfortunately, the worst kind of feature: once
>upon a time, there was a system which implemented things a certain way.
>People took advantage of some of this system's idiosyncrasies. Now,
>everyone is required to duplicate those same idiosyncrasies, even in
>places where they make no sense at all.

How is printing standard text to the screen an idiosyncrasy? I have seen
it being done over primtive text terminals, this is not rocket science
here folks.

>Are you familiar with how quote boxes operate? To draw a quote box, one:
> a) Resizes the status window to cover the area of the screen where the
> quote box is to go.
> b) Draws the quote box _in the status window_(!).
> c) Resizes the status window back to its original size.

Why not just position the cursor to the required spot on the text wndow
and print? Too dificult?

>The assumption is that shrinking the status window is non-destructive.
>Unfortunately, this is not going to be true in any system written for
>a windowing environment, be it the Macintosh, MS-Windows, the X Windowing

Then don't use real wndows! This is what I'm getting at, the Z-Machine
was not ment to use a real windowng enviorment, it should not be hacked
into such an enviorment just to make it easer for lazy programmers.

To draw a status window, print to the top of the window in fixed-font. To
draw the text window, draw below that in proporitional font. When the
status window is refreshed it will overwrite any text that may have
scrolled over it.

>System, or even lowly curses (assuming you use the curses windowing
>features). Therefore, an interpreter writer is left with two choices:
>ignore all windowing system support, and just write everything by hand,

Whch s what was ntended in the frst place.

>or engage in nasty hacks involving status window size. (Xzip and (so
>I hear) MaxZip take the latter approach, which appears to work tolerably
>well.

I wouldn't call t workng since t seems to be causing so many problems.

>I have a strong suspicion that the Win95 interpreters are not using the
>Win95 text objects. (I cannot say for sure, never having used a Win95

What is so important about using text objects? If using this object
doesn't work then write a new one. That s what beng a programmer is
about, writing programs. It is becomng more and more common for people
who can only piece together a few objects to be called programmers. If
you don't know the code then don't program.

>interpreter.) The C64 interpreters clearly are not using any native
>text objects -- there aren't any. They also have a vastly simpler

And thank the Goddess for that. They seem to be more trouble then they
are worth.

>situation to deal with, as they use only a fixed width font. Introducing
>proportional fonts makes life vastly more interesting. (It also makes
>using native windowing system services vastly more appealing, to reduce
>the number of wheels that need to be reinvented.)

I use an Amiga, it uses a native wndowing system, it uses proportional
fonts, it allows quote boxes in the text window. Macs can't? Well, then
so sorry.

>I'm a bit unclear on what these hazards are. As far as I can tell, Glk
>offers a vastly more powerful output interface than the one currently
>supported by the Z-machine (with the exception of graphics, which would
>be easy enough to add into Glk's infrastructure). It seems that the only

Graphics would be required to appear in a seperate wndow. Damned ugly and
very sloppy.

>Z-machine feature that anyone is using which Glk does not offer support
>for is quote boxes overlayed onto a text window. Personally, I don't

And graphics in the same window.

>consider this much of a loss -- I can recall playing Trinity, and having
>quote boxes appear, covering text I hadn't read yet. Most annoying.

So, because you didn't like a feature then it should be removed?

>Furthermore, the manner in which a quote box should interact with a
>scrollback buffer is most unclear to me.

Either don't put the quote box text in the buffer (easy way) or put the
quote box text at the end of the latest text ignoring where it is printed
on the screen (harder way).

>In, perhaps, the same fashion Infocom did? The concept of a window is
>orthogonal to the concept of graphics. The Glk specification quite
>clearly indicates that a window can be, for example, "the top two lines
>of the screen".

Then, why are we now forbiden to do this? This is how Infocom handled it
on ther interpreters for orher platforms. This is exactally what the
Z-Machne was ment for. I wouldn't drive a car over a bridge and expect it
to fly, same thing.

>is pretty much spoken for), I can see no aspect of it which seems to
>cater to any Macintosh-specific limitations. Limitations of windowing

I can print different fonts in the same window, something it appears Macs
can't do. can locate the cursor to any point within that wndow and start
printing at that point, another thing Macs can't seem to do. Glk forbids
anything that a Mac can't do. I'm sure these things can be done on Macs,
but t appears Mac programmers can't be bothered to actually program.

>systems in general, perhaps -- but any such limitations apply equally
>to Windows, Java's AWT, X, and others just as much as to the Macintosh.

The windowing system I use allows all the features of the Z-Machne. I
should be allowed to continue using these features. If I write a game
that uses these features then I will expect the interpreters to deal with
t. The current system of /O on the Z-Machine s fine, it works great and
allows for some great effects. It actually requires an interpreter writer
to read the specfication but that should be expected.

Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking about:

>deferring the 'shrink' until character input is another. In my case I plot
>the upper-window text over the flowed text in the lower window, keeping
>track of which character cells in the upper window are transparent (having
>never been printed.) It doesn't really matter which solution is used,

Why? Why not just move the current cursor position to the proper location
in the lower wndow and start printing? Oh yeah, I forgot Macs can't do
this simple task.

>because the fact the two windows use different fonts is enough to break your
>assumption that the screen-size tells you anything meaningful about the
>lower-window.

I've already mentioned how to get the screen wdth in characters usng
proporitional fons, I won't bother yet again.

>impossible on machines with small screens. (The Z-machine requires a minimum
>upper window size of 64 columns by 16 rows. Some of the platforms which
>currently have interpreters cannot meet that requirement, even using the
>smallest font available. The only reasonable way to fake it is to make the
>upper window larger than physical screen (which is larger than the lower
>window) and to pan around the upper window. That breaks your assumption
>again.)

Where are you getting ths 64 column limit? I've read the specification
and I can't find it. The Z-Machine runs fine on the Commodore 64 (a
machine that only has 40 columns) and I've been told t can run on the
Vic-20 (20 columns) lthough I haven't seen that yet.

Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking about:
>Now, the API as it stands imposes one restriction on Z-machine interpreters:
>block quotes can't be implemented quite as prettily as they are on some
>current platforms (they have to disappear when input happens.) That may be a
>shame, but as an interpreter maintainer I *can* tell you that the complexity
>they add to the display code is considerable. Zarf has taken the decision
>that the cost they add to porting GLK isn't worth the benefit.

Then Glk is flawed. Features shouldn't be removed just because a
programmer or operating system can't deal with them. They should be
removed for that system or programmer. I don't read Spanish, I will most
likely never learn Spanish. This does not mean I can tell everybody that
they can not release a game in Spanish. If you want to use real wndows
despite the fact that this is not how it should be done, then fine. But
we shouldn't be required to all start using real wndows.

>The Z-machine as-is provides two I/O models. The Z5 model is too
>restrictive, with no scope for graphics or multiple text windows. The Z6
>model is so complicated that I still don't understand it. I've considered
>using it and given up on three separate occaisions, and I'm not the only
>interpreter maintainer whose done that. Apart from that it also (AFAIK) has
>the crippling restriction that it isn't compatible with resizing the display
>window during play.

Frst, f you don't understand the V6 standard then don't use it. There,
sinple. Second, it does allow resizing the window, just wrte the new size
in to the header.

The V5 /O is fne, it does what t needs to do in an effecent maner. It's
interpreter authors who are makng it sloppy by using absured windowing
setups for ther interpreters.

V6 is wonderful, it allows interupts after each new line and other great
features. If you can't understand the features of V6 then so be it.

>Neither is a sane choice for an intermediate API for use by other
>interpreter cores, especially a (hypothetical) 32bit future virtual machine.

would rather see V6 screen system cleaned up a little for use in a future
Z-Machine, it has all the needed features for the future of Interactive
Fiction.

Patrick Kellum

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

Just one thought. What do we want? Why should we use the web as a
template for future IF? Do we really need to start droping well
established features just to make it easer for new programmers to port
something that should be done by experanced programmers anyway?

Personally, see no benifit in this proposed Glk standard, it appears to
be a standard for the sake of writing one. It doesn't properly support
the Z-Machine and will cause older games to display incorrectly on Glk
interpreters. It will basicly make a mess of IF, turning t into some
tacky HTML style monstrosity.

Jeff Hatch

unread,
Jan 11, 1998, 3:00:00 AM1/11/98
to

Patrick Kellum wrote:
[snip]

> Personally, see no benifit in this proposed Glk standard, it appears to
> be a standard for the sake of writing one. It doesn't properly support
> the Z-Machine and will cause older games to display incorrectly on Glk
> interpreters. It will basicly make a mess of IF, turning t into some
> tacky HTML style monstrosity.

I don't agree with most of your criticisms of the Glk standard, or most
of your arguments in favor of the Z-machine standard. But regardless,
what difference does it make? I don't see how a new standard can hurt,
no matter how bad it is! If the Z-machine is better, Inform gamers will
continue to use a custom Z-machine interface. Even then, the Glk
standard might benefit other systems. Inform is arguably the best
currently available authoring system, but it's not the only system, and
many others don't support the Z-machine.

Minimum standards don't generally force good systems down to the least
common denominator. Instead, they raise the bad ones to a minimum level
and make things easier for users at all levels. When ANSI C became the
standard, did video game designers stop using graphics and start using
"printf" and "scanf" for all their interfacing needs?

Similarly, I don't think IF authors and gamers will be stupid enough to
use the Glk standard if it's not adequate for their needs.

-Rúmil

Andrew Plotkin

unread,
Jan 12, 1998, 3:00:00 AM1/12/98
to

Patrick Kellum (pat...@syix.com) wrote:
> >Uh, but he isn't talking about any lowest common denominator: He's talking
> >about not allowing authors to do highly system-dependent stuff -- such as
> >specifying font names, or formatted-font-specific-colored styles etc.

> No, he wants to dis-allow authors from using features of the Z-Machine.
> This is NOT system-dependent.

I'm not talking about the Z-machine at all. I'm talking about future IF
systems, and current ones which are not well-ported (like Hugo.) (Or even
TADS. Howzabout a zero-effort Pilot port of TADS?)

> And he is talking lowest common denominator. If the Mac doesn't support a
> feature then it is not allowed. That is the basis of Glk as I read it.

You read... wrongly.

> >A porter is not programming anything -- he is porting a program from one
> >system to another. The whole point of the Glk specification is to make that
> >as easy as possible.

> Wrong! Have you ever ported something from one system to another? Unless
> it uses a simple StdIO interface (printf and such) then it does require
> massive programming.

I have a dream that this is not so. I have a dream that it can be made as
easy as StdIO porting is. And I think I've implemented most of my dream,
too.

Enough.

Andrew Plotkin

unread,
Jan 12, 1998, 3:00:00 AM1/12/98
to

Patrick Kellum (pat...@syix.com) wrote:
> Just one thought. What do we want?

I want a serious romantic relationship with a nice girl.

I also want a circuit diagram for a set of chasing lights -- a small set,
five or six, preferably "fading" in and out (each one fading on as the
last one is going off, in turn around the circle.) The problem is that
these are AC-powered lights -- and in fact it's not standard house
current, but some high-frequency juice I haven't measured yet. Can anyone
provide a clue? Email only.

Oh, yeah, Glk.

> Personally, see no benifit in this proposed Glk standard, it appears to
> be a standard for the sake of writing one. It doesn't properly support
> the Z-Machine and will cause older games to display incorrectly on Glk
> interpreters. It will basicly make a mess of IF, turning t into some
> tacky HTML style monstrosity.

A Glk interpreter is not a Z-machine interpreter. In fact, the word
"interpreter" isn't even being used the same way in those two phrases.

You could write a Glk-based Z-machine(v5/8) interpreter. It would support
very nearly every Z-machine feature I know of, including color and quote
boxes (the latter done the way MaxZip does them.)

But this *is not* the sum total purpose of Glk, or even a major purpose.

I have quite a nice Glk-based AGT interpreter running now, on my Mac.
(Based on Agility.) It looks and plays like MaxZip and MaxTADS -- *not*
like the (crappy, terminal-window-style) Mac Agility I knocked off a few
months ago.

It still has wires hanging out the back, metaphorically, so I'm not
releasing it yet. But *this* is what Glk is for.

Rhodri James

unread,
Jan 12, 1998, 3:00:00 AM1/12/98
to

In article <698q5n$4iu$1...@neko.syix.com>,

Patrick Kellum <pat...@syix.com> wrote:
> In article <34bf6906...@news.virgin.net>, Steve Waddicor was
> talking about:

> >No, an M is conventionally the widest character in a font. That's why


> >the unit for measuring widths in a font is an 'em'. The W is wider
> >than the O too.

> "0", not "O", i.e. Zero, not Ohhhh.

An "M" is conventionally wider than an "0" too. In fact an "O" is
generally wider than an "0". The point being?

--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them

... Error: routine Lunchtime is purely virtual

Rhodri James

unread,
Jan 12, 1998, 3:00:00 AM1/12/98
to

In article <69b9em$hdo$2...@neko.syix.com>,

Patrick Kellum <pat...@syix.com> wrote:
> In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood
> was talking about:

> >deferring the 'shrink' until character input is another. In my case I


> >plot the upper-window text over the flowed text in the lower window,
> >keeping track of which character cells in the upper window are
> >transparent (having never been printed.) It doesn't really matter
> >which solution is used,

> Why? Why not just move the current cursor position to the proper
> location in the lower wndow and start printing? Oh yeah, I forgot Macs
> can't do this simple task.

Bryan isn't talking about Macs. Nor is he talking about something as
simple as "just printing" from an arbitrary pixel coordinate. Your
preconceived notions of what is going on at *any* level appear to be
getting in the way here.

> >because the fact the two windows use different fonts is enough to
> >break your assumption that the screen-size tells you anything
> >meaningful about the lower-window.

> I've already mentioned how to get the screen wdth in characters usng
> proporitional fons, I won't bother yet again.

Actually you said:

> Subtract the length of the text (divided by 2) from the width of the
> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).

I presume the second sentence is the (interestingly non-standard) method
of getting the "screen wdth". I hope you aren't intending to know these
values as an author?


PS: your method of quoting is outstandingly annoying. Please don't indent
so far, it makes requoting what you've quoted much more tedious than is
necessary.

--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them

... Unfortunately we also have the stealth of elephants