[bug #61561] [grotty] 'sgr' device control command takes effect only at page breaks

[G. Branden Robinson]

Follow-up Comment #5, bug #61561 (project groff):


[comment #4 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.

___

Reply to this item at:

  

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

[bug #61561] [grotty] 'sgr' device control command takes effect only at page breaks

[G. Branden Robinson]

Follow-up Comment #4, bug #61561 (project groff):

> 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...

___

Reply to this item at:

  

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

[bug #61561] [grotty] 'sgr' device control command takes effect only at page breaks

[G. Branden Robinson]

Update of bug #61561 (project groff):

  Status:None => Need Info  
 Assigned to:None => gbranden   
 Summary: [grotty] 'sgr' device control command seems to
simply not work => [grotty] 'sgr' device control command takes effect only at
page breaks

___

Follow-up 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::59: debug: turning overstriking drawing scheme OFF
grotty::86: debug: turning overstriking drawing scheme ON
: 696e 6974 0a74 0874 6508 6573 0873 7408  init.t.te.es.st.
0010: 7420 5242 0842 5f08 495f 0858 0858 520a  t RB.B_.I_.X.XR.
0020: 5f08 745f 0865 5f08 735f 0874 2052 4208  _.t_.e_.s_.t RB.
0030: 425f 0849 5f08 5808 5852 0a0a 0a0a 0a0a  B_.I_.X.XR..
0040: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0050: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0060: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0070: 0a0a 0a0a 0a0a 0a0a 0a0a 1b5b 316d 7465  ...[1mte
0080: 7374 201b 5b32 326d 521b 5b31 6d42 1b5b  st .[22mR.[1mB.[
0090: 346d 1b5b 3232 6d49 1b5b 316d 581b 5b32  4m.[22mI.[1mX.[2
00a0: 346d 1b5b 3232 6d52 0a0a 0a0a 0a0a 0a0a  4m.[22mR
00b0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
00c0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
00d0: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
00e0: 0a0a 0a0a 0a0a 0a0a 0a0a 7408 7465 0865  ..t.te.e
00f0: 7308 7374 0874 2052 4208 425f 0849 5f08  s.st.t RB.B_.I_.
0100: 5808 5852 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  X.XR
0110: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0120: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0130: 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  
0140: 0a0a 0a0a 0a0a   ..


___

Reply to this item at:

  

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

MOM heading question

[Richard Morse]

Hi! I’m trying to typeset my newly amended condominium trust, because the word 
version is really ugly, and I decided to try using MOM to do so (the 
heading/list functions in MS didn’t seem powerful enough, and I can’t find 
readable documentation of MM, while the MOM documentation is fantastic).

However, I’ve run into a bit of a weird situation.

Most of the paragraphs in the document are numbered as, e.g., 5.2.23. However, 
the separate articles (ie, the “5” of the example) are introduced as “ARTICLE 
V” — that is, in Roman numerals.

I tried to leave out the number in the heading style for heading level 1, but 
then the subheading (2, 3) don’t include the heading number, and they don’t 
reset to one when a new heading level 1 occurs.

Is there some way to suppress the *display* of the heading number for a 
particular level while still having it count for purposes of labelling the rest 
of the headings? Even if it’s on a per-occurance basis, there are sufficiently 
few first level headings that I could do some weird trickery for each one. (I 
can then include the Roman numeral in the text of the heading).

Alternately, is there some way to have the headings labeled in Roman numerals 
at their level, but using Arabic numerals at the lower levels?

Thanks,
Ricky

Re: PROPOSED: Kill \X'tty: sgr'

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20211125171302.ubixfedm3xtssc5m@localhost.localdomain>:
 |I'm proposing a feature deletion.
 |
 |https://savannah.gnu.org/bugs/index.php?61561
 |
 |Have I overlooked something?

It is the counterpart to the environment variable *_NO_SGR, and
controls the same variable old_drawing_scheme.
Why do you say that does not work?  Have i missed something?
I personally .. would not remove it.  What if anyone uses it to
turn off those ANSI sequences for her macro package?

In fact _i_ would not have simply turned the new scheme on, but
made it depend on some termcap or terminfo capability!  This is
what my MUA does, and if so allowed.  Ie if "Co" is given we _do_
use ISO 6429 sequences and do not care for the rest (aka do not
use the other termcap/terminfo sequences to generate the according
strings, we simply use ISO 6429 -- i found that sufficient for all
my thinkable options over twenty years ago i think, and have never
been dashed).  Iirc it is one of the "improvements" of GNU roff
that i never got right.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

PROPOSED: Kill \X'tty: sgr'

[G. Branden Robinson]

I'm proposing a feature deletion.

https://savannah.gnu.org/bugs/index.php?61561

Have I overlooked something?

Regards,
Branden


signature.asc
Description: PGP signature

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

[G. Branden Robinson]

Follow-up Comment #1, bug #61561 (project groff):


[comment #0 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.

___

Reply to this item at:

  

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

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

[G. Branden Robinson]

URL:
  

 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
: 1b5b 316d 7465 7874 2020 7367 725f 6e6f  .[1mtext  sgr_no
0010: 5f61 7267 2020 7367 725f 3020 2073 6772  _arg  sgr_0  sgr
0020: 5f31 2020 7367 725f 666f 6f1b 5b30 6d0a  _1  sgr_foo.[0m.
0030: 1b5b 346d 7465 7874 1b5b 3234 6d20 201b  .[4mtext.[24m  .
0040: 5b34 6d73 6772 5f6e 6f5f 6172 671b 5b32  [4msgr_no_arg.[2
0050: 346d 2020 1b5b 346d 7367 725f 301b 5b32  4m  .[4msgr_0.[2
0060: 346d 2020 1b5b 346d 7367 725f 311b 5b32  4m  .[4msgr_1.[2
0070: 346d 2020 1b5b 346d 7367 725f 666f 6f1b  4m  .[4msgr_foo.
0080: 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", ) == 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:

  

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

[bug #61443] [PATCH] fix grammatical and off-by-one errors in -Me Reference Manual

[G. Branden Robinson]

Update of bug #61443 (project groff):

  Status:None => In Progress
 Assigned to:None => gbranden   


___

Reply to this item at:

  

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

[bug #61550] [PATCH] grn.1.man: use a unique character for the tabulator in a table

[G. Branden Robinson]

Update of bug #61550 (project groff):

  Status:None => Postponed  

___

Follow-up Comment #2:

I have no plans to work on this for the reasons in comment #1 but someone else
is welcome to take it; setting to postponed.

___

Reply to this item at:

  

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

[bug #61446] [PATCH] doc/ms.ms: Use SI-unit symbols instead of language specific ones

[G. Branden Robinson]

Update of bug #61446 (project groff):

Severity:  3 - Normal => 2 - Minor  
  Status:None => Wont Fix   
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This patch is ill-conceived.

I'll go through the bits of it.


  SI is an abbreviation of "Système International d'Unités".

  Name of units are used in singular when listed.


Most of the units supported by *roff typesetting systems are not, in fact, SI
units.

Further, these documents are written in English and an ability to interpret
the plural forms of words in a base English vocabulary of 10,000 to 20,000
words is assumed.

NIST agrees.


> 9.2 Plurals ... Plural unit names are used when they are required by the
rules of English grammar. They are normally formed regularly, for example,
"henries" is the plural of henry. According to Ref. [6], the following plurals
are irregular: Singular —lux, hertz, siemens; Plural —lux, hertz, siemens.
(See also Sec. 9.7.)

You may be confusing standard practice for the use of SI _symbols_ (like "m",
"L", or "°C") with standard practice for the written-out unit _names_.


  The symbol for the unit inch is 'in'.


...which is not an SI unit
.  (Warning:
non-authoritative source, but that's an improvement on your not citing any
sources at all.  Maybe someone else has an official document handy.)


  The symbol '\[sd]' (PostScript name 'second') is for 'arch second'.


You mean 'arc second', and you are not presenting a complete picture.
 
In English that symbol is used for several purposes.  A symbol adjacent to it
in groff_char(7) is named '\[fm]', which is not a reasonable abbreviation for
"arc minutes".  One can surmise that it is a mnemonic for "feet/minutes",
since it is used for both just as \[sd] is used for inches and secondary
subdivisions of the degree in plane and spherical trigonometry.


-v  \[lq]vees\[rq]; height of a line using the current font
-m  \[lq]ems\[rq]; type size of the font; approx. width of an \[lq]M\[rq]
-n  \[lq]ens\[rq]; same as em/2; approx. width of an \[lq]n\[rq]
+i  inch (in)
+c  centimeter (cm)
+p  point (1/72\~in)
+P  pica (1/6\~in)
+v  \[lq]vee\[rq]; height of a line using the current font
+m  \[lq]em\[rq]; type size of the font; approx. width of an \[lq]M\[rq]
+n  \[lq]en\[rq]; same as em/2; approx. width of an \[lq]n\[rq]


The only SI symbol in the above is the centimeter, which was not listed with
its symbol in the first place, let alone was that symbol inappropriately
pluralized.

This patch is consequently wholly invalid.  I'm not sure whether to set its
status to "Invalid" or "Wont Fix".  I'll go with the latter for now.

___

Reply to this item at:

  

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

[bug #61455] [PATCH] doc/pic.ms: Avoid a yellow background for text when the device uses "tty.tmac"

[G. Branden Robinson]

Update of bug #61455 (project groff):

Severity:  3 - Normal => 2 - Minor  

___

Follow-up Comment #3:

There's not much hope in pic.ms becoming a useful document in nroff mode in
the short term.

Though I have some evil ideas that could change that in the longer term.

I think for now the thing to do is ensure that the fill color escape sequence
is being used idiomatically.  If it is, maybe we should disable the PS/PE
macros in nroff mode in this document.

___

Reply to this item at:

  

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

[bug #61550] [PATCH] grn.1.man: use a unique character for the tabulator in a table

[G. Branden Robinson]

Update of bug #61550 (project groff):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

There's no particular reason to expect an in-tree *.man file to be a
renderable man(7) document; they all undergo transformation to produce (what
should be) valid, renderable pages ending in .[157].

Similarly, groff_man.7.man.in is an m4 document and not even close to a valid
man(7) document.  (It undergoes two stages of transformation.)

___

Reply to this item at:

  

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

[bug #61559] tbl does not accept perverse tab and delim characters

[G. Branden Robinson]

URL:
  

 Summary: tbl does not accept perverse tab and delim
characters
 Project: GNU troff
Submitted by: gbranden
Submitted on: Thu 25 Nov 2021 01:13:20 PM UTC
Category: Preprocessor tbl
Severity: 1 - Wish
  Item Group: New feature
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

tab(() and delim(()) don't work well, although in principle they could be
supported--just need a bit more state in the parser in
main.cpp:process_options().

Noticed while trying to figure out if some of the code in that same function
is even reachable.




___

Reply to this item at:

  

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