If you’re talking about the garglk zcolors and reversevideo functions: those are only meant for Z-Machine support. I cannot imagine that they would ever make it into Glk proper, and I certainly don’t intend to push for them.
Glk supports true color in every one of its eleven styles. The issue is quantity, not quality.
At the moment my feeling is that Glk doesn’t need to move the style limit for the purposes of Z-Machine compatibility, because that is a problem that can be solved at the library level.
That leaves the Glulx-format IF author who just wants custom color #3 on the screen in something of a pickle. The question is whether they want that color for color’s sake, or whether they want it because their control over other elements of typographical style is so limited that color is the only way to distinguish text.
I think the latter case holds for most authors, and if that’s true then I see HTML + CSS as the only reasonable way forward.
Sure, but there are parts that aren’t optional (windows, streams), yet are redundant for an HTML-based interpreter.
Well, the issue I have in mind is that games running on Guncho (or IRC, the Linux console, Floyd, or some other non-HTML platform) will be unable to take advantage of cross-platform style features because the only way to use them in Glk is platform-specific (calling into JavaScript). A well-written extension can, at best, disable those features when running outside of a browser. To actually support them outside of a browser requires a standard way to use them that isn’t tied to JS.
We can’t assume that it’s possible to change the style of text that has already been printed. It’s possible in a browser, and in a full-screen console terp that has a sufficiently complicated screen buffer, but not over Guncho/IRC/etc.
Solved at the Glk library level by hacking in library-specific extensions? I’m not sure why that’s preferable. Surely at least it’d make sense to standardize these extensions so they don’t have to be reinvented by every Glk library author who wants to support the Z-machine.
Well, it’s more than that. I’d say there are two blocking issues and one major issue that can be worked around:
There aren’t enough styles.
If at some point in your game you want to show various combinations of bold, italic, underline, and a handful of colors, you won’t even be able to predefine the styles because there aren’t enough slots.
Styles can’t be changed without recreating the window.
This means you have to predefine all styles you want to use in the game. If issue #1 were eliminated, this wouldn’t be a problem for games that only need semantic styling: even predefining a few hundred styles isn’t unreasonable. But it is a problem for games that use color for color’s sake, e.g. for drawing ASCII art or for printing the temperature in a color mixed between blue and red according to how warm it is. Predefining 16.7 million styles to gain access to the full color spectrum is not reasonable.
Styles have to be referenced by name/number.
If issues #1 and #2 were eliminated, this could be worked around by making the game do a lot of silly, inefficient bookkeeping to keep track of which style combinations had already been allocated… or by assigning a new style for every piece of text and bogging down the interpreter with a lot of duplicated styles. But HTML has , so why not let the game take advantage of it?
The problem is that the CSS-based fork of Glk as described here is still missing a very basic style feature from HTML.
The API extensions are trivial. I know you know that because you added them to Gargoyle in the first place. All of the complexity is library-side: switching the library into a compatibility mode so that the appropriate colors and styles are set and retained when clearing the screen and such. So much of that is tied up in implementation specifics that I don’t see how it could be standardized, and Glk is not meant to force implementors to jump through hoops to accomodate niche use cases.
I can see the value in documenting the discrepancies between the Glk screen model and its styles versus those of the Z-Machine, to help other library implementors who want to add Z-Machine support. But realistically that support is always going to be done in cooperation with the interpreters, which need to be Glk-aware to at least some extent.
Well, you can call it a problem or you can call it a deliberate design choice; it is not an accidental omission and I do not expect that zarf will change his mind.
There are other options for the author who wants more control over output. I don’t think Glk needs to compete with them in terms of discarding player preferences as a meaningful constraint.
I don’t think the Glk library needs a compatibility mode; the interpreter can take care of things like resetting the styles after clearing the screen. My intent is not to add a special Z-machine mode to Glk, but to add a general feature that would enable richer styling in Glulx as well.
The API extensions I came up with for garglk were indeed trivial, but they’re incomplete. For one thing, they only cover colors, and ideally the same control would be available for all styles. For another, they’re not part of Glk’s gestalt and dispatch systems, so they’re not available to Glulx.
I call it both. This functionality has been left out intentionally, and that causes a problem for authors of games and interpreters who have to resort to hacks (like my garglk functions) or simply abandon ideas that aren’t compatible with zarf’s philosophy.
zarf is clearly set on preserving a strict separation between semantics and style that is almost universally recognized as impractical (hence the “style” attribute in HTML). I don’t expect to change his mind, and I don’t think I need to: this is exactly the sort of thing the extension mechanism was meant for. If this functionality is standardized as an extension and implemented in the popular Glk libraries, that’s almost as good as having it in the official spec.
In the past, there’s been some discussion about additional ways to implement dynamic styling in a way that respects player style sheets, such as fading between two predefined styles, but those were rejected as well. I’d be happy to consider them again if someone wants to join me, but if I’m going to be writing all the patches for the major Glk libraries myself, I’m going to go for the less complex option.
As for these other options besides Glk for the author who wants more control over output… what are they? If you write a Glulx game, your only choices are Glk (which only offers this additional control when running inside a browser) and FyreVM’s channel system (which expects to be embedded in a custom application that will do all the heavy lifting). Are you suggesting that authors who want to escape this limitation should abandon Glulx/Inform and write in TADS, or maybe a homebrew engine? Is it reasonable to ask authors to give up the whole Glulx/Inform ecosystem just because they want to take advantage of such a basic styling feature?
They don’t need to give up Glulx/Inform; they just need to target an interpreter that offers HTML windows and programmatic access to styles via JavaScript. Or more likely, they need to use an extension like Vorple that is HTML-only but exposes a lot of other functionality that they also want. It’s reasonable to expect authors to jump through that particular hoop.
That basic styling feature is not compatible with player control over output. That’s OK in the context of the Web, where almost no one expects to have that control. It’s different with desktop interpreters. The proposed solution strikes me as a happy compromise: players and authors each get a platform where their preferences can be binding.
I disagree that it’s reasonable to restrict your game to running inside a browser just so you can take advantage of a styling feature that already exists in other real-time text systems outside of browsers.
Guncho is arguably the most appropriate medium for fancy color tricks – using color to provide an extra layer of information at a glance is something MUDs have been doing for years, far more than typical IF – but this proposal is incompatible with anything like Guncho.
That control has been available on the web for a long time, through user style sheets as well as plugins like Greasemonkey. If you want to change the styles on a web page, or stop it from using dynamic colors, you can do that. But the truth is, few people want to.
Frankly, I suspect it’s the same with IF. Is there really a mass of players who will be offended by a game that shows a few bits of text in a color that can’t be configured? Even if so, why is excluding that feature from the platform a better solution than social conventions like beta testing, asking authors to provide in-game options, and not playing games you don’t like? Why should it be impossible to write those games on an appropriate platform just because some hypothetical fraction of players might not want to play them?
Except they’re separate platforms, providing different features, useful for different purposes, and reaching different audiences. One is not a substitute for the other. This is like telling phone developers that some bug in iOS or Android isn’t a problem because they can always write a desktop app instead.