Glulx styles, Nov 30
Andrew Plotkin
Javascript Glulx interpreter) and then use that as a lab bench for
designing a good style system.
Hammering has obviously ground to a halt since then. (My time has been
going into a non-text iphone game, although I may take a break to work
on a jayisgames-comp entry.) That takes the wind out of my previous
"gimme a few months" statement, and I see you all looking meaningfully
at your torches and pitchforks. Fair enough.
Conveniently, my Thanksgiving plans involve being sent to central
Pennsylvania for five days, where the decadent citified diversions of
louche Boston will be entirely unavailable. So, new plan: over
vacation, I will pound out a proposal and work some test code into
GlkTerm. I will post a week from today -- yes, a hard deadline -- and
say what I've come up with. Screaming will then ensue, at the end of
which we will have a spec proposal that game authors and Glk
implementers can cope with.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Mike Tarbert
> ... I will post a week from today -- yes, a hard deadline --
We'll be expecting you *promptly* on Nov 37th.
Andrew Plotkin
Remember, remember, the 41st of Octember.
Gene Wirchenko
<erky...@eblong.com> wrote:
>Here, Mike Tarbert <miket...@embarqmail.com> wrote:
>> Andrew Plotkin wrote:
>>
>> > ... I will post a week from today -- yes, a hard deadline --
>>
>> We'll be expecting you *promptly* on Nov 37th.
>
>Remember, remember, the 41st of Octember.
That is the 36th. And send presents next year. I will be 50.
Sincerely,
Gene Wirchenko
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Mike Tarbert <miket...@embarqmail.com> wrote:
>> Andrew Plotkin wrote:
>>
>> > ... I will post a week from today -- yes, a hard deadline --
>>
>> We'll be expecting you *promptly* on Nov 37th.
>
>Remember, remember, the 41st of Octember.
Gunpwder, Plimsoll, and thirst.
Adam
Aaron A. Reed
You, sir, are a brave man. All of my own hard deadlines long since
passed by salute you.
(But seriously, awesome news. Looking forward to it!)
--Aaron
Andrew Plotkin
Okay, here's what I've got.
I know RAIF is less the hub of the universe than it used to be, so
I've also posted this document on the wiki:
<http://ifwiki.org/index.php/New_Glk_styles>
Comment there or here.
-------------------------
This is a very rough draft of the new Glk style system which I have been
procrastinating on, wigglesome-wagglesome, for about ten years now.
= A new kind of Glk style system =
== A glimpse through the fog ==
Our goal is to define a "Glk stylesheet", a subset of CSS. This will
typically be provided as a chunk in a Blorb package. A web-based IF
interpreter, or a terp which uses an HTML toolkit, will be able to insert
the stylesheet directly into its HTML output. (Either with @import or DOM
document manipulation.) A standalone IF terp will be able to parse the
stylesheet itself, and apply it to the game output; ideally the results will
be close to the Web rendering.
This requires three definitions:
* A strict subset of CSS (version 2.1), which should be understood by all
terps. Authors can expect IF terps to handle all of this subset.
* A less-strict subset of CSS (a superset of the above), which can be parsed
by all terps. This includes attributes and selectors which a complete HTML
toolkit will be able to handle, but a standalone IF terp may ignore.
* A document model which web-based IF terps must produce, in order for the
stylesheet to be applied properly. A standalone terp should be able to
render its output as if it were using this model with the given stylesheet.
An underlying assumption of this model is that the stylesheet is constant
throughout the game. It is unpacked and parsed before the game starts
running, and the game has no way to modify the stylesheet. From the game's
point of view, the world consists of windows, styles, and text; any given
span of text appears in one window and has exactly one style.
Another assumption: the game cannot know how the text is eventually rendered
on the screen. (Really this has always been true. The old
glk_style_measure() and glk_style_distinguish() calls were never very
useful, because they could not be determined until after the window
appeared, which led to an unfortunate cycle of test-render-test-render.) See
"Ints and introspection", below, for more.
== Style inheritance ==
We would like to set up an inheritance tree of named styles, and encourage
game authors to build off of that tree rather than inventing entirely new
styles. This would maximize the ability of users to customize their
interpreters in a meaningful way.
This two-level tree will be available out of the box. The base level is
three generic style classes; the next level are the existing Glk styles
(plus "Bold", which does not currently exist).
* body
** Normal
** Emphasized
** Bold
** Alert
** Note
** BlockQuote
** User1
** User2
* head
** Header
** Subheader
** Input
* fixed
** Preformatted
(Maybe this tree should be deeper, with "Alert" hanging off "Note", and
"Bold" and "Italic" hanging off "Emphasized"? Not sure. Also, I probably
want to make "Normal" and "body" the same thing, style number zero. Will fix
that later.)
At a basic level, the user might set his terp to use Optima for "head",
Times for "body", and Courier for "fixed". More specific customizations
would be available if desired. A game could then add a "Subsubheader" style
under "head", or add a new subclass of "BlockQuote" for special parser
communiques, or whatever. These new styles would be covered by the user
preferences, but could also be customized by the game stylesheet.
This plan runs into two difficulties:
* CSS does not have any notion of style inheritance. (There is a form of
property inheritance, but that runs down the DOM tree, not from style class
to style class.)
* The Glk API refers to styles by number. Sharing a textual name between
game code, the interpreter, and the stylesheet is a nuisance.
Both of these can be worked around. See below. (But I welcome suggestions
for better workarounds.)
== Fallback, and hazards of the course ==
The above introduction contains a lot of "should"s, "may"s, and "ideally"s.
There are several different axes of variation:
* Any terp based on a web toolkit will suffer from the rendering ills that
all HTML is heir to. WebKit, Firefox, and the minor HTML renderers do not
always behave identically. (We try to control this by limiting what's in the
strict CSS subset -- hopefully avoiding dangerous options.)
* Any terp *not* based on a web toolkit will be re-implementing some of
HTML, which is hard. (Again, we provide a limited CSS subset, which is
intended to be not impossible to implement by hand.)
* Some terps have limited output channels, e.g., terminal windows (GlkTerm)
or unstyled text (CheapGlk). We will try to define a system which can
downgrade cleanly.
* Interpreters may have options to limit game control of output formatting.
For web terps, this consists of a user stylesheet and !important declaration
(see CSS spec). For other terps (and maybe web terps as well), this may
include preferences for "use my colors", "use my fonts", "use larger/smaller
fonts", or other possibilities. All of these features are features.
* Not all games will provide stylesheets. Each interpreter will provide a
default appearance (the "user agent stylesheet", in CSS terminology). This
will be controlled by a combination of user preferences and implementor
whim, as has always been the case with IF interpreters.
* Old interpreters (that is, old Glk libraries) were created for the old
style-hint system. They will not load stylesheets at all. (The old Glk
styles will continue to exist in the new system, so the user agent
stylesheet will cover this case.)
We will provide copious sample and unit tests, to make sure that interpreter
implementations stay on the same page, or at least within the same chapter.
= Rules and definitions =
== The document model ==
The document is divided into windows, as described in Glk. A window contains
text, which is divided into (wrapped) paragraphs, which are divided into
spans of different styles.
The HTML structure generated by a web terp may be more complicated. It must
follow this model (the classes of which will be referenced by the
stylesheet):
* The game content must exist within a div with class="GlkDoc". (This may be
either an immediate child of the body, or embedded in other page content.)
* Each window must be a div contained within the "GlkDoc" div. (Not
necessarily an immediate child.) The window must have these classes:
** "GlkWindow"
** "BufferWindow" or "GridWindow", depending on the Glk window type
** "WindowRock_XYZ", where XYZ is the Glk window rock value. (Unsigned
decimal integer.) This number is assigned by the game at window creation
time. (The standard Inform library uses 201 for the story window, 202 for
the status window, and 203 for the quote-box window.)
* Text within a window must be a sequence of spans. (Again, these are not
necessarily immediate children of the window div.) Each text element must
have class="Style_XYZ", where XYZ is the style name. For a substyle, the
class attribute must list the style and all of its parent styles.
(Note that paragraphs can be represented in different ways. Parchment
currently uses line-break elements between style spans. GlkOte uses a div
wrapped around the style spans. I'm not sure whether these two forms are
compatible with a single stylesheet. I think they are, but I'll have to test
funny cases like background color and paragraph indentation.)
(In this model, the text-align and text-indent properties won't work for
individual styles, because they are meaningless for spans. I have not yet
figured out how to deal with this.)
== The stylesheet model ==
The stylesheet document follows the syntax of CSS 2.1, with the following
limitations:
* No @charset statements; the stylesheet must use UTF-8.
* No @import statements.
* No !important declarations
* No declarations nested in { blocks }.
A stylesheet that violates these limitations may be entirely ignored. We
will provide sample C code that parses stylesheets within this model.
The stylesheet must begin by defining the style inheritance tree, using
@-glk-style declarations. (CSS ordains that unknown @-rules must be ignored,
so this will not cause web toolkits to choke.) These lines look like:
@-glk-style NUMBER STYLENAME [ PARENTNAME ]
So, for the tree given earlier:
@-glk-style 12 body;
@-glk-style 1 emphasized body;
@-glk-style 15 bold body;
@-glk-style 5 alert body;
...
@-glk-style 13 head;
@-glk-style 3 header head;
...
@-glk-style 14 fixed;
@-glk-style 2 preformatted fixed;
(Old Glk styles retain their numbers; new styles, including the new base
styles, get new numbers.) (Should these default declarations exist in every
single game stylesheet? Probably not -- the interpreter can assume them.)
The interpreter (even web terps) will have to parse the stylesheet and
internalize this tree. A game call glk_set_style(1) -- emphasized text --
would cause a web terp to generate a span:
<nowiki><span class="Style_body
Style_emphasized">...</span></nowiki>
IF interpreters should understand and handle selectors in the following
forms:
.WINDOW { ... }
.STYLE { ... }
.WINDOW .STYLE { ... }
A WINDOW class is one of the class values mentioned above: GlkWindow,
BufferWindow, GridWindow, WindowRock_XYZ. A STYLE class is one of the class
values Style_XYZ.
You can also use multi-class selectors, e.g.:
.WINDOW1.WINDOW2 .STYLE1.STYLE2.STYLE3 { ... }
There can be at most two levels, window and style. However, each level can
consist of any number of class values.
All other selectors (including those that use +, *, [attr=...], #id,
element, and :pseudoclass) may be ignored.
Property values which are lengths should be given as pixels (px); other
units may be ignored. Colors should be specified in hex (three-digit or
six-digit). "Inherited" is always an acceptable value.
IF interpreters should handle the following CSS properties:
* font-family, font-style, font-weight, font-size, text-decoration
* color, background-color
* text-indent, text-align, line-height
* border, padding (windows only)
* margin (styles only)
Stylesheets should avoid defining the white-space property, as the
interpreter may need to use this for correct layout.
== Resolution of selector conflicts ==
The CSS precedence rules, in our limited stylesheet model, are
straightforward:
* Overriding user preferences (equivalent to "user important declarations"
in a user stylesheet) take first precedence
* The game stylesheet is next (equivalent to "author normal declarations")
* Generic user preference ("user normal declarations") are next
* Interpreter factory defaults have least precedence
(These are the CSS rules for cascading, section 6.4.1, simplified by the
absence of game important declarations.)
Within the game stylesheet, selectors are sorted by the number of classes in
the selector definition. (Example: ".BufferWindow .Style_bold { ... }" is a
two-class selector. ".BufferWindow .WindowRock_201 .Style_body.Style_bold {
... }" has four.) Selectors with more classes take precedence. If two
selectors have the same number of classes, the one defined later wins.
(If user preferences are defined in terms of a CSS file, the same
class-counting rule applies to conflicts within it.)
= Implementation and details =
== Defining new styles ==
We've said that the interpreter learns style names from the stylesheet. We
haven't said how those names (and their inheritance relationships) are
coordinated between the stylesheet and the game source code.
Ultimately I imagine a native I7 declaration, analogous to the way images
are declared:
Style Disaster is derived from style Alert.
This would cause the compiler to pick a new number, and generate the
appropriate @-glk-style line when copying the author's stylesheet from the
Materials folder to the built game.
Until that feature exists (and also in I6) it would be the author's
responsibility to define numeric constants in the game code, and @-glk-style
rules in the stylesheet, and make sure that they match.
== The transition ==
We want new interpreters to work reasonably with old games, and old
interpreters to work (perhaps minimally) with new games.
The Glk library will offer a new gestalt selector: gestalt_StyleModel.
If this selector returns nonzero, the interpreter implements the new style
model. The glk_style_measure() and glk_style_distinguish() calls will always
return zero (see below).
(Do we want to start by asking interpreters to support both the old model
and the new model, with the game picking one at runtime? I am inclined to
answer "no", despite the etiquette of the opt-in model. This change will be
complicated enough for interpreters without asking them to implement two
systems in one library.)
== Borders ==
Borders around specific Glk windows, and between them, are a tricky subject.
A text window nearly always needs a margin; however, graphical windows
sometimes do not, depending on the layout needs of a given game.
This is sufficiently important that we will add a new flag, winmethod_Border
/ winmethod_NoBorder, to the glk_window_create() call. The terp should (not
"must") use this hint when laying out windows. The default is to have
borders between windows.
(GlkOte has more precise and flexible ways to specify inter-window borders.
Is it worth exporting these to the glk_window_create() level? Alternatively,
should we forget the NoBorder flag and do it all with CSS?)
In addition, windows may define space around their content by using the CSS
padding and border properties. These spaces are *inside* the bounds of the
rectangular Glk window. Avoid using margin properties on windows, as they
have more complex layout rules that a standalone terp may not be able to
replicate.
== Ints and introspection ==
A downside of the stylesheet model is that it is difficult to for the game
to interrogate the display layer. The old glk_style_measure() call could
theoretically be implemented in a web-based terp, using the Javascript
getComputedStyle() method. However, it would be difficult to parse this
information, and translate it to the necessary numeric form; and then it is
unlikely that the game could do anything useful with the results. Similarly,
glk_style_distinguish() would be difficult and subjective to implement (as
indeed it always has been). Therefore, these two calls are deprecated, and
will fail (return 0) on new-style Glk interpreters.
At the same time, the game needs to know (at a minimum) the width of a grid
window in characters. (Note that border padding makes this tricky; the
number of characters that fit in a grid window will, in general, be smaller
than the window width divided by the character width.)
The old definition of glk_window_get_size() should still be satisfiable in
this model. For a web terp, this implies that the Javascript interpreter
will have to be aware of border padding and font sizes, and arrange the Glk
window sizes accordingly. (GlkOte provides an example of one way to do
this.)
-------------------------
mwigdahl
> Here, Andrew Plotkin <erkyr...@eblong.com> wrote:
<major snip>
> == Ints and introspection ==
>
> A downside of the stylesheet model is that it is difficult to for the game
> to interrogate the display layer. The old glk_style_measure() call could
> theoretically be implemented in a web-based terp, using the Javascript
> getComputedStyle() method. However, it would be difficult to parse this
> information, and translate it to the necessary numeric form; and then it is
> unlikely that the game could do anything useful with the results. Similarly,
> glk_style_distinguish() would be difficult and subjective to implement (as
> indeed it always has been). Therefore, these two calls are deprecated, and
> will fail (return 0) on new-style Glk interpreters.
>
> At the same time, the game needs to know (at a minimum) the width of a grid
> window in characters. (Note that border padding makes this tricky; the
> number of characters that fit in a grid window will, in general, be smaller
> than the window width divided by the character width.)
>
> The old definition of glk_window_get_size() should still be satisfiable in
> this model. For a web terp, this implies that the Javascript interpreter
> will have to be aware of border padding and font sizes, and arrange the Glk
> window sizes accordingly. (GlkOte provides an example of one way to do
> this.)
>
This looks great overall (particularly since I'm not an interpreter
coder) but I'm a bit concerned about this last part, possibly
(probably) due to missing something earlier in the post. One thing
I've done in my WIP is to create a glk window that mimics the
appearance of the status line, and to do this I used glk_style_measure
() to get the relevant style data from the status line. Since the
status line is created internally in Inform 7, I didn't have the
option of just using the same settings in code -- I needed to
interrogate the window to get the data, particularly as different
terps can specify different appearances.
In a fixed stylesheet world, I'll somehow need to know what styles the
default-created status line is using to accomplish the same trick. As
far as I can see, this could be done either by Inform 7 exposing the
mechanics of how it creates the status line, or through some sort of
style interrogation at the glk level (which looks pretty difficult in
the general case, as you say).
Does this make sense, or am I off in the weeds? I guess with the new
model, I could just use a multiline status line with my second line in
a slightly different style, but there might be other cases where this
type of style matching was required.
Matt
weevil
some future world where it supports glulx) to carry these styles over
into actual class names that you could style with real CSS.
David Fletcher
Looks reasonable at a first glance. I might have some more things to
say once I look more carefully - just pulling out a couple for now:
>
> == The transition ==
>
> We want new interpreters to work reasonably with old games, and old
> interpreters to work (perhaps minimally) with new games.
>
> The Glk library will offer a new gestalt selector: gestalt_StyleModel.
>
> If this selector returns nonzero, the interpreter implements the new style
> model. The glk_style_measure() and glk_style_distinguish() calls will always
> return zero (see below).
>
> (Do we want to start by asking interpreters to support both the old model
> and the new model, with the game picking one at runtime? I am inclined to
> answer "no", despite the etiquette of the opt-in model. This change will be
> complicated enough for interpreters without asking them to implement two
> systems in one library.)
>
I agree you don't want to require interpreters to support both, but it
would be good if they were allowed to do so.
How about just saying that if gestalt_StyleModel is nonzero then
glk_style_measure and glk_style_distinguish are undefined? This
allows an implementation to let them continue to work for old games,
without requiring it.
> == Borders ==
>
> Borders around specific Glk windows, and between them, are a tricky subject.
> A text window nearly always needs a margin; however, graphical windows
> sometimes do not, depending on the layout needs of a given game.
>
> This is sufficiently important that we will add a new flag, winmethod_Border
> / winmethod_NoBorder, to the glk_window_create() call. The terp should (not
> "must") use this hint when laying out windows. The default is to have
> borders between windows.
>
Does the flag mean there is a border along the new split-line, or does
it mean there is a border round all four sides of the new window?
Another thing: how do hyperlinks fit into all this?
--
David Fletcher.
vaporware
The mechanics already are exposed: look at the routine VM_Initialise
in Glulx.i6t, which (on a Windows system) is probably in C:\Program
Files\Inform 7\Inform7\Extensions\Reserved.
vw
vaporware
> This is a very rough draft of the new Glk style system which I have been
> procrastinating on, wigglesome-wagglesome, for about ten years now.
The lack of any way to create new styles during the game, or to
associate an anonymous style with new spans of text a la HTML's
"style" attribute, seems like an unfortunate omission. Any user-
friendly means of changing text appearance on the fly ("[red][italic]
hello[/italic][/red]") would have to rely on static analysis by the
compiler.
vw
Ben Cressey
Specifically meaning calls to glk_stylehint_set and
glk_stylehint_clear.
It seems like these calls would be part of "the old style-hint system"
referenced in "Fallback, and hazards of the course" and the discussion
in "Transition" suggests that the old system is optional and exclusive
of the new one.
If they are supported, what value do the children of those styles
inherit if the parent value defined in the CSS is overridden by a
glk_stylehint_set call before a new window is created?
Also, if they are supported, calls to glk_stylehint_set for style
values greater than 10 will need to be conditioned by a nonzero return
from gestalt_StyleModel, otherwise they may crash older interpreters.
For example, Gargoyle implements the predefined styles as an array,
and blithely assumes that the indicated style is within the array's
bounds. This is bad form but perhaps not uncommon.
If not supported, it's perhaps worth calling out that any interpreter
that implements only the new style model will not support any text
styles (such as color or reverse printing) in any existing Glulx
game. Apart from Adam Cadre's games, there are many Spanish IF games
that make good use of color. It seems a disservice to that community
to deprecate the old model when they have been among the most
enthusiastic adopters of the Glulx format.
Eliuk Blau
and I look forward to the upcoming implementation.
I only see a problem with the CSS definition:
> * Each window must be a div contained within the "GlkDoc" div. (Not
> necessarily an immediate child.) The window must have these classes:
> ** "GlkWindow"
> ** "BufferWindow" or "GridWindow", depending on the Glk window type
> ** "WindowRock_XYZ", where XYZ is the Glk window rock value. (Unsigned
> decimal integer.) This number is assigned by the game at window creation
> time. (The standard Inform library uses 201 for the story window, 202 for
> the status window, and 203 for the quote-box window.)
What about libraries or codes that create windows on the fly at
runtime?
For example, GWindows library (or Flexible Windows, I think) creates
rocks with numbers generated by code and not explicitly specified by
the programmer. If generated at runtime, how is it possible to specify
those numbers (WindowRock_XYZ) in the CSS?
I just do not see it possible, unless you include some "reflection
routine" for the value of the rock (I guess) and somehow "push" that
value in the CSS.
Or is it possible that I have not understood anything of the new
system... which is also a possibility. =D Hehehe!
Saludos! =)
Eliuk Blau.
Dannii
> Here, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > Remember, remember, the 41st of Octember.
>
> Okay, here's what I've got.
>
> I know RAIF is less the hub of the universe than it used to be, so
> I've also posted this document on the wiki:
> <http://ifwiki.org/index.php/New_Glk_styles>
>
> Comment there or here.
Excellent! Great work on the proposal. The biggest problem is that you
see this as an extension to glk... but I can't see how that would be
wise, nor easy to develop games or interpreters for. It should be an
entirely new IO system. I will indeed comment...
> An underlying assumption of this model is that the stylesheet is constant
> throughout the game. It is unpacked and parsed before the game starts
> running, and the game has no way to modify the stylesheet. From the game's
> point of view, the world consists of windows, styles, and text; any given
> span of text appears in one window and has exactly one style.
>
> Another assumption: the game cannot know how the text is eventually rendered
> on the screen. (Really this has always been true. The old
> glk_style_measure() and glk_style_distinguish() calls were never very
> useful, because they could not be determined until after the window
> appeared, which led to an unfortunate cycle of test-render-test-render.) See
> "Ints and introspection", below, for more.
Don't the multiple style examples you have below contradict this
"exactly one style" rule?
As this will be a new IO system, I hope ALL glk_* functions are
retired! And instead, new functions should be added. In particular,
addClass() and deleteClass() would be very helpful.
I like this idea, but I wonder if perhaps the hierarchy should specify
the difference between block and inline styles.
> This plan runs into two difficulties:
>
> * CSS does not have any notion of style inheritance. (There is a form of
> property inheritance, but that runs down the DOM tree, not from style class
> to style class.)
> * The Glk API refers to styles by number. Sharing a textual name between
> game code, the interpreter, and the stylesheet is a nuisance.
>
> Both of these can be worked around. See below. (But I welcome suggestions
> for better workarounds.)
My feeling is that both of these should be handled by the compiler as
sensibly as possible. If numbers are needed the user shouldn't have to
deal with them. The new IO system should be passed the class names as
text, not numbers.
I think I have the most problems with this section. You're trying to
keep it too similar to Glk, but it needs to be set free! To begin with
the document shouldn't have class="GlkDoc" as this IO system will have
nothing to do with Glk! Numbers too shouldn't be used (unless the user
prefers that!)
I don't like the idea of keeping windows. Instead any structure should
be possible, with instructions that correspond basically to stream()
and replace() (or perhaps clear()/empty().)
Suppose a story has an intro with a single centered title bar, which
changes to the traditional status bar once the game proper begins.
Here is how I would suggest doing that, with something approaching a
jquery style syntax:
status = $('status');
status.addClass('singlecentered');
status.replaceContents('Awesome Game!');
...
status.empty();
status.removeClass('singlecentered');
status.addClass('traditional');
status.streamStructure(['room', 'score', 'turns']);
$('room').replaceContents('First Room');
$('score').replaceContents('0');
$('turns').replaceContents('1');
There is no need to have strict windows... anything should be
streamable to. Indeed... you should be able to stream a structure and
then add text into it. For streaming structures although XML might be
the simplest, I think JSON or YAML would be easier to transfer between
the VM and IO layer, as well as easier to encode in whichever
programming language the story is written in.
> Property values which are lengths should be given as pixels (px); other
> units may be ignored. Colors should be specified in hex (three-digit or
> six-digit). "Inherited" is always an acceptable value.
>
> IF interpreters should handle the following CSS properties:
>
> * font-family, font-style, font-weight, font-size, text-decoration
> * color, background-color
> * text-indent, text-align, line-height
> * border, padding (windows only)
> * margin (styles only)
>
> Stylesheets should avoid defining the white-space property, as the
> interpreter may need to use this for correct layout.
Having only px would be a mistake... in fact I would suggest banning
px. I would use em, % and perhaps ex (as an more approximate measure
of a character's width. ch should be introduced once it gets
widespread support.)
Floats and clears would be invaluable, along with widths. Before the
limits are locked down too strongly it would be great to get people
using the system to see what they'd like to use.
> == Resolution of selector conflicts ==
>
> The CSS precedence rules, in our limited stylesheet model, are
> straightforward:
>
> * Overriding user preferences (equivalent to "user important declarations"
> in a user stylesheet) take first precedence
> * The game stylesheet is next (equivalent to "author normal declarations")
> * Generic user preference ("user normal declarations") are next
> * Interpreter factory defaults have least precedence
>
> (These are the CSS rules for cascading, section 6.4.1, simplified by the
> absence of game important declarations.)
>
> Within the game stylesheet, selectors are sorted by the number of classes in
> the selector definition. (Example: ".BufferWindow .Style_bold { ... }" is a
> two-class selector. ".BufferWindow .WindowRock_201 .Style_body.Style_bold {
> ... }" has four.) Selectors with more classes take precedence. If two
> selectors have the same number of classes, the one defined later wins.
>
> (If user preferences are defined in terms of a CSS file, the same
> class-counting rule applies to conflicts within it.)
I'd be hesitant to define a new algorithm for precedence, but as long
as there are tests and they pass in all browsers that will be fine.
(And defining a simple precedence algorithm would be helpful for terps
which don't actually use a css engine.)
> == The transition ==
>
> We want new interpreters to work reasonably with old games, and old
> interpreters to work (perhaps minimally) with new games.
>
> The Glk library will offer a new gestalt selector: gestalt_StyleModel.
>
> If this selector returns nonzero, the interpreter implements the new style
> model. The glk_style_measure() and glk_style_distinguish() calls will always
> return zero (see below).
>
> (Do we want to start by asking interpreters to support both the old model
> and the new model, with the game picking one at runtime? I am inclined to
> answer "no", despite the etiquette of the opt-in model. This change will be
> complicated enough for interpreters without asking them to implement two
> systems in one library.)
I think we do. But these two models should be completely different IO
systems... not some hybrid Glk system.
If the new system can't be used, Glk will be selected as a fall back.
Using the inheritance system the classes will be converted to Glk
style hints. This is why the block/inline distinction is important...
the interpreter will need to remember whether a class is block, so
that it can manually add linebreaks.
If a new IO system interpreter wants to interpret Glk games (like
Parchment) a wrapper layer could be built. It would manage generating
windows, would have a default system sheet equivalent to Glk's styles,
and would manage linebreaks (though perhaps in addition to paragraph
block styles the new system should also have a streamBreak() function,
which wouldn't close the current paragraph.)
> == Borders ==
>
> Borders around specific Glk windows, and between them, are a tricky subject.
> A text window nearly always needs a margin; however, graphical windows
> sometimes do not, depending on the layout needs of a given game.
>
> This is sufficiently important that we will add a new flag, winmethod_Border
> / winmethod_NoBorder, to the glk_window_create() call. The terp should (not
> "must") use this hint when laying out windows. The default is to have
> borders between windows.
>
> (GlkOte has more precise and flexible ways to specify inter-window borders.
> Is it worth exporting these to the glk_window_create() level? Alternatively,
> should we forget the NoBorder flag and do it all with CSS?)
>
> In addition, windows may define space around their content by using the CSS
> padding and border properties. These spaces are *inside* the bounds of the
> rectangular Glk window. Avoid using margin properties on windows, as they
> have more complex layout rules that a standalone terp may not be able to
> replicate.
Nothing like Glk borders should even be considered in this new system.
All borders should be the style sheet and nowhere else.
> == Ints and introspection ==
>
> A downside of the stylesheet model is that it is difficult to for the game
> to interrogate the display layer. The old glk_style_measure() call could
> theoretically be implemented in a web-based terp, using the Javascript
> getComputedStyle() method. However, it would be difficult to parse this
> information, and translate it to the necessary numeric form; and then it is
> unlikely that the game could do anything useful with the results. Similarly,
> glk_style_distinguish() would be difficult and subjective to implement (as
> indeed it always has been). Therefore, these two calls are deprecated, and
> will fail (return 0) on new-style Glk interpreters.
>
> At the same time, the game needs to know (at a minimum) the width of a grid
> window in characters. (Note that border padding makes this tricky; the
> number of characters that fit in a grid window will, in general, be smaller
> than the window width divided by the character width.)
>
> The old definition of glk_window_get_size() should still be satisfiable in
> this model. For a web terp, this implies that the Javascript interpreter
> will have to be aware of border padding and font sizes, and arrange the Glk
> window sizes accordingly. (GlkOte provides an example of one way to do
> this.)
Some browsers have a ch unit, which makes it very easy to calculate
widths. In other browsers it could be emulated by calculating the
ratio between an em and a ch by measuring the width of a set of known
characters.
Remember that padding is external to a box's width, so neither padding
nor margins will matter.
However there probably won't be many situations where measuring a
box's width will be useful. In the past you needed to measure a
window's width to see, for example, whether you can fit all the status
line info or if you need to cut some of it out. But that isn't how
you'd do it with a CSS system. Instead you would use floats, so that
if something won't fit it will instead just be shifted into the next
line.
I can't see how glk_style_distinguish() would be very useful, though
I'm sure it could be emulated somehow.
> -------------------------
>
> --Z
Thanks Zarf!
David Kinder
Is the presence of a stylesheet auto-detected in a Blorb file? Or is there a
new Glk call to use it?
In "Fallback, and hazards of the course" we have a mention of "!important"
CSS declarations, but these are explicitly listed in "The stylesheet model"
as being outside of the Stylesheet document model.
I'd like to have the C code that parses stylesheets have a relatively simple
interface: something to load a stylesheet and something that, given a window
type and rock, and a style number, returns a structure containing all the
relevant style information. This would require some way to pass in the user
and generic interpreter preferences, which might be a bit awkward.
Do we really want properties that are lengths to only be specified in
pixels? That's always been my least favourite CSS scaling unit, as its the
least likely to play well with user's settings. Does a font size count as a
length?
Supporting both the old and new models will be the reality, I think, at
least for Glk libraries that already handle the old model. (At least, I
intend that Windows Glk will not abandon old games.) It would be nice to
formalize this a bit more, and doesn't seem that awkward: if there's no
stylesheet set, you get the old model. A future web-based interpreter could
just ignore the old stylehint setting calls to minimally support the old model.
I'm not keen on the window border stuff, though admittedly this is because I
don't like the look of Glulx games with internal window borders. Windows Glk
has the option to have window borders or not, and no-one complained when I
silently changed the default to "no borders". Having some windows with
borders and some without will look odd, I think. Regardless, I don't see why
this is special cased and not just in the CSS.
David
vaporware
> On Dec 1, 6:51 am, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > Here, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > > Remember, remember, the 41st of Octember.
>
> > Okay, here's what I've got.
>
> > I know RAIF is less the hub of the universe than it used to be, so
> > I've also posted this document on the wiki:
> > <http://ifwiki.org/index.php/New_Glk_styles>
>
> > Comment there or here.
>
> Excellent! Great work on the proposal. The biggest problem is that you
> see this as an extension to glk... but I can't see how that would be
> wise, nor easy to develop games or interpreters for. It should be an
> entirely new IO system.
I can't see how *that* would be wise. Glk is an established standard,
with many games, interpreters, and implementations written for it. Why
throw that all away?
Glk has its faults, but patching those faults with extensions like
this one is certainly easier on game and interpreter developers than
replacing it with a whole new IO layer -- especially one with CSS-ish
layout features like floats and clears.
> I don't like the idea of keeping windows. Instead any structure should
> be possible, with instructions that correspond basically to stream()
> and replace() (or perhaps clear()/empty().)
This sounds an awful lot like FyreVM's channels. The difference is
that Textfyre's games are written with specific user interface layouts
in mind. If you want to get rid of windows and replace them with named
"structures" in a way that's useful for many different games by
different authors running on different interpreters and platforms,
you'll need to specify how those structures are supposed to be
displayed. And then you just have windows by another name, right?
vw
Dannii
> On Dec 1, 12:14 am, Dannii <curiousdan...@gmail.com> wrote:
>
> > Excellent! Great work on the proposal. The biggest problem is that you
> > see this as an extension to glk... but I can't see how that would be
> > wise, nor easy to develop games or interpreters for. It should be an
> > entirely new IO system.
>
> I can't see how *that* would be wise. Glk is an established standard,
> with many games, interpreters, and implementations written for it. Why
> throw that all away?
Who's throwing anything away? Existing Glulx interpreters already have
Glk, they wouldn't get rid of it. It would only be new interpreters,
especially web ones like Quixe that would benefit from a CSS IO system
and be burdened with a Glk system. But I think it's easy enough to
wrap Glk around the CSS system, so Glk would never be thrown away.
> Glk has its faults, but patching those faults with extensions like
> this one is certainly easier on game and interpreter developers than
> replacing it with a whole new IO layer -- especially one with CSS-ish
> layout features like floats and clears.
I doubt the changes Zarf has proposed could easily co-exist with
Glk... new implementations would need to be developed. The whole
document model is considerably different. Perhaps colours could easily
be added, but I doubt the typography could be.
> > I don't like the idea of keeping windows. Instead any structure should
> > be possible, with instructions that correspond basically to stream()
> > and replace() (or perhaps clear()/empty().)
>
> This sounds an awful lot like FyreVM's channels. The difference is
> that Textfyre's games are written with specific user interface layouts
> in mind. If you want to get rid of windows and replace them with named
> "structures" in a way that's useful for many different games by
> different authors running on different interpreters and platforms,
> you'll need to specify how those structures are supposed to be
> displayed. And then you just have windows by another name, right?
>
> vw
Well no. Windows can't be contained within text windows, only pair
windows. Whereas I'd want to be able to make a structure in the main
frame and be able to stream to it, maybe having it be fixed to the top
of the frame, or in order to add complicated styles or media to it
(the alternative to that would be to stream complex XML/HTML but I
don't think that is wise.
And yes of course you specify how the structures are displayed. That's
the whole point of having a stylesheet!
That reminds me... it would be good to introduce support for fallback
content with this CSS system. Might as well do it at the same time,
and for those using a HTML engine it would be very easy to add. Btw,
traditional terp authors could consider embedding Webkit, it is
supposedly very easy to do just that. It's also quite small and
efficient.
vaporware
> On Dec 1, 6:58 pm, vaporware <jmcg...@gmail.com> wrote:
>
> > On Dec 1, 12:14 am, Dannii <curiousdan...@gmail.com> wrote:
>
> > > Excellent! Great work on the proposal. The biggest problem is that you
> > > see this as an extension to glk... but I can't see how that would be
> > > wise, nor easy to develop games or interpreters for. It should be an
> > > entirely new IO system.
>
> > I can't see how *that* would be wise. Glk is an established standard,
> > with many games, interpreters, and implementations written for it. Why
> > throw that all away?
>
> Who's throwing anything away? Existing Glulx interpreters already have
> Glk, they wouldn't get rid of it.
They'd become obsolete, right? Or are you suggesting that every new
game would have to speak both Glk and this new system? Not that that's
impractical... games compiled with the FyreVM extension are backwards
compatible too. But it puts limits on how much you can take advantage
of either system if you want to stay compatible.
> > Glk has its faults, but patching those faults with extensions like
> > this one is certainly easier on game and interpreter developers than
> > replacing it with a whole new IO layer -- especially one with CSS-ish
> > layout features like floats and clears.
>
> I doubt the changes Zarf has proposed could easily co-exist with
> Glk... new implementations would need to be developed. The whole
> document model is considerably different. Perhaps colours could easily
> be added, but I doubt the typography could be.
Can you be more specific? The document model seems no different to me:
text windows contain paragraphs which contain spans of text in various
styles. The means of determining which style to apply at any given
moment are a little different, but I'm not seeing any big changes to
how those styles are used. Glk implementations already use different
font sizes for different styles; changing the typeface is no more
complicated than that.
> Well no. Windows can't be contained within text windows, only pair
> windows. Whereas I'd want to be able to make a structure in the main
> frame and be able to stream to it, maybe having it be fixed to the top
> of the frame, or in order to add complicated styles or media to it
> (the alternative to that would be to stream complex XML/HTML but I
> don't think that is wise.
Why not - why bother with a programmatic interface at all? You're
already requiring interpreters to implement the hard part of a browser
(the layout engine), so what's the harm in just using XHTML? Parsing
that is easy.
> And yes of course you specify how the structures are displayed. That's
> the whole point of having a stylesheet!
So this system would include the entire CSS layout model. Every IF
interpreter would need a browser layout engine.
> Btw, traditional terp authors could consider embedding Webkit, it is
> supposedly very easy to do just that.
Certainly much easier than writing a browser from scratch! In
practice, every terp would have to embed *some* existing browser
component... but since they don't all work on all platforms, game
authors would face the same compatibility problems that web designers
do. Better hope no one tries to play your game with a terp that's
based around IE6.
vw
Dannii
> On Dec 1, 1:20 am, Dannii <curiousdan...@gmail.com> wrote:
>
> > Who's throwing anything away? Existing Glulx interpreters already have
> > Glk, they wouldn't get rid of it.
>
> They'd become obsolete, right? Or are you suggesting that every new
> game would have to speak both Glk and this new system? Not that that's
> impractical... games compiled with the FyreVM extension are backwards
> compatible too. But it puts limits on how much you can take advantage
> of either system if you want to stay compatible.
Yeah I'd make it backwards compatible like FyreVM. The idea is not for
complete compatibility, but for essential playability, it's called
progressive enhancement in web design. The automatic backup would use
a generic Glk window set up, though I guess that could also be
customisable. Text classes would be matched where possible to Glk
styles. But if you wanted to add a clickable compass rose with the CSS
IO system it would just be ignored in Glk.
> > I doubt the changes Zarf has proposed could easily co-exist with
> > Glk... new implementations would need to be developed. The whole
> > document model is considerably different. Perhaps colours could easily
> > be added, but I doubt the typography could be.
>
> Can you be more specific? The document model seems no different to me:
> text windows contain paragraphs which contain spans of text in various
> styles. The means of determining which style to apply at any given
> moment are a little different, but I'm not seeing any big changes to
> how those styles are used. Glk implementations already use different
> font sizes for different styles; changing the typeface is no more
> complicated than that.
Hmm, you could well be right (and I was probably speaking crap I don't
know nothing about again.) See below for my thoughts on the
progression of interfaces.
> > Well no. Windows can't be contained within text windows, only pair
> > windows. Whereas I'd want to be able to make a structure in the main
> > frame and be able to stream to it, maybe having it be fixed to the top
> > of the frame, or in order to add complicated styles or media to it
> > (the alternative to that would be to stream complex XML/HTML but I
> > don't think that is wise.
>
> Why not - why bother with a programmatic interface at all? You're
> already requiring interpreters to implement the hard part of a browser
> (the layout engine), so what's the harm in just using XHTML? Parsing
> that is easy.
>
> > And yes of course you specify how the structures are displayed. That's
> > the whole point of having a stylesheet!
>
> So this system would include the entire CSS layout model. Every IF
> interpreter would need a browser layout engine.
>
> > Btw, traditional terp authors could consider embedding Webkit, it is
> > supposedly very easy to do just that.
>
> Certainly much easier than writing a browser from scratch! In
> practice, every terp would have to embed *some* existing browser
> component... but since they don't all work on all platforms, game
> authors would face the same compatibility problems that web designers
> do. Better hope no one tries to play your game with a terp that's
> based around IE6.
>
> vw
Let me respond to your points here by noting the progression of IF
interfaces. The very first interfaces, like the Z-machine and to some
extent Glulx were very much console applications. Positioning is
dependent on fixed width fonts and there is minimal typographic
control.
Next came the rich text interfaces (think .rtf). Glulx has this, as
does HTML TADS to an even greater extent. They allow much more control
over typography, and can have inline graphics etc.
There have also been what I'll call Flash interfaces, which include
FyreVM, and some other one-off games written in Flash (or silverlight
or whatever.) Often they'll have pretty spliced image interfaces, but
the actual text is still at the console or rich text level.
We could imagine many other interfaces, though many wouldn't be good
choices. We could have one made out of OS-level widgets, with a text
box input and labels that change to show the room descriptions. Ick.
Or one made with TeX, where the results of an action are re-rendered
each time. The results would be beautiful, but performance would suck.
I believe the future is in HTML interfaces. Amazing layout engines are
now designed to be easily embedded in other applications, and
generally don't take an excessive amount of ram or processing power
either. And of course we can work on actual web terps too.
------
Zarf's proposal seems to be at the level of a rich text interface,
though one that is certainly more advanced than Glk. The API for using
it is based on CSS. Although this makes it easy to implement in a
browser, as it is such a cut down version of CSS it will be
implementable on other rich text components too.
I don't like this for a number of reasons:
- In one way it's overkill... CSS may simply be too much for the new
features that Z is proposing. Why not instead have more than 2 user
styles, add colours and better indents to Glk as it is now.
- Using CSS will lead people to have expectations of what they can do
with it that won't be met. They may even try something in a browser
terp, and then be quite disappointed when it doesn't look the same (or
maybe is deeply buggy) on a non-HTML rich text terp.
- At some time in the future when a real CSS+HTML IO system was
developed there would be a lot of confusion between the two.
- The underlying model here is plain text marked up with styling. This
isn't actually how CSS or HTML works though. CSS is applied to HTML or
XML which is a structured document, not plain text, though it may
contain text. Elements may have various kinds of meta data, and there
is an events system which would be great to use in IF too.
Why I'm looking forward to a real HTML system:
- It will actually deal with structured data, not text with attached
class names. We'll add structures to the interface, or stream/append
them to the end of part of it. We'll stream a turn, with a couple of
descriptions and an item list, a graphical map with textual fallback
(and not ASCII art either!)
- The full strengths of the web will be utilised, but as it will be
restricted somewhat, development will be much easier. Care will be
taken so that the author never has to worry about browser differences.
- This would necessitate an actual layout engine widget in all
engines, but this isn't necessarily a bad thing. Modern computers can
definitely handle them, and they could even be more efficient than a
custom made rich text widget. It would also mean that an identical
interface really would be achievable in basically all terps, including
desktop and web.
My basic argument is that if we use CSS to specify styles we should
really make the interface be at the HTML level, not the rich text
level. CSS and HTML has a lot more potential than rich text.
mwigdahl
Thanks! That's my problem, then -- lack of sufficient I6 knowledge.
Matt
Andrew Plotkin
> Is the plan to deprecate Glk style hints in the new CSS style model?
> Specifically meaning calls to glk_stylehint_set and
> glk_stylehint_clear.
Yes. They will become no-ops. I decided that early on and then forgot
to write it down. Thanks for catching that.
(Note to self: document that they will be safe no-ops, even for values
greater than 10.)
> If not supported, it's perhaps worth calling out that any interpreter
> that implements only the new style model will not support any text
> styles (such as color or reverse printing) in any existing Glulx
> game. Apart from Adam Cadre's games, there are many Spanish IF games
> that make good use of color. It seems a disservice to that community
> to deprecate the old model when they have been among the most
> enthusiastic adopters of the Glulx format.
Unlike the above omission, this is one that I forgot to think about in
the first place. :)
Yes, that's too big a hole to ignore. David Fletcher made a related
comment:
> I agree you don't want to require interpreters to support both, but it
> would be good if they were allowed to do so.
Agreed. New plan. An interpreter can support the old system, the new
system, or both. (Or, realistically, neither -- but you can do this
just by implementing either API and then throwing all the style
information on the floor, as CheapGlk does.)
The Glk library will have two new calls:
glk_set_stylemodel(int);
int glk_get_stylemodel();
The style models are 0 (old way of doing things -- respect stylehints)
and 1 (new way -- parse and respect the stylesheet). If the
interpreter supports both, it should default to 0. For sanity's sake,
you must call glk_set_stylemodel() before *any* windows are created;
it's an error after the first time a window is created.
The gestalt_StyleModel selector tests only for the existence of these
two calls. To test whether the library *supports* a model, use a
second selector, gestalt_StyleModelAvailable.
Here, Dannii <curiou...@gmail.com> wrote:
>
> The biggest problem is that you
> see this as an extension to glk... but I can't see how that would be
> wise, nor easy to develop games or interpreters for. It should be an
> entirely new IO system.
I thought about this, but I'm not changing anything about how windows
are created, how events are received, how text is printed, how sounds
are played. Of all the Glk calls, only the stylehint calls are
changing at the API level (and only to say they're now no-ops). So if
this were a new IO system, it would be nearly identical to the
existing one, which seems silly.
You go on to offer a strong proposal for a completely different I/O
model, roughly a combination of DOM and fyrevm-streaming (or maybe
fyrevm does all of that, I'm not sure). That is a fine thing to
discuss but not in this thread. :) I want to keep most of the existing
Glk library work, and that applies both to game code and Glk library
code.
> I like this idea, but I wonder if perhaps the hierarchy should specify
> the difference between block and inline styles.
Very possibly. This might be the path to solving the text-align problem.
> My feeling is that both of these should be handled by the compiler as
> sensibly as possible. If numbers are needed the user shouldn't have to
> deal with them. The new IO system should be passed the class names as
> text, not numbers.
Getting text from the VM into the Glk layer is nasty and I very much
want to avoid doing it for simple parameters. (Obviously, I have to
support it for printing text, but other than that...)
> Having only px would be a mistake... in fact I would suggest banning
> px. I would use em, % and perhaps ex (as an more approximate measure
> of a character's width. ch should be introduced once it gets
> widespread support.)
I agree with you so far as saying that we should *either* ban px or pt. :)
So, which to use? I don't have a strong leaning. I'd want to hear from
library implementors about how much work they're willing to do for
font introspection. I also worry that em/%/ex measurements would offer
too much room for implementations to diverge from each other and from
web toolkits. Saying "indent ten pixels" is cranky and
resolution-dependent but at least it's unambiguous.
Here, mwigdahl <ma...@wigdahl.net> wrote:
>
> This looks great overall (particularly since I'm not an interpreter
> coder) but I'm a bit concerned about this last part, possibly
> (probably) due to missing something earlier in the post. One thing
> I've done in my WIP is to create a glk window that mimics the
> appearance of the status line, and to do this I used glk_style_measure
> () to get the relevant style data from the status line. Since the
> status line is created internally in Inform 7, I didn't have the
> option of just using the same settings in code -- I needed to
> interrogate the window to get the data, particularly as different
> terps can specify different appearances.
For this, you should just look at the I7 library and see what styles
it uses -- which turns out to be "normal", anyhow. The current library
uses a "reverse" style hint, but that won't be an issue in the new
world. The only sticky point is ensuring that the new window's colors
match the normal status window, and the easiest way to do *that* is to
set the styles for both in your game stylesheet.
> Does this make sense, or am I off in the weeds? I guess with the new
> model, I could just use a multiline status line with my second line in
> a slightly different style
That works too.
> but there might be other cases where this type of style matching was
> required.
It would be reasonable for interpreters to set up their default
stylesheets based only on the window type (grid or buffer), rather
than rock values. The default 201-203 rock values have never changed,
but they're not guaranteed either, and it would be a little icky for a
game to change them and find its status window colors shifting on many
interpreters.
We could also reasonably have a standard style "status", derived from
"fixed". (The Z-machine Inform tradition is for the status line to be
reverse text, but status-window menus to be normal.) Old games
wouldn't pick that up, though.
Here, David Fletcher <david...@bubblycloud.com> wrote:
> [winmethod_Border]
> Does the flag mean there is a border along the new split-line, or does
> it mean there is a border round all four sides of the new window?
The former.
> Another thing: how do hyperlinks fit into all this?
Hyperlinks, hyperlinks, hyperlinks. Good question. They're kind of
outside the style system I described, so just have the interpreter add
an extra class "GlkLink" (not "Style_link") to those spans?
Here, vaporware <jmc...@gmail.com> wrote:
>
> The lack of any way to create new styles during the game, or to
> associate an anonymous style with new spans of text a la HTML's
> "style" attribute, seems like an unfortunate omission. Any user-
> friendly means of changing text appearance on the fly ("[red][italic]
> hello[/italic][/red]") would have to rely on static analysis by the
> compiler.
For the second time in a month, we have opposite notions of what
"user-friendly" means... I am obviously going 100% for static
stylesheets here, and the idea of a hybrid system is not attractive at
all. Ad-hoc styles would bring back many of the problems of the
limited User1/User2 styles, with only the limited improvement of
allowing more than two of them. If I'd wanted to go down that road, I
would have written a different proposal.
Here, David Kinder <da...@david.david> wrote:
>
> I'd like to have the C code that parses stylesheets have a relatively simple
> interface: something to load a stylesheet and something that, given a window
> type and rock, and a style number, returns a structure containing all the
> relevant style information. This would require some way to pass in the user
> and generic interpreter preferences, which might be a bit awkward.
I'll keep it modular: one call to parse the stylesheet and return a
list of selectors, another call (perhaps with preferences) to resolve
that data down to style info.
> I'm not keen on the window border stuff, though admittedly this is because I
> don't like the look of Glulx games with internal window borders. Windows Glk
> has the option to have window borders or not, and no-one complained when I
> silently changed the default to "no borders". Having some windows with
> borders and some without will look odd, I think. Regardless, I don't see why
> this is special cased and not just in the CSS.
CSS doesn't really have a notion of borders in this sense -- a
horizontal or vertical line between two adjacent windows. CSS window
borders are outside of that.
Maybe you're right that discarding internal borders entirely is the
way to go.
Here, Eliuk Blau <eliu...@gmail.com> wrote:
>
> What about libraries or codes that create windows on the fly at
> runtime?
>
> For example, GWindows library (or Flexible Windows, I think) creates
> rocks with numbers generated by code and not explicitly specified by
> the programmer. If generated at runtime, how is it possible to specify
> those numbers (WindowRock_XYZ) in the CSS?
I think those libraries will have to incorporate ways for the game
author to specify a rock value.
Jeff Nyman
mention of:
What does this do for the author?
What's being provided?
What will not be possible?
How will authors be able to use these changes in their source text?
That way maybe some acceptance criteria can be set out and, at the
very least, be used as a basis for discussion. I appreciate that
there's a need to solicit the feedback of library authors and
interpreter implementors but it would also be good to hear about the
end-state(s) being driven to. That way design discussion can precede
too much implementation.
- Jeff
vaporware
> Here, vaporware <jmcg...@gmail.com> wrote:
>
> > The lack of any way to create new styles during the game, or to
> > associate an anonymous style with new spans of text a la HTML's
> > "style" attribute, seems like an unfortunate omission. Any user-
> > friendly means of changing text appearance on the fly ("[red][italic]
> > hello[/italic][/red]") would have to rely on static analysis by the
> > compiler.
>
> For the second time in a month, we have opposite notions of what
> "user-friendly" means... I am obviously going 100% for static
> stylesheets here, and the idea of a hybrid system is not attractive at
> all. Ad-hoc styles would bring back many of the problems of the
> limited User1/User2 styles, with only the limited improvement of
> allowing more than two of them. If I'd wanted to go down that road, I
> would have written a different proposal.
How much would you have to be bribed in order to include an equivalent
to HTML's "style" attribute? I'll start up a collection if that's what
it takes.
Sorry, but I just don't see how this proposal adds usability for
authors without that, nor, frankly, what the point is of basing it on
CSS while leaving out one of the key things that has made CSS itself
useful -- other than perhaps making life easier for the two or three
people who are working on browser-based terps. "Terpetude" would still
require something like 80 predefined styles!
Style inheritance is a nice idea, but where is the actual demand for
it, like the actual demand we've seen for a way to change text
appearance on the fly?
vw
Ron Newcomb
Being unfamiliar with Glk beyond "it's middleware", I understand only
about 80% of the issues brought up. But I'm pretty sure I agree with
Jesse. While having the user define or name a Style is good
programming practice, I see few doing so. Or if they do, they will do
it using the existing tools at their disposal, like:
To say Death's Dialogue: say "[all-caps style][bold style]".
To say end DD: say "[roman style]".
And let's not even get into subclassing styles while the average
writer struggles with Class vs. Instance.
(Or if named styles do appear, let it only be the ones the interpreter
absolutely needs to name, such as the ones in its Preferences/Options
dialogue: input, status, normal.)
Myself didn't know CSS until the IFDB supported it, and after learning
some of it, well, presentation / content separation is a good idea in
theory, but I'll never create another stylesheet again. While
everyone may have an opinion about your visual art, at least the tools
are rather intuitive drag-drop affairs. And while programming may be
a fussy, just-work-damn-you activity, at least everybody and their
mother won't complain about that bass-ackwards algorithm you used
while coding at 2am. CSS creation combines the worst of both
worlds: it's as friendly as tweaking obscure code in an unfamiliar
language, but even the smallest flaw will be highlighted in blinking
neon headers for all the world to judge. (Sometimes literally
highlighted in neon, as when I confused HSV with RGB.) In this way,
CSS creation reminds me of coding a natural-language parser: hard,
with any flaws or shortcuts obvious even to six-year-olds.
Perhaps when the community said "Glk + CSS = Love" we didn't mean it
quite so literally. We heard CSS as "you can now do X, Y and Z"
rather than "you must now define X, Y, and Z in a separate file using
a syntax you don't know, and six year olds will criticize you for
it."
Like Jeff's students, I thought that, being middleware, the changes
wouldn't be obvious to me except for some more functioning say phrases
in Inform 7 (or whatever your authoring language of choice is).
~ ~ ~
A thing I would like to do is have my game ask the interpreter what
the user's preferences are, and change the game to match. For
example, in the above proposal, inputted text is stylized externally
(CSS, interpreter default, user override), and the command prompt is
stylized internally (within the game itself). In a game like
_Winchester's Nightmare_ (which changed the command prompt to "Sarah
decides to ", sans quotes), the author may want to simply ask the
interpreter "what's the user using for inputted text?" and then change
the command prompt to match. Or highlighted keywords to match. Or
out-of-world text to semi-match.
Such querying allows the author to extend any typographic conventions
set by the player.
I would prefer to play gam-- pardon, I would prefer to read
interactive fiction in as a book-like manner as possible. Indented
paragraphs, no blank lines except scene-breaks, and leaned back in a
chair. (The latter meaning the font size is right around the 36-point
mark, and getting worse every year.) A book in the hand is worth two
laptops on the legs, or something like that. When authoring, I would
prefer to extend whatever convention you love, rather than impose my
own, and would appreciate the same courtesy, GlkGod allowing.
~ ~ ~
Bold, italic... and strikeout? Given the prolific appearances of to-
do lists, used-up hints, and shrinking lists of suspects in I-F (and
murder-mysteries), strikeout seems like it would have a home if it
were guaranteed to exist. Since the proposal assumes color, an
interpreter could use half-faded text as a substitute for strikeout.
~ ~ ~
Also, can we get rid of the "style" Emphasis entirely? IIRC
supporting it is how the interpreters ended up getting bold and italic
confused to begin with. Emphasis could also be, theoretically, a
larger font size. Or a much more standout color. Like neon. The
word is just too big of an umbrella.
-R
Jim Aikin
"an easy way to make it look the way I want it to look."
This is, of course, an open-ended desideratum. What we'll end up with
will, inevitably, be no more than a small subset of style variations
that's practical to implement. But whatever subset is made available to
the author, it should be as simple to use as this:
When play begins:
say "[blockquote]'He[']s pinin['] for the fjords.'[line break][flush
right]--Michael Palin, [i]Parrot Sketch[/i][end flush right][end
blockquote]".
--JA
Dannii
>
> Also, can we get rid of the "style" Emphasis entirely? IIRC
> supporting it is how the interpreters ended up getting bold and italic
> confused to begin with. Emphasis could also be, theoretically, a
> larger font size. Or a much more standout color. Like neon. The
> word is just too big of an umbrella.
>
> -R
I disagree... emphasis is a great style/class. Parchment uses
smallcaps, which is usually great (though unfortunately it doesn't
look great in all web fonts). I would prefer to specify the meaning of
phrases and then use CSS to suggest a way to display them which could
be overridden by the player.
Dannii
> I second Jeff's concern. I would define the Gold Standard for authors as
> "an easy way to make it look the way I want it to look."
>
> This is, of course, an open-ended desideratum. What we'll end up with
> will, inevitably, be no more than a small subset of style variations
> that's practical to implement. But whatever subset is made available to
> the author, it should be as simple to use as this:
>
> When play begins:
> say "[blockquote]'He[']s pinin['] for the fjords.'[line break][flush
> right]--Michael Palin, [i]Parrot Sketch[/i][end flush right][end
> blockquote]".
>
> --JA
Or instead:
When play begins:
say a quotation with body "He's pinin' for the fjords.",
author "Michael Palin",
and source "Parrot Sketch".
Or have that info in a table etc.
Aaron A. Reed
> I second Jeff's concern. I would define the Gold Standard for authors as
> "an easy way to make it look the way I want it to look."
>
> This is, of course, an open-ended desideratum. What we'll end up with
> will, inevitably, be no more than a small subset of style variations
> that's practical to implement. But whatever subset is made available to
> the author, it should be as simple to use as this:
>
> When play begins:
> say "[blockquote]'He[']s pinin['] for the fjords.'[line break][flush
> right]--Michael Palin, [i]Parrot Sketch[/i][end flush right][end
> blockquote]".
>
> --JA
Thirded here-- as a member of the "was playing with Music Constructor
Set in the '80s instead of BASIC" brigade, I can't quite wrap my brain
around what styling text would be like for the author under this
proposal.
Jim's syntax would be fine, as would anything along the lines of:
say "It's coming right for us!" styled with alert.
...but my useless artist brain gets the feeling it's not going to be
quite that easy. Defining rock numbers sounds ominous. Please, I'm
afraid of numbers. Don't leave me alone with them.
(Don't get me wrong. "Possible although difficult" is obviously a huge
improvement over "impossible." But the closer we can get to
eliminating that "although difficult" bit, the better.)
--Aaron
Dannii
>
> --Z
Can I suggest this be put on github soon, and that you split out the
specs from the glk/glulx tests? It could be useful for us to
contribute suggestions to this spec or to notify you of ambiguities/
bugs in the existing specs, without the tests and other stuff being
there too. I'd also like to work on Z-Machine spec which brings across
all the stuff from 1.1 which has actually been implemented but no
more, so that people actually have a decent idea of what will work
without getting their hopes high.
David Kinder
> "an easy way to make it look the way I want it to look."
Provided you're prepared to accept "an easy way to say how I want it
to look, but the player can ignore me" then we are, hopefully, heading
in the right direction. Windows Glk based interpreters already have an
option to ignore style hints, and as I find myself using it more
often, it may migrate to being a more obvious toolbar button.
It's important to be clear about what this is, and what it is not.
What it is not is anything that says what the Inform 7 syntax will be.
The only restriction that this proposal puts on Inform 7 is that I7
must be able analyze the game's source code and produce an appropriate
style sheet as part of its build process. Of course, for Inform 6
users there will be @glk calls and numbers and all sorts of tricky
things to get exactly right, but that's always been the Inform 6 way.
David
David Kinder
> I agree with you so far as saying that we should *either* ban px or pt. :)
>
> So, which to use? I don't have a strong leaning. I'd want to hear from
> library implementors about how much work they're willing to do for
> font introspection. I also worry that em/%/ex measurements would offer
> too much room for implementations to diverge from each other and from
> web toolkits. Saying "indent ten pixels" is cranky and
> resolution-dependent but at least it's unambiguous.
I don't see having em/%/ex sizes as causing me much difficulty, at
least on Windows. As we're going to have implementations diverging
anyway due to the joys of the web, I'd rather live with that than have
everything measured in annoyingly small pixels.
David
vaporware
Inform 6 users would have to write a separate style sheet, then
package it and the game into a blorb - no more distributing .ulx
files, if you want anything besides the standard styles. That's a new
requirement: currently, I6 games can change style hints with Glk calls
before opening the windows.
vw
Jeff Nyman
> It's important to be clear about what this is, and what it is not.
> What it is not is anything that says what the Inform 7 syntax will be.
But could "what the Inform 7 syntax will be" have some ramifications
on design ideas that are considered? In other words, if (enough)
people say: "Here's what I would really like to be able to do ...",
might that not have some impact on design decisions in terms of what
Glk will or will not support and how it might do so?
If not, it will be one of the first times I've seen where the end
design appears to bear no relation on the implementation chosen.
A (possibly) good example of this being the fact that only two styles
were thought to be "good enough" for the initial Glk implementation.
Everytime that comes up, it there's certainly more than one person
that questions why that path was chosen. My point there not being to
criticize a decision but to suggest that maybe a little more feedback
about the end state or the goals would help prelude similar blind
spots as this new Glk implementation goes forward.
So beyond just the I7 syntax -- which is only one level of design --
there's the notion of what authors would like to see possible at all,
regardless of how ultimately the I7 syntax handles that.
- Jeff
Jim Aikin
>> I second Jeff's concern. I would define the Gold Standard for authors as
>> "an easy way to make it look the way I want it to look."
>
> Provided you're prepared to accept "an easy way to say how I want it
> to look, but the player can ignore me" then we are, hopefully, heading
> in the right direction.
I'm not willing to accept that, no. As I mentioned in another thread,
I'm firmly of the mindset that the author MUST be able to control every
detail of the appearance of the game, subject only to the limitations of
what has or has not been implemented in the interpreter software.
I spend most of my computer time working with pro-level music software.
I'm not aware of ANY music software that gives the listener a speck of
control over the presentation of the artistic work, other than a
start/pause/stop button and a volume knob. And I can readily imagine
that recording artists would react with horror to any proposal that they
utilize (much less be required to utilize) such a system.
I would expect the same view of this to be found in the graphic arts
community. "What do you mean, the viewer should be able to turn red to
yellow in my image???"
Do you get to rearrange the buttons and menus on other people's websites
in ways that seem more aesthetically pleasing to you? No, you do not.
Since IF is basically text, the appearance of the text is very
legitimately something that the author needs to be concerned with.
That's what style sheets are all about, for God's sake! The insistence
that the user of an IF terp should be given the ability to monkey with
this stuff just plain baffles me. It makes no sense, other than through
an appeal to hoary tradition: "We've always done it this way, so we're
going to keep on doing it this way. The horse and buggy is good enough,
by Godfrey. Who needs one of those new-fangled auty-mobiles?"
--JA
mwigdahl
>
> I spend most of my computer time working with pro-level music software.
> I'm not aware of ANY music software that gives the listener a speck of
> control over the presentation of the artistic work, other than a
> start/pause/stop button and a volume knob. And I can readily imagine
> that recording artists would react with horror to any proposal that they
> utilize (much less be required to utilize) such a system.
What about a graphic equalizer?
>
> Do you get to rearrange the buttons and menus on other people's websites
> in ways that seem more aesthetically pleasing to you? No, you do not.
>
Although many modern applications support skinning.
> Since IF is basically text, the appearance of the text is very
> legitimately something that the author needs to be concerned with.
> That's what style sheets are all about, for God's sake! The insistence
> that the user of an IF terp should be given the ability to monkey with
> this stuff just plain baffles me. It makes no sense, other than through
> an appeal to hoary tradition: "We've always done it this way, so we're
> going to keep on doing it this way. The horse and buggy is good enough,
> by Godfrey. Who needs one of those new-fangled auty-mobiles?"
>
> --JA
I don't understand. Providing the user the ability to override
certain aspects of presentation is "old-fashioned", while removing
those options entirely is somehow more modern and progressive? Should
the author be required to bundle up the specific fonts they want used
as well?
I don't think overriding the author's intent should be done lightly,
but I'm willing to allow that people with colorblindness, other
eyesight issues, or simply preferences in whether they read white text
on black or black text on white, etc. should be able to tweak (and I
do mean 'tweak') the work's presentation to their taste.
Matt
Jim Aikin
> On Dec 2, 10:25 am, Jim Aikin <midigur...@gmail.com> wrote:
>> I spend most of my computer time working with pro-level music software.
>> I'm not aware of ANY music software that gives the listener a speck of
>> control over the presentation of the artistic work, other than a
>> start/pause/stop button and a volume knob. And I can readily imagine
>> that recording artists would react with horror to any proposal that they
>> utilize (much less be required to utilize) such a system.
>
> What about a graphic equalizer?
Some playback systems have them, some don't. Fiddling with the sliders
on a graphic EQ is a lot like adjusting the brightness of your computer
screen, of switching from a hi-res display to 800x600. But in EVERY song
you hear (even the ones that were mixed badly by amateurs) decisions
were made about the mix. The listener doesn't get to go in and say, "Oh,
I think I'd like the drums louder."
A few experiments along these lines have been tried. I believe Todd
Rundgren released a CD ten or twelve years back that invited the
listener to remix. It didn't lead to a groundswell of interest in
listener remixing -- it was just a stunt.
>> Do you get to rearrange the buttons and menus on other people's websites
>> in ways that seem more aesthetically pleasing to you? No, you do not.
>>
>
> Although many modern applications support skinning.
True. I'm not saying for a moment that the IF author shouldn't be
_allowed_ to include any sort of skinning he or she might feel
appropriate, including giving the player a choice of fonts! But it's the
author's prerogative to decide whether to offer those options. The
author who feels that he or she has found an optimum, appropriate form
of display should be able to implement it, secure in the knowledge that
it won't be hosed.
> I don't understand. Providing the user the ability to override
> certain aspects of presentation is "old-fashioned", while removing
> those options entirely is somehow more modern and progressive?
I can see that this is a point of possible confusion. What I'm saying is
that the AUTHOR should have the options. That's the progressive
approach. The author can then give the end user certain options, or not.
> Should
> the author be required to bundle up the specific fonts they want used
> as well?
Required, no. Allowed, certainly! Although in the case of bundling fonts
for redistribution, I believe there are copyright and licensing issues.
But if the author feels that a game requires some particular font in
order to achieve the desired effect, and if that font is one that's not
commonly found on end users' computers, the author could very
legitimately want to write a game that starts with a warning that says,
"Sorry, in order to run this game you need Zapf WingDings 9 installed in
your system. Please download it from Xxxxx and install it." Only an
idiot would require a font that people had to purchase, but requiring a
specific font is not weird. Book designers do it quite routinely. And in
a self-published medium, the author is the book designer.
> I don't think overriding the author's intent should be done lightly,
> but I'm willing to allow that people with colorblindness, other
> eyesight issues, or simply preferences in whether they read white text
> on black or black text on white, etc. should be able to tweak (and I
> do mean 'tweak') the work's presentation to their taste.
There's certainly a need to provide a delivery system that will be
useful for people with visual disabilities. You could make a strong case
that every game should be able to run in text-only (console) mode. But
providing for people who have special needs is very different from
allowing each user to redesign your presentation according to their own
whim.
It's also the case that people with visual disabilities can't play
graphic games. Nobody that I'm aware of has suggested that designers of
graphic games should be required to accommodate the visually impaired.
So while I think it's considerate, appropriate, and sensible to deliver
text games in a way that makes them accessible to the blind community, I
can't quite grasp the idea that the author should be required to do so
in every case. If the author wants to do something (whatever it might
be) that renders the game unplayable by the visually impaired, I don't
feel it's appropriate to tell the author, "No, we're not going to let
you do that."
--JA
mwigdahl
> Some playback systems have them, some don't. Fiddling with the sliders
> on a graphic EQ is a lot like adjusting the brightness of your computer
> screen, of switching from a hi-res display to 800x600. But in EVERY song
> you hear (even the ones that were mixed badly by amateurs) decisions
> were made about the mix. The listener doesn't get to go in and say, "Oh,
> I think I'd like the drums louder."
Agreed -- just like no one goes into an interactive fiction title and
says "Oh, I think I'd like the room descriptions to be more vibrant."
I'm not sure the audio analogy works well here.
> >> Do you get to rearrange the buttons and menus on other people's websites
> >> in ways that seem more aesthetically pleasing to you? No, you do not.
>
> > Although many modern applications support skinning.
>
> True. I'm not saying for a moment that the IF author shouldn't be
> _allowed_ to include any sort of skinning he or she might feel
> appropriate, including giving the player a choice of fonts! But it's the
> author's prerogative to decide whether to offer those options. The
> author who feels that he or she has found an optimum, appropriate form
> of display should be able to implement it, secure in the knowledge that
> it won't be hosed.
>
There's no way to assure this -- if I want to play your game cross-
eyed, while standing on my head, or while wearing tinted sunglasses to
change the background of the screen from white to yellow, I can do
so. All will affect how I perceive your work.
> > Should
> > the author be required to bundle up the specific fonts they want used
> > as well?
>
> Required, no. Allowed, certainly! Although in the case of bundling fonts
> for redistribution, I believe there are copyright and licensing issues.
> But if the author feels that a game requires some particular font in
> order to achieve the desired effect, and if that font is one that's not
> commonly found on end users' computers, the author could very
> legitimately want to write a game that starts with a warning that says,
> "Sorry, in order to run this game you need Zapf WingDings 9 installed in
> your system. Please download it from Xxxxx and install it." Only an
> idiot would require a font that people had to purchase, but requiring a
> specific font is not weird. Book designers do it quite routinely. And in
> a self-published medium, the author is the book designer.
>
Book designers may do it quite routinely, but (for instance) e-book
readers don't honor that. With the Kindle or the nook, you get what
you get, which is a serviceable but not outstanding serif font.
There's currently no (easy) way to change the fonts, whether to honor
the author's intent or simply to indulge the user's whims, and that's
one of the most rabidly requested features these devices have. I'll
bet dollars to donuts that the overwhelming majority of people
requesting different fonts are looking for readability improvements,
_not_ to match the aesthetics of the print editions. More to the
point, I haven't heard of any authors or book publishing companies
refusing to sell e-book rights because the devices can't match the
intended appearance of the text.
> > I don't think overriding the author's intent should be done lightly,
> > but I'm willing to allow that people with colorblindness, other
> > eyesight issues, or simply preferences in whether they read white text
> > on black or black text on white, etc. should be able to tweak (and I
> > do mean 'tweak') the work's presentation to their taste.
>
> There's certainly a need to provide a delivery system that will be
> useful for people with visual disabilities. You could make a strong case
> that every game should be able to run in text-only (console) mode. But
> providing for people who have special needs is very different from
> allowing each user to redesign your presentation according to their own
> whim.
>
> It's also the case that people with visual disabilities can't play
> graphic games. Nobody that I'm aware of has suggested that designers of
> graphic games should be required to accommodate the visually impaired.
> So while I think it's considerate, appropriate, and sensible to deliver
> text games in a way that makes them accessible to the blind community, I
> can't quite grasp the idea that the author should be required to do so
> in every case. If the author wants to do something (whatever it might
> be) that renders the game unplayable by the visually impaired, I don't
> feel it's appropriate to tell the author, "No, we're not going to let
> you do that."
>
> --JA
You might be surprised at how many graphical games have been converted
to provide access to the visually impaired. I certainly agree that
there should be no _requirement_ to do so.
I guess really it comes down to a disagreement as to where in the
delivery chain control over the game passes out of the author's
grasp. You see interactive fiction as analogous to a physical book,
where the author/publisher should have control over every aesthetic
aspect of the work, from the content of the prose to the font used to
the particular paper, binding, and cover art. I respect that, but I
don't think the analogy holds up well to this medium.
I see (probably because I come from the programming side of the aisle)
interactive fiction as analogous to a souped-up text file, where the
the author/publisher has total control over the content and is (or
should be) free to specify desired formatting down to whatever level
of detail they would like, but that the finished work is a result of a
synthesis between the author-controlled data file and rendering
software (the interpreter) that is essentially under the control of
the user.
As an author, I would like that rendering software to respect my style
choices insofar as possible, but I accept that I don't fully control
that and probably _shouldn't_ be able to fully control that -- that
the reader can at any time decide to modify aspects of the
presentation based on needs or desires I was unaware of while writing
the work. I don't feel that the user making such modifications
necessarily compromises the integrity of the work -- any enhancement
or degradation of the "ideal author's intended experience" that
results for that particular person is solely the responsibility of
that particular person.
If they like playing while standing on their head, who am I to tell
them that my game _requires_ them to play while sitting at a TV tray
instead? I might strongly _suggest_ that the game is best experienced
while seated at a TV tray, but I personally would not want to try to
lock them out of it if they aren't.
Matt
Jon Ingold
Players and authors don't really care about individual "styles". At
present, I doubt anyone uses them - as an author, I have no idea what
they do; as a player, I have no idea where the game uses them so can't
really take any sensible decisions.
Players care about "skinning" their terps. Parchment-style lowercaps,
or Windows Frotz neat-PC look? Looking ahead, we could share a library
of skins - manuscript, copperplate, vellum, scifi - and the player
chooses simply from a drop-down list, which effects the game across
the board. CSS, I guess, is a good way of achieving this.
(And this is a good thing: if players start caring about tweaking your
"emphasis" text, then they're not playing your game, which is a bad
thing.)
As an author, I care about the *relative* appearance of text. I want
to know that strikeout is the same font as the normal text + a
strikeout. I want to know that I can turn text blue for the word
"water" and green for "grass". I don't really care about the
background, the paragraph and indenting, the overall font (probably).
As an author, I want to be able to say [italic][red]... or at least,
[red italics]. So we could do this with a finite list of styles, but
it'll need to be a long one. I want every colour, every text effect
(bold/italic/underline/&c) and I want these across three or four
levels of Heading, superscript and subscript. Predefined styles sound
crazy, looking at it this way.
I can't help feeling the Z-machine is the model we should be
following, on the coding side. Then it's up to 'terp writers to (a)
provide the effects, if they can, and (b) customise the effects, if
they want to allow it (select the font, the size, so forth). Which is
to say that the rendering data should be at the level of the
interpreter not the game, and decisions about how to store that data
(CSS, etc) shouldn't be affecting the way we design I7 itself.
Because although there will be authors who want to tweak this stuff
into obscurity, *most* will want to simply differentiate one bit of
text from the next in a predictable, coherent way.
cheers
jon
Jim Aikin
> Having read all this, the following occurs to me.
Thanks, Jon. Very sensible.
I might quibble about indenting, because I never did care for the TADS 2
tabbed-paragraph-with-no-blank-lines style. But for the rest, I think
you're making good sense.
--JA
Ben Cressey
> two calls. To test whether the library *supports* a model, use a
> second selector, gestalt_StyleModelAvailable.
What do you think about gestalt tests for the different CSS
properties? I can't say how universal this is, but Gargoyle uses
glk_style_measure and glk_style_distinguish calls to convey
information on the style hints it actually supports, albeit in a crude
and inconsistent way that may not be worthwhile. A gestalt mechanism
would make this transparent to the game and compensate somewhat for
the loss of these two functions.
I anticipate a bit of trouble with the various font properties. Font-
family might be hard to deal with in a cross-platform library, and may
wind up being more trouble than it's worth. It would be nice for the
library to be able to tell the game that its font choices simply won't
be honored, in the event that gameplay hinges on reading a span of
text set to an Arabic font that is common on Windows but not available
on a Mac or under Linux.
(As an aside, I like the idea of an extension to the blorb format to
support embedded fonts. Obviously the fonts would need to be
unencumbered, but this would allow a game to e.g. display Norse runes
in Junicode and have some chance of it working out of the box.)
Font-size would likewise require some radical revisions to Gargoyle,
which assumes a consistent height for all lines, much like a terminal
window.
Is there a standard CSS mechanism to set vertical alignment of text,
in the event that characters of different sizes are printed on the
same line? It's not one of the text-align values but it does seem
that authors might want to specify the behavior.
> So, which to use? I don't have a strong leaning. I'd want to hear from
> library implementors about how much work they're willing to do for
> font introspection. I also worry that em/%/ex measurements would offer
> too much room for implementations to diverge from each other and from
> web toolkits. Saying "indent ten pixels" is cranky and
> resolution-dependent but at least it's unambiguous.
Em/%/ex measurements would map more cleanly on to overriding user
preferences, which could mandate a particular font / font size. If an
author lays out a work with pixel-precise margins in 8pt Comic Sans,
the library would need to scale up the pixel values anyhow to display
it in a more normal fashion. Also, a library may support margins but
not line-heights or font-sizes, which could only lead to pain if
margin values are not given relative to some aspect of the font.
> Hyperlinks, hyperlinks, hyperlinks. Good question. They're kind of
> outside the style system I described, so just have the interpreter add
> an extra class "GlkLink" (not "Style_link") to those spans?
Why not force the game to define the way it wants hyperlinks to look
in the new style model, using a custom style? If no style is
specified, the hyperlink is not guaranteed to be visually
distinguishable, though it will be functional if the library supports
hyperlinks.
> Maybe you're right that discarding internal borders entirely is the
> way to go.
I like that idea too.
Regards,
Ben
mwigdahl
Yes, that makes a lot of sense!
Matt
Ben Cressey
> [red italics]. So we could do this with a finite list of styles, but
> it'll need to be a long one. I want every colour, every text effect
> (bold/italic/underline/&c) and I want these across three or four
> levels of Heading, superscript and subscript. Predefined styles sound
> crazy, looking at it this way.
As a library author, I assume that all the truly hard stuff will be
handled by Inform 7 extension authors.
You could have a "Simple Colored Text" extension that defines all the
Z-Machine foreground and background colors and provides a simple
syntax to use them that works for both Zcode and Glulx. The
corresponding stylesheet would be generated by the extension and
bundled into the released blorb.
More complicated extensions could tackle the rest of the predefined
styles, though to get full coverage you would need to generate the CSS
at build time based on the styles used in the source text. I have no
idea how practical that would be, but if it's not possible then that
is a legitimate objection to the proposed system.
> Players care about "skinning" their terps. Parchment-style lowercaps,
> or Windows Frotz neat-PC look? Looking ahead, we could share a library
> of skins - manuscript, copperplate, vellum, scifi - and the player
> chooses simply from a drop-down list, which effects the game across
> the board. CSS, I guess, is a good way of achieving this.
Your idea for "skins" could be implemented as extensions for the
author as well, and I think this shows the real strength of the
proposal. I don't relish the notion of playing through twenty
"Science Fiction Text Effects" games in IF Comp 2020, each with the
same skin. At the same time, making high quality, accessible layouts
easy to implement in new games can only be a good thing, especially if
they are also easy to tweak and customize.
The web parallel would be something like themes for a Wordpress blog.
A lot of WP blogs use the same few themes, because they're freely
available, easy to find, and look a lot nicer than the standard
Wordpress theme. I could set up a new Wordpress.com blog in seconds
that had the same look and feel as Emily Short's. Could we then be
criticized for not tweaking all the CSS by hand or making our own
theme from scratch? Perhaps, but it would be rather unreasonable
unless the point of the website was to showcase a unique website
design. Otherwise it just means our sites are more attractive than
they would be otherwise.
vaporware
> > As an author, I want to be able to say [italic][red]... or at least,
> > [red italics]. So we could do this with a finite list of styles, but
> > it'll need to be a long one. I want every colour, every text effect
> > (bold/italic/underline/&c) and I want these across three or four
> > levels of Heading, superscript and subscript. Predefined styles sound
> > crazy, looking at it this way.
>
> As a library author, I assume that all the truly hard stuff will be
> handled by Inform 7 extension authors.
>
> You could have a "Simple Colored Text" extension that defines all the
> Z-Machine foreground and background colors and provides a simple
> syntax to use them that works for both Zcode and Glulx. The
> corresponding stylesheet would be generated by the extension and
> bundled into the released blorb.
>
> More complicated extensions could tackle the rest of the predefined
> styles, though to get full coverage you would need to generate the CSS
> at build time based on the styles used in the source text. I have no
> idea how practical that would be, but if it's not possible then that
> is a legitimate objection to the proposed system.
I don't think it's impossible, at least if you restrict where and how
styles can be changed (only with text substitutions, and no random or
calculated color changes), but it is a big change to the language and
compiler. We can sit here discussing ways Inform could theoretically
be changed to suit this static stylesheet proposal, but what we're
really doing is imagining work for Graham, without knowing his
thoughts or his schedule.
vw
Ron Newcomb
Further question for Plotkin: is the CSS that's in the blorb possible
to be automagically handled by the authoring tool? Something like
the way Inform 7 can "release along with source text" and the source
text grabs a CSS without asking, but is perfectly possible to manually
make & specify one?
If we can use [red][italic] in our code regardless whether the CSS
wants to "zip" them up into a Style with Heirarchy, then that's
perfectly fine by me. As long as it's transparent.
Ron Newcomb
> I might quibble about indenting, because I never did care for the TADS 2
> tabbed-paragraph-with-no-blank-lines style.
Soooo... are you saying that maybe *some* player-overriding
preferences are a good thing?
You were pretty author-knows-best upthread, is why I ask.
On Dec 2, 11:55 am, Jon Ingold <jon.ing...@gmail.com> wrote:
> As an author, I want to know that I can turn text blue for the word
> "water" and green for "grass". I don't really care about the
> background,
If the player happened to set his background to be blue or green, then
you must care. Else your words won't appear at all.
Perhaps our proposal needs a way to incorporate how important a
particular effect is? And if the user's overriding preferences happen
to clash with "very important" or "important", a warning is
displayed? Or other action taken?
For example, let's say I like to play white-on-blue, and I load up
_Blue Lacuna_ with its green & blue highlighted words. In that case,
the exact color isn't real important, only that they are different yet
consistent colors. Orange and green would work just as well. But if
I load up _Photopia_, something is lost if Mars isn't red. I should
have a warning for Photopia but not for Blue Lacuna. The CSS/game
must communicate with the interpreter/player-preferences so one of
them knows to pop a warning.
Possibly, the game should be responsible for popping a warning,
because this also give the game -- and hence the author -- the ability
to do something other than showing a warning, such as defining a
fallback (with its own importance). Perhaps Blue Lacuna chose blue &
green because they are soothing colors, in line with its tropical
island motif, so it would prefer violet as a substitute over red/
orange/yellow.
Likewise whitespace stuff. If my preferences force all games to be
indented paragraphs, it will likely work with most works except
interactive poetry, which tends to coordinate whitespace with meter.
I need a warning, or, the game needs to know what my setting was so it
can take appropriate action -- such as always spitting out newlines in
pairs.
-R
Lazu God
> Do you get to rearrange the buttons and menus on other people's websites
> in ways that seem more aesthetically pleasing to you? No, you do not.
Actually, yes you can (as evidenced by
https://addons.mozilla.org/en-US/firefox/collection/0dea8e04-d8b6-a0b5-0e4c-c7ebe13c7fc7
and the existence of Greasemonkey itself).
Jim Aikin
> On Dec 2, 12:05 pm, Jim Aikin <midigur...@gmail.com> wrote:
>> I might quibble about indenting, because I never did care for the TADS 2
>> tabbed-paragraph-with-no-blank-lines style.
>
> Soooo... are you saying that maybe *some* player-overriding
> preferences are a good thing?
A good thing? Only if the player is visually impaired and needs to do
so. But as a practical matter in the real world -- that's the world
where I would only get a system that worked the way I would like if I
wrote everything myself (which I'm not a good enough programmer to do)
-- I think Jon has the right approach.
> On Dec 2, 11:55 am, Jon Ingold <jon.ing...@gmail.com> wrote:
>> As an author, I want to know that I can turn text blue for the word
>> "water" and green for "grass". I don't really care about the
>> background,
>
> If the player happened to set his background to be blue or green, then
> you must care. Else your words won't appear at all.
And this is a perfect example of why giving the player that type of
control is a terrible, dreadful idea.
> Perhaps our proposal needs a way to incorporate how important a
> particular effect is? And if the user's overriding preferences happen
> to clash with "very important" or "important", a warning is
> displayed? Or other action taken?
In order to work around the fact that you've given the player too much
control, you're now proposing to complicate the specification. That's
one reason why I think Jon's proposal is good. If I understand it, Jon
is saying, "Let's just give the author more types of control and not
worry about the rest of that magillah that Aikin is so freaked out
about." And I'm fine with that.
Basically, if the interpreter's author gives the user too much control,
then the game author can't and shouldn't concern herself with that. If
the player is getting screwed by the fact that he's doing something that
causes problems, the player is quite likely to blame the author -- so
now the author has to jump through hoops, adding extra tags to solve a
problem that never should have existed in the first place. Ugh.
--JA
Gene Wirchenko
wrote:
[snip]
>Do you get to rearrange the buttons and menus on other people's websites
>in ways that seem more aesthetically pleasing to you? No, you do not.
I can override various settings. In Firefox, if a Webpage wants
to open a new browser, I can force it to open a tab instead. There
are others related to settings. <Ctrl-+> and <Ctrl--> change the size
of the displayed fonts.
I can also turn off Java and JavaScript.
>Since IF is basically text, the appearance of the text is very
>legitimately something that the author needs to be concerned with.
Since books are basically text, the appearance of the text is
very legitimately something that the author needs to be concerned
with. FALSE. Sometimes, the author does, and often, it is just the
publisher.
>That's what style sheets are all about, for God's sake! The insistence
>that the user of an IF terp should be given the ability to monkey with
>this stuff just plain baffles me. It makes no sense, other than through
Colourblindness, blindness, visual acuity are all legitimate
reasons for wanting to change settings.
>an appeal to hoary tradition: "We've always done it this way, so we're
>going to keep on doing it this way. The horse and buggy is good enough,
>by Godfrey. Who needs one of those new-fangled auty-mobiles?"
I think you have that backwards.
My computer, MY rules. If you do not agree, I will delete your
malware.
Sincerely,
Gene Wirchenko
Gene Wirchenko
wrote:
[snip]
>I can see that this is a point of possible confusion. What I'm saying is
>that the AUTHOR should have the options. That's the progressive
>approach. The author can then give the end user certain options, or not.
My computer, my options.
You can warn that something may not run best if ..., but if you
get in the way of my using my computer as I see fit, I am extremely
likely to delete your work.
[snip]
Sincerely,
Gene Wirchenko
Gene Wirchenko
<psc...@yahoo.com> wrote:
[snip]
>On Dec 2, 11:55 am, Jon Ingold <jon.ing...@gmail.com> wrote:
>> As an author, I want to know that I can turn text blue for the word
>> "water" and green for "grass". I don't really care about the
>> background,
>
>If the player happened to set his background to be blue or green, then
>you must care. Else your words won't appear at all.
Or if the player has blue-green colourblindness.
[snip]
Sincerely,
Gene Wirchenko
Adam Thornton
>Do you get to rearrange the buttons and menus on other people's websites
>in ways that seem more aesthetically pleasing to you? No, you do not.
Among the first plugins I load for any new Firefox installation are
Greasemonkey, AdBlock Plus, and NoScript. So, to be blunt, yes, I do.
>Since IF is basically text, the appearance of the text is very
>legitimately something that the author needs to be concerned with.
>That's what style sheets are all about, for God's sake! The insistence
>that the user of an IF terp should be given the ability to monkey with
>this stuff just plain baffles me. It makes no sense, other than through
>an appeal to hoary tradition: "We've always done it this way, so we're
>gohing to keep on doing it this way. The horse and buggy is good enoughY,
>by Godfrey. Who needs one of those new-fangled auty-mobiles?"
Do you have a mother-in-law? I do. And she demands a computer to play
Yahoo bridge on when she visits. And when she's done and I get it back,
the screen resolution is always 640x480 because she needs the text to be
bigger so she can read it and she doesn't know any other way to make the
display suit her needs.
I'm happy for games to recommend and strongly suggest presentation
styles. I am deeply resentful of the notion that they are entitled to
impose them on me. It's only slightly less rude than that DOS comp game
that (unforgiveably) reset my system clock.
Adam
Jim Aikin
>
> You can warn that something may not run best if ..., but if you
> get in the way of my using my computer as I see fit, I am extremely
> likely to delete your work.
...and who loses out in that event? Not me.
--JA
Amy Lear
> Having read all this, the following occurs to me.
>
> Players and authors don't really care about individual "styles". At
> present, I doubt anyone uses them - as an author, I have no idea what
> they do; as a player, I have no idea where the game uses them so can't
> really take any sensible decisions.
<snip>
> Because although there will be authors who want to tweak this stuff
> into obscurity, *most* will want to simply differentiate one bit of
> text from the next in a predictable, coherent way.
I find myself needing to second Jon's points here. The importance here
is being able to set apart certain elements in a distinct -- yet
thematically consistent, within a given work -- manner. Aaron Reed's
Blue Lacuna using colors for interface keywords being a solid example
of what the most typical 'need' may be. For something like that, the
objective of simply being able to tag certain sections of text to be
certain colors -- which may or may not occur concurrently with
typeface changes, such as bold, italics, etc -- means a coherent and
straightforward mechanism needs to be presented to the author.
With regards to player impact and their customization.. I used to
spend a lot of time on MUD/MUSH/MUCK systems, and on most games I was
forced to disable ansi color because of jarring color combinations,
which were literally too painful for me to look at. The result was
typically that I was missing some significant interface hinting, but I
could more or less limp along.
I'm not colorblind, just particularly sensitive to patterns, so I can
understand why some people might want control over these things, but I
think trying to build that kind of customization into a standard is a
bit excessive. That kind of design never really works out well for
anyone, in my experience.. The designers, implementers, world
builders, or users. They all lose.
Instead of trying to bend the tool creation in some kind of absurdly
complicated way, work from the social perspective: Try to encourage
authors not to do the things that are awful.
On the other hand, both as a potential author and as a user, I would
be perfectly happy with just having more than two style slots to work
with in the existing framework. For the 'distinct presentation'
objective, even just five or six would be more than enough -- as long
as you're not trying to do something that's more of a work of art than
a piece of fiction, like 'Photopia' sounds like it was. (I personally
have not and do not intend to try it, because from what I've read it
will only end in pain for me. Ah well.)
A small number of discrete style slots also lends itself well to end-
user overrides on a case-by-case basis.
Maybe taking the time to really consider and discuss the scope of
what's beneficial and needed would help?
Aaron A. Reed
> You see interactive fiction as analogous to a physical book,
> I see (probably because I come from the programming side of the aisle)
> interactive fiction as analogous to a souped-up text file
I just want to come in here firmly on Jim's side-- IF should be more
like printed books than ASCII files-- but I'd like to opine that your
argument would hold more weight if people were still routinely
swapping text files. They're not. They're mostly swapping heavily
styled, intricately designed HTML, which includes all sorts of
advanced features including, yes, embedded fonts.
> If they like playing while standing on their head, who am I to tell
> them that my game _requires_ them to play while sitting at a TV tray
> instead?
I think the ridiculousness of the action here betrays the weakness of
this argument. If we're catering to people who want to stand on their
heads while playing IF at the expense of the vast majority who would
prefer to play *the way the author intended them to*, then we're doing
something wrong.
And, what Jim said: no one is trying to take away the ability of
players to customize their playing experience. We're just trying to
give authors the same flexibility. If you want to turn off my custom
styles, that's fine; but I'd like the ability to create them in the
first place so you can have that luxury.
--Aaron
Aaron A. Reed
> My computer, my options.
>
> You can warn that something may not run best if ..., but if you
> get in the way of my using my computer as I see fit, I am extremely
> likely to delete your work.
Gene, I'm curious if you feel the same way about web pages.
Do you have CSS and Javascript disabled in your web browser? Are you
averse to web developers using tags like bold and underline? If not,
why do you think the standards for IF are different?
--Aaron
Aaron A. Reed
> On Dec 2, 8:25 am, Jim Aikin <midigur...@gmail.com> wrote:
>
> > Do you get to rearrange the buttons and menus on other people's websites
> > in ways that seem more aesthetically pleasing to you? No, you do not.
>
> and the existence of Greasemonkey itself).
But what percentage of web surfers routinely uses Greasemonkey to
affect the layout of an individual web site?
I worry that we are intentionally crippling the aesthetics of IF to
cater to an extremely small minority of people who are overrepresented
in the raif community, due to the high percentage of coders,
designers, and other brilliant people here who enjoy having a high
degree of control over their environments. That's lovely. But most
people are happy letting content creators decide how their content
should look, and I think most content creators enjoy making their
content look beautiful.
I know I've told these stories again and again, but: I repeatedly talk
to people who are potentially interested in IF, but are immediately
turned off by the command-line aesthetics that authors in the Inform/
Glk infrastructure are trapped in. I want to make my games pretty by
default. I don't think we need jettison the option to play them in an
80-character terminal to do so.
--Aaron
Roger
presentation. This may sound especially callous, but so what if you
have blue-green colorblindness? If I paint a landscape of a green
meadow and waterfall, it may look like a big splotch to you (does it?
- I admit am not very familiar with the specifics of color-blindness),
and that sucks, but so be it. I don't really see that as a valid
argument against authorial control over presentation, sorry. If an
author thinks it is highly important for certain words to appear blue
and green then that is his prerogative and he does not necessarily
need to accommodate you. You could argue that the text in an IF is
more important than the visual presentation (and fundamentally I would
agree with you) but if the author thinks a certain style is important,
then as far as I'm concerned, that is what matters. The author defines
the canon of his work, and I would argue that style and presentation
have a part in artistic canon.
The problem - if you view it as such - is not that authors have too
little control/players have too much, or that authors have too much/
players have too little, or even that there is a "right" or "wrong"
direction to move in. It's that the advent of computers has forever
confused the concept of authorial control over presentation, a level
of control that continues and will continue to exist in other mediums.
Computers are and will remain customizable. People view their desktop
as a filter, a lens through which to interpret digital media, and they
get rather offended when they are not offered as much control as
possible over their personal computing experiences. So while I agree
fully with Jim Aiken's sentiments, I feel they are unfortunately
impractical and that we just have to deal with the medium as it
stands. As much as I philosophically believe an author should have
100% control of how his work is presented, to deny the client the
ability to modify what is being presented to them is simply
incongruous with how computers work. They are two competing
philosophies and I think while both sides have equivalent merit, when
push comes to shove, denying a client the ability to do something he
or she can usually do in the medium is not going to be met with
anything but frustration or outright indignation.
Heck, I can play ANY video game in reverse polarity if I wanted to.
And unless you come over to my home and physically disable that
feature on my PC, you're not ever going to be able to prevent from
doing so. So we have to be practical. You can only do so much to limit
an end user's choices in a digital medium. A video game - in the
context of this argument - is not a paperback novel, or a painting, or
even a board game. By default, a video game is something you can
customize the appearance of.
One last thing, though: Someone mentioned authors rejecting the eBook
format. This happens a lot. JK Rowling, for instance, refuses because
she "thinks physical books are best" or some such rubbish. (Aside: I
own a Kindle.) Also, you'll probably never see House of Leaves on a
Kindle or similar reader precisely because of its formatting, unless
it's a massive PDF instead of a Kindle-format eBook. I'd be very, very
surprised if it ever appeared. The formatting in House of Leaves lends
a lot to the story and what it attempts to evoke in the reader. I
think it is a great example of why authorial control over presentation
matters. If House of Leaves were presented as a straight dump of text
instead of being packaged as it is, it would not have the same impact.
Aaron A. Reed
> denying a client the ability to do something he
> or she can usually do in the medium is not going to be met with
> anything but frustration or outright indignation.
But no one is suggesting, as far as I can tell, that we should deny
users the right to their custom styles. Why does this keep getting
framed as a zero sum game?
Yes, you have a right to say "I would like to play your game in 80
point Comic Sans." I would just like the right to say "Sure, but I
would prefer you play it in 12 point Garamond."
--Aaron
David Kinder
> I worry that we are intentionally crippling the aesthetics of IF
In what way, though, does Zarf's proposal cripple anything? We're talking
about using the CSS model here, which is what the web uses, yet I haven't
seen any suggestions in this discussion that that isn't sufficient control.
David
Roger
But you already have the ability to do that.
[code]
Include Basic Screen Effects by Emily Short.
When play begins:
clear the screen;
say "Author here! Quick note before you play: I designed the game
to be played in Frotz, with color, while you eat a banana nude. That
is the suggested play style of The Dr. Monkey.";
pause the screen.
[/code]
You can already make suggestions to the player is a multitude of ways,
so...I'm not sure what you are suggesting. Some people most assuredly
are suggesting overriding a client's choices. I'm suggesting that it
is impossible.
Hmm. I used the word "suggesting" four times which suggests I go to
bed now but the point is, the author does have control over what the
client sees in other mediums, but never will here. It's just a fact of
life. You can nudge the player toward the well, but you can't make him
drink the water.
Aaron A. Reed
You're right, we've sort of derailed the thread: I think this line
came from the suggestion upstream that it wasn't important to consider
how authors might actually use this functionality, which led to
worries that the needs of authors were not being adequately
considered, which led to assertions that the needs of authors were
outweighed by the needs of players who want to play IF while standing
on their heads, etcetera.
I'm in no way critical of zarf's proposal, which a) I don't understand
the tech details of well enough to critique anyway and b) certainly
seems to be moving in the right direction. I am still unsure how
authors would use this new functionality compared to the current
system, though.
--Aaron
Jon Ingold
> In what way, though, does Zarf's proposal cripple anything? We're talking
> about using the CSS model here, which is what the web uses, yet I haven't
> seen any suggestions in this discussion that that isn't sufficient control.
I think there are two lines here: the first is, how do we implement a
system in the interpreters (for which a CSS model may well be
excellent, I really don't know); the second is, what functionality do
players and authors actually need.
I'm not sure I've seen a consensus on the second question, which
surely needs to drive the answer to the first?
cheers
jon
David Kinder
> You're right, we've sort of derailed the thread: I think this line
> came from the suggestion upstream that it wasn't important to consider
> how authors might actually use this functionality
I'm not sure that that was the original meaning, if you're referring to
something I wrote. What I intended to indicate was that I don't believe that
the design of this should be tightly coupled to how Inform 7 presents style
choices to the user: that's an Inform 7 design choice. You can write web
sites with raw HTML+CSS, but you don't have to: there are plenty of tools
that let you put things together without needing a detailed understanding of
the low-level workings, which is how it should be. All that's really needed
is for the low-level stuff to be sufficiently powerful to support enough
different ways that design systems might make it available to the author.
David
Jon Ingold
> > Yes, you have a right to say "I would like to play your game in 80
> > point Comic Sans." I would just like the right to say "Sure, but I
> > would prefer you play it in 12 point Garamond."
> But you already have the ability to do that...
You've got to ask yourself, though, does this maximise the enjoyment
of the player? In the early stage of a game, the player needs to
entertained very quickly or they'll turn the game off. That's the
reality of life for an author.
I think an opening line that says "please adjust your settings" is a
terrible way to start a game. Whereas, opening in a particular font,
on a nice background (say, the way the "Secret Letter" TextFyre game
plays), is appealing and says "this is a crafted work worth
exploring."
[ We're really got to move away from this console-line app fixation if
we expect anyone else in the world to ever give a damn about what we
do. (we do care about that, right?) ]
cheers
jon
Roger
Well the opposite certainly worked for Twilight Zone. ("Please do not
adjust...")
Jokes aside - Jon, doesn't "Make It Good" immedialely offer a menu to
turn colors on/off, etc. when you start the game? I didn't find that
particularly off-putting. I don't find it off-putting when 99% of the
video games I play have an initial configuration screen. There's no
reason you can do that and make suggestions, or specify a default and
say "the author suggests this style for optimal play/quality" (or
however you want to word it).
John G. Wood
> Gene Wirchenko wrote:
> >
> > You can warn that something may not run best if ..., but if you
> > get in the way of my using my computer as I see fit, I am extremely
> > likely to delete your work.
>
And if Gene is allowed to override your carefully-chosen settings and
play the game with, say, 3pt text in lime green on a puce background,
who loses out then? I can't see that it's you.
I reckon at least 90% of people will play it as it comes. As written,
the spec already allows authors to override normal user preferences,
just not the ones the user declares are important to them. Surely that
should be enough?
John
vaporware
The web uses CSS in two ways.
First, you can write an HTML page that contains no information about
the appearance of different elements, only the conceptual layout:
"this part is a heading", "this part is a quote box", "this part is
the paragraph called Disclaimer". You can then write a separate style
sheet using CSS that describes the appearance of all those parts:
"headings are 24 point bold, quote boxes are indented one inch, the
Disclaimer paragraph is 8 point gray italic". This is easily suited to
customization by the user ("I want disclaimers to be in small caps,
not italics") but requires the author to go back and forth between
HTML and CSS as he writes the page.
Second, you can write a page that contains all the style information
inline: "this is a heading that's 24 point bold", "this is a box
that's indented one inch", "this is a paragraph that's 8 point gray
italic". This makes for coarser customization options ("don't ever
listen to the page when it talks about italics") but is easier on the
author... especially when the author is actually a program generating
HTML on the fly. Some pages have so much variety that it would be
impractical to give a name to each unique combination of attributes.
You can also mix these two approaches within a single page, which you
might do if, for example, your page has things like headings and quote
boxes that the user might want to customize, but also has some rainbow
colored text that (1) probably wouldn't be customized, except in broad
strokes like "ignore all color changes", and (2) uses so many styles
that it would be impractical to name them all.
This Glk proposal includes the first approach but, it seems,
intentionally rejects the second. I believe that's a mistake.
Here's a concrete example of how it cripples things: under this
proposal, it is utterly infeasible to write a game that chooses a
random text color from the allowed range and prints one word in that
color. Technically, it's not *impossible*, but the style sheet would
be over 300 megabytes!
Throw in a random font style (bold and/or italic and/or underline) and
you'd need nearly 6 gigabytes worth of style sheet.
Throw in a random background color as well, and now it *is*
impossible: the style sheet's size would be measured in exabytes,
which would make it too big to fit in a Blorb container... or a hard
drive... or even $5 million worth of hard drives.
It's a contrived example, sure. One could argue about whether the
ability to select a random color -- or to programmatically control
text appearance in general -- is important enough to worry about. But
the fact is, it's trivial to implement that on the Z-machine, or in an
HTML generator, or in pretty much any other user-interface library.
vw
David Kinder
> It's a contrived example, sure.
I'd be more sympathetic to your argument if you had an example that wasn't
contrived.
David
vaporware
In other words, you want to argue over whether the ability to select a
random color (or to programmatically control text appearance in
general) is important enough to worry about. I don't. You asked about
the limitations of this proposal, I gave one: it prevents programmatic
combination of styles.
I'll leave it to better authors than myself to muse about how a game
might benefit from that ability. But my instinct as a programmer tells
me it's a good thing to have. I can't tell you why a painter would
need the ability to mix paints either, instead of just choosing
premixed colors off the shelf, but I know that's a good thing to have
too.
vw
Jon Ingold
> Jokes aside - Jon, doesn't "Make It Good" immedialely offer a menu to
> turn colors on/off, etc. when you start the game?
Sure, but seriously: I'd much rather it just *played*, maybe with a
nice picture and a banner, and the ability to flick to a plan of the
house that showed where you were, &c &c, and the crossword came up in
a separate window with a jpeg that filled itself in, and and and...
jon
mwigdahl
That's what I thought Jim was saying with:
> I'm not willing to accept that, no. As I mentioned in another thread,
> I'm firmly of the mindset that the author MUST be able to control every
> detail of the appearance of the game, subject only to the limitations of
> what has or has not been implemented in the interpreter software.
I read this as saying that interpreters should (somehow) not be
allowed to _modify_ styles that the author had set -- that the only
thing they could do would be to fail to implement them fully. If I'm
wrong, then I don't have any fundamental disagreements with you and
Jim.
Matt
mwigdahl
>
> One last thing, though: Someone mentioned authors rejecting the eBook
> format. This happens a lot. JK Rowling, for instance, refuses because
> she "thinks physical books are best" or some such rubbish. (Aside: I
> own a Kindle.) Also, you'll probably never see House of Leaves on a
> Kindle or similar reader precisely because of its formatting, unless
> it's a massive PDF instead of a Kindle-format eBook. I'd be very, very
> surprised if it ever appeared. The formatting in House of Leaves lends
> a lot to the story and what it attempts to evoke in the reader. I
> think it is a great example of why authorial control over presentation
> matters. If House of Leaves were presented as a straight dump of text
> instead of being packaged as it is, it would not have the same impact.
That was me. At least some eBook readers are now supporting PDF, so
we might see those kinds of works eventually. As far as JK Rowling,
her attitude is interesting considering she's licensed movie,
videogame, and (most significantly) audiobook rights for her works.
Matt
weevil
over styling is moot. If you don't want to be able to control the
presentation of your game, don't. Also if this CSS model is anything
like real CSS, it keeps the content accessible because the styling is
separate from the content- so your grumpy user who hates color should
still be able to opt out of the styling.
On Dec 3, 2:24 am, Roger <roger.helge...@gmail.com> wrote:
mwigdahl
> On Dec 2, 11:07 am, mwigdahl <m...@wigdahl.net> wrote:
>
>
> I think the ridiculousness of the action here betrays the weakness of
> this argument. If we're catering to people who want to stand on their
> heads while playing IF at the expense of the vast majority who would
> prefer to play *the way the author intended them to*, then we're doing
> something wrong.
I'll give you that the example was weak, but not that the argument
itself is. Here's a better example of what I was trying to get at.
Take the game Thief: The Dark Project. At the time it came out, it
was revolutionary as the first FPS-style game to focus on stealth,
with a protagonist who was often less powerful than the enemies he was
trying to evade or eliminate. That game specifically asked you to set
your brightness and contrast settings in a certain way for the
"best" (intended) playing experience. When you did so, you got game
graphics that were markedly darker than what players were generally
used to from FPS titles at the time.
I played in the intended way, and loved the game. Others tried it
that way and hated it because they felt they couldn't see anything,
and cranked the brightness and contrast settings up so they could
enjoy it. If the game had somehow tried to compel you to play with
the "correct" settings, some folks wouldn't have played at all, and
others would have played but enjoyed it less.
My points are that:
1. You _can't_ control what happens outside your game file, so I see
no point in pretending you can.
2. There are many real-world cases where user modification of styles
is a legitimate accessibility issue, and trying to block these seems
arbitrary and cruel -- akin to throwing the baby out with the
bathwater. I know it's been argued that this is not what Jim was
trying to say, but that's how I read his earlier post.
3. Personally, I'd rather have more eyeballs on my game, even if
they're not seeing it exactly as I envisioned it. I realize not
everyone shares this viewpoint.
>
> And, what Jim said: no one is trying to take away the ability of
> players to customize their playing experience. We're just trying to
> give authors the same flexibility. If you want to turn off my custom
> styles, that's fine; but I'd like the ability to create them in the
> first place so you can have that luxury.
>
> --Aaron
That's not at all what I got from Jim's earlier comments. Part of the
issue might be the distinction you both seem to make between "turn
off" and "change". Jim alluded to this as well when he said:
> I'm not willing to accept that, no. As I mentioned in another thread,
> I'm firmly of the mindset that the author MUST be able to control every
> detail of the appearance of the game, subject only to the limitations of
> what has or has not been implemented in the interpreter software.
"Turn off" really means "change to the default" -- why is this OK but
"change to a different color" is a major problem?
Matt
mwigdahl
> On the other hand, both as a potential author and as a user, I would
> be perfectly happy with just having more than two style slots to work
> with in the existing framework. For the 'distinct presentation'
> objective, even just five or six would be more than enough -- as long
> as you're not trying to do something that's more of a work of art than
> a piece of fiction, like 'Photopia' sounds like it was. (I personally
> have not and do not intend to try it, because from what I've read it
> will only end in pain for me. Ah well.)
>
> A small number of discrete style slots also lends itself well to end-
> user overrides on a case-by-case basis.
>
> Maybe taking the time to really consider and discuss the scope of
> what's beneficial and needed would help?
As far as I can tell, most authors want more colors available in their
windows at one time. Full stop. I'd love to see a survey of Glulx
custom style use and see what percentage are used solely for text
color changes -- I'm guessing it would be 90%+.
I agree that having, say, 8 custom styles per window in the current
Glulx model would be great. But all I would do with them would be to
load up the basic Z-machine colors and drive happily on, which makes
me think that it might be a better idea to decouple text coloring from
the typography-affecting aspects of style altogether, regardless of
the style model we end up with.
Even if Zarf stuck more closely with the current architecture, two
custom styles as we have now would probably be fine IF we had built-in
support for arbitrary text coloring. Heck, forget arbitrary -- even a
16-color customizable colormap associated with each window should be
plenty, and that would still allow accessibility issues to be
addressed through the end-user overrides you mentioned.
Matt
Jim Aikin
I think what Aaron and Jeff were getting at, if memory serves, was that
it would be useful to start at the front end, by contemplating what
authors will want to do, rather than by starting at the back end. When
the discussion centers on the design of a CSS-based system (or any other
type of system) without consideration of how plain old authors (who
don't know CSS and don't want to) will want to use it ... that's just
the wrong way to go about creating a design specification.
The precise Inform syntax isn't important. What's important is, first,
that the system be amenable to a compact Inform syntax, and second, that
the system do -- in a highly controllable way -- the things that authors
will want to do.
--JA
Jim Aikin
>
> [ We're really got to move away from this console-line app fixation if
> we expect anyone else in the world to ever give a damn about what we
> do. (we do care about that, right?) ]
Amen.
--JA
Jerome West
> I'm not aware of ANY music software that gives the listener a speck of
> control over the presentation of the artistic work, other than a
> start/pause/stop button and a volume knob.
- Graphic equaliser
- Loudness / bass boost button
- 'Ambience' processor
- Guitar Hero / Rock Band / DJ Hero
- iPhone remix app
- GarageBand
- Rez and similar games
- Media center visualisers
- Neon and other lightsynths
Snacky Pete
wrote:
>Gene Wirchenko wrote:
>>
>> You can warn that something may not run best if ..., but if you
>> get in the way of my using my computer as I see fit, I am extremely
>> likely to delete your work.
>
>...and who loses out in that event? Not me.
>
>--JA
But how is that so, Jim? As an author myself, if I make decisions
regarding the presentation of my prose that displease some readers, I
am limiting my reading audience. That not only causes the potential
readers to lose out (assuming my work was worth reading) but affects
me as well. Why do I write things? So that I can have the simple
satisfaction that I was able to do it? Or to have people read and
enjoy it? For me, anyway, the latter alternative carries more weight.
I want as many people as possible to enjoy my prose, because that's
why I write it.
I feel that if we become strict or inflexible about how our prose is
presented, we are stepping beyond our role as fiction authors and
moving towards the realm of graphical game designers, which is
contrary to the intent of IF, IMHO.
-Pete
Roger
hence a graphic. It may not necessarily be a sophisticated piece of
graphics but I don't think it is inherently worng (or right) to be
concerned over the way it is presented to the reader. A writer should
not be limited to what academia has defined as literature and I would
argue that if a writer feels that the textual style is important, then
it is.
I just don't think it is a practical perspective in this particular
medium.
Ben Cressey
> it would be useful to start at the front end, by contemplating what
> authors will want to do, rather than by starting at the back end. When
> the discussion centers on the design of a CSS-based system (or any other
> type of system) without consideration of how plain old authors (who
> don't know CSS and don't want to) will want to use it ... that's just
> the wrong way to go about creating a design specification.
I think the notion of a design specification is commendable but
somewhat misplaced in this thread. The CSS proposal is specific to
Glk. Glk is not meant to be all things to all people. It is not
intended as a way for authors to have absolute control over display
elements. Actually it very deliberately chooses the opposite goal:
offering a subset of display functionality, culled from the limitless
set all possible output options on all possible devices.
Even within that subset, it guarantees only the functionality that is
absolutely necessary based on the current conception of IF. A way to
put text on the screen. A way to get user input. A way to save and
open files.
The Glk spec has weaknesses, to be sure. The lowest common
denominator approach inevitably means that some features available on
high-end platforms will be inaccessible. This is a legitimate
criticism, and a point of frustration for ambitious authors who wish
to do more with IF. But it's fair to point out that this weakness is
simply the other side of a very important strength: the ability for
many authors to create a simple game that can run well on a staggering
variety of devices.
If this strength is absolutely not important to you, you can and
should prepare a design specification for a new IF virtual machine
format. You could even base it on Flash, or Silverlight, or some
other VM that offers robust display capabilities. This may well be
the way forward for IF. It is a commendable goal in any event.
However, it is not zarf's goal. He is trying to improve the Glk spec
in response to many years of pent-up demand. He is doing it in a way
that is conceptually challenging and necessarily imperfect.
> The precise Inform syntax isn't important. What's important is, first,
> that the system be amenable to a compact Inform syntax, and second, that
> the system do -- in a highly controllable way -- the things that authors
> will want to do.
If implemented as it stands, the proposal would make it trivial to
implement Inform 7 extensions that offer exactly the same level of
text style support for Glulx and Z-Machine. At the virtual machine
level, the implementations would be rather different, but at the
author level they could be identical.
Now, when you move beyond the limits of the Z-Machine and fully
utilize all the available Glulx styles and colors, of course it
changes somewhat. Instead of 16 colors you have 16 million. If you
absolutely have to have all 16 million colors in your game, the
proposal will not serve your needs. Likely Glk will not serve your
needs either; many devices cannot display color at all. Many cannot
display nearly so many colors. In practice, many users would have
trouble visually distinguishing those colors, and you could not
guarantee that they would even see the color you intended if their
monitor was not calibrated properly, as it almost certainly would not
be.
It's fine to wave away these objections by insisting that the author
knows best, but that does not make them any less of an obstacle in the
real world. Again, if you care nothing for the practicality of
implementation, or if portability means nothing to you, you are free
to design a VM specification that is unencumbered by such concerns.
Jim Aikin
> Jim Aikin wrote:
>> I'm not aware of ANY music software that gives the listener a speck of
>> control over the presentation of the artistic work, other than a
>> start/pause/stop button and a volume knob.
Okay, you've got a good list here, though it's riddled with points of
contention. What I wrote, however, was technically correct. I wasn't
_aware_ of most of these things.
> - Graphic equaliser
> - Loudness / bass boost button
> - 'Ambience' processor
I've never heard of an ambience processor (reverb?) in listener
software, but if there is such a thing, as a composer it makes my skin
itch. The fact that someone can fuck up my mix by adding reverb does not
strike me as an advert for the desirability of allowing user control.
Quite the contrary -- it's an advert for _preventing_ user control.
> - Guitar Hero / Rock Band / DJ Hero
What's going on with Guitar Hero, as far as I can tell (having tried,
with some success, to stay as far away from it as I possibly could), is
that record companies are licensing tracks to GH -- a practice over
which the recording artists very likely have no control whatsoever. I'm
not sure that people who use GH (in what manner I don't want to know)
qualify as music listeners. I'm not sure they would qualify for
admission to the human race, either, but I understand that the standards
for admission are somewhat lax.
> - iPhone remix app
Never used it. Can't imagine why anyone would bother remixing (however
that term is being used ... and I'll bet it's being used loosely) on an
iPhone. How about "iPhone audio mangling app"? Yeah, that sounds about
right. You can download Audacity (it's free) and mangle audio on your
computer. You can slice and dice bits of Haydn with Fine Young Cannibals
if it suits you. Enjoy.
> - GarageBand
Not a listener app. Wrong category. GB is for music creators (albeit at
a low level), not for listeners.
> - Rez and similar games
> - Media center visualisers
> - Neon and other lightsynths
Never heard of any of them, but a lightsynth wouldn't be a music app,
would it? It would be a video app. A quick detour over to Wikipedia
suggests that it's something in the Xbox -- which isn't a music delivery
platform. Unless it is. But if you're listening to music on your Xbox
... well, I guess that's a step up from Guitar Hero. Maybe.
Even Windows Media Player has a light show. It also has skins. But that
has nothing to do with the presentation of the music, that's just eye candy.
In any event, real listeners don't use this kind of crap, other than
perhaps to set the graphic EQ to produce a good sound in their room.
They listen to the music the way the composer and recording artist
intended it to be heard. Thinking you have to get in and mess with the
music to have a satisfying experience is just the arrogance of stupidity.
--JA
Ron Newcomb
> I'd be more sympathetic to your argument if you had an example that wasn't
> contrived.
I have one.
_Bronze_, in its compass rose in the status bar, colored unvisited
rooms red and visited ones white. But let's say, instead of the
either/or property "visited", we want to color the room according to
"% explored". As you look under and behind every piece of furniture
in the room, the explored % rises, and the room gets whiter in the
compass rose.
Per vw, this would require a large CSS file.
-Ron
mwigdahl
> Jerome West wrote:
> > Jim Aikin wrote:
> > - Guitar Hero / Rock Band / DJ Hero
>
> What's going on with Guitar Hero, as far as I can tell (having tried,
> with some success, to stay as far away from it as I possibly could), is
> that record companies are licensing tracks to GH -- a practice over
> which the recording artists very likely have no control whatsoever. I'm
> not sure that people who use GH (in what manner I don't want to know)
> qualify as music listeners. I'm not sure they would qualify for
> admission to the human race, either, but I understand that the standards
> for admission are somewhat lax.
>
I play and enjoy Rock Band. The fake guitar is nothing like the real
thing, of course, but I've gotten so much enjoyment out of the game
that I was motivated to buy an acoustic guitar and start to learn it.
The drums are simplistic, but from what those in the know tell me (a
friend that played rock drums for 15 years) are very similar to the
real thing. And although the singing is karaoke style (you try to
exactly match the master track -- variations too far off the line
either in pitch or timing cause you to lose points) it is real
singing. In fact, the Beatles version that just came out supports up
to 2 harmony tracks along with the melody line.
My wife, who was in vocal ensembles all the way through college,
enjoys playing with me; it's a great way for us to combine my love of
gaming with her love of music in a shared activity while I slowly
learn to do the real thing. Based on my experience with my family and
others who play, I'm confident all of us are human beings.
Snacky Pete
<roger.h...@gmail.com> wrote:
>Text itself is a graphic. It is a visual representation on language,
>hence a graphic. It may not necessarily be a sophisticated piece of
>graphics but I don't think it is inherently worng (or right) to be
>concerned over the way it is presented to the reader. A writer should
>not be limited to what academia has defined as literature and I would
>argue that if a writer feels that the textual style is important, then
>it is.
>
>I just don't think it is a practical perspective in this particular
>medium.
>
You are arguing semantics, Roger. My point is based on the fact that
text is different from graphics. Text is the basic medium through
which the prose must be presented. We have no choice about that.
Graphics are optional pretty (or ugly) pictures and colour choices.
It appears we may be getting to the point where an IF author must
decide whether he wants his work to be evaluated on prose alone, or a
combination of prose and presentation. This will result in (at least)
two main types of IF. The people who lose out, were this to happen,
would be the visually impaired, as mentioned earlier in this thread. I
really don't want that to happen.
-Pete
mwigdahl
> > Jim Aikin wrote:
> > - Guitar Hero / Rock Band / DJ Hero
>
> know) qualify as music listeners. I'm not sure they would qualify for
> admission to the human race, either, but I understand that the standards
> for admission are somewhat lax.
> In any event, real listeners don't use this kind of crap, other than
> perhaps to set the graphic EQ to produce a good sound in their room.
> They listen to the music the way the composer and recording artist
> intended it to be heard. Thinking you have to get in and mess with the
> music to have a satisfying experience is just the arrogance of stupidity.
>
> --JA
...I'm not sure that people who use "Interactive Fiction" (in what
manner I don't want to know) qualify as fiction readers. I'm not sure
they would
qualify for admission to the human race, either, but I understand that
the standards for admission are somewhat lax.
...
In any event, real readers don't use this kind of crap, other than
perhaps to set the room lighting to produce a good visible page in
their room. They follow the plot the way the author and publisher
intended it to be read. Thinking you have to get in and mess with the
narrative to have a satisfying experience is just the arrogance of
stupidity.
--MW
Snacky Pete
<jon.i...@gmail.com> wrote:
>[ We're really got to move away from this console-line app fixation if
>we expect anyone else in the world to ever give a damn about what we
>do. (we do care about that, right?) ]
>
>cheers
>jon
I would be happy with this as long as provision is made for those who
are visually impaired -- to any extreme -- so that they are not left
out because of any narrow ideas we authors may have regarding
presentation.
-Pete
Snacky Pete
<roger.h...@gmail.com> wrote:
>Ideally, the author in any medium should have full control over
>presentation. This may sound especially callous, but so what if you
>have blue-green colorblindness?
This is indeed especially callous. This whole thread is disturbing
me. Interactive fiction is one of the very few game types that people
who are visually impaired can actually play. Now were're saying "I
have my rights to change the medium itself so that it conforms to
whatever the hell I want to do." Up till now, the limitations of the
medium automatically enabled people who are severely visually impaired
to employ screen readers so that they could play along. I expect
that, since I was last involved in this, screen readers have advanced
along with everything else, but we seem to be going out of our way to
befoul this. Why??
>If I paint a landscape of a green
>meadow and waterfall, it may look like a big splotch to you (does it?
>- I admit am not very familiar with the specifics of color-blindness),
>and that sucks, but so be it. I don't really see that as a valid
>argument against authorial control over presentation, sorry.
This is an irrelevant example based on completely different mediums.
The medium we are talking about here is text-on-the-screen. Something
that screen readers can recognise and read aloud in a comprehendable
manner. Someone who can't see does not expect to appreciate a
painting, but up until now they have been able to expect to play IF.
Now you want the option to take that away from them.
>If an
>author thinks it is highly important for certain words to appear blue
>and green then that is his prerogative and he does not necessarily
>need to accommodate you. You could argue that the text in an IF is
>more important than the visual presentation (and fundamentally I would
>agree with you) but if the author thinks a certain style is important,
>then as far as I'm concerned, that is what matters. The author defines
>the canon of his work, and I would argue that style and presentation
>have a part in artistic canon.
>
The example you present here of blue text on green would not be an
issue for people who use screen readers. However, why should we
marginalize people who are colour blind? Especially when we don't
have to?
I suppose the bottom line here is that if we as authors want to
produce IF that people who are visually impaired cannot access, or
have extra trouble accessing, no one can stop us. It would be a real
shame, though, and I would hope that the more responsible of us would
refuse to do so.
mwigdahl
> On Thu, 3 Dec 2009 00:24:52 -0800 (PST), Roger
>
>
> produce IF that people who are visually impaired cannot access, or
> have extra trouble accessing, no one can stop us. It would be a real
> shame, though, and I would hope that the more responsible of us would
> refuse to do so.
Does Adam Cadre's _Lock and Key_ work well in a screenreader? It
seems like Glulx already gives you plenty of tools to break
screenreader-friendliness.
It certainly goes without saying (or should) that you wouldn't want to
break accessibility without good reason.
Matt
JDC
> _Bronze_, in its compass rose in the status bar, colored unvisited
> rooms red and visited ones white. But let's say, instead of the
> either/or property "visited", we want to color the room according to
> "% explored". As you look under and behind every piece of furniture
> in the room, the explored % rises, and the room gets whiter in the
> compass rose.
I was just about to mention this one. In my game Mobius I had some
color changes in the status line (e.g., one part changes from green to
yellow to red to indicate impending doom). I based my initial code on
the example in in the I7 manual of the compass rose (I assume the
example was based on the Bronze code). Everything looked fine in
Zoom...
And then I tested it in Spatterlight. In Zoom the status line is
displayed in reverse video, but Spatterlight defualted to normal. My
status line now showed a bunch of normal text, with the colored
characters displayed with black boxes around them because my code was
assuming black background text in the status line. I believe Bronze's
status line also looked mangled. I eventually managed to rewrite my
code so that things looked reasonable in both (I don't remember
anymore what the right way to do this was; I don't have the code
handy).
But I see this as a potential problem with static styles vs. being
able to alter text attributes programmatically. What I wanted to do
was say "print everything the same way as the rest of the status line,
but change the text color to [green/yellow/red]". If I had to declare
styles for each of these I would need to know what the regular status
line style looked like; otherwise, maybe the interpreter/player has
decided to override the default status line style, but doesn't know
that I am going to be using these other styles, so that there will be
a glaring mismatch.
-JDC
Ben Cressey
> rooms red and visited ones white. But let's say, instead of the
> either/or property "visited", we want to color the room according to
> "% explored". As you look under and behind every piece of furniture
> in the room, the explored % rises, and the room gets whiter in the
> compass rose.
>
> Per vw, this would require a large CSS file.
Well, it would require one style per color step, or at most 100 styles
if every 1% increase was represented visually.
100 styles in a text file is not unreasonable, provided that the
development tools can generate that file automatically. I agree that
it would be too cumbersome to bother with if the author had to
implement it by hand, and that it would be unfortunate if Glk went
from making the use of so many colors impossible to unreasonably
difficult instead.
The intent behind the Glk style model design is to enforce semantic
meaning for text styles. That is, the author can say that such-and-
such a style should be "red" or "blue," but they must also identify it
as a "heading" or "pre-formatted text." This is to allow for a
variety of implementations, including a spoken rendition, where colors
are not available but changes in inflection are.
This is why zarf has said that he wishes Glk had not two user-defined
styles but zero. It is provocative statement but illustrates the
point. An arbitrary, user-defined style carries no semantic meaning,
at least not without requiring the library to guess the author's
ultimate intent.
I believe this is also why he is opposed to the idea of inline
styles. They would be easier to use and easier for everyone to
implement, so they would assuredly supplant the static, structured
model, to the point where it might as well not exist at all. It takes
a lot more discipline and requires authors to accept the unpleasant
truth that their vision of the work might be compromised in the name
of greater accessibility.
The trend in HTML has been toward greater and more rigid structure.
Web designers lose a great deal of flexibility in adhering to strict
standards, but they also simplify access issues and ensure greater
cross-browser compatibility by doing so. I suspect very few of the
authors in this thread who privilege authorial control above all else
would welcome a return to the bad old days of the Web, when Internet
Explorer was king and tag soup was the name of the web design game.
By demanding the unconditional flexibility of the Z-Machine, that is
effectively the direction you would take IF.
Roger
you draw without first comprehending that are thereby invalid. Text is
just one of many visual mediums an artist can use to convey a story. I
am not playing word Games here. Text insofar as the word is being used
here is necessarily graphical.
Roger
tell his story however he wants and has no moral obligation to modify
his product for "accessibility" as you seem to be arguing. I don't
disagree that a wide audience can be attained by allowing the client
more freedom (and I must reiterate that while I philosophically
believe the artist should have full control over presentation, I don't
agree that it is practical) there is absolutely.no moral obligation
for the author to do so.
And while you haven't used the word "moral" you seem to be arguing
what an aither should or shouldn't do so you are basically suggesting
a "duty" of some kind here to appeal to the broadest spectrum. it is
up to the author.
Snacky Pete wrote:
> On Thu, 3 Dec 2009 00:24:52 -0800 (PST), Roger
> <roger.h...@gmail.com> wrote:
>
> >Ideally, the author in any medium should have full control over
> >presentation. This may sound especially callous, but so what if you
> >have blue-green colorblindness?
>
> This is indeed especially callous. This whole thread is disturbing
> me. Interactive fiction is one of the very few game types that people
> who are visually impaired can actually play. Now were're saying "I
> have my rights to change the medium itself so that it conforms to
> whatever the hell I want to do." Up till now, the limitations of the
> medium automatically enabled people who are severely visually impaired
> to employ screen readers so that they could play along. I expect
> that, since I was last involved in this, screen readers have advanced
> along with everything else, but we seem to be going out of our way to
> befoul this. Why?
>
mwigdahl
> The intent behind the Glk style model design is to enforce semantic
> meaning for text styles. That is, the author can say that such-and-
> such a style should be "red" or "blue," but they must also identify it
> as a "heading" or "pre-formatted text." This is to allow for a
> variety of implementations, including a spoken rendition, where colors
> are not available but changes in inflection are.
>
> This is why zarf has said that he wishes Glk had not two user-defined
> styles but zero. It is provocative statement but illustrates the
> point. An arbitrary, user-defined style carries no semantic meaning,
> at least not without requiring the library to guess the author's
> ultimate intent.
>
In the main window this is a good argument, but I'd argue that trying
to map the status line to a document-based semantic style model is
questionable. And without the flexibility to easily specify color for
what are almost always used as UI enhancements (inline keywords,
status line indicators, etc.) the alternative is to hack, which I'd
argue compromises both aesthetics and accessibility.
Take a look at the source for Eric Eve's Exit Lister extension. The Z-
machine section is straightforward, highlighting unvisited rooms in a
color that can be modified under user control. The Glulx version, on
the other hand, doesn't use color -- it capitalizes the unvisited
rooms. In either version you can bracket the direction with a user-
selected character symbol, like '+' or '=', and he specifically calls
out non-color-supporting Z-code interpreters like Gargoyle as the
reason why he had to do this.
Is a screenreader going to distinguish a fully capitalized word from
an uncapitalized one written in the same style? Are the symbols going
to be interpreted and spoken in any kind of reasonably aesthetic way?
(These questions aren't rhetorical -- I really don't know)
Probably the optimum approach for a visually impaired person playing a
game that uses Eric's extension would be to forget about the status
line display entirely, and add an option to enable or disable a rule
that lists the exits every time the room description was printed.
This would be very easy to do. But if you are going to support this
option, which would be great, there shouldn't be a problem in also
offering an option to provide flexible color choice for the status
line exit display in Glulx for those that want it. Those colors in
the status line _do_ have semantic meaning; they're just not easily
mapped to the One True document-based style model.
Matt
Ron Newcomb
> if every 1% increase was represented visually.
I can construct arbitrarily more elaborate examples. The general idea
is using shades of color to correspond to a numeric game variable.
Since there's 3 primarily colors (presuming you're neither colorblind
nor a tetrachromat) I can stuff 3 orthogonal variables into a single
color. This would be ideal for conveying finer gradations of NPC mood
without resorting to hard numbers which are susceptible to meta-
gaming.
> The intent behind the Glk style model design is to enforce semantic
> meaning for text styles.
On that, the % explored is, in a way, a single semantic meaning. The
exact color changes, but the shades are collectively used for a single
purpose. But I don't see how the proposal allows for a single
semantic meaning's presentation to be varied like that at runtime.
And even if it did, that semantic style appears about 8 distinct times
on the compass rose, a different shade each time. So does the
proposal allow for, well, distinct instantiations of the same style?
I think this is what vw meant when he offered bribes for the HTML
style tag -- he was asking for parameterized styles to support the
above compass rose.
Furthermore, dovetailing off JDC:
On Dec 3, 12:17 pm, JDC <jd...@psu.edu> wrote:
> But I see this as a potential problem with static styles vs. being
> able to alter text attributes programmatically. What I wanted to do
> was say "print everything the same way as the rest of the status line,
> but change the text color to [green/yellow/red]".
It is useful to the author to be able to ask the interpreter "what
does this user prefer?" and extend that. I don't see anywhere in the
proposal for allowing information to flow in that direction. (Is it
already in there somewhere, like, Glk can do this anyway and I just
don't know it because it hasn't been exposed in the authoring tool(s)
I use?)
While I am sympathetic both to Aiken & co.'s author-knows-best
mentality as well as the visually-impaired user's author-doesn't-
consider-everything exception, and even to Gene's hardline my-computer-
my-rules, it is perfectly possible to navigate a central course here
and work with the player's preferences, rather than both author &
player shouting "my way or the highway" at each other. It requires
1) the game/CSS can interrogate the interpreter, and 2) the game/CSS
can then programmatically set the just-in-time compromising styles.
Am I missing something here?
> An arbitrary, user-defined style carries no semantic meaning,
> at least not without requiring the library to guess the author's
> ultimate intent.
I presume the Preferences of the interpreter would list the particular
game's included styles, even if it an autogenerated name like, "this
game's red/italic/strikeout style shall be rendered as...: " Granted,
that would include silly stuff like "render Bold text as.." and
defaulting it to bold text, but I don't see why the author should be
required to *name* all that stuff.
> requires authors to accept the unpleasant
> truth that their vision of the work might be compromised in the name
> of greater accessibility.
See, I'm fine if a player wants to override what I think is best --
after all, I can't think of everything. This actually relieves me the
author of the burden of having to account ahead of time for every
single idiosyncracy of hardware ability and human disability.
> I suspect very few of the
> authors in this thread who privilege authorial control above all else
> would welcome a return to the bad old days of the Web, when Internet
See, I'm missing your point here. These authors make artworks, not
information tools. Does Jim Munroe's _Everybody Dies_ lose something
for blind players? I believe so, but in such a case there's nothing
to be done about it. Artworks are allowed to be hit-or-miss in a way
that websites are not.
James Jolley
One of the most reasoned postings i've seen in a long time regarding VI
access. As a blind mac user myself, Andrew and the other folks have
gone out of there way to assist and make there products accessible.
Even game authors have considered accessibility, Aaron is one who
certainly accomodates where possible.
This CSS styling issue does concern me, but i'm just reading along and
monitoring. If the IF systems/terps become unusable for me, i'll be
leaving the community indefinitely.
Best
-James-
vaporware
> > I think what Aaron and Jeff were getting at, if memory serves, was that
> > it would be useful to start at the front end, by contemplating what
> > authors will want to do, rather than by starting at the back end. When
> > the discussion centers on the design of a CSS-based system (or any other
> > type of system) without consideration of how plain old authors (who
> > don't know CSS and don't want to) will want to use it ... that's just
> > the wrong way to go about creating a design specification.
>
> I think the notion of a design specification is commendable but
> somewhat misplaced in this thread. The CSS proposal is specific to
> Glk. Glk is not meant to be all things to all people. It is not
> intended as a way for authors to have absolute control over display
> elements. Actually it very deliberately chooses the opposite goal:
> offering a subset of display functionality, culled from the limitless
> set all possible output options on all possible devices.
Glk may not have been meant to be a front end for Z-machine
interpreters, but in practice, that is one thing it's being used for.
And as it stands, with or without this proposal, Glk is not capable of
providing all the features that a Z-machine interpreter wants. You've
worked on Gargoyle, and you accepted my patch that added those
features into Gargoyle's Glk library. Wouldn't it be nice if other Glk-
based terps could support those features without having to tie
themselves to one particular Glk implementation?
> The Glk spec has weaknesses, to be sure. The lowest common
> denominator approach inevitably means that some features available on
> high-end platforms will be inaccessible. This is a legitimate
> criticism, and a point of frustration for ambitious authors who wish
> to do more with IF. But it's fair to point out that this weakness is
> simply the other side of a very important strength: the ability for
> many authors to create a simple game that can run well on a staggering
> variety of devices.
>
> If this strength is absolutely not important to you, you can and
> should prepare a design specification for a new IF virtual machine
> format. You could even base it on Flash, or Silverlight, or some
> other VM that offers robust display capabilities. This may well be
> the way forward for IF. It is a commendable goal in any event.
>
> However, it is not zarf's goal. He is trying to improve the Glk spec
> in response to many years of pent-up demand. He is doing it in a way
> that is conceptually challenging and necessarily imperfect.
It's a way that deliberately ignores much of that pent-up demand. For
years, people have been saying "give me X so I can do Y", and this
proposal responds, "X isn't pure enough for my tastes, but here's Z,
which lets you do the subset of Y that I approve of, and that subset
Ought To Be Enough For Everybody".
> > The precise Inform syntax isn't important. What's important is, first,
> > that the system be amenable to a compact Inform syntax, and second, that
> > the system do -- in a highly controllable way -- the things that authors
> > will want to do.
>
> If implemented as it stands, the proposal would make it trivial to
> implement Inform 7 extensions that offer exactly the same level of
> text style support for Glulx and Z-Machine. At the virtual machine
> level, the implementations would be rather different, but at the
> author level they could be identical.
Inform 7 already offers the same level of text style support for Glulx
and Z-code: you can have bold, italic, or plain text. It's easy to be
compatible with both platforms when your options are limited to the
lowest common denominator.
This proposal would make it possible for Glulx to support all the
attribute changes that the Z-machine standard 1.0 allows, as long as
you don't mind defining 800 styles (which I wouldn't call trivial). It
would not, however, be possible for Glulx to support all the attribute
changes that the Z-machine standard 1.1 allows.
vw
Ben Cressey
> without resorting to hard numbers which are susceptible to meta-
> gaming.
I like this example. If authors are able to provide instances in a
similar vein, of valid interactive narrative possibilities that will
not be feasible under the current proposal, they may yet influence the
final product.
> On that, the % explored is, in a way, a single semantic meaning. The
> exact color changes, but the shades are collectively used for a single
> purpose. But I don't see how the proposal allows for a single
> semantic meaning's presentation to be varied like that at runtime.
It does not, in its current form. But in and of itself, the lack of a
capability is not going to be persuasive. Glk lacks many capabilities
by design.
Perhaps there could be a Glk call that allows runtime modification of
a single attribute of a single predefined style, within the scope of a
single window. This would retain the emphasis on predefined styles
and appears to be compatible with the overarching intent.
> And even if it did, that semantic style appears about 8 distinct times
> on the compass rose, a different shade each time. So does the
> proposal allow for, well, distinct instantiations of the same style?
It does. You could flag each of the compass rose letters as being in
style "compass rose" and the interpreter would handle it properly.
> It is useful to the author to be able to ask the interpreter "what
> does this user prefer?" and extend that. I don't see anywhere in the
> proposal for allowing information to flow in that direction.
This (in theory) was one of the possible uses of glk_style_measure and
glk_style_distinguish.
In practice it is difficult to distinguish what the user prefers from
what the library supports. For instance, Gargoyle allows the user to
set sound off in the ini file; if turned off, the Glk library will
return false when queried about its sound support. The same is true
for graphics support.
This is part of what I was driving for when I asked for gestalt
mechanisms for all of the CSS attributes. Then if a user did not want
custom fonts, he could set a preference in the .ini file (or
equivalent), and the library would tell the game that it did not
support font changes, whether or not that was technically true.
Gargoyle has a crude way of disabling style hints presently, again
based on a .ini value, but since it's not coupled with a gestalt test
it is impossible to tell the game whether or not style hints will be
honored.
> player shouting "my way or the highway" at each other. It requires
> 1) the game/CSS can interrogate the interpreter, and 2) the game/CSS
> can then programmatically set the just-in-time compromising styles.
I agree about the usefulness of interrogating the interpreter, but I
don't think 2 follows from 1. You could for instance have two static
styles in place, and choose between them based on the result of a
gestalt test.
> I presume the Preferences of the interpreter would list the particular
> game's included styles, even if it an autogenerated name like, "this
> game's red/italic/strikeout style shall be rendered as...: " Granted,
> that would include silly stuff like "render Bold text as.." and
> defaulting it to bold text, but I don't see why the author should be
> required to *name* all that stuff.
Some interpreters might offer that level of granularity - "here are
all the game's styles, now tell me how you want to display each of
them." But as a practical matter, if there is a defined hierarchy of
styles in place and no new parent nodes are possible, then
interpreters could just allow users to customize only the standard
styles and those values would be inherited by any custom styles
derived from that node.
E.g. you would have a "compass rose" style derived from the base
"preformatted" style. The user might have set an override on
"preformatted" style insisting on black text on white; thus your
compass rose would be displayed in black on white instead.
> See, I'm missing your point here. These authors make artworks, not
> information tools. Does Jim Munroe's _Everybody Dies_ lose something
> for blind players? I believe so, but in such a case there's nothing
> to be done about it. Artworks are allowed to be hit-or-miss in a way
> that websites are not.
Right, but when IF as a medium is predominantly text, it makes sense
to privilege concerns about the responsible use of text on the
implementation side.
It's tough to think of an example outside the field, but take Adobe
Photoshop. A graphic artist might want to create a parody of a $100
bill to print out. Depending on the verisimilitude of his creation,
the software might very well not allow him to do so, due to overriding
social concerns about counterfeiting.
It is unpleasant to be in a position to tell artists that they cannot
do something. It is not a role I aspire to. However, I can see both
sides of the issues, and I do not feel that the artist in the above
scenario has lost any essential freedom. They are still able to
create their artwork, but the nature and form of that art is such that
the preferred tool cannot accommodate it without causing collateral
damage.