bugGNU roff - Bugs: bug #61561, [grotty] remove 'sgr' device...

 
 

bug #61561: [grotty] remove 'sgr' device control command

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Thu 25 Nov 2021 05:05:48 PM UTC
   
 
Category:  Driver grotty Severity:  3 - Normal
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 Feb 2022 11:18:57 AM UTC, comment #9: 


commit dec7367f785e1482dc79aaaaa83436248cea790c
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Feb 16 14:43:19 2022 +1100

    [grotty]: Remove 'sgr' device control command.

    * src/devices/grotty/tty.cpp (tty_printer::special): Do it.
    * src/devices/grotty/grotty.1.man (Device control commands):
      (De-)document it.
    * NEWS: Add item.

    Fixes <https://savannah.gnu.org/bugs/?61561>.


G. Branden Robinson <gbranden>
Group administrator
Tue 11 Jan 2022 09:49:01 PM UTC, comment #8: 

...since it takes effect only at page breaks.

I reiterate that I have no plans to alter GROFF_SGR or the `-c` command-line option.

G. Branden Robinson <gbranden>
Group administrator
Fri 26 Nov 2021 11:38:57 PM UTC, comment #7: 

Whoops.  I made an error.  The think I thought I could break, doesn't break.  That's good.  But my other points stand.

Here's the wrong part.

comment #6:

> It occurs to me that you could break this by enabling SGR (the default), going nuts with SGR character attributes, and then contriving to disable SGR in the midst of the page, which, as we've seen, won't actually turn anything off in the terminal.  When the page bottom is hit, all the logic that cleans up character attribute state will be skipped, because you're in nice, clean legacy output mode.  Let's see.
>
> Input:


> $ cat EXPERIMENTS/grotty-make-a-mess.groff
> .fcolor magenta
> .gcolor white
> .ft BI
> obnoxious\X'tty: sgr'
> .bp
> still obnoxious\[em]ha ha ha


I forgot to put a (space and) '0' after the 'sgr' above, so I didn't actually do anything at all.  My brain itched momentarily regarding why I got only one debugging output diagnostic instead of two, but I didn't pay attention.

> Yup.


Nope.  :P

> In other words, most of the logic quoted above should have been moved into `update_options()` or, even better, its own function, called from  there and `end_page()`.


Terminal output would have to be refactored to handle this.  grotty(1) really outputs a page at a time instead of a line at a time, which changes the analysis a bit.

