I love the ease of distribution that Parchment gives us, but it seems like a proper HTML TADS 3 interpreter will be a bit of work. My previous workaround for this problem was to get JavaScript to hack back in some functionality by noticing certain regexps in divs set for game output (and not the parser input box for example). This is janky, crude and not performant.
I had another idea tonight that I have yet to test. I believe that output from TADS 3 is processed before throwing to the interpreter, and it is here that links etc are stripped out by outputManager (?). During initialisation of a session the game checks the type of interpreter and sets whether it can handle HTML, and this flag directs whether HTML stripping happens or not.
Suppose I make a Parchment-only version of my game that breaks that check and pretends the non-HTML interpreter handles HTML. The browser does, and that’s all I care about.
Because I’m violating the contract of TADS 3 doing the right thing by an interpreter, I wouldn’t make this file the universal T3 file to distribute.
Would this work? Anyone see any landmines I’m about to step on?
One thing I couldn’t find was how <hr/> are turned into a sequence of dashes. This might be happening in the interpreter itself?
My gut intuition (if that matters at all) says that outputManager is less what runs the filter, and more like the filter’s messenger telling your game what the interpreter itself is going to do, so that you can adjust accordingly.
So while I have not tested this for crashes or interpreter compatibility, I’m guessing if you override outputManager, the interpreter is still gonna filter stuff.
However, I’m curious to see how this works with Parchment, too, just to be certain.
One gotcha: Links in TADS can be used both for hyperlinks on the web as well as to execute commands. I assume what you’re talking about is only web hyperlinks?
I appreciate the motivation, but I think the best result would be to improve Parchment to support more of HTML TADS’ feature set.
The conversion from HTML to text-mode formatting happens in the VM’s C++ code: vmconhmp.cpp
Edit — to elaborate: the VM asks the frontend (osglk.c for Parchment and Gargoyle) what features it supports. This dictates whether HTML will be passed on to the display layer or translated by vmconhmp. The game is merely informed of the current state of affairs via the outputManager object (which basically just wraps the relevant systemInfo call).
Ah yes, this makes sense. The bits I was looking at in adv3/output.h are just for the custom HTML like <.p> and the like.
Absolutely. My desperation comes from a looming deadline, the destructive effect the HTML filter has on my text, and the understanding that improving Parchment is a huge (unpaid) tranche of work. Which I fully acknowledge is a problem I’ve gotten myself into
Ah cool. And there’s all the missing HTML filter/conversions I couldn’t find. I assume the hack of just forcing HTML support couldn’t just pass through everything and let the browser catch it, because of the way the frame is constructed by the rest of Parchment?
