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.
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…
/*************/
/* DROP CAPS */
/*************/
/* "drop caps"/"initials" (https://en.wikipedia.org/wiki/Initial
https://wiki.obormot.net/Reference/DropCapsDemo) are large fancy
block letters used to start a page/section.
The 5 drop-caps right now are Cheshire ('drop-caps-cheshire') (https://www.dafont.com/cheshire-initials.font), Goudy Initialen (https://www.1001fonts.com/goudy-initialen-font.html)
('drop-caps-goudy'), yinit (https://www.tug.org/TUGboat/tb12-1/tb31hara.pdf#page=8) ('drop-caps-yinit'), Kanzlei Initialen ('drop-caps-kanzlei') (https://wiki.obormot.net/Main/BonusFontsDemo?demo_font_one=Kanzlei+Initialen), and
De-Zs/Deutsche Zierschrift (https://www.typografie.info/3/Schriften/fonts.html/deutsche-zierschrift-r250/) ('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-']::first-letter,
*[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::first-letter,
.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);
}
Alrighty!
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:
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:
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.
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
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?
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.)