Re: pic doesn't center when i use a macro

2021-11-01 Thread Douglas McIlroy 
Remember that macros work by substitution. So each line of label_for
becomes a separate line in the macro-expanded program. A label alone
on a line gets plotted at the current point, which in this case is
last box.e.  (The macro definition begins with an empty line. If it
didn't, then the case-0 line would have been pasted on the end of
the dashed-box line and manifested as a syntax error.)

BTW, what are the empty strings ("") for? Formally, they make a
three-line label, too high for the dashed box.

(The code layout below differs slightly from the original. I inserted
the backslash-newline to keep gmail from breaking the line at an
awkward place.)

Doug

> .PS
>
> define label_for {
> if $1 == 0 then { "Ent?te Ethernet"  } else {
> if $1 == 1 then { "Ent?te IP"} else {
> if $1 == 2 then { "Ent?te TCP"   } else {
> if $1 == 3 then { "Donnees applicatives" } else {
> } } } }
> }
>
> w = 3 ; h = 2; margin = .2 ; tr = 2 * margin
> for layer = 0 to 3 do {
> s = layer * margin
> box width w height h with .sw at (s,s)
> box width w height margin with .nw at last box .nw dashed \
>"" label_for(layer) ""
> w = w - tr
> h = h - tr
> }
> .PE

Re: Git, where zombie branches shamble again

2021-11-01 Thread G. Branden Robinson 
At 2021-11-01T22:30:28+, Keith Marshall via Groff-commit wrote:
> On 01/11/2021 14:01, G. Branden Robinson wrote:
> > At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
> >> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson
> >> wrote:
> >>> Since I am now accused four times over of rewriting history, and
> >>> moreover of violating an "absolute taboo", I must insist upon the
> >>> presentation of particulars.
> >>
> >> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
> >> the first distributed source management system, hg, git, etc are
> >> copies, I'm the guy that figured this model out.
> > 
> > Fear not!  I've known your name and (some of) your work for many
> > years.
> > 
> >> If you did not rewrite history, which means you changed things so
> >> that a pull won't work or will create a massive merge mess, then
> >> you are fine.
> > 
> > As far as _I_ can tell, neither of these has taken place.
> 
> Seriously?  You absolutely _did_ rewrite history ... not just once,
> but twice!  You deleted an _entire branch_ of published development
> history, then after my subsequent push had reinstated it, you deleted
> it once again!  If that isn't rewriting history, then I'd like to know
> what you would call it.

Larry's operational definition seems fine to me.  You've asserted
neither that (1) a pull won't work [depending on what, precisely, that
means--there are plenty of ways a pull won't work, like having a dirty
working tree or accessing the wrong remote] nor that (2) I've created a
massive merge mess.

I've told you earlier in the thread, what I call it: "marking a
development branch closed, abandoned, or otherwise defunct"[1].  I've
acknowledged, also more than once, that I may well have used an
incorrect approach to doing so, and I apologized for my error.  Yet you
remain unsatisfied.

> Now, I'm sure you made this mistake in ignorance, rather than with any
> malicious intent,

Thank you for acknowledging that.  I would ask that you let this
knowledge influence the tenor of your communications in a collaborative
working environment.

> but it was a history rewriting mistake nonetheless.

I remain unconvinced that it was; I'm not aware of any rule that says
dev branches must be immortal.  Once all of their work has been
merged/rebased/cherry-picked onto a living branch--as is the case here--
why do they need to stick around?

Here are some branches on Savannah right now.
  origin/gropdfmultiglyph
  origin/unique-version

They do not appear in the Web interface
.  Getting Savannah to
similarly "unlist" dev-gropdf-boxes was all I really wanted, but when I
found it was gone I didn't regard it as an emergency, since that was
consistent with branch management practices I've been exposed to
elsewhere (see below).  For the benefit of groff developers in general,
would you explain how to put a branch into the state where the Savannah
Web UI doesn't list it?

> Two things which you should never do, after anything has been pushed
> to a public repository: you should not rebase any of it; neither
> should you delete any of it.

Neither of these prohibitions is a universal practice applied to topic
branches.  I've seen force-pushes and deletion of branches like this
done commonly and encouraged as a matter of policy at workplaces.  With
dozens of developers, each of whom created topic branches at a frenzied
pace (often one per JIRA ticket), it was the only way to keep "git
branch --list --remote" (as excerpted above) output sane.  Similarly,
forced pushes (again, to topic branches, never to master) was a common
activity for uncluttering a series of commits before merging or rebasing
it onto the master branch.

The motivation for forced pushes on topic branches is simple: in a
peer-reviewed environment, development seldom proceeds in a straight
line: blind alleys are pursued, mistaken assumptions get written into
code and commit messages.  (Most often, in my experience, a person
initially simply isn't clear about what the root cause of a problem is;
they tend to feel pressure, often self-imposed, to get a "fix" pushed
without a detailed analysis, so that they can report progress to
supervisors.  A peer reviewer subsequently talks through the issue with
them, both of them understand it better, and the description and
sometimes the nature of the change are altered, reflecting this improved
knowledge.)

Eventually (ideally) full understanding and a code or documentation
change of impact proportional to the problem is arrived at.  Having the
false starts, blind alleys, and mistaken assertions in the master
branch's commit history is confusing to a project's own developers and
to the general public.  For a rigorously-engineered, high-profile, and
(in part) externally-funded project, such digressions are unwelcome.

groff is not the same sort of project, thankfully.  It's more casual and
doesn't draw the attention of suits or uniforms.  If

Re: Git, where zombie branches shamble again

2021-11-01 Thread G. Branden Robinson 
At 2021-11-01T22:30:28+, Keith Marshall via Groff-commit wrote:
> On 01/11/2021 14:01, G. Branden Robinson wrote:
> > At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
> >> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson
> >> wrote:
> >>> Since I am now accused four times over of rewriting history, and
> >>> moreover of violating an "absolute taboo", I must insist upon the
> >>> presentation of particulars.
> >>
> >> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
> >> the first distributed source management system, hg, git, etc are
> >> copies, I'm the guy that figured this model out.
> > 
> > Fear not!  I've known your name and (some of) your work for many
> > years.
> > 
> >> If you did not rewrite history, which means you changed things so
> >> that a pull won't work or will create a massive merge mess, then
> >> you are fine.
> > 
> > As far as _I_ can tell, neither of these has taken place.
> 
> Seriously?  You absolutely _did_ rewrite history ... not just once,
> but twice!  You deleted an _entire branch_ of published development
> history, then after my subsequent push had reinstated it, you deleted
> it once again!  If that isn't rewriting history, then I'd like to know
> what you would call it.

Larry's operational definition seems fine to me.  You've asserted
neither that (1) a pull won't work [depending on what, precisely, that
means--there are plenty of ways a pull won't work, like having a dirty
working tree or accessing the wrong remote] nor that (2) I've created a
massive merge mess.

I've told you earlier in the thread, what I call it: "marking a
development branch closed, abandoned, or otherwise defunct"[1].  I've
acknowledged, also more than once, that I may well have used an
incorrect approach to doing so, and I apologized for my error.  Yet you
remain unsatisfied.

> Now, I'm sure you made this mistake in ignorance, rather than with any
> malicious intent,

Thank you for acknowledging that.  I would ask that you let this
knowledge influence the tenor of your communications in a collaborative
working environment.

> but it was a history rewriting mistake nonetheless.

I remain unconvinced that it was; I'm not aware of any rule that says
dev branches must be immortal.  Once all of their work has been
merged/rebased/cherry-picked onto a living branch--as is the case here--
why do they need to stick around?

Here are some branches on Savannah right now.
  origin/gropdfmultiglyph
  origin/unique-version

They do not appear in the Web interface
.  Getting Savannah to
similarly "unlist" dev-gropdf-boxes was all I really wanted, but when I
found it was gone I didn't regard it as an emergency, since that was
consistent with branch management practices I've been exposed to
elsewhere (see below).  For the benefit of groff developers in general,
would you explain how to put a branch into the state where the Savannah
Web UI doesn't list it?

> Two things which you should never do, after anything has been pushed
> to a public repository: you should not rebase any of it; neither
> should you delete any of it.

Neither of these prohibitions is a universal practice applied to topic
branches.  I've seen force-pushes and deletion of branches like this
done commonly and encouraged as a matter of policy at workplaces.  With
dozens of developers, each of whom created topic branches at a frenzied
pace (often one per JIRA ticket), it was the only way to keep "git
branch --list --remote" (as excerpted above) output sane.  Similarly,
forced pushes (again, to topic branches, never to master) was a common
activity for uncluttering a series of commits before merging or rebasing
it onto the master branch.

The motivation for forced pushes on topic branches is simple: in a
peer-reviewed environment, development seldom proceeds in a straight
line: blind alleys are pursued, mistaken assumptions get written into
code and commit messages.  (Most often, in my experience, a person
initially simply isn't clear about what the root cause of a problem is;
they tend to feel pressure, often self-imposed, to get a "fix" pushed
without a detailed analysis, so that they can report progress to
supervisors.  A peer reviewer subsequently talks through the issue with
them, both of them understand it better, and the description and
sometimes the nature of the change are altered, reflecting this improved
knowledge.)

