Fonts

[Erquint]

I know you got enough on your platter, so I'm just leaving this suggestion for later.

Implement the cursive font found on manual pages 21 and… I forget the other one… and the isocube font found on pages 6 and 41.

I'm a fan of the latter personally. No edge segmentation or overlaps to worry about…

I saw another webapp (straight up translator I think, haven't used it) implement the cursive one.

[Erquint]

It took a lot of crutches, given your encoding scheme, but I implemented the isocube font locally.

And that effectively also solved #6 but not in an optional way of course.

[Erquint]

The last bits of polish took a big lot of hurt wrangling the swamp of frameworks at play… 😣
@Erquint/tunic-decoder#isocube
But it's looking good to me as it is now.

With some crusty caveats, however, which is why I'm not PRing this. Take what you can from my example.
But if I was to work on this to further perfection — I'd absolutely have to raze it all to the ground and rewrite it with zero frameworks and in a DRY paradigm from the outset.

[SaphireLattice]

Haven't checked the code but that looks pretty neat. Well poke at in some time later. It's a bit difficult to get to stuff for me, alas.

Not sure what frameworks you mean? There's Vue and Bootstrap, but neither need extra setup...

Rewriting the entire thing to use neither would be a nightmare. Input handling alone is rather difficult. Having to reimplement the list generation, handling and rendering in "raw" TypeScript and HTML does not sound like a fun time for me, either.

[Erquint]

There's also a serif font featured on page 36.

Haven't checked the code

There's still bugs in there and I'm butchering some things in the process but if you wanted to yoink the font assets — you could sleuth them out. I've done away with arbitrary absolute inline constants and try to reuse a predefined set of algebraically-derived ones instead. Could still be done better. A gigantic problem I experienced in altering the font is that you seem to have reimplemented your font three different times with three separate approaches through three disparate APIs for corresponding contexts and it's such a headache to hunt it down all strewn around the project and duplicate changes over and over… There needs to be one generalized function for rendering one asset per font. Be it with polymorphism and control flow routes as needed. I couldn't find the strength to generalize and combine them all yet.

Rewriting […] does not sound like a fun time for me, either.

Look, I don't want you to take my criticisms as offence and don't expect you to remake it.
I'm grateful it exists at all for me and more importantly others.
If someone was to remake it — probably falls onto someone like me in a fork.

But from where I stand, even not being a prolific frontender myself, I do, quite on the contrary to your reprehension of the idea, see it as very straightforward to implement all of it in basic frameworkless clientside APIs, not even TS is a must, even if neat.
There's event listeners for input handling, which you already do assign manually.
As for the list: seems like simple templating one could implement ad-hoc. Procedural markup isn't difficult. The usual threat of a templater growing into an interpreter is outside the scope here.
From getting intimate with the project I'm seeing that the features of the frameworks aren't even used all that much — they're mostly just there and get in the way or are used in expressions that have direct equivalents in basic APIs. Bloat of dead weight otherwise.

Anyway, again, not trying to be pushy, just sharing my thoughts.
It's on me or someone with more will to do it.
The hardest part, honestly, is ship-of-Theseus-ing it progressively from an already existing project. That glyph stroke click callback generalization I did last took more effort than I am proud to admit, given I had to keep it on life support through iterative redesign workflow.