Fix vttest errors (all of them)

[davidrg]

Recently with the help of the vttest automation script I ran K95 through almost all of VTTESTs tests. It will take (quite) a while to evalulate the thousands of results, but already there are a few failures turning up that will need fixing.

Most of the failures affect VT420 or higher features, and as K95 doesn't currently claim to emulate a VT420 those can be deprioritised for now. But the failures affecting VT320 or lower features should probably fixed sooner rather than later.

This will probably be a long-lived ticket - it may as well stick around until all VTTEST failures that are feasable to fix are fixed.

• Update VTTEST automation script to cover printing features
• There are a few other tests that the automation script could capture a bit better (eg, the ones that affect the cursor - its not currently rendered in the images), plus blinking text - see Render blinking text in a dimmer colour when blinking off #506
• DECLRMM and DECSLRM - set left/right margins #232 - needed to have any chance of passing a large portion of the VT420 tests
• Tests 2.7 and 2.8 - Soft Scroll (not supported by K95 yet)
• Tests 11.2.5.2.5 and 11.2.5.2.6 - VT320 (I assume really VT330/340) locator status and identity
• 11.2.5.3.1.7 - DECCIR is not implemented yet
• 11.2.5.3.2.1 through 11.2.5.3.2.7 - DECRQPSR - Tab Stop Report (DECTABSR) - not implemented yet
• 11.2.5.3.4 DECRSPS

Related: #198 - fix all the issues reported by esctest2

[j4james]

Note that there is one entry in vttest's "known bugs" menu that's actually a documented requirement and not a bug, so it's something that a conformant terminal emulator should be supporting (and I believe Kermit doesn't currently handle this correctly).

9.8 - Erase right half of double width lines.

This is documented in chapter 5 of STD 070 for both the DECDWL and DECDHL controls:

Setting this attribute causes data which is beyond the end of the Active Line after execution of the control to be lost.

And you can also see in the algorithm that they're explicitly clearing the buffer for the columns beyond the end of the line.

for (x=end_of_line(active_position.line)+1;
     x<=columns_per_page;
     x++)
  {
  display[active_position.line + base][x].code = EMPTY_CHARACTER;
  }

If you want to double check that end_of_line definition, that's documented in section 5.14.1. On a double width line, it's half of the full line width.

[davidrg]

Thanks for catching that! K95 does indeed not behave that way, but it should be an easy fix

[davidrg]

@j4james Your HTMLised version of STD 070 is a whole lot easier to deal with than that giant PDF! At some point I'll have to update all the references in the K95 control sequences documentation to point at that rather than the big PDF, or at least add the HTML version as an alternative to the PDF.