For the first one, add imagealign_Block as an option for val1 when displaying images in text buffer windows. This would display the image centered horizontally in its own paragraph. (Being its own paragraph means we don’t have to worry about how text wraps around it, or the centering interacting with other things.)
For the second one, Glk could simply recommend that a library that doesn’t support style hints should make style_User1 and style_User2 distinguishable from all other styles. It’s then up to the library how that should happen. In Gargoyle I can make one of them red and the other blue, for example, or a screen reader could change its pitch. This will take care of things like Threaded Conversation (which puts topic names in style_User2 to highlight them): the highlighting may not look exactly how the author wanted, but the semantics are maintained (just like if the interpreter decided to default to a serif font when the author hoped for sans serif).
Would this create any problems? It seems to me like a reasonable way to replace the main uses of style hints, while waiting for the upcoming CSS extension.
It’s tough to say what the best way forward is. Zarf long ago said the stylehint system was deprecated, but AFAIK he’s not close to providing his CSS plan.
In the mean time I added stylehint support to GlkOte (though it’s not in Lectrote), and I’m much closer to getting my CSS plan working; I could have a test version working within a week or so, but I intend to work on other things first sorry. (Working out a plan for autosaves is trickier and slightly more important to me for now.) (Also, I haven’t worked out the security implications of custom CSS on iplayif.com, which I want to do before enabling it.) My CSS plan is a generalisation of the stylehint system rather than replacement of it.
Adding an imagealign_Block option could work, but it wouldn’t necessarily be very simple. I suspect that adding support for it, for example, in Gargoyle might take just as much time as just adding support for the justification stylehint in the first place.
As to making user1/2 distinguished in interpreters that don’t support stylehints, it would probably help with some games, but would probably make the experience worse in others. Maybe someone could do a survey of Glulx games to see how they use user1/2?
I’m also vaguely interested in making a version of Parchment with Tauri, so there may be a Lectrote alternative eventually.
I’d imagined it would be a fairly straightforward extension of the margin alignments, which seem a lot more complicated (text has to flow around it). Are there other complications I’m not considering, that make it harder than just extending a margin image all the way across? (Probably.)
There is also a bunch of interpreters and games (Level 9, Magnetic, ScottFree etc.) which use glk_style_measure() to make the background colour of the graphics window match that of the text window below. More precisely, they use it to get the background colour of the normal text style, which tends to be the same as that of the entire window. If the style hints go, that won’t work anymore.
Oh, interesting, didn’t know about that one. Though I think it’s specifically style hinting that’s going away, not using or measuring the styles. (And I’m not sure distinguishing was ever widely implemented.)
Yes, of course. The API uses glk_style_measure(winid_t win, glui32 styl, glui32 hint, glui32 *result), but I suppose the hint parameter could be replaced with a corresponding enumeration called something else.
Somewhat tangential, I recall that Zarf has mentioned deprecating the left/right margin alignment of graphics in text buffer windows, too [citation needed]. They are indeed very complicated, and hardly ever used. Supporting the justification stylehint has a pleasing logic to it, as then images are primarily just in-line with the text, so you can have an image with text around it, or an image on its own, and the justification stylehint does the “right thing” in a natural way.