Transcript Annotation Tool

Okay, I’m reporting back in.

I might wind up using this library, alongside a custom-built transcript annotator to create HTML files that contain everything necessary, without needing other external files of any kind.

I’ll let y’all know if I come up with anything.

1 Like

Yeah, looks like that font is Cheshire and it’s using the ::first-letter selector on the paragraph, plus a bunch of fiddling to get the spacing right. Here’s some of their description and code…

CSS, long-ish
/*  "drop caps"/"initials" ( are large fancy
    block letters used to start a page/section.

    The 5 drop-caps right now are Cheshire ('drop-caps-cheshire') (, Goudy Initialen (
    ('drop-caps-goudy'), yinit ( ('drop-caps-yinit'), Kanzlei Initialen ('drop-caps-kanzlei') (, and
    De-Zs/Deutsche Zierschrift ( ('drop-caps-de-zs').

    Drop-caps are used to subtly 'theme' pages: Cheshire is for literary pages, Goudy is for
    historical/humanities pages, Kanzlei is for light technical/scientific pages, while yinit is for hardcore technical/scientific
    pages (if it has a lot of equations, it's yinit), and De-Zs is for everything else (such as newsletters).

    We use them on desktop & skip them on mobile because
    they use up 8-12KB each (even after @font-face subset optimization to load
    only 1 letter at a time), and take up a lot of screen space.
    (Mobile users can't have nice things.)

    To implement them, each Markdown
    page has a custom metadata field like "css: drop-caps-goudy" which is
    substituted into the compiled HTML like
    '<body class="pagename drop-caps-goudy">', allowing defining of multiple
    drop-caps and customized per page. The body class then is read by JS
    (currently: `rewrite.js` l841, the `dropCapBlocksSelector` variable) which
    actually sets it on relevant paragraphs. It would be difficult to define 'first paragraph'
    at the start of the page correctly without many special-case pure-CSS selectors.
    (Drop-caps in arbitrary manually-specified places, like appendices or split-out articles,
    are supported by a separate 'drop-cap' singular class which can wrap either the abstract
    or a specific <p>.)
@media all and (min-width: 650px) {
    *[class*='drop-cap-'] {
        min-height: 6em;
    *[class*='drop-cap-'] > p:first-child::first-letter {
        font-style: normal;
        font-weight: normal;
        float: left;

    /*  All of these numbers are magic.
    .drop-cap-cheshire > p:first-child::first-letter {
        font-family: "Cheshire Initials";
        font-size: 6.75em;
        line-height: 1;
        margin: 0.045em 0.05em -0.25em 0;
        color: var(--GW-drop-caps-cheshire-color);


Good news: I have something that works.

Bad news: Right now, it only works from command line with Node.js, which is uh…not ideal for the average user. I gotta get this to a release stage, somehow.

Neutral news: This uses markup, so you aren’t able to just highlight text and push a button. Also, just because I’ve seen some really weird room names, you have to manually mark something as a room name for it to be formatted as such in the final result, but you can just copy and paste the “room tag” everywhere necessary, with relatively-little time and effort.

I need to create a proper set of documentation, and give this a real front-end, but it does create annotated, self-contained HTML files from a transcript!

The marked-up transcript (which I used for an input) is here:
Dreamhold.txt (3.0 KB)

And the final HTML output is here:
Dreamhold.html.txt (10.7 KB)
(Just cut the final “.txt” from the end of it, and crack it open in your browser of choice.)

(Shout out to @zarf for a fantastic game. I was too self-conscious to use my own works as target practice. If he prefers, I will swap out the Dreamhold stuff for my own work, and re-upload this.)

Supported features:

  • Bold room names!
  • Clickable text, which contains notes!
  • Spelling correction!
  • Comments from either “during gameplay” or “after gameplay”.

The differentiation for comments was important to me, because editor notes would be very different from showing the author a glimpse of your experience/reactions during gameplay.

This process is not automatic. You need to manually go over notes you made in-game, and format things accordingly. The idea here is that formatting takes very little time, and the overall result keeps things very organized, saving headaches for both parties involved.

Also, as I’ve said before, I’m very skeptical of anything which claims to automatically parse a transcript. Line breaks are not consistent, and some room names are very strange sometimes, so there’s a little too much context required for a computer to tell the different between “Taken.” and “Room That Ends Uncertainly?”, if you see what I mean.

Future plans:

  • Working front-end so people can actually use this!
  • Mayyyyybe a highlight-and-button based editor? (I’m really burnt out on UI code)
  • Mayyyyyyyyyyyyyyyyybe WYSIWYG support…? (I would need to do some stuff in a fundamentally-different way to make this work.)
  • Light mode (?) Idk, do we have any non-night owls here? I program every with dark mode by default, because I have light hypersensitivity.
  • Would screen-reader users be interested in something like this? I might need to figure out how to get this to behave with screen readers, and how the notes should be read out, particularly with spelling corrections and such…

In theory an interpreter could save a transcript with formatting included, in which case you can tell when something is a room name because it’s on its own in Subheader style. Something like RemGlk should be able to make a nice HTML-ified transcript (since converting RemGlk output to HTML is basically what web interpreters already do).

I wonder how hard it would be to mod Quixe or Parchment to output either RemGlk or HTML for a nice pretty transcript. This would be something done on the interpreter side, not the game side, because the transcripting features built into the virtual machine assume plain text and this is very difficult for a game to override.

1 Like

I’ve thought about this. RemGlk output would seem better because then you could have a variety of tools to process it into anything you wanted.

(Previously mentioned: Recording z-code game transcripts without the game's support? - #4 by zarf )


Added a Lectrote item: Feature: enhanced transcript mode · Issue #151 · erkyrath/lectrote · GitHub

1 Like

Unfortunately it probably wouldn’t work with other Glk implementations, which would mean I have to stop playing everything in Gargoyle to get the nice transcripts—running two separate Glk libraries side-by-side in the same interpreter is more of a headache than I’m willing to deal with.

But for an interpreter that’s already using RemGlk and GlkOte under the hood, it should be pretty easy to also dump every new RemGlk update into a text file (or the localstorage equivalent to a text file), right?

1 Like

I haven’t sorted out exactly how it would work, but I think Lectrote would set up GlkOte to do the dumping (with a callback to Lectrote to update a text file).

This would work across all of Lectrote’s built-in interpreters, but doesn’t help Gargoyle at all.

You could update GarGlk to do the same thing, but it would be a separate implementation. (Well, it would have to be, since GarGlk is C code.)