[frob] Curses interface and UTF-8

I’m experiencing a couple of issues with the curses interface (the default one) of frob v1.2.3 (no past versions tested).

UTF-8 game and environment, so…

frob --character-set utf-8 game.t3

[size=85]By “special” I mean accented ones and the like.[/size]

  • When typing “special” characters, they appear as a pair of special marks. In this terminal emulator: inversed question marks inside a diamond, YMMV (I think this is equivalent to what tomasb said).

Curiously, going back in the command history (up arrow) shows the past command just fine.

  • When (and from then on) text first overflows the window, near every “special” character the “M” appears. Sometimes damaging the character, the next, the next, both… It depends.

I see no mention of this second issue anywhere. Can anyone confirm it?


PS: [size=85]I’m not sure if this message belongs to this forum or to “General: Interpreters, Add-Ons, and Tools”. Fell free to move it if appropriate. Excuse any inconvenience.[/size]

TADS in general in incapable of displaying Unicode through its terminal-oriented module. Only the GUI part of TADS can handle that. (Plain text mode only works because UTF-8 is compatible with ASCII when all you do is copy text around and don’t try to parse it.)

It’s unlikely that this will ever be fixed, unless someone rewrites that particular part of TADS.

OK, so maybe the module is not parsing until overflow occurs. Then it happens to start parsing and printing the last part of the buffer.

I thought the buffer/scrolling’s handled by curses.

To be precise, my experience is based on an old installation which behaves a little differently. I still have that old Frob v. 1.1 based on TADS v. 3.1.0 on my notebook so I was able to look at it once again.

In this version the scrolling is not an issue. Game behaves the same before and after scrolling. However in contrast to the current version (which I have installed on my main computer and which behaves exactly as you said) the accented characters are displayed correctly in the old version only with wrong attributes making them blink and inversed. Typed characters on command line are not displayed correctly in the old version, but game understands them so I can play the game successfully. This screenshot illustrates that:

The core problem is that the text-only screen positioning code of TADS assumes that one byte equals one character, which of course is not true. When frob sends text to it, TADS displays each byte of the text in its own position on the screen. As you can imagine, this results in all sorts of unpredictable glitches, as NCurses receives broken up parts of Unicode characters.

The part of TADS that’s responsible for this is tads2/osgen3.c. and it’s a fairly large piece of code (several thousands of lines.)

The “GUI part of TADS” includes QTads, right? I just want to confirm, since I’ll (hopefully) be moving into full Linux desktop use sometime next year.

I’m pretty sure there aren’t a lot of TADS games that require Unicode use, but still, it would be great to know QTads will be able to handle that.

Yes, QTads works AFAIK flawlessly since v. 2.0.2.