bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61561] [grotty] 'sgr' device control command seems to simply not w


From: G. Branden Robinson
Subject: [bug #61561] [grotty] 'sgr' device control command seems to simply not work
Date: Thu, 25 Nov 2021 12:05:50 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

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

                 Summary: [grotty] 'sgr' device control command seems to
simply not work
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Thu 25 Nov 2021 05:05:48 PM UTC
                Category: Device - others
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

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.





    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]