The Glulx Image Centering extension does it by hinting that style User1 should be center-justified, then switching to that style before printing the image. So it depends on the implementation of text justification.
One could reliably center text, with effort, by switching to a text grid screen. But with less effort you could add the text to the image itself. (I’m not sure in practice how good terps are about respecting alt text, though.)
Regarding the fact that style hints are no longer supported, what about those released works that already use them? They ought to be supported, even if there might not be many. (And some are quite important, like Counterfeit Monkey).
It seems that Windows Git (the interpreter; ifarchive zip link) works for both image and text centering, so maybe you could recommend that for Windows users.
In Windows Glulxe, image centering seems to work, as well as the text centering method that Draconis mentioned above, using the special user style from Glulx Image Centering (which comes from another extension, Glulx Text Effects), whereas the method from Basic Screen Effects doesn’t seem to work.
So if you use the text centering method with “special-style-1” instead of the method from Basic Screen Effects, you could probably recommend both Windows Git and Windows Glulxe, for the moment.
In contrast to that, in Gargoyle, only the method from Basic Screen Effects works.
Figure of Stonechat is the file "stonechat_small.jpg".
Include Glulx Image Centering by Emily Short.
Include Basic Screen Effects by Emily Short.
The Lab is a room.
When play begins:
display Figure of Stonechat centered;
center "Centered by Basic Screen Effects";
say line break;
say "[special-style-1]Centered by special-style-1 from Glulx Image Centering[roman type]";
pause the game.
Windows Glk and Windows Glulxe should behave identically. Basic Screen Effect’s centring method is based on measuring the screen using the current fonts, and printing indenting spaces, so I think it’s the different font choices you have in Windows Glk vs Glulxe that is causing the difference you’re seeing. The monospaced and proportional fonts would need to have similar metrics for BSE’s approach to work. It’s unreliable and not really recommended.
If the interpreter supplies good defaults (making them all distinct), I think it should be okay for most works: it’s not a huge change to the Counterfeit Monkey experience if User2 is green instead of blue, for example, as long as it’s distinct from Normal.
In my experience, the styles are generally interpreted as:
Normal is roman type
Emphasized is italic type
Preformatted is fixed-width type
Subheader is bold type
Conveniently, these are the four inline styles that the Z-machine supports.
Header, Alert, Note, BlockQuote, Input are occasionally used by the library but otherwise ignored; I know I’ve repurposed Alert as “extra emphasized” (bold italic) and Note as “de-emphasized” (lightweight) but never made much use of this at all.
User1 and User2 are used for different colors the game needs, like in Threaded Conversation. I think Blue Lacuna used this for keywords in the text also?
So if the default is roman, italic, fixed-width, bold, [anything really], and then two different arbitrary colors, I don’t think removing style hints will cause noticeable changes to most games. The one thing the Z-machine can do that Glk can’t is fancy colors, and the Garglk color extension seems to be catching on to cover that need.
While the User1 and User2 styles aren’t enough to do something like Photopia (without closing and reopening the main window several times), it does seem true that most games can get by with only a couple special inline styles (e.g. “this is an interactible keyword” and “this is an error message from the parser rather than the simulated world”), and any way of making them distinct will have pretty much the same effect. So while I was originally skeptical, over the years I’ve slowly been won over on them.
The one thing style hints are really necessary for, then, is messing with text justification. Hence this thread. And this seems like a generally different use case than the rest of the style system. A convention to make, say, Header style centered could work (since that’s not a style that’s generally used inline), but I suppose it would come down to how much centering is really used in text windows (as opposed to the status window), and for what purposes.
Ah, you’re right! When I set Git to the same font settings, it looks the same as Glulxe (i.e., the Basic Screen Effects line is not centered). I had thought that the difference maybe wouldn’t matter, because Basic Screen Effects uses a fixed-width font for the centering, but apparently it does matter, as you said.
So, the recommendation for the “special-style-1” centering method is strengthened.
I don’t know of any interpreters which assign colours to user1 and user2, and I don’t think it would be safe to do so. Games normally assume that they begin with no stylehints, and so don’t go to the trouble of resetting them.
Ah, so something like Lectrote? I could kind of see the sense in making user1&2 two colours. But that won’t help when someone wants to use it to centre text, set monospace, etc etc. I don’t think it would be reliable enough improvement.
Surprisingly there’s no gestalt for whether stylehints are supported.
Yeah; this is just idle musing about what functionality we would lose by getting rid of style hints. Text justification being the big one; making a special type of monospaced text (maybe colors for a fancy ASCII map?) is another one I hadn’t thought of. (EDIT: But that of course can be compensated for with Garglk color.)
In general, the way I’ve seen User1 and User2 used for actual text (as opposed to images), I think it would be fine to not be able to specify their style as long as they’re somehow distinct from all the other styles (hence color). But I can imagine someone using them for three different types of monospace too.