If we look earlier in `end_page()`, we see this.


 750   for (int i = 0; i < last_line; i++) {
 751     tty_glyph *p = lines[i];
 752     lines[i] = 0;
 753     tty_glyph *g = 0;
 754     while (p) {
 755       tty_glyph *tem = p->next;
 756       p->next = g;
 757       g = p;
 758       p = tem;
 759     }


...and then a whole bunch more logic to format the output with the currently configured text attributes.

Like I said, this doesn't change much.  But I incorrectly deduced that grotty(1) has for 20 years been susceptible to the SGR-switching tomfoolery I attempted in the quoted comment--it has not been.

Sadly grotty(1)'s page-at-a-time approach to output is nowhere documented; it might explain the otherwise mysterious claims sprinkled around our Texinfo manual and maybe some other places that GNU nroff can't be used interactively as Unix nroff could (`.rd` again).  Even that claim is too strong--a while back I updated groff(1) to illustrate how you can run groff -T utf8 as a REPL and I've used it that way frequently since I started participating in its development.

Page-at-a-time layout even for terminal devices is indeed more consistent with troff and reflects the grand unification strategy that GNU roff undertook in the first place.  It's not clear to me exactly what was lost.  It would be nice to have a model document that works under Unix nroff but not GNU troff as a result of this change.

Okay, I need to stop procrastinating and read some ncurses man pages...                               



G. Branden Robinson <gbranden>
Group administrator
Fri 26 Nov 2021 11:15:44 PM UTC, comment #6: 

comment #3:

> It seems that the state of SGR at the bottom of the page (when it gets ejected?) is the one that wins.
> I'll see if I can find in the code how the fonts get re-initialized, or what exactly is going on there.


Okay, here it is.  grotty's `end_page()` is huge--nearly 200 lines.  Near the end of it we have the following nearly 100 lines of undoing all the possible character attributes (bold, underlining, color, etc.) that might have been applied.


 790       if (hpos > p->hpos) {
 791         do {
 792           putchar('\b');
 793           hpos--;
 794         } while (hpos > p->hpos);
 795       }
 796       else {
 797         if (want_horizontal_tabs) {
 798           for (;;) {
 799             int next_tab_pos = ((hpos + TAB_WIDTH) / TAB_WIDTH) * TAB_WIDTH;
 800             if (next_tab_pos > p->hpos)
 801               break;
 802             if (is_continuously_underlining)
 803               make_underline(p->w);
 804             else if (!use_overstriking_drawing_scheme
 805                      && is_underlining) {
 806               if (do_sgr_italics)
 807                 putstring(SGR_NO_ITALIC);
 808               else if (do_reverse_video)
 809                 putstring(SGR_NO_REVERSE);
 810               else
 811                 putstring(SGR_NO_UNDERLINE);
 812               is_underlining = false;
 813             }
 814             putchar('\t');
 815             hpos = next_tab_pos;
 816           }
 817         }
 818         for (; hpos < p->hpos; hpos++) {
 819           if (is_continuously_underlining)
 820             make_underline(p->w);
 821           else if (!use_overstriking_drawing_scheme && is_underlining) {
 822             if (do_sgr_italics)
 823               putstring(SGR_NO_ITALIC);
 824             else if (do_reverse_video)
 825               putstring(SGR_NO_REVERSE);
 826             else
 827               putstring(SGR_NO_UNDERLINE);
 828             is_underlining = false;
 829           }
 830           putchar(' ');
 831         }
 832       }
 833       assert(hpos == p->hpos);
 834       if (p->mode & COLOR_CHANGE) {
 835         if (!use_overstriking_drawing_scheme) {
 836           if (p->fore_color_idx != curr_fore_idx) {
 837             put_color(p->fore_color_idx, 0);
 838             curr_fore_idx = p->fore_color_idx;
 839           }
 840           if (p->back_color_idx != curr_back_idx) {
 841             put_color(p->back_color_idx, 1);
 842             curr_back_idx = p->back_color_idx;
 843           }
 844         }
 845         continue;
 846       }
 847       if (p->mode & UNDERLINE_MODE)
 848         make_underline(p->w);
 849       else if (!use_overstriking_drawing_scheme && is_underlining) {
 850         if (do_sgr_italics)
 851           putstring(SGR_NO_ITALIC);
 852         else if (do_reverse_video)
 853           putstring(SGR_NO_REVERSE);
 854         else
 855           putstring(SGR_NO_UNDERLINE);
 856         is_underlining = false;
 857       }
 858       if (p->mode & BOLD_MODE)
 859         make_bold(p->code, p->w);
 860       else if (!use_overstriking_drawing_scheme && is_boldfacing) {
 861         putstring(SGR_NO_BOLD);
 862         is_boldfacing = false;
 863       }
 864       if (!use_overstriking_drawing_scheme) {
 865         if (p->fore_color_idx != curr_fore_idx) {
 866           put_color(p->fore_color_idx, 0);
 867           curr_fore_idx = p->fore_color_idx;
 868         }
 869         if (p->back_color_idx != curr_back_idx) {
 870           put_color(p->back_color_idx, 1);
 871           curr_back_idx = p->back_color_idx;
 872         }
 873       }
 874       put_char(p->code);
 875       hpos += p->w / font::hor;
 876     }
 877     if (!use_overstriking_drawing_scheme
 878         && (is_boldfacing || is_underlining
 879             || curr_fore_idx != DEFAULT_COLOR_IDX
 880             || curr_back_idx != DEFAULT_COLOR_IDX))
 881       putstring(SGR_DEFAULT);
 882     putchar('\n');