Eventually (ideally) full understanding and a code or documentation
change of impact proportional to the problem is arrived at.  Having the
false starts, blind alleys, and mistaken assertions in the master
branch's commit history is confusing to a project's own developers and
to the general public.  For a rigorously-engineered, high-profile, and
(in part) externally-funded project, such digressions are unwelcome.

groff is not the same sort of project, thankfully.  It's more casual and
doesn't draw the attention of suits or uniforms.  If

Re: pic doesn't center when i use a macro

2021-11-01 Thread Tadziu Hoffmann 


> I can do something more manual but i really would like to take advantage
> of the expressivity of pic. Any other comment is also warmly welcome.

It looks like pic has no string variables, and the "if"
works at the statement level, not expression level.

To provide a somewhat constructive answer: do you really
need the "for" loop here?  Perhaps it might also help to
restructure the code, for example like this:

  .PS

  define mybox {
  s = layer * margin
  box width w height h with .sw at (s,s)
  box width w height margin with .nw at last box .nw dashed $1
  w = w - tr
  h = h - tr
  layer = layer + 1
  }

  w = 3; h = 2; margin = .2; tr = 2 * margin; layer = 0
  mybox("Entête Ethernet")
  mybox("Entête IP")
  mybox("Entête TCP")
  mybox("Donnees applicatives")

  .PE

Re: [groff] 05/14: tbl(1): Say decimal "separator", not "point".

2021-11-01 Thread Keith Marshall 
On 01/11/2021 13:19, G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.
> 
> commit a0ec5ffd258b9f54daa46b88471ec837e8213ad1
> Author: Bjarni Ingi Gislason 
> AuthorDate: Sun Oct 31 00:42:09 2021 +
> 
> tbl(1): Say decimal "separator", not "point".

Surely, the correct English-language terminology is "radix point", (and
where the radix is "decimal", this becomes "decimal point").  It is
irrelevant whether the prevailing convention, of the user's locale, is
to represent the radix point by a comma, or a period, we do *not* refer
to a "decimal comma", or a "decimal period", (or a "decimal dot"); the
correct terminology is "decimal point".

This change introduces invalid terminology, and should be reverted.

Re: Git, where zombie branches shamble again

2021-11-01 Thread Keith Marshall 
On 01/11/2021 14:01, G. Branden Robinson wrote:
> At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
>> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson wrote:
>>> Since I am now accused four times over of rewriting history, and
>>> moreover of violating an "absolute taboo", I must insist upon the
>>> presentation of particulars.
>>
>> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
>> the first distributed source management system, hg, git, etc are
>> copies, I'm the guy that figured this model out.
> 
> Fear not!  I've known your name and (some of) your work for many years.
> 
>> If you did not rewrite history, which means you changed things so
>> that a pull won't work or will create a massive merge mess, then
>> you are fine.
> 
> As far as _I_ can tell, neither of these has taken place.

Seriously?  You absolutely _did_ rewrite history ... not just once, but
twice!  You deleted an _entire branch_ of published development history,
then after my subsequent push had reinstated it, you deleted it once
again!  If that isn't rewriting history, then I'd like to know what you
would call it.

Now, I'm sure you made this mistake in ignorance, rather than with any
malicious intent, but it was a history rewriting mistake nonetheless.
Two things which you should never do, after anything has been pushed to
a public repository: you should not rebase any of it; neither should you
delete any of it.

>> The taboo is once you have some history, don't change that because
>> all of the clones of your public repository depend on that history.
> 
> Agreed, and this is consistent with everything I've learned about
> distributed revision control.

Yet you ignored what you suggest you have learned; you _did_ change some
of that (published) history, by deleting an entire branch of it.

>> I'd be happy to get on the phone with you if I could help.  While
>> I may be an SCM guy, I've been a groff fan for decades.  Love to
>> help.
> 
> I appreciate the offer.  I let this issue lie for a few days so Keith
> could lay out the particulars of my cardinal sin, but none have proven
> forthcoming.

Frankly, I thought you might have been smart enough to work it out for
yourself.

> Without an accurate description of damage done (if any) to the
> repository, there is no way anyone can repair it.  And if there is none,
> then charges of rewriting history are overblown, unwarranted, and
> unfriendly.

Claims that you have not done what you so clearly have, are frankly
disingenuous.  The damage done may not be critical, insofar as we may be
able to live without that deleted branch, but a possibility remains,
that it could find its own way back at some future date; indeed, I still
have a local clone, in which that history remains ... 54 commits, per
attached deleted-history.log, (produced by 'hg outgoing' from that ...
now outdated ... clone).comparing with git+ssh://keithmarsh...@git.savannah.gnu.org/srv/git/groff.git
searching for changes
changeset:   4451:aa614de6cbd7
user:Bertrand Garrigues 
date:Sat Apr 03 01:35:46 2021 +0200
summary: Add Deri James'extension to gropdf to draw boxes and sboxes macros.

changeset:   4452:26a3eeeca527
user:G. Branden Robinson 
date:Sun Apr 04 19:19:24 2021 +1000
summary: doc/groff.texi: Remove stray word from recast.

changeset:   4453:6de33277812e
user:G. Branden Robinson 
date:Sun Apr 04 19:20:46 2021 +1000
summary: doc/ms.ms: Fix style nits.

changeset:   4454:a4d08bdbf325
user:G. Branden Robinson 
date:Sun Apr 04 20:43:23 2021 +1000
summary: [docs]: Improve hyphenation discussion.

changeset:   4455:1b6b08cc0806
user:G. Branden Robinson 
date:Mon Apr 05 11:12:26 2021 +1000
summary: doc/groff.texi: Remove unnecessary command.

changeset:   4456:2ec5537895d5
user:G. Branden Robinson 
date:Tue Apr 06 14:50:08 2021 +1000
summary: [docs]: Revise hyphenation discussion.

changeset:   4457:c8c5fbb97eec
user:Dave Kemper 
date:Tue Apr 06 10:48:33 2021 +
summary: [nroff]: Support and document -k and -K options.

changeset:   4458:889e0caf1781
user:G. Branden Robinson 
date:Wed Apr 07 17:07:05 2021 +1000
summary: ChangeLog: Log Dave's fix for Savannah #60349.

changeset:   4459:bffdf9b90c1a
user:G. Branden Robinson 
date:Wed Apr 07 17:58:07 2021 +1000
summary: doc/groff.texi: Fix content and style nits.

changeset:   4460:4c61f307235d
user:G. Branden Robinson 
date:Fri Apr 09 09:37:37 2021 +1000
summary: doc/groff.texi: Fix content nits.

changeset:   4461:eb94463e8aca
user:G. Branden Robinson 
date:Fri Apr 09 10:17:34 2021 +1000
summary: [ms]: Update footnote documentation.

changeset:   4462:3f8b00ff6bd7
user:G. Branden Robinson 
date:Fri Apr 09 12:14:27 2021 +1000
summary: doc/groff.texi (I/O): Shift sentence.

changeset:   4463:9f4f825eec09

Re: Git, where zombie branches shamble again

2021-11-01 Thread Keith Marshall via Groff-commit 
On 01/11/2021 14:01, G. Branden Robinson wrote:
> At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
>> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson wrote:
>>> Since I am now accused four times over of rewriting history, and
>>> moreover of violating an "absolute taboo", I must insist upon the
>>> presentation of particulars.
>>
>> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
>> the first distributed source management system, hg, git, etc are
>> copies, I'm the guy that figured this model out.
> 
> Fear not!  I've known your name and (some of) your work for many years.
> 
>> If you did not rewrite history, which means you changed things so
>> that a pull won't work or will create a massive merge mess, then
>> you are fine.
> 
> As far as _I_ can tell, neither of these has taken place.

Seriously?  You absolutely _did_ rewrite history ... not just once, but
twice!  You deleted an _entire branch_ of published development history,
then after my subsequent push had reinstated it, you deleted it once
again!  If that isn't rewriting history, then I'd like to know what you
would call it.

Now, I'm sure you made this mistake in ignorance, rather than with any
malicious intent, but it was a history rewriting mistake nonetheless.
Two things which you should never do, after anything has been pushed to
a public repository: you should not rebase any of it; neither should you
delete any of it.

>> The taboo is once you have some history, don't change that because
>> all of the clones of your public repository depend on that history.
> 
> Agreed, and this is consistent with everything I've learned about
> distributed revision control.

Yet you ignored what you suggest you have learned; you _did_ change some
of that (published) history, by deleting an entire branch of it.

>> I'd be happy to get on the phone with you if I could help.  While
>> I may be an SCM guy, I've been a groff fan for decades.  Love to
>> help.
> 
> I appreciate the offer.  I let this issue lie for a few days so Keith
> could lay out the particulars of my cardinal sin, but none have proven
> forthcoming.

Frankly, I thought you might have been smart enough to work it out for
yourself.

> Without an accurate description of damage done (if any) to the
> repository, there is no way anyone can repair it.  And if there is none,
> then charges of rewriting history are overblown, unwarranted, and
> unfriendly.

