FYI I’ve added a demo for the layout bug I’m encountering to the github issue I made a while back for centred images.
This also includes links to run in both Quixe and in Parchment. Interestingly they each have different bugs for the text in the centre navigation window in demo2/demo3.
All three demos behave as expected in Glulxe/Git.
The broader issue here, which I’ve been dancing around for years now, is that there’s no good compromise between (Z-machine) “here’s a tiny TTY device / fixed-width grid” and (Twine) “you got a damn web browser, everything is HTML and CSS, jQuery is installed, you’re on your own, pal.”
There may exist a sweet spot in between those extremes. I even have some notes on finding it[1]. What’s certain is that the stylehint API that I came up with in 1997 (for Glk/Glulx) is not that sweet spot. It’s terrible and almost completely useless, for a variety of reasons[2]. If there were a better option, it wouldn’t be compatible with stylehints as they exist today (to the extent that they exist today, which is not all that much). [3]
So, with apologies, no. Stylehints ain’t coming back. The answer to the question about Glulx Image Centering is that Glulx doesn’t support image centering.
Now, I realize this is a frustrating answer on at least two axes:
Legacy Z-machine support is a real use case and Parchment wants to do it. Extending Quixe/GlkOte for Z-machine features (primarily color) is a reasonable thing to do. Those changes aren’t going to be absorbed back into the spec, but they can exist in Parchment and Lectrote as a separates set of files.
Stylehints can’t do much but they can do centered text and inline images. As we see, people rely on this feature already, or want to. As a narrow use case, it’s pretty high return for a small amount of effort and complexity.[4] So there’s an argument for keeping that much of the old API un-deprecated.
Sorry about the long and inconclusive rant. :(
Footnotes, because I’ve been turning this over in my head since last night…
(1: Although that notes file has a last-touched timestamp of February 2012.)
(2: At a quick glance: Stylehints can only deal with integers. So no font names, no units on dimensions, no fractional numbers, for a start. Also, stylehints don’t encompass the difference between block (paragraph) and span (letter) styles. So no way to represent italics in a centered paragraph. Still less any fancier layout such as toolbars, menus, full-layout status windows, etc. More abstractly, stylehints are way too crude to balance the requirements of interpreter style control (app-wide font preferences, window size, etc) with the requirements of the author/designer. When I wrote down the initial ideas, I handwaved a lot and said “compromises are possible”, but there was never any plan for actually doing it.)
(3: The better way which exists today is Vorple, which I think demonstrates my point – it works by letting you get at the HTML/CSS directly.)
(4: To dig into this a bit: text centering does not clash with interpreter preferences/typography the way per-span color text does.)
Since you mentioned control over HTML/CSS: the nice thing with stylehints is that they allow to style a game in Quixe with custom CSS, but since Glk only gives 2 custom styles, it limits the ability a bit.
So an enhancement would be to have an unlimited number of custom styles (which would act more as markers or HTML classes) for the sake of Quixe CSS customisation.
But aside of this, well, I see why the style hints aren’t coming back.
As I understand it, the principle behind the stylehints seems sound – having a set of standard classes that allow semantic overrides. It just perhaps could have done with more flexibility in defining additional custom styles, and perhaps a better separation between paragraph styles and inline styles.
Saying that CSS/Vorple solves it better doesn’t seem entirely accurate, since there are more terps that don’t support CSS than ones that do, and it’s a pain for authors to try to support two different kinds of styling systems in the same story – unless you choose to sacrifice the blorb output entirely and go browser-only (which the standard templates don’t support, and seems to run counter to the spirit of IF).
But either way, things need to be layered carefully – the terp needs to provide defaults for the styles that the story can override, but in turn be able to override the story’s settings based on explicit user preferences (e.g. for users that need or prefer high-contrast).
3.5 years ago I suggested adding a subset of the larger CSS Glk proposal. It would be worth thinking again about what the simplest addition that would move us forward would be. Just increasing the number of styles would be pretty easy, though the CSS proposal had the advantage that named styles would be additive, rather than substitutive like the numbered styles are. But, we could do both! Worth considering.
And Zarf, I don’t think we have to say that stylehints aren’t coming back, I’ve almost finished implementing it for GlkOte. (Except measure/distinguish, ugh. Maybe those ones won’t come back.)
I do like the idea of additive styles. Have the base set of semantic styles be predefined and not extensible (though each terp can have its own default presentation of those styles, or multiple themes).
The next layer is that the story author can impose specific overrides on these predefined styles (“all note text should be green by default”). This would rarely actually be used.
Then on top of these the story author can define any number of extra custom styles that all chain to a base semantic style (“normal story text, but bold and blue”, for example, or “blockquote, but green”), where the base style is inherited from the terp’s defaults and the story-based overrides. The chaining could be indirect, e.g. they can define a “bold-blue” style that inherits from the “bold” style that inherits from the “normal” style.
Finally, the terp gets a last chance to re-override anything, to force a style (e.g. for high contrast), though it should usually only do this according to explicit user preferences.
(Though this discussion is derailing this thread a little.)
Latest update: I’ve added support for paragraph stylehints and the demo1 test seems to be working properly.
There’s still some weird stuff showing up in the 2nd and 3rd tests.
2nd test: the text is showing up, but the contrast isn’t great because there’s only a stylehint for the background colour (which becomes the foreground colour when it’s reversed.) Is that colour coming from the Gargoyle background window padding though? Because it shouldn’t apply to a grid window…
3rd test: I really have no idea. If that’s happening in the original Quixe too then it’s probably not my fault. Only had one idea: are you focusing the main window before requesting char input? It’s legal to request char input on a grid window, but it might make it more confused.
Yeah, the layout bouncing is a Quixe thing. Parchment had different colours in demo2 from Quixe but actually it was the only terp that appeared to show a colour at all – in the IDE and in Git the “reverse” seemed to win over the “background colour” and it still appeared white on black. I’m not sure which behaviour is more correct; neither one was entirely what I was expecting.
You can see the source text for those demos; demo2 does write to the main window last, while demo3 writes to a different buffer window “as the acting main window”, but does still write to this last before accepting input. The original main window has been completely covered, although not explicitly closed because it wants to preserve the content.
The specific window arrangement is main window -> popover window (placeabove, proportional, 100%) -> graphics window (placeabove, proportional, 75%) -> navigation window (placebelow, fixedsize, 1). It’s possible there’s something dumb about that arrangement, but it does seem to work outside of the browser.
Ah, I hadn’t realised that it was using popover windows. Yes I remember Quixe used to have trouble with them, and I doubt anything has been done to improve support for them since I last tried it years ago.
Popover windows are kind of hacky, but I’m pretty sure they’re legal by the Glk spec. I think it’s just Quixe in particular that has trouble with them. I don’t know if it’s Quixe’s “More” feature that is causing trouble in particular. I never particularly liked Quixe’s “More” system (I preferred the old Parchment way of printing everything but just having it scroll to the top). I could try changing over to that system, but I don’t know what it would take.
I’ll have a look at the source code for demo2 and try to figure out what’s going on with the colours.
Edit: So I checked how demo2 runs in Windows Glk, and it is correctly displaying the background colour reversed as #b7dfed on black. It’s just hard to tell. And with subpixel rendering it’s only exactly #b7dfed on the horizontal strokes.
And it looks like you’re doing the right thing with the popover window in demo3, so yeah, no idea what to do with that.
They’re legal, but when you change the height to 1, you get into edge cases when it’s trying to deal with scrolling. (Scrolling is, almost by definition, a big pile of edge cases…)
It wouldn’t be unreasonable to add yet another special case to the Quixe scroll code to improve handling for squashed windows. (I suppose “windows whose height is less than one text line”.)
Hm. This is what Quixe does, though – all the text appears, the scroll position is set to the top, and it adds the “more” flag as a div with position:absolute. Then it captures keystrokes and treats them as “page down” until all the text has been seen.
(You can test this at Quixe – type ALL to generate a lot of text and a “more” prompt.)
You are of course correct. Not sure why I thought it wasn’t printing everything.
The measurement of 1 (which is 1 whole row, BTW, so it’s not a “squashed window” or “less than one text line”) applies to the text grid “navigation window”, not the main popover window. Which shouldn’t be controversial as that’s the exact same thing that the status window does.
Also text grid windows aren’t supposed to have scrolling anyway – although I note that during the layout bouncing, one does appear in that window, so perhaps that’s part of the bug.
The weird thing though is that this is showing the MORE when there isn’t any hidden text; everything fits on the screen. It’s just continuously bouncing between scroll and no-scroll.
Oh, sorry, I misunderstood. Yes, a one-line grid window should work entirely without problems.
I’ll see if I can take a look today.
iplayif.com doesn’t yet include any of these enhancements; as far as I can tell, those enhancements were only visible in the IFComp online player, and that was only available while IFComp was running.
May I request that we push these changes out to iplayif.com?
(Why does IFComp even have its own, separate player? Wouldn’t it be better if it just used iplayif.com, so IFDB would benefit as well?)
Sorry, yes, it is my next priority, when I’m in a good programming mindset.
I rewrote Parchment essentially from scratch, implementing just enough for the Inform 7 template, as well as for IFComp. Both of those use hardcoded gamefile URLs. The full Parchment will also need support for arbitrary cross-domain URLs, sometimes using the proxy server. It’s not too much work, so hopefully I’ll get it done in the next week or two.
Would you expect that IFComp will need/use its own custom player again next year? Or would it make sense to have IFComp just use iplayif.com like everybody else?
I think because of transcripts it needs to be a standalone version. It also makes the IFComp set easier, as it already has to support arbitrary HTML that entrants upload, so the comp interpreter code is designed to only create an index.html if it doesn’t already exist. We could probably make it work to use iplayif.com, but the benefits would be minimal.
What would it be like to ship stylehints to Lectrote? It looks like Parchment is using a pretty big fork of glkote right now. Would you have to do a bunch of work to prepare a PR back to @zarf’s repository?
(Zarf, would you even accept a PR that brought stylehint support to mainline glkote? Your remarks in this thread from last year, “Stylehints ain’t coming back,” seem to indicate that this wouldn’t/shouldn’t merge…?)
That’s an open discussion between me and Zarf, but other things have been priorities. I definitely would like to stop maintaining a separate fork if possible.
Well, to that, I’ll just say this. Here’s a list of top-ranked Glulx games on IFDB that I believe use stylehints (or, at least, they’re styling text, especially with color, in a way that doesn’t render correctly on iplayif.com or in Lectrote).
Literally most of the top-rated Glulx games have text formatting “bugs” in Lectrote. (And even if a newer, better alternative to stylehints were invented, it’s not the least bit clear that these games would/could be updated to use the new thing.)
Therefore, I recommend that Lectrote be updated to support color stylehints.