At the moment that will take a little bit of manual work sorry, but only a little. Copy index.html and style.css into the Parchment folder. Then convert the .glorb to a .glorb.js file with this tool (or one of these other methods) and put it in the Parchment folder, and then edit index.html to refer to it instead of "./gargoyle-text.ulx.js". All the files need to be in one folder for it to work when running locally from a file: URL.
Use ifsitegen:
It, ah, turns out that the file has to have a .ulx.js suffix or Parchment won’t like it.
I’ve found my first Parchment bug! When I resize the browser window narrower, there’s a JS console error, and the game stops responding to input.
To reproduce:
Use this base64’d JS of The Wizard Sniffer. story.ulx.js.zip (535.1 KB)
Launch the game so you see some text. Now resize the browser window narrower and press the Enter key.
You’ll see a JS error on the console:
main.js:1 Uncaught RangeError: Invalid array length
at ae (main.js:1)
at ae (main.js:1)
at Object.w [as accept] (main.js:1)
at de (main.js:1)
at _e (main.js:1)
And pressing keys in the game now just prints a console log message: Not sending repeated generation number: 2
(I’m on Google Chrome 83, on macOS 10.15.5.)
Next bug: images!
To reproduce: Use this Counterfeit Monkey. https://drive.google.com/file/d/15FxIZTbO_fz4aUw7uNafkudkXo2iU03B/view?usp=sharing
Launch the game, type “y” and then “andra.”
Expected: A map should appear on the left side of the screen
Actual: A big black rectangle where the map should be
(I encountered a similar problem with the 2018 Anchorhead release, but I can’t provide a sample copy of that, because it’s a commercial product.)
BTW, you might be wondering why I resized the browser window narrower. That’s because by default the game text is full width with teeny tiny margins.
It’s preferable to restrict the width of text to somewhere in the vicinity of 60ch to 80ch. I always link to Ian Millington’s Cheat Sheet for Better Typography for this.
I’d love it if Parchment (or at least iplayif) would offer me the sort of text preferences that Lectrote offers: fonts, zoom, color themes, margins.
I definitely want more options like that. For now this is meant to be a drop-in replacement for the Quixe template, so it will have a side bar, but otherwise use up the width of the window.
The problem with images not appearing is most likely because the blorb conversion strips the images out.
In order to get them back you need to run the blorbtool.py script, which extracts the images and generates the interpreter/resourcemap.js file.
The steps are explained in several different comments here. (Background here.)
Edit: although having said that, it appears that isn’t sufficient in this case. Trying it out on my own unreleased story that uses graphics it still doesn’t show any of them. (This appears to be that, as far as I can tell, there’s no way to set the image_info_map with the Parchment template.)
Also, the page title shows up as undefined.
Fixed the bugs that have been reported:
undefined in the page titleCounterfeit Monkey.gblorb Dan provided, though I think it should also work with extracted images, you’ll just have to overwrite resourcemap.js with blorbtool.py like you would for the old Quixe template.)I would’ve caught these errors if I’d tested a little more widely, so thank you for your patience with me!
Get the updated template from the same link in the first post.
Yep, images are working now, and layout seems to be behaving like Quixe. (Which is to say, still misbehaving on my particular story, but that’s probably something I’m doing wrong. Though it works ok in the IDE.)
Have you described those problems before? It could be that Quixe has a bug too.
Something else I’d like your opinions on is on styling. Currently this uses Quixe’s default tan-coloured status line. The new stylehints system can properly handle reverse styling in the main window and in the status window, though the stylesheet doesn’t currently enable that. I could enable it and keep the tan-colour, or I could switch to a more traditional black or dark-grey with white text. Any opinions on what would look best and be most readable? (The stylehints system will also allow for darkmodes, which I’m keen to add, but probably after IFComp.)
If you’re thinking about color themes, I think a good starting point might be the Visual Studio Code built-in color themes.
VSC’s default theme is a dark theme, but it has a handful of light themes built in; it seems intuitively right for Parchment to go with a light theme by default. Take a look at the Quiet Light and Solarized Light themes for inspiration. Look at their status bars in particular.
(Related: I don’t know whether this is required by some standard or other, but all of the popular IF interpreters I’m aware of render the status window in a monospace font. Why is that? It looks ugly/wrong.)
Well the interpreters have to use a grid window if the stories tell them to. And the stories tell them to because there’s no other way to align text. It would be possible to split the status window in two horizontally, with the left window being left aligned and the right right aligned, and then you could use buffer windows. But there’s a lack of interpreter support for text alignment (Gargoyle and Quixe don’t. Though I plan to add it to Quixe.) So it could be done, but it would be a lot of fiddly work for arguably not much benefit. Many years ago I started work on an extension to do it, but I stopped when I realised Gargoyle didn’t support it. But, maybe this can change in the future.
I don’t know much/anything about this stuff. What’s a grid window? How does right alignment (and center alignment) work in a grid window today?
A grid window is a grid of characters, with a set width and height, and therefore are necessarily monospaced. You can print at a particular set of coordinates. You can centre and right align text in grid windows by getting the window’s width and calculating the coordinates you need.
Buffer windows don’t have coordinates, you just print text at the end of the window. In theory you can change the alignment of text in buffer windows, but as I said, some intepreters don’t support it.
We could perhaps convert some of the common grid window patterns (left and right texts, a single centred text) into proportional-spaced fonts, but any custom design (adding exits, or a compass, things like that) would have to keep the grid window as is. Lots of ways to experiment, but maybe after the comp. 
Oh, and I remembered one of my ideas for a theme, which was to change from reverse text in the status window to a underline like you’d see in many books.
Speaking of stylehints: this does appear to have the same issue as Quixe, where using Glulx Image Centering by Emily Short to try to center an image in a standard text buffer window (by trying to use the center-justified hint in a special style) does not actually center the image, but leaves it left-aligned.
This technique works in the IDE terp and in Git. I haven’t tested any others.
I assume this probably needs to be fixed in Quixe. Just seemed worth mentioning.
Quixe didn’t have any stylehint support, at all. This template now has basic stylehint support, by which I mean the stylehints that are applied to individual characters, but not the ones applied to paragraphs. It probably won’t be too hard to add them, assuming no bugs come up I’ll work on that next.
FYI I’ve added a demo for the layout bug I’m encountering to the github issue I made a while back for centred images.
This also includes links to run in both Quixe and in Parchment. Interestingly they each have different bugs for the text in the centre navigation window in demo2/demo3.
All three demos behave as expected in Glulxe/Git.
The broader issue here, which I’ve been dancing around for years now, is that there’s no good compromise between (Z-machine) “here’s a tiny TTY device / fixed-width grid” and (Twine) “you got a damn web browser, everything is HTML and CSS, jQuery is installed, you’re on your own, pal.”
There may exist a sweet spot in between those extremes. I even have some notes on finding it[1]. What’s certain is that the stylehint API that I came up with in 1997 (for Glk/Glulx) is not that sweet spot. It’s terrible and almost completely useless, for a variety of reasons[2]. If there were a better option, it wouldn’t be compatible with stylehints as they exist today (to the extent that they exist today, which is not all that much). [3]
So, with apologies, no. Stylehints ain’t coming back. The answer to the question about Glulx Image Centering is that Glulx doesn’t support image centering.
Now, I realize this is a frustrating answer on at least two axes:
Legacy Z-machine support is a real use case and Parchment wants to do it. Extending Quixe/GlkOte for Z-machine features (primarily color) is a reasonable thing to do. Those changes aren’t going to be absorbed back into the spec, but they can exist in Parchment and Lectrote as a separates set of files.
Stylehints can’t do much but they can do centered text and inline images. As we see, people rely on this feature already, or want to. As a narrow use case, it’s pretty high return for a small amount of effort and complexity.[4] So there’s an argument for keeping that much of the old API un-deprecated.
Sorry about the long and inconclusive rant. :(
Footnotes, because I’ve been turning this over in my head since last night…
(1: Although that notes file has a last-touched timestamp of February 2012.)
(2: At a quick glance: Stylehints can only deal with integers. So no font names, no units on dimensions, no fractional numbers, for a start. Also, stylehints don’t encompass the difference between block (paragraph) and span (letter) styles. So no way to represent italics in a centered paragraph. Still less any fancier layout such as toolbars, menus, full-layout status windows, etc. More abstractly, stylehints are way too crude to balance the requirements of interpreter style control (app-wide font preferences, window size, etc) with the requirements of the author/designer. When I wrote down the initial ideas, I handwaved a lot and said “compromises are possible”, but there was never any plan for actually doing it.)
(3: The better way which exists today is Vorple, which I think demonstrates my point – it works by letting you get at the HTML/CSS directly.)
(4: To dig into this a bit: text centering does not clash with interpreter preferences/typography the way per-span color text does.)
Since you mentioned control over HTML/CSS: the nice thing with stylehints is that they allow to style a game in Quixe with custom CSS, but since Glk only gives 2 custom styles, it limits the ability a bit.
So an enhancement would be to have an unlimited number of custom styles (which would act more as markers or HTML classes) for the sake of Quixe CSS customisation.
But aside of this, well, I see why the style hints aren’t coming back.
As I understand it, the principle behind the stylehints seems sound – having a set of standard classes that allow semantic overrides. It just perhaps could have done with more flexibility in defining additional custom styles, and perhaps a better separation between paragraph styles and inline styles.
Saying that CSS/Vorple solves it better doesn’t seem entirely accurate, since there are more terps that don’t support CSS than ones that do, and it’s a pain for authors to try to support two different kinds of styling systems in the same story – unless you choose to sacrifice the blorb output entirely and go browser-only (which the standard templates don’t support, and seems to run counter to the spirit of IF).
But either way, things need to be layered carefully – the terp needs to provide defaults for the styles that the story can override, but in turn be able to override the story’s settings based on explicit user preferences (e.g. for users that need or prefer high-contrast).