Claims that you have not done what you so clearly have, are frankly
disingenuous.  The damage done may not be critical, insofar as we may be
able to live without that deleted branch, but a possibility remains,
that it could find its own way back at some future date; indeed, I still
have a local clone, in which that history remains ... 54 commits, per
attached deleted-history.log, (produced by 'hg outgoing' from that ...
now outdated ... clone).comparing with git+ssh://keithmarsh...@git.savannah.gnu.org/srv/git/groff.git
searching for changes
changeset:   4451:aa614de6cbd7
user:Bertrand Garrigues 
date:Sat Apr 03 01:35:46 2021 +0200
summary: Add Deri James'extension to gropdf to draw boxes and sboxes macros.

changeset:   4452:26a3eeeca527
user:G. Branden Robinson 
date:Sun Apr 04 19:19:24 2021 +1000
summary: doc/groff.texi: Remove stray word from recast.

changeset:   4453:6de33277812e
user:G. Branden Robinson 
date:Sun Apr 04 19:20:46 2021 +1000
summary: doc/ms.ms: Fix style nits.

changeset:   4454:a4d08bdbf325
user:G. Branden Robinson 
date:Sun Apr 04 20:43:23 2021 +1000
summary: [docs]: Improve hyphenation discussion.

changeset:   4455:1b6b08cc0806
user:G. Branden Robinson 
date:Mon Apr 05 11:12:26 2021 +1000
summary: doc/groff.texi: Remove unnecessary command.

changeset:   4456:2ec5537895d5
user:G. Branden Robinson 
date:Tue Apr 06 14:50:08 2021 +1000
summary: [docs]: Revise hyphenation discussion.

changeset:   4457:c8c5fbb97eec
user:Dave Kemper 
date:Tue Apr 06 10:48:33 2021 +
summary: [nroff]: Support and document -k and -K options.

changeset:   4458:889e0caf1781
user:G. Branden Robinson 
date:Wed Apr 07 17:07:05 2021 +1000
summary: ChangeLog: Log Dave's fix for Savannah #60349.

changeset:   4459:bffdf9b90c1a
user:G. Branden Robinson 
date:Wed Apr 07 17:58:07 2021 +1000
summary: doc/groff.texi: Fix content and style nits.

changeset:   4460:4c61f307235d
user:G. Branden Robinson 
date:Fri Apr 09 09:37:37 2021 +1000
summary: doc/groff.texi: Fix content nits.

changeset:   4461:eb94463e8aca
user:G. Branden Robinson 
date:Fri Apr 09 10:17:34 2021 +1000
summary: [ms]: Update footnote documentation.

changeset:   4462:3f8b00ff6bd7
user:G. Branden Robinson 
date:Fri Apr 09 12:14:27 2021 +1000
summary: doc/groff.texi (I/O): Shift sentence.

changeset:   4463:9f4f825eec09

an officially maintained version of dformat outthere ?

2021-11-01 Thread Marc Chantreux 
hello groffers,

Long time ago, i download this pdf

%K dformat data format CSTR142
%A Jon L. Bentley
%C Bell Labs
%D April 1988
%T DFORMAT - A Program for Typesetting Data Formats
%R CSTR #142
%O 142.ps.gz

I started to use the original implementation available here:

https://github.com/sathlan/dformat

I started to hack on it a little bit

* shebang using # /usr/bin/env -S gawk -f
* the possibility to add comments with #

Then I wanted to add more features and realize someone in
this list already did a part of what i was trying to do:

https://lists.gnu.org/archive/html/groff/2012-11/msg00027.html

This message contains an augmented version of the original paper
with a patched version of the original script with the support of
a 'shaded' style so it is possible to colorize some frames.

Heinz-Jürgen Oertel proposed to add the new version to the groff
project but:

* the patched version of the script is in the pdf file and
  a simple copy/paste just ruins the code.
* there was no anwser to his message.

Before i start to work on it to make it a usable version of dformat,
i have some questions:

* is there a repo of this version outhere ?
* is there a reason no one replied to what I think is a valuable
  contribution (we should probably write a man page to this using
  the existing paper).

regards,
marc

Re: pic doesn't center when i use a macro

2021-11-01 Thread Marc Chantreux 
Le Mon, Nov 01, 2021 at 04:12:46PM -0400, T. Kurt Bond a écrit :
> While I don't have any suggestions as how to fix this, I did try it with
> Heirloom troff, and it seems to have the same unwanted non-centering result
> as groff.

thanks a lot for confirming. i guess the next step would be to gdb pic?
if so: i will come back to a less elegant solution for the moment and
come back later on this.

regards,
marc

Re: pic doesn't center when i use a macro

2021-11-01 Thread T. Kurt Bond 
While I don't have any suggestions as how to fix this, I did try it with
Heirloom troff, and it seems to have the same unwanted non-centering result
as groff.

On Mon, Nov 1, 2021 at 3:52 PM Marc Chantreux  wrote:

> hello groffers,
>
> I wrote the following code to illustrate the DOD model encapsulation.
>
> sadly: the label of the layers are not centred. it seems to be relative
> to the fact i use a function as it works fine when i replace
> label_for(layer) by a simple string
>
> like
>
> box width w height margin \
> with .nw at last box .nw dashed \
> "" label_for(layer) ""
>
> by
>
> box width w height margin \
> with .nw at last box .nw dashed \
> "" "eat the road, jack" ""
>
> I can do something more manual but i really would like to take advantage
> of the expressivity of pic. Any other comment is also warmly welcome.
>
> regards,
> marc
>
> # compiled with
> # scan.ps: scan.ms ${deps} ; groff -skp -ms -mfr $< > $@
>
> .PS
>
> define label_for {
> if $1 == 0 then { "Entête Ethernet"  } else {
> if $1 == 1 then { "Entête IP"} else {
> if $1 == 2 then { "Entête TCP"   } else {
> if $1 == 3 then { "Donnees applicatives" } else {
> } } } }
> }
>
> w = 3 ; h = 2; margin = .2 ; tr = 2 * margin
> for layer = 0 to 3 do {
> s = layer * margin
> box width w height h with .sw at (s,s)
> box width w height margin with .nw at last box .nw dashed ""
> label_for(layer) ""
> w = w - tr
> h = h - tr
> }
> .PE
>
>

-- 
T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io

pic doesn't center when i use a macro

2021-11-01 Thread Marc Chantreux 
hello groffers,

I wrote the following code to illustrate the DOD model encapsulation.

sadly: the label of the layers are not centred. it seems to be relative
to the fact i use a function as it works fine when i replace
label_for(layer) by a simple string

like

box width w height margin \
with .nw at last box .nw dashed \
"" label_for(layer) ""

by

box width w height margin \
with .nw at last box .nw dashed \
"" "eat the road, jack" ""

I can do something more manual but i really would like to take advantage
of the expressivity of pic. Any other comment is also warmly welcome.

regards,
marc

# compiled with
# scan.ps: scan.ms ${deps} ; groff -skp -ms -mfr $< > $@

.PS

define label_for {
if $1 == 0 then { "Entête Ethernet"  } else {
if $1 == 1 then { "Entête IP"} else {
if $1 == 2 then { "Entête TCP"   } else {
if $1 == 3 then { "Donnees applicatives" } else {
} } } }
}

w = 3 ; h = 2; margin = .2 ; tr = 2 * margin
for layer = 0 to 3 do {
s = layer * margin
box width w height h with .sw at (s,s)
box width w height margin with .nw at last box .nw dashed "" 
label_for(layer) ""
w = w - tr
h = h - tr
}
.PE

Re: Sed failure in contrib/sboxes on MacOS

2021-11-01 Thread Douglas McIlroy 
> [POSIX] doesn't say anything about #! in shell scripts.

Of course not. #! has nothing to do with the shell. It is interpreted by exec.

Doug

Re: Git, where zombie branches shamble again

2021-11-01 Thread G. Branden Robinson 
Hi, Larry!

At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson wrote:
> > Since I am now accused four times over of rewriting history, and
> > moreover of violating an "absolute taboo", I must insist upon the
> > presentation of particulars.
> 
> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
> the first distributed source management system, hg, git, etc are
> copies, I'm the guy that figured this model out.

Fear not!  I've known your name and (some of) your work for many years.

> If you did not rewrite history, which means you changed things so
> that a pull won't work or will create a massive merge mess, then
> you are fine.

As far as _I_ can tell, neither of these has taken place.

> The taboo is once you have some history, don't change that because
> all of the clones of your public repository depend on that history.

Agreed, and this is consistent with everything I've learned about
distributed revision control.

> I'd be happy to get on the phone with you if I could help.  While
> I may be an SCM guy, I've been a groff fan for decades.  Love to
> help.

I appreciate the offer.  I let this issue lie for a few days so Keith
could lay out the particulars of my cardinal sin, but none have proven
forthcoming.

Without an accurate description of damage done (if any) to the
repository, there is no way anyone can repair it.  And if there is none,
then charges of rewriting history are overblown, unwarranted, and
unfriendly.

This thread of contention will have to sleep until awakened by a
non-spurious interrupt.

Regards,
Branden


signature.asc
Description: PGP signature
___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

Re: Git, where zombie branches shamble again

2021-11-01 Thread G. Branden Robinson 
Hi, Larry!

