Glulx styles: tangents and secants
Andrew Plotkin
week's discussion, and comment on them at random. I will not try to
tie them together into any kind of coherent whole. Coherent is for
later. :)
By the way, if you didn't see my message from Sunday ("Glulx styles,
from the top, or bottom as it might be") then go back and read it
first. It's important. (Aaron suggested that it might be buried inside
the old thread and not visible to everybody. I'm not a fan of these
new-fangled threaded newsreaders, so I wouldn't know about that, but
here's your reminder.)
Final prefatory comment: I wrote down a lot of points, or summarized
them in my notes, without noting who said them. I apologize. 115
messages was a lot.
----------
Do people hate CSS? I don't *like* CSS -- I don't imagine many people
do -- but I hate the pre-CSS HTML world a lot more. I am usually
guilty of assuming that everybody is just like me.
I can imagine people disliking CSS, but then I can imagine people
disliking the current I7 idiom with tables full of style hint
information. CSS has the disadvantage of being different from I7 --
you have to switch languages when you switch domains -- but then it
has the advantage that a lot of people *do* know it already.
People who have strong opinions about typography are particularly
likely (though of course not *certain*) to have worked with CSS at
some point.
Another factor: CSS has a lot in it that I don't have to define. If
you're setting up a game for a web interpreter, my original "drop the
CSS chunk straight in there" proposal gives you a lot of potential
fanciness -- background images, line and letter spacing, big initial
letters, graphical section dividers, etc. All of that can be done in
CSS, keyed off of style classes.
I guess I shouldn't go on with that argument without splitting out the
two basic design questions: (1) where does style information come
from: a separate stylesheet, or I7 declarations in the source code?
(2) if it's a separate stylesheet, what's the format? (3) if it's in
the source code, are semantic styles divided from their appearance
information, or are there only appearances?
Three. Three basic design questions. :) And now that I've asked them,
I'll change the subject. :)
Someone asked: "Can the game query the interpreter preferences?" That
is, should this game-vs-player preference conflict be managed *by the
game code*, after sucking in preference info. I'm going to go out on a
limb and say "No." If the style resolution system varies per-game, it
becomes impossible for the player to predict what her preference
settings are going to *do*, or whether they'll do anything at all. I
dislike that a lot.
Same goes for letting the author set "this is super-important!" on a
style hint.
"Interpreter skinning" popped up, as a concept. I take this as the
idea of having the user preferences *not* be expressed as a
traditional dialog box (which can get very complicated for even
moderate text styling choices); but rather as a stylesheet in its own
right, created by a designer, imported (as a black box) by a player.
That's a nice idea. It means that players don't have to become
typography experts (which seems to be a terrifying prospect even to
programmers!) It means, conceivably, that the problem of resolving
style conflicts could be kept between the people interested in style
design: skin designers and opinionated game authors. I'll keep that
one in mind.
"Parametrized styles". This is a nice shorthand for a group of cases I
hadn't considered: places where you want a *continuum* of styles,
rather than a fixed list of variants. E.g., colored text varying from
red to blue, representing a heat scale, or an interestingness scale,
or whatever.
Quite a bit was said about parametrized styles. Can my recent proposal
handle them? Yes, if you're willing to create (say) fifty styles in
slightly different hues. Does that suggestion make me claw my eyes
out? Not *completely* out, no. :) The notion of style inheritance
could let a player customize fifty styles at once, without undue
headache. But it sure feels like an abuse of the system.
...Now don't make that face. I'd rather set up a system that people
will use *without* jumping through that sort of crazy hoop. So you're
making a good argument that my recent proposal was inadequate. I don't
have a better plan yet, because this is not the better-plan post, but
the point is well-made.
(To requote someone: "the alternative is to hack, which I'd argue
compromises both aesthetics and accessibility". Exactly!)
Along this line, Aaron said:
> Imagine in Blue Lacuna I let the user select a color for the three
> types of highlighted keywords, the standard text, and the parser error
> message.
...then went on to the idea of an in-game color picker. That
immediately gave me a migraine -- because color-picking, like window-
resizing and line-wrapping, belongs at the interpreter level, not the
game level. (Shouldn't people be able to select a color for *every*
style in *every* game? If they want? Using their machine's standard
color-selection widget?)
My proposal went some distance in that direction. That's the whole
point of *having* named styles, declared by the game author, in a
terp-parsable section of the stylesheet. It lets the interpreter pop
up a nice preference pane which lists those styles and lets you tweak
their appearance.
However, I have to accept that there can be an impedance mismatch
between what the author wants to do, and what the game winds up doing.
In an ideal world, the author would know exactly what styles his game
could use, the game could then communicate that information to the
interpreter, the interpreter could put up a lovely preference dialog.
In practice? Somebody mentioned the idea of a "Simple Colored Text"
extension. Now half the games out there have the same list of sixteen
color-specific styles. Is that ideal? No, but neither is *not* having
a "Simple Colored Text" extension. Here, too, I have no better plan,
but I acknowledge the problem.
As a tangent: is color different? I think someone suggested using
named styles, as per my model, but allowing ad-hoc colors.
Answer: no, color is not special. First of all, many of the uses of
color -- including _Blue Lacuna_, _Photopia_, _Rover's Day Out_ --
*are* completely semantic. But more importantly, the notion of
parametrized styles goes way beyond color. We've all seen "tag clouds"
expressed as boxes of words of varying size. Carroll's "Mouse's Tail"
(cited by somebody) uses line indentation as a parameter. The CSS
"font-weight" parameter is technically a nine-step numerical scale,
although most fonts only offer one or two weights. So if you're going
to drag me down the parametrized primose path, you can't ask for
special treatment for color. :)
(Color does have some unique problems, like the light-or-dark-
background conundrum. If I (as an author) want to specify some red
highlighted words and some blue highlighted words, I'm not going to
use saturated colors (#FF0000, #0000FF). Forget the (perhaps
contrived) case of a solid-red or solid-blue background. I think the
saturated colors are ugly on *any* background. I'm going to use muted
tones -- meaning #660000, #000088 on a light background, or #FF8888,
#9999FF on a dark background!
Can that level of discrimination be fit into a style model? Or a
"Simple Color Extension"? I don't know. But it's more of a headache
than font size, where saying "120%" gets you most of the way home.)
On to the questions that fell out of my more recent post:
David Fletcher
>
> A complicated example is the one Ron Newcomb suggested, where the
> author wants to use a colour which is halfway between the user's two
> preferred colours for normal text and input text.
Yep, that's another tough one.
Ron Newcomb:
> The compiler should *not* have opinions about game appearance.
> (I agree, but, does that include linebreaks & indents? 'Cause I think
> compilers have opinions there.)
Line breaks, definitely. I would love to put semantic paragraphs and
line-by-line lists into the document model, but that's just too far
away from what I7 (or I6) does. We're stuck with line breaks the way
they are.
Indentation runs both ways -- an interpreter can specify paragraph
indentation, and so can the game (just by printing spaces).
Fortunately, this conflict can trivially be resolved by adding the
indents. :)
> I do not think interpreter writers should be required to support
> user preferences.
I agree, I agree, I agree.
(Like I said, interpreter creation is the hardest job, so Glk has
always leaned towards giving them leeway to adapt the spec to the
needs of the platform.) (Besides, if an interpreter errs on the
side of too few user preferences, that's unequivocally the
interpreter-writer's problem -- and not mine. :)
I'm not sure how to rephrase my rules. I don't want to have a "Glk
layer 1", "Glk layer 2" split of features to implement. (Life isn't
that tidy.) I guess it falls into the category of "when it comes down
to it, the interpreter will do what it wants; but it ought to handle
whatever is reasonable and practical of this model: ..."
Jesse:
>
> However, I wouldn't want to sacrifice one person's possible for
> another person's pleasant. I get the impression that restricting
> games to a finite number of predefined styles was an attempt to make
> changing styles pleasant for the player, at the cost of making
> certain style changes impossible for the author.
Well, yes. And no. The old Glk model for preferences was that the
interpreter would show you all eleven styles to customize. Obviously
that setup is only possible with a finite number. If the game can
raise the limit arbitrarily, sooner or later we'd have a game with
hundreds or thousands -- as frequently mentioned last week. Is that
dialog impossible to manage or merely very very unpleasant? It's bad
enough, anyhow.
In the end, though, my job is declaring some things to be impossible.
Aaron wrote a big blog post last week in which he frowned on
"legislating from the compiler". Well, it's going to happen. If I fail
to write legislation, somebody else will, or else we'll be stuck with
the legislation I wrote *last* time. There is no outcome in which
every possibility remains possible for everybody.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
vaporware
> Jesse:
>
> > However, I wouldn't want to sacrifice one person's possible for
> > another person's pleasant. I get the impression that restricting
> > games to a finite number of predefined styles was an attempt to make
> > changing styles pleasant for the player, at the cost of making
> > certain style changes impossible for the author.
>
> Well, yes. And no. The old Glk model for preferences was that the
> interpreter would show you all eleven styles to customize. Obviously
> that setup is only possible with a finite number. If the game can
> raise the limit arbitrarily, sooner or later we'd have a game with
> hundreds or thousands -- as frequently mentioned last week. Is that
> dialog impossible to manage or merely very very unpleasant? It's bad
> enough, anyhow.
Well, in practice, the sort of game that needed thousands of styles
could easily offer a better interface for customization. If an author
wants to use shades of red to represent a character's anger level, he
can offer the choice to use shades of some other color instead, or to
disable the feature and use some other means. It might require some
cooperation between author and player, but it is nonetheless possible
to give the player control there.
On the other hand, there is no workaround for the situation where a
game can't choose a certain style combination because it's restricted
to a static list of styles. A game that selects arbitrary 24-bit
foreground and background colors is *literally impossible* to make out
of static CSS today: it would require a style sheet that's too big to
fit on anyone's hard drive, let alone fit into a Blorb.
Parametrized styles could be a great solution, though, and I look
forward to seeing the plan for those.
> In the end, though, my job is declaring some things to be impossible.
> Aaron wrote a big blog post last week in which he frowned on
> "legislating from the compiler". Well, it's going to happen. If I fail
> to write legislation, somebody else will, or else we'll be stuck with
> the legislation I wrote *last* time. There is no outcome in which
> every possibility remains possible for everybody.
I'm more concerned about what the system makes possible for authors
than for players, for the reason I gave above: a cooperative *author*
can make things possible for the player even without the system's
help, but even with a cooperative *player*, the author is still
limited to what the system lets him do.
vw
John G. Wood
> Do people hate CSS? I don't *like* CSS -- I don't imagine many people
> do -- but I hate the pre-CSS HTML world a lot more. I am usually
> guilty of assuming that everybody is just like me.
I have similar feelings about CSS. It's sort of like democracy: the
worst form of style management except for all the rest. I think the
pros (including familiarity and compatibility) outweigh the cons.
> Color does have some unique problems, like the light-or-dark-
> background conundrum. [...] I'm going to use muted tones --
> Meaning #660000, #000088 on a light background, or #FF8888, #9999FF
> on a dark background!
I feel that supporting this level of response to the player's /
interpreter's choices is close to essential. Since you're not allowing
the game to query the interpreter preferences there would have to be
some way of marking style alternates - by saying, for example, "use
this CSS file for a dark background, use this other one for a light
background and as the default".
Thanks for trawling through the thread for the useful stuff...
John
Ron Newcomb
> two basic design questions: (1) where does style information come
> from: a separate stylesheet, or I7 declarations in the source code?
Separate stylesheet, but, I7 declarations instruct Inform to *create*
that separate stylesheet. (So it doesn't look like it's separate from
the author's point of view, even though it is.) This also works with
non-Inform authoring tools that can 1) declare color & stuff in a way
native to that tool, or, 2) completely ignore the whole problem, the
author making the stylesheet as a completely separate process.
I leave your other 2 points as exercises for the reader. :)
> > The compiler should *not* have opinions about game appearance.
> > (I agree, but, does that include linebreaks & indents? 'Cause I think
> > compilers have opinions there.)
> Line breaks, definitely. I would love to put semantic paragraphs and
> line-by-line lists into the document model, but that's just too far
> away from what I7 (or I6) does. We're stuck with line breaks the way
> they are.
Just as a color style can be flicked on & off and a font-weight style
can be flicked on & off, how about a run-paragraph-on "style" that can
be flicked on & off? If on, the interpreter ignores any linebreaks
the game/compiler stuck in there. If off, everything works like it
normally does. This seems like it would degrade nicely: an
interpreter that doesn't implement it would still print the usual
linebreaks for the default look. And even if an interpreter does
support it, it can expose it as a user preference, as a simple
checkbox, "Allow author to screw with your linebreaks? (Y/N)".
For completeness'es sake, include a "style" for stick-a-linebreak-here
that works within the rpo style. It isn't something that turns on/
off, obviously, but being a "style", it would still be ignored by non-
CSS interpreters, and would also obey the same exact checkbox.
Seems like a cheap way for authors to override how their authoring
tool does linebreaking, and easy enough for interpreter-writers to
implement. And still allows the "default default" look at the flick
of a player's checkbox.
> David Fletcher
> > A complicated example is the one Ron Newcomb suggested, where the
> > author wants to use a colour which is halfway between the user's two
> > preferred colours for normal text and input text.
> Yep, that's another tough one.
Call it another example of parameterized styles, where the two
parameters are each of type "style" rather than of type "color" or
"number" or "weight". Does that make it easier?
> Someone asked: "Can the game query the interpreter preferences?" That
> is, should this game-vs-player preference conflict be managed *by the
> game code*, after sucking in preference info. I'm going to go out on a
> limb and say "No."
For conflict, ok, I'll agree. But the above color-halfway-between
isn't an author/player *conflict*.
If a parameterized style can take other styles as parameter(s), then
that implies querying the interpreter preferences. But again, just
because it can "read" the inputted-text preference doesn't mean it has
the ability to "[over-]write" that preference. It's hard to conflict
by just reading values.
I think your larger question is, how do we allow a player to override
*computed* styles?
(Is it enough just to override the inputs???)
> I'm not sure how to rephrase my rules. I don't want to have a "Glk
> layer 1", "Glk layer 2" split of features to implement. (Life isn't
> that tidy.) I guess it falls into the category of "when it comes down
> to it, the interpreter will do what it wants; but it ought to handle
> whatever is reasonable and practical of this model: ..."
Good enough for government work.
> > However, I wouldn't want to sacrifice one person's possible for
> > another person's pleasant. I get the impression that restricting
> > games to a finite number of predefined styles was an attempt to make
> > changing styles pleasant for the player, at the cost of making
> > certain style changes impossible for the author.
>
> Well, yes. And no. The old Glk model for preferences was that the
> interpreter would show you all eleven styles to customize. Obviously
> that setup is only possible with a finite number.
I don't see the clash here. As long as the number of parent styles is
a finite and reasonable number, we're good. If one of those parent
styles has 1,000 children, well, just tinker with their parent and
forget about drilling-down.
This implies that "tinkering with the parent" may involve picking 2 or
3 colors for that parent -- the extreme ends of the children's
spectrum.
Ron Newcomb
> parameters are each of type "style" rather than of type "color" or
> "number" or "weight".
Mr. Voice-in-my-head says, "If a style only took as a parameter one
other style, isn't that just called 'inheritance'? So a style that
takes two or more styles as parameters using multiple inheritance?"
...which CSS kinda-sorta allows anyway:
Aaron A. Reed
>
> > Imagine in Blue Lacuna I let the user select a color for the three
> > types of highlighted keywords, the standard text, and the parser error
> > message.
>
> ...then went on to the idea of an in-game color picker. That
> immediately gave me a migraine -- because color-picking, like window-
> resizing and line-wrapping, belongs at the interpreter level, not the
> game level. (Shouldn't people be able to select a color for *every*
> style in *every* game? If they want? Using their machine's standard
> color-selection widget?)
>
> My proposal went some distance in that direction. That's the whole
> point of *having* named styles, declared by the game author, in a
> terp-parsable section of the stylesheet. It lets the interpreter pop
> up a nice preference pane which lists those styles and lets you tweak
> their appearance.
I guess what I was trying to avoid, by doing the end-run around
interpreter control of styles in Blue Lacuna, was an instruction
message like the following:
"Welcome! In this game some words look like this. Did that word look
different? If not, well, you'll need to figure out how to change it in
your interpreter program. That's the program that's running this
program-- look, never mind about that, just click through some of
those menus up there. Do you see an option in any of them for
'preferences' or maybe 'settings?' No? Maybe? Oh good, you found it.
Now there is probably going to be a lot of stuff in there, you're
looking for something that lets you set a thing called 'User Style 1'.
That's for highlighted objects. Then 'User Style 2' is highlighted
directions. They might be called 'Custom Style 1' or 'First Custom
Style' or something instead. No, I'm afraid I can't tell you which
preferences tab it's going to be in, it's different from one terp to
the next. Actually it might not even be there, in some of them. Anyway
once you've changed that, you may, depending, need to quit and restart
to see how your change looks. No, not just the game, the whole
interpreter program I'm afraid. Then just relaunch it, load the game
again, come back to this spot and see if the text looks the way you
want it to l--- Hey, where are you going?"
The point is that letting people deal with the game's custom styles on
the interpreter level was a) inconsistent from terp to terp and
platform to platform, and thus hard to explain, b) required learning a
second program (the terp), not just Blue Lacuna, and c) was not even a
consistently available or functional option on many interpreters. So
my response was basically "Well, this is broken: I'll just give them a
menu."
However: even if all of these things became completely standardized
and easy to do (which may not even be possible or desirable,
particularly in the case of #1), I'm still not sure I'd do things the
"correct" way. I'm envisioning my instructions now looking like this:
"Welcome to Blue Lacuna! Before getting started, you'll need to select
'Preferences' from the 'File' menu, choose the 'Custom Styles' tab,
and then select a color for 'User Style 1' (to represent the color of
highlighted objects) and 'User Style 2' (to represent directions).
Once you're done, click OK and you're ready to play!"
This is certainly a big improvement, but not exactly the gripping
first impression I'm trying to make. It's like telling people they
need to edit an .ini file: acceptable and expected in DOS, not so much
on XBox Live.
Seen from another angle: the interpreter has no way of knowing what
the custom styles signify in my particular story, and thus can't be
expected to present a context-aware interface to the player for
changing them. I'm not sure it's possible to keep the process of
selecting sensible styles something that happens entirely at the
interpreter level.
--Aaron
Ben Cressey
> named styles, as per my model, but allowing ad-hoc colors.
Somewhere in the dark recesses of the last thread, I proposed using
the static style model but with an additional glk_style_override call
that could tweak one value for any of that style's attributes. It was
floated in terms of text colors but I agree that it is not sensible to
privilege color above any of the other attributes from a design
perspective.
From an interpreter standpoint, I expect some of the style overrides
would be a higher priority to implement. Colors, yes, as well as any
other attribute suitable for emphasis (bold, italic, underline.)
My thought is that successive glk_style_override calls would not be
cumulative; each time the style would be reverted to its static or
inherited default, and then exactly one attribute would be adjusted.
Ideally this could happen for output in an existing window, but that
might be pushing it.
I really like the idea of the static style system, but I think its
success would be heavily predicated on the rise of I7 extensions that
offered predefined sets of styles: either as a packaged theme or just
covering the basic demand for colored text. I envision a distinct
syntax for each type of extension; for simple effects, the user might
write "print X in red text" to set the relevant style. For the more
complete themes, they would instead write "print X as a medium header"
and allow the theme to use its prepackaged setting.
In an environment like that, where most authors would end up using
stylesheets that they did not create, a method to tweak individual
values would be extremely useful, if not indispensable. It would
allow an author to use a theme without modification - thereby
encouraging the creation of such themes in the first place - but to
decide that medium headers should be mauve instead of olive. Or that
alerts should be printed in a special font that could display the
necessary characters, while keeping all other font settings intact.
Jim Aikin
drunken moose. Aaron has articulated the issue with admirable lucidity.
Any IF delivery system that requires that the user jump through such
preposterous hoops -- or even requires, in the interest of effective
game-play, that the user be warned of the existence of said hoops in
order to avoid possible problems and confusion -- ought to be quietly
led out behind the barn and shot in the head.
The analogy with editing an .ini file on a DOS system is both reasonable
and revealing. Legacy systems that hark back to the 1970s are not a good
thing. They were tolerable in the early '90s, certainly. Today, no.
--JA
Ron Newcomb
This seems to be a point in favor of allowing styles to be named
(optionally please!), but other than that, I think it odd to call out
to the player "and you can customize these colors". Of course they
can customize colors. They can also customize fonts, font sizes,
margins, etc. as well, just by virtue of using an interpreter. I don't
see why it's worth the shout-out. 90% of the players will trust you to
choose decent defaults anyway.
What your example *does* cry out for is asking the interpreter if it
supports color or if it supports color but the user has it disabled.
'Terps can already do the 1st IIRC; you just need an extension
exposing it in an author-friendly way. The 2nd, well, Ben already
remarked that most interpreters don't report the distinction between
"off" and "unsupported".
Gregory Ewing
combinatorial explosions of styles:
1) Using more than one style at a time. If I have
an Emphasised style set to bold, and a Keyword style
set to blue, I should be able to display output using
both styles together and get bold blue text.
If the styles specify orthogonal attributes it's
straightforward to combine them. Otherwise some
arbitrary rule would be needed to resolve conflicts.
It probably doesn't matter much what rule is used,
as authors would be expected to specify non-conflicting
defaults, and if a player changes them to something
conflicting he deserves whatever he gets.
2) Linear combinations of styles. This is for handling
things like continuous colour gradations. For example,
I could define two styles called Cold and Hot and
display a temperature of 70 (on a scale from 0 to 100)
using 0.3 * Cold + 0.7 * Hot.
This would also address the case of wanting a text
colour half way between two of the user's preferred
standard colours.
It could also be useful for specifying relative font
sizes.
--
Greg
mwigdahl
> Loud sounds of stamping feet, clapping, whistling, and bellowing like a
> drunken moose. Aaron has articulated the issue with admirable lucidity.
>
> Any IF delivery system that requires that the user jump through such
> preposterous hoops -- or even requires, in the interest of effective
> game-play, that the user be warned of the existence of said hoops in
> order to avoid possible problems and confusion -- ought to be quietly
> led out behind the barn and shot in the head.
>
> The analogy with editing an .ini file on a DOS system is both reasonable
> and revealing. Legacy systems that hark back to the 1970s are not a good
> thing. They were tolerable in the early '90s, certainly. Today, no.
>
> --JA
>
Consider also that it would be theoretically possible to configure how
a modern PC game such as Half-Life 2 or Dragon Age interacts with the
video card by going into your video adapter's UI and setting up a
custom configuration profile. Of course, no one actually does this.
All modern games that run on top of, say, DirectX on Windows have
their own in-game menu interface to set these options, and these in-
game menus are tailored to match the overall aesthetics of the game.
They can do this because DirectX provides capability interrogation and
reflection features such that default settings like the screen
resolution and anti-aliasing (and yes, sometimes fonts and colors as
well) can be modified internally to the game, without breaking
immersion.
It would seem both reasonable, useful, and aesthetically justified to
provide similar features in Glk/Glulx to support Aaron's style of in-
game customization.
Matt
Ben Cressey
> and revealing. Legacy systems that hark back to the 1970s are not a good
> thing. They were tolerable in the early '90s, certainly. Today, no.
Gargoyle uses an .ini file to set user preferences. Is it
unfriendly? I suppose. It gets the job done, though, and I think the
users that gravitate toward Gargoyle are for the most part comfortable
with that sort of thing.
I could put more development effort toward it. The same is true of
any number of features that Gargoyle lacks. However, in this case I
think it's useful to have a barrier toward customization. It promotes
feedback from the user to the developer if the default settings -
fonts, styles, all the rest - drift away from what the majority of
users want.
In a perfect world the .ini file would not exist. It's clunky,
archaic, difficult to parse and tricky to modify properly. But it
shares many of these traits with Glk styles in the current
incarnation, and I see no point in crafting an intuitive in-game
interface to deal with what is fundamentally not a user-friendly
system.
I don't want to see "no more .ini files!" become a rallying cry,
because .ini files are not the problem. Rather, they are an imperfect
solution to the real problem.
mwigdahl
I think the .ini file is just fine as a way to customize interpreter
defaults -- I just think allowing style reflection and modification at
the glk layer will provide the tools to allow authors like Aaron to
take their own game's default stylesheet and provide a mechanism to
allow users to modify aspects of that stylesheet in-game.
To me this makes a lot of sense, since the game author is the one with
the most knowledge about the semantics of the styles as applied in the
game. He or she can provide an interface that makes sense in context,
and fosters immersion. And if changing a certain color setting
entails cascading changes to 50+ styles, and perhaps swapping the
background color to boot, the author will know this and can provide
the code to make it work properly. As an interpreter writer, you
don't have this context (and shouldn't _need_ to have it).
Matt