These undoings use the current state of SGR enablement as configured by the user, not whatever state(s) might be active in the output stream going to the terminal, so that addresses the point that surprised me.  I'll say one thing for legacy output mode--it's not stateful, or at least not for more than one character cell.  SGR is heavily so.

What the above does is unwind all the crazy stuff that might be in effect at the end of a page so that the next one starts over from a clean slate.  It occurs to me that you could break this by enabling SGR (the default), going nuts with SGR character attributes, and then contriving to disable SGR in the midst of the page, which, as we've seen, won't actually turn anything off in the terminal.  When the page bottom is hit, all the logic that cleans up character attribute state will be skipped, because you're in nice, clean legacy output mode.  Let's see.

Input:

$ cat EXPERIMENTS/grotty-make-a-mess.groff
.fcolor magenta
.gcolor white
.ft BI
obnoxious\X'tty: sgr'
.bp
still obnoxious\[em]ha ha ha


Hex dump of output:

$ ./build/test-groff -b -ww -T utf8 EXPERIMENTS/grotty-make-a-mess.groff | xxd
grotty:<standard input>:16: debug: turning overstriking drawing scheme OFF
00000000: 1b5b 3337 6d1b 5b34 356d 1b5b 346d 1b5b  .[37m.[45m.[4m.[
00000010: 316d 6f62 6e6f 7869 6f75 731b 5b30 6d0a  1mobnoxious.[0m.
00000020: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000030: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000040: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000050: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000060: 0a1b 5b34 6d1b 5b31 6d1b 5b33 376d 1b5b  ..[4m.[1m.[37m.[
00000070: 3435 6d73 7469 6c6c 1b5b 3234 6d20 1b5b  45mstill.[24m .[
00000080: 346d 6f62 6e6f 7869 6f75 73e2 8094 6861  4mobnoxious...ha
00000090: 1b5b 3234 6d20 1b5b 346d 6861 1b5b 3234  .[24m .[4mha.[24
000000a0: 6d20 1b5b 346d 6861 1b5b 306d 0a0a 0a0a  m .[4mha.[0m....
000000b0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000c0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000d0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000e0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a       ..............


Yup.

In other words, most of the logic quoted above should have been moved into `update_options()` or, even better, its own function, called from  there and `end_page()`.

I plan to experiment with terminfo, but if that goes badly or takes too long, I'll take a stab at the "should have been" approach.

But even if I do the latter, I think this device control command needs to go away.  Terminal capabilities do not change in the course of rendering a document[1].  If terminfo is infeasible, I reckon we'll need our own miniature terminal capability description feature, produced by the formatter (troff) and consumed by grotty(1) when it initializes so that it knows what to do.  That is pretty close to what 'sgr' was supposed to be and the only way it reliably works today, except we have the problem that it communicates only 1 bit of information when we need more.

[1] Real terminal application developers know all too well the notorious exception to this: terminal window size and the asynchronous hell of SIGWINCH.  Fortunately, grotty(1) is a non-interactive application (most of the time--I'm not forgetting `.rd`) and in any event troff's `.pl` and `.ll` (and `.lt`) decide the matter of terminal dimensions for us.  So I think we get to enjoy some blissful ignorance in that respect.

G. Branden Robinson <gbranden>
Group administrator
Fri 26 Nov 2021 04:31:58 AM UTC, comment #5: 


comment #4:

> Yes...on the mailing list named an idea


Comrade Stalin got a hold of that comment somehow...

It was Steffen who did aforementioned naming.

G. Branden Robinson <gbranden>
Group administrator
Fri 26 Nov 2021 04:30:38 AM UTC, comment #4: 


> Not sure about you, but I see a perfect opportunity to put a currently-useless bit of kruft to good use by repurposing it to toggle “real” italics, Fraktur, dimmed text, strikeouts, and any other spiffy-looking but fundamentally useless effect for terminals that happen to support such nicer-looking effects:

[...]

> I might be leaning too strongly on my expectations as a part-time Emacs user, whose graphical mode brings out these pleasant-looking effects in text I'm normally used to reading in very spartan settings.


Yes...on the mailing list named an idea I've hinted at before (in doc/ms.ms): having grotty use available system resources to determine these matters instead of installing its own bespoke configuration system.

The terminfo library.

I can understand why this road wasn't taken 20 years ago: ncurses had only been under Thomas Dickey's official maintenance for a couple of years after mercurial stewardship by others and an erratic release history, there were still a lot of S-Lang partisans touting its superiority on scant evidence, and people were still clinging to termcap as somehow preferable on any basis to terminfo.

But we're in a better world now.

What I don't know is exactly how we want to preserve the ability to ignore certain terminal capabilities.  I expect people to be surprised if underlines in nroff documents suddenly turn into real italics.  Some will be pleasantly surprised, but not all.

I need to learn how capability cancellation would be achieved at runtime.  I have the atom of knowledge that in a terminfo description, you suffix a capability name with '@' to cancel it, but not much more.  There is the question of what we tell our users.  More command-line options and environment variables, or tell them to override terminfo?  The latter would be a surprise too.  Even if it turns out to be the architecturally correct solution (which I suspect), we would need a period of transition as a considerable number of our users discover that terminal capabilities are even a thing that exists in Unix systems (look at all the fancy programs and scripts that blast ECMA-48 color attribute escape sequences completely unconditionally, without checking anything or caring what's going to have to process them).

Having seem npm run, I have a pretty good guess who some of those people are...

G. Branden Robinson <gbranden>
Group administrator
Fri 26 Nov 2021 04:07:01 AM UTC, comment #3: 

Good news!  The feature isn't quite as broken as I thought.

I noticed that even with groff -P-c, SGR sequences were getting enabled seemingly instantly, in spite of the option being initially honored.

You can dynamically change SGR enablement within a document.

At a page break.

Not a word break.  Not an output line flush.

Not even after vertical space.

A page break.

It seems that the state of SGR at the bottom of the page (when it gets ejected?) is the one that wins.

This doesn't really change my mind about the non-usefulness of the feature--almost anybody who wants dynamic control of overstriking vs. SGR sequences is going to want finer-grained resolution than this--but it does partially invalidate my analysis.  I'll see if I can find in the code how the fonts get re-initialized, or what exactly is going on there.

Here's input and a hex dump from an instrumented groff Git HEAD.  (The output in the initial report was from Debian's groff 1.22.4.)


$ cat EXPERIMENTS/grotty-smaller-sgr.groff
.de Ts
test
\fRR\fBB\fII\f(BIX\fRR
.br
..
init
.br
.ft B
.Ts
.ft I
.Ts
.bp
\X'tty: sgr'\c
.ft B
.Ts
.bp
\X'tty: sgr 0'\c
.ft B
.Ts


I encourage the reader to substitute 'fl', 'sp', or any request of their choice for those 'bp's.


$ ./build/test-groff -b -ww -P-c -Tascii EXPERIMENTS/grotty-smaller-sgr.groff |xxd
grotty: debug: turning overstriking drawing scheme ON
grotty:<standard input>:59: debug: turning overstriking drawing scheme OFF
grotty:<standard input>:86: debug: turning overstriking drawing scheme ON
00000000: 696e 6974 0a74 0874 6508 6573 0873 7408  init.t.te.es.st.
00000010: 7420 5242 0842 5f08 495f 0858 0858 520a  t RB.B_.I_.X.XR.
00000020: 5f08 745f 0865 5f08 735f 0874 2052 4208  _.t_.e_.s_.t RB.
00000030: 425f 0849 5f08 5808 5852 0a0a 0a0a 0a0a  B_.I_.X.XR......
00000040: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000050: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000060: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000070: 0a0a 0a0a 0a0a 0a0a 0a0a 1b5b 316d 7465  ...........[1mte
00000080: 7374 201b 5b32 326d 521b 5b31 6d42 1b5b  st .[22mR.[1mB.[
00000090: 346d 1b5b 3232 6d49 1b5b 316d 581b 5b32  4m.[22mI.[1mX.[2
000000a0: 346d 1b5b 3232 6d52 0a0a 0a0a 0a0a 0a0a  4m.[22mR........
000000b0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000c0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000d0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
000000e0: 0a0a 0a0a 0a0a 0a0a 0a0a 7408 7465 0865  ..........t.te.e
000000f0: 7308 7374 0874 2052 4208 425f 0849 5f08  s.st.t RB.B_.I_.
00000100: 5808 5852 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  X.XR............
00000110: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000120: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000130: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  ................
00000140: 0a0a 0a0a 0a0a                           ......


G. Branden Robinson <gbranden>
Group administrator
Thu 25 Nov 2021 07:34:46 PM UTC, comment #2: 


> Rather than trying to fix this to allow dynamic update of mounted font properties [...] I propose to simply rip out this device control command entirely.
>
> On a related but different subject, I want a better way to tell grotty to use real italics so it's easier to make it the default


Not sure about you, but I see a perfect opportunity to put a currently-useless bit of kruft to good use by repurposing it to toggle “real” italics, Fraktur, dimmed text, strikeouts, and any other spiffy-looking but fundamentally useless effect for terminals that happen to support such nicer-looking effects:


\X'sgr: italics on'

\e[3m Now THAT'S what I call emphasis \e[23m

\X'sgr: italics off'


I might be leaning too strongly on my expectations as a part-time Emacs user, whose graphical mode brings out these pleasant-looking effects in text I'm normally used to reading in very spartan settings.

John Gardner <alhadis>
Thu 25 Nov 2021 05:10:31 PM UTC, comment #1: 


original submission:

> The problem is that these properties are all associated with fonts,


Sorry, not "all".  `do_sgr_italics` and `do_reverse_video` are exceptions.  But they're pretty similar in that they need only be statically configured when the output driver initializes.  At present we expose neither device control commands nor environment variables to manipulate them.  You get command-line options and that's it.

G. Branden Robinson <gbranden>
Group administrator
Thu 25 Nov 2021 05:05:48 PM UTC, original submission:  

Input:


$ cat EXPERIMENTS/grotty-sgr.groff
.de Ts
text
\X'tty: sgr'
sgr_no_arg
\X'tty: sgr 0'
sgr_0
\X'tty: sgr 1'
sgr_1
\X'tty: sgr foo'
sgr_foo
\X'tty: sgr'
.br
..
.ft B
.Ts
.ft I
.Ts


Output:


$ nroff EXPERIMENTS/grotty-sgr.groff | cat -s
text  sgr_no_arg  sgr_0  sgr_1  sgr_foo
text  sgr_no_arg  sgr_0  sgr_1  sgr_foo


Now, that's not going to come through on Savannah, so let's hex dump it.


$ nroff EXPERIMENTS/grotty-sgr.groff | cat -s | xxd
00000000: 1b5b 316d 7465 7874 2020 7367 725f 6e6f  .[1mtext  sgr_no
00000010: 5f61 7267 2020 7367 725f 3020 2073 6772  _arg  sgr_0  sgr
00000020: 5f31 2020 7367 725f 666f 6f1b 5b30 6d0a  _1  sgr_foo.[0m.
00000030: 1b5b 346d 7465 7874 1b5b 3234 6d20 201b  .[4mtext.[24m  .
00000040: 5b34 6d73 6772 5f6e 6f5f 6172 671b 5b32  [4msgr_no_arg.[2
00000050: 346d 2020 1b5b 346d 7367 725f 301b 5b32  4m  .[4msgr_0.[2
00000060: 346d 2020 1b5b 346d 7367 725f 311b 5b32  4m  .[4msgr_1.[2
00000070: 346d 2020 1b5b 346d 7367 725f 666f 6f1b  4m  .[4msgr_foo.
00000080: 5b30 6d0a 0a                             [0m..


As far as I can tell, the problem is that the `update_options()` function which diligently updates rendering parameters when the `sgr` device control command is handled is basically doing a bunch of work for nothing...


 448   if (strncmp(command, "sgr", p - command) == 0) {
 449     for (; *p == ' ' || *p == '\n'; p++)
 450       ;
 451     int n;
 452     if (*p != '\0' && sscanf(p, "%d", &n) == 1 && n == 0)
 453       use_overstriking_drawing_scheme = true;
 454     else
 455       use_overstriking_drawing_scheme = false;
 456     update_options();
 457   }

 900 static void update_options()
 901 {
 902   if (use_overstriking_drawing_scheme) {
 903     do_sgr_italics = false;
 904     do_reverse_video = false;
 905     bold_underline_mode = bold_underline_mode_option;
 906     do_bold = want_emboldening_by_overstriking;
 907     do_underline = want_italics_by_underlining;
 908   }
 909   else {
 910     do_sgr_italics = want_sgr_italics;
 911     do_reverse_video = want_reverse_video_for_italics;
 912     bold_underline_mode = BOLD_MODE|UNDERLINE_MODE;
 913     do_bold = true;
 914     do_underline = true;
 915   }
 916 }


The problem is that these properties are all associated with fonts, which have already been mounted and changes to these parameters do not affect them.


 119 tty_font *tty_font::load_tty_font(const char *s)
 120 {
 121   tty_font *f = new tty_font(s);
 122   if (!f->load()) {
 123     delete f;
 124     return 0;
 125   }
 126   const char *num = f->get_internal_name();
 127   long n;
 128   if (num != 0 && (n = strtol(num, 0, 0)) != 0)
 129     f->mode = (unsigned char)(n & (BOLD_MODE|UNDERLINE_MODE));
 130   if (!do_underline)
 131     f->mode &= ~UNDERLINE_MODE;
 132   if (!do_bold)
 133     f->mode &= ~BOLD_MODE;
 134   if ((f->mode & (BOLD_MODE|UNDERLINE_MODE)) == (BOLD_MODE|UNDERLINE_MODE))
 135     f->mode = (unsigned char)((f->mode & ~(BOLD_MODE|UNDERLINE_MODE))
 136                               | bold_underline_mode);
 137   return f;
 138 }


Rather than trying to fix this to allow dynamic update of mounted font properties, or telling people they need to make new fonts which their documents manually load with .fp requests (I tried that, and it doesn't seem to work anyway), I propose to simply rip out this device control command entirely.  The variables `update_options()` manipulates will remain in place; they'll simply have their values fixed for the run of the output driver.

Since no one seems to have complained about this problem in 19 years, I assume no one will miss it.  They would miss the `-c` option and `GROFF_NO_SGR` environment variable, so I do not propose to drop those.

On a related but different subject, I want a better way to tell grotty to use real italics so it's easier to make it the default (an environment variable is not "better").  I'm not sure yet what that would be.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by alhadis (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-07 gbranden CategoryDriver - others/general Driver grotty
    2022-02-21 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-02-16 gbranden StatusConfirmed In Progress
    2022-01-11 gbranden Item GroupIncorrect behaviour Feature change
        Summary[grotty] 'sgr' device control command takes effect only at page breaks [grotty] remove 'sgr' device control command
    2021-11-26 gbranden StatusNeed Info Confirmed
    2021-11-26 gbranden StatusNone Need Info
        Assigned toNone gbranden
        Summary[grotty] 'sgr' device control command seems to simply not work [grotty] 'sgr' device control command takes effect only at page breaks

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code