At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson wrote:
> > Since I am now accused four times over of rewriting history, and
> > moreover of violating an "absolute taboo", I must insist upon the
> > presentation of particulars.
> 
> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
> the first distributed source management system, hg, git, etc are
> copies, I'm the guy that figured this model out.

Fear not!  I've known your name and (some of) your work for many years.

> If you did not rewrite history, which means you changed things so
> that a pull won't work or will create a massive merge mess, then
> you are fine.

As far as _I_ can tell, neither of these has taken place.

> The taboo is once you have some history, don't change that because
> all of the clones of your public repository depend on that history.

Agreed, and this is consistent with everything I've learned about
distributed revision control.

> I'd be happy to get on the phone with you if I could help.  While
> I may be an SCM guy, I've been a groff fan for decades.  Love to
> help.

I appreciate the offer.  I let this issue lie for a few days so Keith
could lay out the particulars of my cardinal sin, but none have proven
forthcoming.

Without an accurate description of damage done (if any) to the
repository, there is no way anyone can repair it.  And if there is none,
then charges of rewriting history are overblown, unwarranted, and
unfriendly.

This thread of contention will have to sleep until awakened by a
non-spurious interrupt.

Regards,
Branden


signature.asc
Description: PGP signature

Re: [PATCH] *.man: Break URIs at points specified by the Chicago Style

2021-11-01 Thread G. Branden Robinson 
Hi, James!

At 2021-10-18T10:05:55-0400, James K. Lowden wrote:
> Is there a way to say, "set this URL all on one line if at all
> possible, else break at these specific points"?  Sort of a ".ne" for
> horizontal space?

Yes, there is!

[man]: Try to minimize the number of times a URI is broken when it has
to be typeset and prevent it from provoking adjustment warnings.

* tmac/an-ext.tmac (UE, ME): Do it.  New Boolean register `mL` records
  whether the URI will cause a break.  New string `m2` contains the
  user-specified URI (`m1`) plus the angle brackets around it and any
  user-specified trailing punctuation (\$1).  New register `mW` stores
  the formatted width of `m2`.  If the page offset plus the indentation
  plus the current horizontal position on the output line plus `mW`
  exceeds the output line length, turn off adjustment and break the line
  _before_ typesetting `m2`.  Then, if we forced a break, restore the
  previous adjustment mode.  Shift off the first macro parameter and
  emit the (undocumented) rest as before.[1]

> I think URLs are easier to read (like any word) on one line.  I think
> I would rather see one unbroken, even if it meant the preceding line
> had only the word "at" on it.  Whitespace is a lot cheaper today, now
> that ink and paper are mostly made of photons.

I agree, and since I'm one of those weirdos who still lets man pages
undergo adjustment (.ad b), I was exasperated with troff getting cross
when it encountered an un-adjustable line.

Here's how I documented it:

[...]
   support ECMA-48 OSC 8 escape sequences (see grotty(1)).  When
   device support is unavailable or disabled with the U register
   (see section “Options” below), .MT and .UR URIs are rendered
   between angle brackets after the linked text.  If such a URI will
   not fit on the remainder of the output line, the macro package
   temporarily turns off adjustment (if enabled) and breaks the line
   before the URI to minimize the number of output lines over which
   it spreads.
[...]

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=c7efb5fd40aae5293d9de87092b7a4b2be89df91



signature.asc
Description: PGP signature

Re: [PATCH] *.man: Break URIs at points specified by the Chicago Style

2021-11-01 Thread G. Branden Robinson 
Hi, Ralph,

At 2021-10-23T10:46:32+0100, Ralph Corderoy wrote:
> Hi Branden,
> 
> > But in fact, trailing slashes on URIs are semantically
> > significant[1]
> ...
> > [1] 
> > https://stackoverflow.com/questions/5948659/when-should-i-use-a-trailing-slash-in-my-url/
> 
> StackOverflow isn't an authority.

It was useful enough for my purpose at the time.  I'll remember for my
next discussion with you that you require primary sources, not
literature reviews.  :-O

> Trailing slashes are not always significant.  There is no semantic
> difference between these two.
> 
> https://example.com
> https://example.com/
> 
> The difference comes if the slash is at the end of the path component,
> so these two are different.
> 
> https://example.com/foo
> https://example.com/foo/

That's what I was referring to.  I didn't want to spend time in the
groff man pages in semantic dissection of UR{I,L}s.

> When just the domain name is needed, I omit the needless slash as it's
> clutter.

Do you think we should instruct readers of our man pages to follow your
example?

> (Please consider turning off hyphenation and justification when
> producing text to paste; I like MANOPT='--nh --nj'.)

I don't format pages from my groff working tree with man because it's
harder to test my changes to page text and macro packages, among other
things, that way.  But I'll see about making a "test-groff -man" wrapper
suitable for this purpose.

[...]
> .UR http://\:example\:.com/\:fb8afcfbaebc74e\:.cc
[...]
> I think that's too prescriptive.  The example may split at
> 
>  http://
> example.com/fb8afcfbaebc74e.cc
>   http://example
> .com/fb8afcfbaebc74e.cc
>  http://example.com/
> fb8afcfbaebc74e.cc
>   http://example.com/fb8afcfbaebc74e
> .cc
> 
> A small suffix probably shouldn't be marked as a place to split.
> I think there's judgement by the author and the text should just
> advise.

It does--that's why I used the word "recommend".  But I have further
softened the language[1].  The thrust of my observations is that _if_
people break adjacently to slashes or dots in a URI, they should follow
our[2] advice about which sides of these characters to do it on.

They can always eschew breaking altogether, and in fact I've just made
it less painful to do practice such abstinence.[3]

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=0a111a916ee344d5046e244dcc95b4d3f49c352d
[2] well, "my"--but I persuaded Alex, at least :D
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=c7efb5fd40aae5293d9de87092b7a4b2be89df91


signature.asc
Description: PGP signature

