Using Quixe in Web Page; Changing Font Size of Display

Greetings all.

I suspect I’m posting this in the wrong category. I’m happy to have it moved to wherever makes the most sense. I’m asking here because while this is technically about publishing a work it’s more about specifics around the interpreter. Let me provide the context. I think the context is necessary for my question to make sense.

I have a web page that will be providing some narrative around Inform 7 with embedded examples. I’m going to have the following markup in place:

<pre class="inform7-source">
  <span class="i7-string">"Exploring Inform 7"</span> by Jeff Nyman

   The Lobby is south of the Office.

   A table is here. It is fixed in place.
   A small bowl is on it.

   A piece of candy is in it.

   A professor is here.

   The professor wears a jacket.

Right below that will be this:

<div class="quixe-embed quixe-div" id="quixe-div">
    <button class="quixe-start" data-story-name="exploring" onclick="expandDiv(this)">Explore</button>

At the bottom of the page I have this:

    document.addEventListener("DOMContentLoaded", function() {
      var quixeStartElements = document.querySelectorAll(".quixe-start");
      quixeStartElements.forEach(function(element) {
        element.addEventListener("click", function() {
          var storyName = element.getAttribute("data-story-name");
          var parentElement = element.parentElement;
          var iframe = document.createElement("iframe");
          iframe.setAttribute("alt", "Inform Interpreter");
          iframe.setAttribute("src", `quixe/play-remote.html?story=/story/${storyName}.gblorb`);
          iframe.className = "quixe-container";
          parentElement.innerHTML = "";

    function expandDiv(button) {
      var quixeDiv = button.parentElement; = "30em";

This all works great. If I have my gblorb located correctly, a Quixe (or GlkOte) interface shows up in the web page and the story file plays in it.

What I’m not sure how to do is handle font sizing. Specifically, I just want to increase the overall font size of the interface a bit.

Do I just do that in the glkote.css file? I do notice that if I change the font-size property in the .BufferWindow class that seems to work on everything except the title of the game for some reason. But otherwise seems okay. Although the prompt doesn’t increase in size so it’s off-centered and still shows quite small.

I know there’s talk about style hints and things like that but I’m trying to figure out if that’s the right way to handle this. The main thing I’m trying to do is just globally increase the size of the font for the displayed Quixe/GlkOte interface that shows up for the user in my above context.

Hopefully this made sense and I’m happy to clarify more if it doesn’t.


That’s pretty much the whole answer.

I do notice that if I change the font-size property in the .BufferWindow class that seems to work on everything except the title of the game for some reason. But otherwise seems okay. Although the prompt doesn’t increase in size so it’s off-centered and still shows quite small.

You’ll notice there are other font-size statements farther down, under .BufferWindow .Input {} and .BufferWindow .Style_header {}. You’ll need to tweak those too.

(It would be nice if there were a single knob you could turn to adjust all font sizes across the board, as there is in Lectrote. This is hard in CSS, although recasting every font size declaration in percentages might work…? I admit I haven’t look at the problem in a long time.)

I know there’s talk about style hints

Style hints never worked right and I’ve been trying to deprecate them for years.

Excellent and thank you!

I was playing around with style hints a bit. Or, rather, what I should say is that I have this as the basis for many of my examples:

Include Glulx Text Effects by Emily Short.

Table of User Styles (continued)
style name	relative size	color	background color
normal-style	3	--	--
italic-style	3	--	--
fixed-letter-spacing-style	--	"#444444"	--
header-style	10	"#0000CC"	--
bold-style	4	"#336600"	--
alert-style	5	"#FF0000"
note-style	4	"#990099"
blockquote-style	--	"#FFFF00"
input-style	3	"#0000FF"

Table of User Styles (continued)
style name	relative size	justification	italic	indentation	first line indentation	font weight	color
special-style-1	6	left-right-justified	--	--	--	bold-weight	"#0000FF"
special-style-2	4	left-right-justified	true	--	--	light-weight	"#CC0000"

When play begins:
	now the command prompt is "[input style]> ".

This requires using a modified version of Quixe for it all to display. So I take your point on the desire to deprecate and I’ll work with the styles directly.

Yeah, the “supported” way to do it now (in quotes because it only works in Quixe/Parchment/Lectrote and you still need to also have style hints for other interpreters) is to tweak the CSS. I believe all JS Glulx interpreters now use <span>s for text styles, so you can attach your styling to .Style_preformatted or whatever and customize it as you like.

For example, this is from the CSS for Stormrider:

	color: var(--terp-special);

Then the JavaScript for switching between dark and light mode sets --terp-special to either #ac2216 or #ffd078 as appropriate. (Note style is used for the tutorial prompts.)

Not Lectrote, I’m afraid. CSS can only be modified when presenting on your web site.

Parchment does support style hints, so you could just raise the font size using them.

1 Like

Well, this is where the gears clash. You’ve mentioned having font-size trouble with GlkOte display in Parchment. (E.g. in this comment.) But I haven’t seen these problems with pure Quixe/GlkOte games. (The bug mentioned in that thread turned out to be with DOM events, not CSS.)

I haven’t dug into it, but I think the problems comes from the way Parchment tries to implement the stylehint model in the DOM. Which are inevitable, because the stylehint model is just fundamentally inadequate for describing span and paragraph styles. (Not to mention fonts, themed colors, and anything else you might want to do with CSS.)

Heh, that’s right, I have warned against changing Parchment font sizes through CSS. It mostly comes down to background colours though, so if you don’t use any of them, then I think it should be safe to change font sizes.

HTML/CSS is arguably too smart for Glk. It lets you change a lot of text metrics, which is good in general, but it’s very hard to just fill in the background colour for a line. And even that wouldn’t matter most of the time, if it wasn’t for ASCII art like the jigsaw pieces in Jigsaw.

I’ll admit, I’ve been continuing to hope that the garglk_zcolors extension catches on everywhere. It seems to be pretty widely accepted now that “subheader” is glk-speak for bold, “emphasized” for italic, and “preformatted” for fixed-width, and those three cover the majority of the text styling used in classic Infocom-style games…apart from color. (And centering, but that’s never been universally supported.)

For the most part, a convention that User1 and User2 are somehow distinguishable from Normal (maybe via underlining, maybe via two distinct colors that look good in the current theme) would take care of this too, but speaking as someone who’s partially color-blind myself, I still miss the ability to print numbers in a HUD in red, amber, green for quick reference.