[bug #61371] [PATCH] [tbl]: tbl.1.man: use neutral wording "decimal separator" in place of English specific "decimal point" and "dot"

2021-11-01 Thread G. Branden Robinson 
Update of bug #61371 (project groff):

Severity:  3 - Normal => 2 - Minor  
  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #9:


commit a0ec5ffd258b9f54daa46b88471ec837e8213ad1
Author: Bjarni Ingi Gislason 
Date:   Sun Oct 31 00:42:09 2021 +

tbl(1): Say decimal "separator", not "point".

Fixes .


___

Reply to this item at:

  

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

[groff] 14/14: [man]: Modify typeset URI breaking strategy.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit c7efb5fd40aae5293d9de87092b7a4b2be89df91
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 19:33:50 2021 +1100

[man]: Modify typeset URI breaking strategy.

[man]: Try to minimize the number of times a URI is broken when it has
to be typeset and prevent it from provoking adjustment warnings.

* tmac/an-ext.tmac (UE, ME): Do it.  New Boolean register `mL` records
  whether the URI will cause a break.  New string `m2` contains the
  user-specified URI (`m1`) plus the angle brackets around it and any
  user-specified trailing punctuation (\$1).  New register `mW` stores
  the formatted width of `m2`.  If the page offset plus the indentation
  plus the current horizontal position on the output line plus `mW`
  exceeds the output line length, turn off adjustment and break the line
  _before_ typesetting `m2`.  Then, if we forced a break, restore the
  previous adjustment mode.  Shift off the first macro parameter and
  emit the (undocumented) rest as before.

* tmac/groff_man.7.man.in (Hyperlink macros): Document it.

* tmac/tests/an-ext_UE-breaks-before-long-URIs.sh: Test it.
* tmac/tmac.am (tmac_TESTS): Run test.

Prompted by a suggestion from James K. Lowden

--thanks, James!

Also add a credit for myself to an-ext.tmac.
---
 ChangeLog   | 27 
 tmac/an-ext.tmac| 47 ++--
 tmac/groff_man.7.man.in |  6 +++
 tmac/tests/an-ext_UE-breaks-before-long-URIs.sh | 58 +
 tmac/tmac.am|  1 +
 5 files changed, 135 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c548606..4ad4047 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,32 @@
 2021-11-01  G. Branden Robinson 
 
+   [man]: Try to minimize the number of times a URI is broken when
+   it has to be typeset and prevent it from provoking adjustment
+   warnings.
+
+   * tmac/an-ext.tmac (UE, ME): Do it.  New Boolean register `mL`
+   records whether the URI will cause a break.  New string `m2`
+   contains the user-specified URI (`m1`) plus the angle brackets
+   around it and any user-specified trailing punctuation (\$1).
+   New register `mW` stores the formatted width of `m2`.  If the
+   page offset plus the indentation plus the current horizontal
+   position on the output line plus `mW` exceeds the output line
+   length, turn off adjustment and break the line _before_
+   typesetting `m2`.  Then, if we forced a break, restore the
+   previous adjustment mode.  Shift off the first macro parameter
+   and emit the (undocumented) rest as before.
+
+   * tmac/groff_man.7.man.in (Hyperlink macros): Document it.
+
+   * tmac/tests/an-ext_UE-breaks-before-long-URIs.sh: Test it.
+   * tmac/tmac.am (tmac_TESTS): Run test.
+
+   Prompted by a suggestion from James K. Lowden
+   
+   --thanks, James!
+
+2021-11-01  G. Branden Robinson 
+
* src/devices/grohtml/post-html.cpp
(html_printer::do_file_components): Add assertion.
 
diff --git a/tmac/an-ext.tmac b/tmac/an-ext.tmac
index 274f653..fb1b6e4 100644
--- a/tmac/an-ext.tmac
+++ b/tmac/an-ext.tmac
@@ -4,6 +4,7 @@
 .\"
 .\" Written by Eric S. Raymond 
 .\"Werner Lemberg 
+.\"G. Branden Robinson 
 .\"
 .\" You may freely use, modify and/or distribute this file.
 .\"
@@ -139,11 +140,30 @@
 \&\\$*\"
 .  \}
 .  el \{\
+.nr mL 0 \" Will the URI+punctuation cause a break?
+.ds m2 \\*(la\\*(m1\\*(ra\\$1\"
+.nr mW \\w'\\*(m2'
+.\" If the URI won't fit on the rest of the line, break early and
+.\" turn off adjustment.
+.if \\n(.o+\\n(.i+\\n(.ku+\\n(mWu>\\n(.lu \{\
+.  nr mL 1
+.  nr mJ \\n(.j
+.  br
+.  na
+.\}
 .nh
-\\*(la\\*(m1\\*(ra\c
+\\*(m2
+.\" If we had to break before the URI, restore adjustment.
+.if \\n(mL .ad \\n(mJ
+.do shift
 .ie \n(.g \&\\$*\"
-.el \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9\"
+.el \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9\"
 .hy \\n(HY
+.rr mJ
+.rr mW
+.rr mL
+.rm m2
+.rm m1
 .  \}
 ..
 .
@@ -190,11 +210,30 @@
 \&\\$*\"
 .  \}
 .  el \{\
+.nr mL 0 \" Will the URI+punctuation cause a break?
+.ds m2 \\*(la\\*(m1\\*(ra\\$1\"
+.nr mW \\w'\\*(m2'
+.\" If the URI won't fit on the rest of the line, break early and
+.\" turn off adjustment.
+.if \\n(.o+\\n(.i+\\n(.ku+\\n(mWu>\\n(.lu \{\
+.  nr mL 1
+.  nr mJ \\n(.j
+.  br
+.  na
+.\}
 .nh
-\\*(la\\*(m1\\*(ra\c
+\\*(m2
+.\" If we had to break before the URI, restore adjustment.
+.if \\n(mL .ad

[groff] 12/14: [sboxes]: Retitle document.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 229940d821684a44c828ba353aa59be3662fa0c5
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 13:01:03 2021 +1100

[sboxes]: Retitle document.

* contrib/sboxes/msboxes.ms.in: Retitle document to "Using PDF Boxes
  with _groff and_ the ms macros" (emphasis added) to make it clearer
  that this package does not _require_ ms.

Update cross references accordingly.  Also make the foregoing point in
groff_tmac(5).
---
 NEWS |  4 ++--
 contrib/sboxes/ChangeLog |  6 ++
 contrib/sboxes/msboxes.ms.in |  6 --
 doc/ms.ms|  4 +++-
 man/groff_tmac.5.man | 12 +++-
 tmac/groff_ms.7.man  |  4 +++-
 6 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/NEWS b/NEWS
index 8951d18..41f7448 100644
--- a/NEWS
+++ b/NEWS
@@ -130,8 +130,8 @@ o The new rfc1345 macro package, contributed by Dorai 
Sitaram, defines
 o The new sboxes macro package, contributed by Deri James, offers a
   simple interface to the new gropdf(1) "background" feature.  Using it,
   ms documents can draw colored rectangles beneath any groff output.
-  See "Using PDF boxes with the ms macros", installed as `msboxes.ms`
-  and `msboxes.pdf` for instructions and a demonstration.
+  See "Using PDF boxes with groff and the ms macros", installed as
+  `msboxes.ms` and `msboxes.pdf` for instructions and a demonstration.
 
 o The an (man) macro package can now produce clickable hyperlinks within
   terminal emulators, using the OSC 8 support added to grotty(1) (see
diff --git a/contrib/sboxes/ChangeLog b/contrib/sboxes/ChangeLog
index ae848cc..d2496b1 100644
--- a/contrib/sboxes/ChangeLog
+++ b/contrib/sboxes/ChangeLog
@@ -1,3 +1,9 @@
+2021-11-01  G. Branden Robinson 
+
+   * msboxes.ms.in: Retitle document to "Using PDF Boxes with
+   _groff and_ the ms macros" (emphasis added) to make it clearer
+   that this package does not _require_ ms.
+
 2021-10-27  G. Branden Robinson 
 
* notquine.sed: Improve portability and tighten logic.  Thanks
diff --git a/contrib/sboxes/msboxes.ms.in b/contrib/sboxes/msboxes.ms.in
index 74e0337..77e4eee 100644
--- a/contrib/sboxes/msboxes.ms.in
+++ b/contrib/sboxes/msboxes.ms.in
@@ -11,7 +11,7 @@
 .ND March 2021
 .EH '%''March 2021'
 .EF 
-.OH 'Using PDF boxes with the \f[I]ms\f[] macros''%'
+.OH 'Using PDF boxes with \f[I]groff\f[] and the \f[I]ms\f[] macros''%'
 .OF 
 .\" Define a quotation macro.
 .de Qq
@@ -28,7 +28,9 @@
 ..
 .ds FAM H
 .TL
-Using PDF boxes with the
+Using PDF boxes with
+.BI groff
+and the
 .BI ms
 macros
 .AU
diff --git a/doc/ms.ms b/doc/ms.ms
index a6695ad..bc17a05 100644
--- a/doc/ms.ms
+++ b/doc/ms.ms
@@ -3408,7 +3408,9 @@ California at Berkeley.)
 .
 .
 .IP \[bu]
-\[lq]Using PDF boxes with the
+\[lq]Using PDF boxes with
+.I groff
+and the
 .I ms
 macros\[rq];
 Deri James;
diff --git a/man/groff_tmac.5.man b/man/groff_tmac.5.man
index d6a304b..219c6d3 100644
--- a/man/groff_tmac.5.man
+++ b/man/groff_tmac.5.man
@@ -709,15 +709,17 @@ offers a simple interface to the
 device control command supported by
 .MR gropdf @MAN1EXT@ .
 .
-Using it,
-.I ms
-documents can draw colored rectangles beneath any
+Using this package,
 .I groff
-output.
+documents can draw colored rectangles beneath any output;
+it further includes special support for
+.IR "groff ms" .
 .
 See
 .UR file://\%@DOCDIR@/\:msboxes\:.pdf
-\[lq]Using PDF boxes with the
+\[lq]Using PDF boxes with
+.I groff
+and the
 .I ms
 macros\[rq]
 .UE
diff --git a/tmac/groff_ms.7.man b/tmac/groff_ms.7.man
index e4138f9..9c66bea 100644
--- a/tmac/groff_ms.7.man
+++ b/tmac/groff_ms.7.man
@@ -2574,7 +2574,9 @@ Larry Kollar.
 .I \%@DOCDIR@/\:msboxes\:.ms
 .TQ
 .I \%@DOCDIR@/\:msboxes\:.pdf
-\[lq]Using PDF boxes with the
+\[lq]Using PDF boxes with
+.I groff
+and the
 .I ms
 macros\[rq];
 Deri James.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 13/14: [docs]: Fix font desc file content and style nits.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit d837b0e5b0279b7a91a84997747a7177f9327bd9
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 14:34:29 2021 +1100

[docs]: Fix font desc file content and style nits.

Content:
* Directives aren't strictly "one per line"; a few can span more than
  one line.
* Correct and clarify explanation of character/glyph repertoire
  definitions.
  - These entities have to be printable.
  - Fix error: special character glyph names generally _don't_ start
with a backslash here.  Problem introduced by me on 17 July.
  - Discuss the three cases of a charset entry beginning with a
backslash worth mentioning.  (The backslash glyph itself requires no
special treatment here, though in our font descriptions "rs" always
either aliases it or duplicates its definition.)

Style:
* Use imperative mood when explaining device description directives only
  when they have more to do with changing formatter operation (a lot of
  grohtml stuff) than with _describing the device_.
* Postprocessors don't "store" information in device description files,
  they obtain it.
* Refer to "device control" instead of "special" commands.  I complain
  yet again of the reckless overloading of the word "special" in *roff
  documentation.
* Say "font _description_ file" more reliably.
* Say "directive" instead of "keyword".
* Tighten wording.
* Add comment about the weirdness of glyph names starting with \; worth
  noting for source divers but too obscure even for a footnote.

Sync groff.texi with groff_font(5).
---
 doc/groff.texi   | 119 +++
 man/groff_font.5.man | 100 ---
 2 files changed, 121 insertions(+), 98 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index 3767954..2d30c1c 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -17910,16 +17910,16 @@ extensions of those used by @acronym{AT} 
device-independent
 @code{groff} lacks a binary format; all files are text
 files.@footnote{Plan@tie{}9 @code{troff} has also abandoned the binary
 format.}  The device and font description files for a device @var{name}
-are stored in a directory called @file{dev@var{name}}.  The device
+are stored in a @file{dev@var{name}} directory.  The device
 description file is called @file{DESC}, and, for each font@tie{}@var{f}
-supported by the device, a font file called@tie{}@file{@var{f}}, where
-@var{f}@tie{}is usually an abbreviation of a font's name and/or style.
-For example, the @code{ps} (PostScript) device has @code{groff} font
-description files for Times roman (@file{TR}) and Zapf Chancery Medium
-italic (@file{ZCMI}), among many others, while the @code{utf8} device
-(for terminal emulators) has only font descriptions for the roman,
-italic, bold, and bold-italic styles (@file{R}, @file{I}, @file{B}, and
-@file{BI}, respectively).
+supported by the device, a font description file is
+called@tie{}@file{@var{f}}, where @var{f}@tie{}is usually an
+abbreviation of a font's name and/or style.  For example, the @code{ps}
+(PostScript) device has @code{groff} font description files for Times
+roman (@file{TR}) and Zapf Chancery Medium italic (@file{ZCMI}), among
+many others, while the @code{utf8} device (for terminal emulators) has
+only font descriptions for the roman, italic, bold, and bold-italic
+styles (@file{R}, @file{I}, @file{B}, and @file{BI}, respectively).
 
 @menu
 * DESC File Format::
@@ -17935,9 +17935,9 @@ italic, bold, and bold-italic styles (@file{R}, 
@file{I}, @file{B}, and
 @cindex format of font description file
 @pindex DESC@r{ file format}
 
-The @file{DESC} file contains a series of directives, one per line.
-Except for the @code{charset} directive, which must come last (if at
-all), the order of the lines is not important.  If a directive name is
+The @file{DESC} file contains a series of directives; each begins a
+line.  Except for the @code{charset} directive, which must come last (if
+at all), their order is not important.  If a directive name is
 duplicated, however, later entries in the file override previous ones.
 @cindex comments in device description files
 @cindex device description files, comments
@@ -17976,8 +17976,8 @@ this directive.
 
 @item paperlength @var{n}
 @kindex paperlength
-The vertical dimension of the output medium is @var{n}@tie{}basic units.
-Deprecated: use @code{papersize} instead.
+The vertical dimension of the output medium is @var{n}@tie{}basic units
+(deprecated: use @code{papersize} instead).
 
 @item papersize @var{format-or-dimension-pair-or-file-name} @r{@dots{}}
 @kindex papersize
@@ -18012,7 +18012,7 @@ left to right and uses the first valid paper 
specification.
 @item paperwidth @var{n}
 @kindex paperwidth
 The horizontal dimension of the output medium is @var{n}@tie{}basic
-units.

[groff] 11/14: [grohtml]: Add assertion.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit da9ea39380bdc0861e4a40eff684c9989343
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 12:48:32 2021 +1100

[grohtml]: Add assertion.

* src/devices/grohtml/post-html.cpp (html_printer::do_file_components):
  Add assertion.

The command "echo | ./build/test-groff -Thtml" was core dumping on me.
`current_paragraph` was a null pointer.  groff 1.22.4 was fine.  A
bisect did not track down the problem, and it no longer manifested after
return to Git HEAD and rebuilding.  I presume there is a missing
dependency somewhere that skipped necessary rebuilding/relinking.  Until
that can be tracked down, explicitly slam on the brakes if the situation
arises again.
---
 ChangeLog | 5 +
 src/devices/grohtml/post-html.cpp | 1 +
 2 files changed, 6 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 51ad9f0..c548606 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2021-11-01  G. Branden Robinson 
 
+   * src/devices/grohtml/post-html.cpp
+   (html_printer::do_file_components): Add assertion.
+
+2021-11-01  G. Branden Robinson 
+
* src/devices/grops/ps.cpp (usage): Document -p and --version
options.
 
diff --git a/src/devices/grohtml/post-html.cpp 
b/src/devices/grohtml/post-html.cpp
index 5758280..e716217 100644
--- a/src/devices/grohtml/post-html.cpp
+++ b/src/devices/grohtml/post-html.cpp
@@ -5042,6 +5042,7 @@ void html_printer::do_file_components (void)
   if (fragment_no > 1)
 write_navigation(top, prev, next, current);
   else {
+assert(current_paragraph != 0);
 current_paragraph->done_para();
 write_rule();
 if (valid_flag) {

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 09/14: [grops]: Document -p, --version in usage message.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 819645e8b25d91700fb5d01f8583749e5f9f4e0c
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 11:26:09 2021 +1100

[grops]: Document -p, --version in usage message.

* src/devices/grops/ps.cpp (usage): Document -p and --version options.

Also organize usage message consistently with our others, and stop
wrapping the output line: we know neither the width of the terminal nor
the length of the `program_name` string we're interpolating.  See commit
b4de44f0, 19 July.
---
 ChangeLog| 5 +
 src/devices/grops/ps.cpp | 6 +++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2faa406..51ad9f0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2021-11-01  G. Branden Robinson 
+
+   * src/devices/grops/ps.cpp (usage): Document -p and --version
+   options.
+
 2021-10-31  G. Branden Robinson 
 
* tmac/mdoc/doc-nroff (doc-setup-page-layout): Set the title
diff --git a/src/devices/grops/ps.cpp b/src/devices/grops/ps.cpp
index 804e4f5..37ac546 100644
--- a/src/devices/grops/ps.cpp
+++ b/src/devices/grops/ps.cpp
@@ -1868,9 +1868,9 @@ int main(int argc, char **argv)
 static void usage(FILE *stream)
 {
   fprintf(stream,
-"usage: %s [-glmv] [-b n] [-c n] [-w n] [-I dir] [-P prologue]\n"
-"   [-F dir] [files ...]\n",
-program_name);
+"usage: %s [-glm] [-b n] [-c n] [-F dir] [-I dir] [-p paper-format]"
+" [-P prologue] [-w n] [file] ...\n"
+"usage: %s {-v | --version}\n", program_name, program_name);
 }
 
 // Local Variables:

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 08/14: tbl(1): Do some spot cleaning.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 79afd29a346f97c687fadb1878e66471803955b3
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 21:07:06 2021 +1100

tbl(1): Do some spot cleaning.

Content:
* Start standardizing the term "(table) region" as that material between
  ".TS" and the first subsequent ".TE".
* Start standardizing the term "(table) description".  (A table region
  consists of one (or more, separated by .T&) table description(s)).
* Add parenthetical paragraph aiding the reader who knows just enough
  *roff to start making unwarranted assumptions (as I once did, and
  probably will continue to do).  Try to clarify the fact that ".TS",
  ".T&", ".TE" are input tokens to tbl, but macro calls to troff.
* When introducing the term "decimal separator", note that it is
  configurable, in hopes of justifying the sesquipedalian terminology.
* Speak of "alignment", not "justification".
* Advise when tbl(1) generates *roff code to produce warning messages.
  (There are other cases not yet noted.)
* Prefer "table entries" to "data items".
* Instead of talking about "whitespace", identify specific input
  characters.
* Remove discussion of "column separator lines" (not allowing '_', '-',
  or '='); I couldn't figure out what was meant.

Style:
* Recast to use more formal and idiomatic English.
* Stop ending sentences with colons.
* Speak consistently of "GNU extensions", not "GNU tbl only".  Other
  implementations might adopt GNU extensions.
* Say "AT", not "Unix", tbl.  There are many Unices and not all
  shipped AT troff (or not exclusively).
* Use "\[em]", not " \[en] ", to "break" (interrupt) a sentence.
* Turn some sentence fragments into parentheticals.
* Add space after commas in table format specifiers used as paragraph
  tags.

Markup:
* Break input lines after commas.
* Break input lines before and after multi-word parentheticals.
* Use two empty requests where vertical space is expected.
* Protect non-sentential dots from end-of-sentence detection.
---
 src/preproc/tbl/tbl.1.man | 359 +-
 1 file changed, 230 insertions(+), 129 deletions(-)

diff --git a/src/preproc/tbl/tbl.1.man b/src/preproc/tbl/tbl.1.man
index 045b79d..055fdda 100644
--- a/src/preproc/tbl/tbl.1.man
+++ b/src/preproc/tbl/tbl.1.man
@@ -120,20 +120,53 @@ the standard input stream is read.
 .SS Overview
 .\" 
 .
-.B tbl
-expects to find table descriptions wrapped in the
+.I \%@g@tbl
+expects to find table descriptions between input lines that begin with
 .B .TS
-(table start) and
+(table start)
+and
 .B .TE
-(table end) macros.
+(table end).
 .
-Within each such table sections, another table can be defined by
-using the request
-.B .T&
-before the final command
-.BR .TE .
+Within each such table region,
+another description can be preceded with an input line beginning with
+.BR .T& .
+.
+.
+.P
+(Experienced
+.I roff
+users should observe that
+.I \%@g@tbl
+is not a
+.I roff
+language interpreter:
+the default control character must be used,
+and no spaces or tabs are permitted between the control character and
+the macro name.
+.
+These
+.I \%@g@tbl
+input tokens remain as-is in the output,
+where they become ordinary macro calls.
+.
+Macro packages often define
+.BR TS ,
+.BR T& ,
+and
+.B TE
+macros to handle issues of table placement on the page.
+.
+.I \%@g@tbl
+produces
+.I groff
+code to define these macros as empty if their definitions do not exist
+when the formatter encounters a table region.)
+.
+.
+.P
+Each table definition has the following structure.
 .
-Each table definition has the following structure:
 .
 .TP
 .I Global options
@@ -147,6 +180,7 @@ The
 must always be finished by a
 .B "semi-colon ;" .
 .
+.
 .TP
 .I Table format specification
 .
@@ -157,12 +191,12 @@ Each cell in a column is classified by being
 centered,
 left-aligned,
 numeric
-(aligned to a decimal separator),
+(aligned to a configurable decimal separator),
 and so on.
 .
 This specification can have several lines,
 but must be finished by a
-.B dot .
+.B dot .\&
 at the end of the last line.
 .
 After each cell definition,
@@ -187,81 +221,99 @@ is an arbitrary character.
 .
 The line immediately following the
 .B .TS
-macro may contain any of the following global options (ignoring the
-case of characters \[en] Unix tbl only accepts options with all
-characters lowercase or all characters uppercase), separated by
-spaces, tabs, or commas:
+macro may contain any of the following global options
+(ignoring the
+case of characters\[em]AT
+.I tbl \" AT
+accepted only options with all characters in the same lettercase),
+separated by
+spaces,
+tabs,
+or commas.
+.
 .
 .TP
 .B allbox
 Enclose each item of the table in a box.
 .
+.
 .TP
 .B box
 Enclose the

[groff] 07/14: [mdoc]: Use more reasonable fallback title length.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 2c63c2b3cc488ea129302dc46c65374ad334af7a
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 20:03:53 2021 +1100

[mdoc]: Use more reasonable fallback title length.

* tmac/mdoc/doc-nroff (doc-setup-page-layout): Set the title length to
  the configured line length (register `.l`) if register `LT` is not
  defined.  This keeps the title length from being set to 78n when the
  line length is not, preventing the output from looking silly.
---
 ChangeLog   | 8 
 tmac/mdoc/doc-nroff | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index ae58232..2faa406 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2021-10-31  G. Branden Robinson 
 
+   * tmac/mdoc/doc-nroff (doc-setup-page-layout): Set the title
+   length to the configured line length (register `LL`) if register
+   `LT` is not defined.  This keeps the title length from being set
+   to 78n when the line length is not, preventing the output from
+   looking silly.
+
+2021-10-31  G. Branden Robinson 
+
* src/preproc/tbl/main.cpp (main): Emit groff code to define
macro `T&` as empty if it is not already defined.  (All of our
full-service macro packages [except mdoc(7)] already do this, so
diff --git a/tmac/mdoc/doc-nroff b/tmac/mdoc/doc-nroff
index fb07753..133b384 100644
--- a/tmac/mdoc/doc-nroff
+++ b/tmac/mdoc/doc-nroff
@@ -141,7 +141,7 @@
 .  ie r LT \
 .lt \n[LT]u
 .  el \
-.lt 78n
+.lt \n[.l]u
 .
 .  po 0i
 .

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 03/14: [tests]: Get rid of last Bashism known to me.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit e9dcf2425837d21bd22611c48d790814b1e39bc1
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 18:46:10 2021 +1100

[tests]: Get rid of last Bashism known to me.

* src/roff/groff/tests/string_case_xform_requests.sh: Migrate test to
  POSIX shell, dropping use of process substitution (a Bashism).  Also
  rewrite to stop using a here document within a command substitution,
  mainly for paranoia.

Also update old ChangeLog entry; the above
here-document-inside-a-command-substitution didn't provoke a bug in GNU
Bash 3.2, but the one in the earlier entry did.  It appears to involve
the presence of unpaired neutral apostrophes in the here document.
---
 ChangeLog  | 17 -
 src/roff/groff/tests/string_case_xform_requests.sh | 14 +-
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 22cbe4a..529e569 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2021-10-31  G. Branden Robinson 
 
+   * src/roff/groff/tests/string_case_xform_requests.sh: Migrate
+   test to POSIX shell, dropping use of process substitution (a
+   Bashism).  Also rewrite to stop using a here document within a
+   command substitution, mainly for paranoia.
+
+2021-10-31  G. Branden Robinson 
+
* src/devices/grops/ps.cpp (encode_subfont): Update assertion to
check for `sub` parameter being a null pointer rather than
`sub->glyphs`; the latter is a member array of a `subencoding`
@@ -129,11 +136,11 @@
sed semicolon problem.
 
* src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh: Rewrite
-   test to stop using a here document inside a command
-   substitution, which is broken in GNU Bash 3.2 and some other
-   versions.  Instead construct the input with printf(1).  Also
-   gets rid of a Bashism (process substitution) that Ingo pointed
-   out years ago.
+   test to stop using a here document (containing an unpaired
+   single quote) inside a command substitution, which is broken in
+   GNU Bash 3.2 and some other versions.  Instead construct the
+   input with printf(1).  Also gets rid of a Bashism (process
+   substitution) that Ingo pointed out years ago.
* src/utils/grog/tests/recognize-perl-pod.sh: Same problem,
different solution.  The Perl POD output is far too large to
construct programmatically, so move it into an external file...
diff --git a/src/roff/groff/tests/string_case_xform_requests.sh 
b/src/roff/groff/tests/string_case_xform_requests.sh
index 0d85ebb..2c678c2 100755
--- a/src/roff/groff/tests/string_case_xform_requests.sh
+++ b/src/roff/groff/tests/string_case_xform_requests.sh
@@ -20,17 +20,13 @@
 
 groff="${abs_top_builddir:-.}/test-groff"
 
-expected="Résumé résumé RÉSUMÉ"
-
-actual=$("$groff" -Tutf8

[groff] 04/14: [tests]: "#!/usr/bin/env bash" -> "#!/bin/sh"

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit c57f33d08c2b0984777b9b768b0faaeeb17b4f19
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 18:50:01 2021 +1100

[tests]: "#!/usr/bin/env bash" -> "#!/bin/sh"

* src/roff/groff/tests/string_case_xform_requests.sh:
* src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh: Update shebang
  lines to use /bin/sh as the interpreter.
---
 ChangeLog   | 4 
 src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh | 2 +-
 src/roff/groff/tests/string_case_xform_requests.sh  | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 529e569..32da712 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -5,6 +5,10 @@
Bashism).  Also rewrite to stop using a here document within a
command substitution, mainly for paranoia.
 
+   * src/roff/groff/tests/string_case_xform_requests.sh:
+   * src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh: Update
+   shebang lines to use /bin/sh as the interpreter.
+
 2021-10-31  G. Branden Robinson 
 
* src/devices/grops/ps.cpp (encode_subfont): Update assertion to
diff --git a/src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh 
b/src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh
index 0fce270..b2c17bc 100755
--- a/src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh
+++ b/src/roff/groff/tests/on_latin1_device_oq_is_0x27.sh
@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!/bin/sh
 #
 # Copyright (C) 2019-2020 Free Software Foundation, Inc.
 #
diff --git a/src/roff/groff/tests/string_case_xform_requests.sh 
b/src/roff/groff/tests/string_case_xform_requests.sh
index 2c678c2..a9b8fa6 100755
--- a/src/roff/groff/tests/string_case_xform_requests.sh
+++ b/src/roff/groff/tests/string_case_xform_requests.sh
@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!/bin/sh
 #
 # Copyright (C) 2019-2020 Free Software Foundation, Inc.
 #

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 02/14: [grops]: Give an assertion some potency.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 32a49e3a01314d8395efdb60e6bfb7ff3ac585f7
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 11:35:58 2021 +1100

[grops]: Give an assertion some potency.

* src/devices/grops/ps.cpp (encode_subfont): Update assertion to check
  for `sub` parameter being a null pointer rather than `sub->glyphs`;
  the latter is a member array of a `subencoding` struct so it can't be
  a null pointer.  (`glyphs` is an array of pointers to `const char`;
  the _elements_ of the array can [and are initialized to] be null
  pointers, but the address of the array itself will never be in a C/C++
  implementation.)  Detected by Clang 13's
  "-Wtautological-pointer-compare".

Also update editor aid comments, dropping old-style Emacs file-local
variable.
---
 ChangeLog| 11 +++
 src/devices/grops/ps.cpp |  9 +++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 99f3e2e..22cbe4a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,16 @@
 2021-10-31  G. Branden Robinson 
 
+   * src/devices/grops/ps.cpp (encode_subfont): Update assertion to
+   check for `sub` parameter being a null pointer rather than
+   `sub->glyphs`; the latter is a member array of a `subencoding`
+   struct so it can't be a null pointer.  (`glyphs` is an array of
+   pointers to `const char`; the _elements_ of the array can [and
+   are initialized to] be null pointers, but the address of the
+   array itself will never be in a C/C++ implementation.)  Detected
+   by Clang 13's "-Wtautological-pointer-compare".
+
+2021-10-31  G. Branden Robinson 
+
* src/libs/libgroff/new.cpp (delete): Declare `throw()` (no
exceptions thrown); quiets "-Wimplicit-exception-spec-mismatch"
from Clang 13.
diff --git a/src/devices/grops/ps.cpp b/src/devices/grops/ps.cpp
index 8bbc166..804e4f5 100644
--- a/src/devices/grops/ps.cpp
+++ b/src/devices/grops/ps.cpp
@@ -1,4 +1,3 @@
-// -*- C++ -*-
 /* Copyright (C) 1989-2020 Free Software Foundation, Inc.
  Written by James Clark (j...@jclark.com)
 
@@ -851,7 +850,7 @@ void ps_printer::encode_fonts()
 
 void ps_printer::encode_subfont(subencoding *sub)
 {
-  assert(sub->glyphs != 0);
+  assert(sub != 0);
   out.put_literal_symbol(make_subencoding_name(sub->idx))
  .put_delimiter('[');
   for (int i = 0; i < 256; i++)
@@ -1873,3 +1872,9 @@ static void usage(FILE *stream)
 "   [-F dir] [files ...]\n",
 program_name);
 }
+
+// Local Variables:
+// fill-column: 72
+// mode: C++
+// End:
+// vim: set cindent noexpandtab shiftwidth=2 textwidth=72:

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/14: [libgroff]: Quieten Clang 13 warning.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 6990fdf589933244934a7d54320477b207dec0ae
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 11:07:43 2021 +1100

[libgroff]: Quieten Clang 13 warning.

* src/libs/libgroff/new.cpp (delete): Declare `throw()` (no exceptions
  thrown); quiets "-Wimplicit-exception-spec-mismatch" from Clang 13.

Seen on Mac OS X.

Also add editor aid comments.
---
 ChangeLog | 6 ++
 src/libs/libgroff/new.cpp | 8 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index b74254b..99f3e2e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2021-10-31  G. Branden Robinson 
 
+   * src/libs/libgroff/new.cpp (delete): Declare `throw()` (no
+   exceptions thrown); quiets "-Wimplicit-exception-spec-mismatch"
+   from Clang 13.
+
+2021-10-31  G. Branden Robinson 
+
* m4/groff.m4: Fix messaging nits.
(GROFF_MAKEINFO): Set `missing` to "missing 'makeinfo'" for
consistency with other assignments to `missing`.
diff --git a/src/libs/libgroff/new.cpp b/src/libs/libgroff/new.cpp
index 4c6d1b8..2af976c 100644
--- a/src/libs/libgroff/new.cpp
+++ b/src/libs/libgroff/new.cpp
@@ -48,7 +48,7 @@ void *operator new(size_t size)
   return p;
 }
 
-void operator delete(void *p)
+void operator delete(void *p) throw()
 {
   if (p)
 free(p);
@@ -67,3 +67,9 @@ void operator delete(void *p,
   if (p)
 free(p);
 }
+
+// Local Variables:
+// fill-column: 72
+// mode: C++
+// End:
+// vim: set cindent noexpandtab shiftwidth=2 textwidth=72:

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 06/14: [tbl]: Supply (empty) fallback `T&` definition.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 91cee73b19b46e759abc92037940b7a5df0daa18
Author: G. Branden Robinson 
AuthorDate: Sun Oct 31 19:56:45 2021 +1100

[tbl]: Supply (empty) fallback `T&` definition.

* src/preproc/tbl/main.cpp (main): Emit groff code to define macro `T&`
  as empty if it is not already defined.  (All of our full-service macro
  packages [except mdoc(7)] already do this, so there's no change in
  semantics; mom(7) even defines it as an empty _string_.)
---
 ChangeLog| 8 
 src/preproc/tbl/main.cpp | 1 +
 2 files changed, 9 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 32da712..ae58232 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2021-10-31  G. Branden Robinson 
 
+   * src/preproc/tbl/main.cpp (main): Emit groff code to define
+   macro `T&` as empty if it is not already defined.  (All of our
+   full-service macro packages [except mdoc(7)] already do this, so
+   there's no change in semantics; mom(7) even defines it as an
+   empty _string_.)
+
+2021-10-31  G. Branden Robinson 
+
* src/roff/groff/tests/string_case_xform_requests.sh: Migrate
test to POSIX shell, dropping use of process substitution (a
Bashism).  Also rewrite to stop using a here document within a
diff --git a/src/preproc/tbl/main.cpp b/src/preproc/tbl/main.cpp
index 8cb19e8..2c2d879 100644
--- a/src/preproc/tbl/main.cpp
+++ b/src/preproc/tbl/main.cpp
@@ -1595,6 +1595,7 @@ int main(int argc, char **argv)
 }
   printf(".if !\\n(.g .ab GNU tbl requires groff extensions; aborting\n"
 ".do if !dTS .ds TS\n"
+".do if !dT& .ds T&\n"
 ".do if !dTE .ds TE\n");
   if (argc > optind) {
 for (int i = optind; i < argc; i++) 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 10/14: groff_man*(7): Fix content and style nits.

2021-11-01 Thread G. Branden Robinson 
gbranden pushed a commit to branch master
in repository groff.

commit 0a111a916ee344d5046e244dcc95b4d3f49c352d
Author: G. Branden Robinson 
AuthorDate: Mon Nov 1 11:46:48 2021 +1100

groff_man*(7): Fix content and style nits.

Content:
* : Attempt to clarify the meaning of the "section" (manual volume).
* : Remove use of passive voice to make it clear that the package
  will perform any necessary abbreviation of `TH` parameters.
* (Hyperlink macros): Advise reader that arguments to `MR`, `MT`, and
  `UR` should be prepared for typesetting (meaning: use escapes for the
  hyphen-minus, apostrophe, double quote, grave accent, caret,
  backslash, and tilde, though apart from the first, many of those are
  doubtless uncommon or invalid in their remote contexts).
* (Hyperlink macros): Soften guidance regarding URI breaking; discretion
  is warranted.  Thanks to Ralph Corderoy for the suggestion.
* (Deprecated features): Explicitly annotate `OP` macro as an extension.

Style:
* Spell "PostScript" with StudlyCaps.
---
 tmac/groff_man.7.man.in | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/tmac/groff_man.7.man.in b/tmac/groff_man.7.man.in
index 74282fd..09b912f 100644
--- a/tmac/groff_man.7.man.in
+++ b/tmac/groff_man.7.man.in
@@ -348,7 +348,7 @@ macros.
 .RI " [" header-middle ]
 Define the title of the man page as
 .I title
-and the section of the manual volume as
+and the volume of the manual to which it belongs as
 .IR section .
 _ifstyle()dnl
 .
@@ -405,13 +405,15 @@ If
 is a simple integer between 1 and\~9 (inclusive),
 there is no need to specify
 .IR header-middle ;
-the macro package will supply text for it.
+.I an.tmac
+will supply text for it.
 .
+The macro package may also abbreviate
 .I title
 and
 .I footer-inside
-may each be abbreviated with an ellipsis if they overrun the space
-available in the header and footer,
+with an ellipsis if they overrun the space available in the header and
+footer,
 respectively.
 .
 For HTML output,
@@ -1180,10 +1182,24 @@ Plan\~9
 .I troff \" Plan 9
 implements
 .BR .MR .
-_ifstyle()dnl
 .
 .
 .P
+The arguments to
+.BR .MR ,
+.BR .MT ,
+and
+.B .UR
+should be prepared for typesetting since they can appear in the
+output.
+.
+Use special character escape sequences to encode Unicode basic Latin
+characters where necessary,
+particularly the hyphen-minus.
+_ifstyle()dnl
+.
+(See section \[lq]Portability\[rq] below.)
+.
 URIs can be lengthy;
 rendering them can result in jarring adjustment or variations in line
 length,
@@ -1197,7 +1213,7 @@ after each slash
 (or series thereof),
 and before each dot
 (or series thereof)
-is recommended.
+is recommended as a rule of thumb.
 .
 The former practice avoids forcing a trailing slash in a URI onto a
 separate output line,
@@ -1250,13 +1266,13 @@ _ifstyle()dnl
 .EX
 The output driver
 \&.MR grops @MAN1EXT@
-produces Postscript from
+produces PostScript from
 \&.I troff
 output.
 \&.
 The Ghostscript program (\[rs]c
 \&.MR gs 1 )
-interprets Postscript and PDF.
+interprets PostScript and PDF.
 .EE
 .RE
 _endif()dnl
@@ -2880,7 +2896,7 @@ Square brackets in roman surround both arguments.
 .IP
 Use of this quasi-semantic macro,
 .\" https://github.com/n-t-roff/DWB3.3/blob/master/macros/man/an.sr#L37
-originating in Documenter's Workbench
+an extension originating in Documenter's Workbench
 .IR troff ,\" DWB
 is deprecated.
 .

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

Re: SEE ALSO fails

2021-11-01 Thread Tadziu Hoffmann 


> If the proposal is to remove See Also's that aren't installed, I
> could not be more against that idea.  That just makes the system
> harder to learn.

I agree.

Also, some of the manual pages reference Bell Labs Technical
Reports or other papers that are hardly ever installed on any
system.  Nevertheless, these "see also" entries are still helpful
to the reader by indicating specific non-manpage documentation
that contains relevant information on the subject.