Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[Dave Kemper]

On 1/23/24, G. Branden Robinson  wrote:
> At 2024-01-23T20:52:34-0600, Dave Kemper wrote:
>> However, .bp arguably shouldn't have been affected by the change,
>> since it probably wasn't subject to the same historical ambiguity.
>
> I agree, and I wasn't happy about it.

I wonder if the proper way to address this lies in core groff.

Having no-space mode suppress .bp seems quirky, and at odds with the
info manual's stated use case for the mode: "A paragraphing macro
might ordinarily insert vertical space to separate paragraphs.  A
section heading macro could invoke 'ns' to suppress this spacing for
the first paragraph in a section."  (CSTR #54, befitting its terser
nature, suggests no usage for .ns.)  But of course this behavior
cannot be overturned unilaterally.

However, .ns currently takes no arguments -- but it could, a value to
specify "suppress only vertical space, but not page breaks."  The
behavior with no argument would be unchanged, so historical usage
would work as it always has.

There are probably down sides to this I haven't thought of.

[bug #65201] [mm] support section-page numbering style in index

[Dave]

Update of bug#65201 (group groff):

 Summary: [mm] support secion-page numbering style in index =>
[mm] support section-page numbering style in index


___

Reply to this item at:

  

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

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

Hi Dave,

At 2024-01-23T20:52:34-0600, Dave Kemper wrote:
> However, .bp arguably shouldn't have been affected by the change,
> since it probably wasn't subject to the same historical ambiguity.

I agree, and I wasn't happy about it.

> (I bet implementing that distinction would require some macro
> gymnastics, though, since a user-invoked .ns *should* suppress .bp,
> while a -ms-invoked post-display one shouldn't.)

Yes.  I thought about adding a `BP` macro to _groff_ ms, meaning
essentially "restore spacing mode and break now, damn it, even if we're
in a diversion" (see tbl(1)).  But I decided that so much rendering of
ms documents is of historical ones that this wouldn't really help much.

And unlike with man(7) and mdoc, ms users are _expected_ to define their
own macros.  It's so expected that I _think_ one of the reasons USG (or
whatever it was called back around PWB/Unix 1.0 days) forked ms off into
mm was because they had, or expected, users who would be less ambitious
than those in the (1)127 building that housed the CSRC, and who would
approach macro authorship with much greater trepidation.

Thus, in mm(7), there was an explicit list of "safe" requests and the
user was warned off of using others.

  "Most formatter requests should not be used with MM because MM
  provides equivalent functionaltiy[sic] in a much more user-oriented
  and surprise-free fashion than do the basic formatter requests.
  However, some formatter requests are useful, namely [...]  Use of
  other requests without fully understanding their implications very
  often leads to disaster."
  -- "MM - A Macro Package for Generating Documents" (DWB 3.3), §3.3

Eric Allman similarly documented a list of requests one could "use with
impunity" with the me(7) package, once it was initialized.

Peter Schaffter's mom(7), of course, takes this principle to its logical
conclusion.

In my imagination I conceive a bit of friendly one-upmanship in the CSRC
with respect to how much mastery one could demonstrate of Ossanna's
famously impenetrable formatter, which Kernighan's device-independent
rewrite may have somewhat de-obfuscated but did not really demystify.
(Many symbol names remained reconditely encoded, as we can see through
their survival into DWB troff.)

But that community, and the one served by the (proto-?)USG, did not, I
suspect, share that trait.

Regards,
Branden


signature.asc
Description: PGP signature

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

At 2024-01-24T02:26:44+, Bjarni Ingi Gislason wrote:
>   This is a regression (not backward compatible)

It's a _change_.  That's why it's documented in the ChangeLog file.

It is a change that can have a significant measurable effect on user
documents.  That's why it's documented in the NEWS file.

> caused by Branden acting as a developer (not as a maintainer).

If you want something "maintained" at a point of stagnation, the easy
and obvious thing to do is to pick a version of groff that you're
satisfied with and never upgrade it.

>   This is the second case of this kind of a bug (bug #65077),

I figured some people would notice; that is why it is documented in the
NEWS file.

>  see for example "CSTR #54", chapter 5, about the 'ns' request or
> the "groff.info" (info groff) and groff(7) (incomplete).

More relevant to this topic is Lesk's paper on the ms macro package,
"Typing Documents on the UNIX System".[1]  It falls unfortunately short
of a strict specification, and unlike later macro packages' manuals, it
does not offer an explicit list of formatter requests that are "safe" to
use with it.

In areas where a system is not specified, divergence can be expected
among multiple implementations.

Further, the `DD` display distance, at issue here, register was not even
a feature of Lesk/AT ms, but an innovation by 4.2BSD.  The relevant
paper for this is by Tuthill.[2]  It also did not mention how it
interacted with no-space mode, nor with how vertical spacing was
expected to accumulate (or not) with inter-paragraph spacing or spacing
before section headings.

See .

Decisions had to be made.  I made ones that made groff render Kernighan
& Cherry's "Typesetting Mathematics" paper render reasonably well.[3]

>   Macros for historical documents should be put into a separate
> directory (e.g., tmac/historical), which can then be searched
> with the '-M ' option.

If someone wants to contribute precise work-alikes for historical
implementation of macro packages, we have a mechanism and place for
that--the "contrib" directory, and it can be accessed as you describe.

But someone has to step up, do the work, and do it conscientiously.
Among other matters, they should employ a GPL-compatible Free Software
license if they want groff to adopt it, and they should avoid
plagiarizing historical macro package implementations.

>   The user should have control, not a committer.

The user _has_ control.  groff is Free Software.  You know this because
you maintain your own private fork of groff, and your failure to measure
the GNU version of it has led you repeatedly to file defect reports that
are inapplicable to GNU groff, arising from observations you make of
your own changes.[4]

>   Read the "mission statement" in
> https://www.gnu.org/software/groff/

I'm familiar with it.  If you mean to charge me with infidelity to its
objectives, you are going to have to be specific regarding which goal
you feel I have frustrated.  If you can't do that, then your attempt at
deploying it to lend your argument weight is counterfeit.

Regards,
Branden

[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/msmacros/ms
[2] 
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/doc/msmacros/ms.diffs
[3] https://github.com/g-branden-robinson/retypesetting-mathematics
[4] 
https://savannah.gnu.org/bugs/index.php?go_report=Apply=groff==custom=0_id=225=0_id==bjarnigroff_by=0_id=0_to=0_group_id=0_id=0=0_id=0_release_id=0_search=0_field=0_event=modified_date_dayfd=24_date_monthfd=1_date_yearfd=2024=50=5=1#options


signature.asc
Description: PGP signature

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[Dave Kemper]

On 1/23/24, Bjarni Ingi Gislason  wrote:
>   Macros for historical documents should be put into a separate
> directory (e.g., tmac/historical), which can then be searched
> with the '-M ' option.

As the NEWS item (posted in full a couple hours ago in this thread)
mentions, this change *increases* the back compatibility of some
historical documents, so it would likely be eligible for your proposed
tmac/historical directory on those grounds.

The root of the problem, as the savannah bug you cited points out, is
that the historical -ms specification was ambiguous about how it
handled post-display spacing, so naturally different authors made
different assumptions.

However, .bp arguably shouldn't have been affected by the change,
since it probably wasn't subject to the same historical ambiguity.  (I
bet implementing that distinction would require some macro gymnastics,
though, since a user-invoked .ns *should* suppress .bp, while a
-ms-invoked post-display one shouldn't.)

>   The user should have control, not a committer.

Since the user can always force extra vertical space or a page break,
the user does have control.

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[Bjarni Ingi Gislason]

  This is a regression (not backward compatible) caused by
Branden acting as a developer (not as a maintainer).

  This is the second case of this kind of a bug (bug #65077),
 see for example "CSTR #54", chapter 5, about the 'ns' request or
the "groff.info" (info groff) and groff(7) (incomplete).

  Macros for historical documents should be put into a separate
directory (e.g., tmac/historical), which can then be searched
with the '-M ' option.

  The user should have control, not a committer.

  Read the "mission statement" in
https://www.gnu.org/software/groff/

  See also

commit 3061f20f53e3616a8577fd2ecce1b068d0d66dd4
Author: G. Branden Robinson [...]
Date:   Thu Jan 26 19:08:17 2023 -0600

[ms]: Enable no-space mode in `TE` macro.

* tmac/s.tmac (TE): Enable no-space mode after outputting the
display
  distance vertically, replacing any inter-paragraph distance
that might
  follow.

diff --git a/ChangeLog b/ChangeLog
index 4603d7d91..5a1fbc4b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2023-01-26  G. Branden Robinson [...]
+
+   * tmac/s.tmac (TE): Enable no-space mode after outputting
the
+   display distance vertically, replacing any inter-paragraph
+   distance that might follow.
+
 2023-01-24  G. Branden Robinson [...]

[grohtml]: Fix misleading diagnostic message.
diff --git a/tmac/s.tmac b/tmac/s.tmac
index 3cacfdedb..bdf36b885 100644
--- a/tmac/s.tmac
+++ b/tmac/s.tmac
@@ -2031,7 +2031,10 @@ along with this program.  If not, see
.
 .ie '\\n(.z'tbl*header-div' .@error-recover .TS H but no .TH
before .TE
 .el \{\
 .  nr tbl*have-header 0
-.   if !'\*(.T'html' .sp \\n[DD]u
+.  if !'\*(.T'html' \{\
+.  sp \\n[DD]u
+.  ns
+.  \}
 .\}
 .HTML-IMAGE-END
 .if '\*(.T'html' \

Re: Groff's -mm Indexing

[G. Branden Robinson]

[self-follow-up]

At 2023-07-01T05:58:16-0500, G. Branden Robinson wrote:
> We could:
> 
> 1.  Make `INITI` recongize a "location-type" argument of 'C' (for
> "custom"), where the entry format is whatever the user supplies as
> the arguments to `IND`.
> 2.  Make `IND` require two arguments minimum if the "location-type" is
> 'C'.
> 
> But before I mess with that I think I want to support 'S' for
> section-page numbering in the index, and audit use of `hd*mark` to see
> if it's being used other places where `hd@mark-trimmed` should be.

I performed that audit several months ago and was satisfied, but I just
did it again since I didn't leave any record thereof.  So if one snuck
through, it will be due to my failure of vigilance twice over.  :P

I've filed Savannah #65201 for the section-page numbering issue.

Regards,
Branden


signature.asc
Description: PGP signature

[bug #65201] [mm] support secion-page numbering style in index

[G. Branden Robinson]

URL:
  

 Summary: [mm] support secion-page numbering style in index
   Group: GNU roff
   Submitter: gbranden
   Submitted: Wed 24 Jan 2024 02:07:00 AM UTC
Category: Macro mm
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 24 Jan 2024 02:07:00 AM UTC By: G. Branden Robinson 
GNU _mm_'s indexing system doesn't appear to support this page numbering
convention in the indexes it generates.  Make it do so.

Background:
https://lists.gnu.org/archive/html/groff/2023-07/msg4.html







___

Reply to this item at:

  

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

[bug #65198] [bjarnigroff] mom/examples/*.txt: change '-k' to '-K utf8'

[G. Branden Robinson]

Follow-up Comment #3, bug#65198 (group groff):


[comment #2 comment #2:]
> 
>   This ticket is not invalid as this is about the content of the
> *.txt files.
> 
>   How does the command change the ascii text?

It doesn't.  There are none in the source tree and GNU _groff_ doesn't
generate any (from the artifacts in this directory).

Go to
https://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/mom.am?h=1.23.0
and search the file for "txt".

Possibly you generate plain text versions of these documents in your private
fork.

So, yes, the ticket is and remains invalid.


___

Reply to this item at:

  

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

[bug #65198] [bjarnigroff] mom/examples/*.txt: change '-k' to '-K utf8'

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug#65198 (group groff):


  This ticket is not invalid as this is about the content of the
*.txt files.

  How does the command change the ascii text?



___

Reply to this item at:

  

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

[bug #65199] deprecate the option '-k' on the command line

[G. Branden Robinson]

Update of bug#65199 (group groff):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Rejected   
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

[comment #0 original submission:]
> Subject: deprecate the option '-k' on the command line
> 
>   The option '-k' is superfluous,
> 
> 1) the input file must be readable
> 
> 2) thus the encoding can be found

Incorrect.  (2) does not follow from (1).  Read the _preconv_(1) man
page.


   iconv support
   While preconv recognizes all of the coding tags listed above, it
   is capable on its own of interpreting only three encodings:
   Latin‐1, code page 1047, and UTF‐8.  If iconv support is
   configured at compile time and available at run time, all others
   are passed to iconv library functions, which may recognize many
   additional encoding strings.  The command “preconv -v” discloses
   whether iconv support is configured.


If a user's _groff_ build lacks a sufficiently capable _iconv_(3)
implementation, then an encoding will not necessarily be correctly
deduced.

> 3) '-k' is unnecessary used to find the encoding that can
> already be found and used

There is more of the _preconv_(1) man page that you appear not to have
read.


   The use of iconv means that characters in the input that encode
   invalid code points for that encoding may be dropped from the
   output stream or mapped to the Unicode replacement character
   (U+FFFD).  Compare the following examples using the input “café”
   (note the “e” with an acute accent), which due to its short
   length challenges inference of the encoding used.
  printf 'caf\351\n' | LC_ALL=en_US.UTF-8 preconv
  printf 'caf\351\n' | preconv -e us-ascii
  printf 'caf\351\n' | preconv -e latin-1
   The fate of the accented “e” differs in each case.  In the first,
   uchardet fails to detect an encoding (though the library on your
   system may behave differently) and preconv falls back to the
   locale settings, where octal 351 starts an incomplete UTF‐8
   sequence and results in the Unicode replacement character.  In
   the second, it is not a representable character in the declared
   input encoding of US‐ASCII and is discarded by iconv.  In the
   last, it is correctly detected and mapped.


> 4) the preconv is used every time to find the encoding of the file
> when used as an input file, which is a waste of resources.

No.  _preconv_(1) is not run unconditionally by _groff_, but only when
demanded by the `-k` or `-K` options.

> Actions:
> 
> 1) man pages need to announce that '-k' is deprecated and '-K
> ' should be used instead
> 
> 2) the scripts "groff" and "nroff" should announce the same as the
> man pages
> 
> 3) other commands that accept the '-k' option should do the same.

I disagree with all of this.

Closing as rejected.



___

Reply to this item at:

  

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

[bug #65198] [bjarnigroff] mom/examples/*.txt: change '-k' to '-K utf8'

[G. Branden Robinson]

Update of bug#65198 (group groff):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[bug #65198] [bjarnigroff] mom/examples/*.txt: change '-k' to '-K utf8'

[G. Branden Robinson]

Update of bug#65198 (group groff):

Severity:  3 - Normal => 1 - Wish   
  Item Group:   Documentation => Build/Installation 
  Status:None => Invalid
 Assigned to:None => gbranden   
 Summary: mom/examples/*.txt: change '-k' to '-K utf8' =>
[bjarnigroff] mom/examples/*.txt: change '-k' to '-K utf8'

___

Follow-up Comment #1:

There's nothing to change here.  The master branch already uses '-K
utf8', and has for quite a while.

4af85b7ed6 (G. Branden Robinson 2022-08-29 22:34:28 -0500  30)   $(PDFMOMBIN)
$(FFLAG) $(MFLAG) -M$(mom_srcdir) -K utf8 -p -e -t

Possibly this is a fix you did not merge to your private fork of
_groff_.

Resolving as invalid.



___

Reply to this item at:

  

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

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

At 2024-01-23T19:10:00-0600, Dave Kemper wrote:
> On 1/23/24, T. Kurt Bond  wrote:
> > I have a groff -ms source file
> [...]
> > When I groff it with version 1.23.0 the page breaks
> > corresponding to the explicit .bp requests are missing.
> 
> This item in the (very lengthy) NEWS file for 1.23 probably explains
> the change you're seeing:
> 
>   The s (ms) macro package now enables the formatter's "no-space mode"
>   after ending displays (`DE`), equations (`EN`), tables (`TE`), and
>   pictures without flyback (`PE`).  This means that display distance
>   spacing (the `DD` register) overrides the spacing that may follow in
>   a subsequent paragraph, section heading, or display instead of
>   accumulating with that distance.  This change is to make the behavior
>   of the package more predictable; you can fine-tune such spacing by
>   setting the `DD` register in desired places.  It has also helped us
>   to improve groff ms's rendering of historical ms(7) documents such as
>   Kernighan & Cherry's "Typesetting Mathematics".
> 
> As documented, .bp has no effect in no-space mode.  You can force it
> to start a new page anyway by defining your own simple macro that
> first disables no-space mode (via the .rs request), then invokes .bp.
> Then call that macro where you'd normally call .bp.

Thanks for clearing this up, Dave.  I'll amend the NEWS item to mention
page breaks as well.  That won't help a lot of people since 1.23.0 is
already out, but it may help a few in the future.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Proposed: make \X read its argument in copy mode

[G. Branden Robinson]

Hi Deri,

At 2024-01-23T11:32:02+, Deri wrote:
> Just to be sure, can you confirm your intention is to return .device
> to its 1.23.0 state, and mirror that behaviour for \X,

Yes, that is my intention.

> so we will have no more red seepage.

Not sure what that is, so I can't promise it.  Does it have to do with
the phase of the moon?  :P

Regards,
Branden


signature.asc
Description: PGP signature

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[Dave Kemper]

On 1/23/24, T. Kurt Bond  wrote:
> I have a groff -ms source file
[...]
> When I groff it with version 1.23.0 the page breaks
> corresponding to the explicit .bp requests are missing.

This item in the (very lengthy) NEWS file for 1.23 probably explains
the change you're seeing:

  The s (ms) macro package now enables the formatter's "no-space mode"
  after ending displays (`DE`), equations (`EN`), tables (`TE`), and
  pictures without flyback (`PE`).  This means that display distance
  spacing (the `DD` register) overrides the spacing that may follow in
  a subsequent paragraph, section heading, or display instead of
  accumulating with that distance.  This change is to make the behavior
  of the package more predictable; you can fine-tune such spacing by
  setting the `DD` register in desired places.  It has also helped us
  to improve groff ms's rendering of historical ms(7) documents such as
  Kernighan & Cherry's "Typesetting Mathematics".

As documented, .bp has no effect in no-space mode.  You can force it
to start a new page anyway by defining your own simple macro that
first disables no-space mode (via the .rs request), then invokes .bp.
Then call that macro where you'd normally call .bp.

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Lennart Jablonka]

Quoth Lennart Jablonka:

I’ve attached a PDF of our favourite table.



Content-Type: application/pdf
Content-Disposition: attachment; filename="table1.pdf"
Content-Transfer-Encoding: quoted-printable


Oops.  That should be application/postscript and table1.ps.

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Lennart Jablonka]

Quoth Lennart Jablonka:

and the character codes emitted are still those of the C/A/T,
resulting in the wrong glyphs being used.


The codes should probably be remapped by default, with a command-line
option to restore the original ones.  I would of course recommend
writing out 'C' commands with groff special character names.


The C instruction exists in AT troff, just not for names longer (or 
shorter?) than two characters.  I’d rather not depend on groff.  But 
yes, for such a remapping, I’ll probably use the c and C instructions.


I done did it, or something.  I’ve attached a PDF of our favourite 
table.  As you can see, there are still some issues left not 
explained by not having the correct Times: The ■ is at the 
right of the line, even though it’s on the left in the input.  
The $ is on the fifth line, even though it’s on the fourth in the 
input.  And the extra pages at the end.


PS: heirloom troff -Tpost has a ∨ for \(or instead of 
the proper |.


table1.pdf
Description: Adobe PDF document

[bug #65199] deprecate the option '-k' on the command line

[Bjarni Ingi Gislason]

URL:
  

 Summary: deprecate the option '-k' on the command line
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 23 Jan 2024 09:03:22 PM UTC
Category: General
Severity: 3 - Normal
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 23 Jan 2024 09:03:22 PM UTC By: Bjarni Ingi Gislason 
Subject: deprecate the option '-k' on the command line

  The option '-k' is superfluous,

1) the input file must be readable

2) thus the encoding can be found

3) '-k' is unnecessary used to find the encoding that can
already be found and used

4) the preconv is used every time to find the encoding of the file when used
as an input file, which is a waste of resources.

Actions:

1) man pages need to announce that '-k' is deprecated and '-K
' should be used instead

2) the scripts "groff" and "nroff" should announce the same as the
man pages

3) other commands that accept the '-k' option should do the same.







___

Reply to this item at:

  

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

[bug #65198] mom/examples/*.txt: change '-k' to '-K utf8'

[Bjarni Ingi Gislason]

URL:
  

 Summary: mom/examples/*.txt: change '-k' to '-K utf8'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 23 Jan 2024 08:52:54 PM UTC
Category: Macro mom
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 23 Jan 2024 08:52:54 PM UTC By: Bjarni Ingi Gislason 
Subject: mom/examples/*.txt: change '-k' to '-K utf8'

  The example files are built with '-K utf8' in the "mom.am" file.

  See "https://lists/gnu.org/archive/html/groff/2024-01/msg00106.html;
(Subject: mom example documents PDF conversions in Fedora 39 distribution)








___

Reply to this item at:

  

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

[bug #61453] want native mechanism for continuous (non-paginated) rendering

[Dave]

Follow-up Comment #8, bug#61453 (group groff):

[comment #7 comment #7:]
> We could then migrate (some of) our macro packages to support
> continuous rendering under this approach rather than the
> current one, which has caused other problems.  See bug #57665
> and bug #63960.

and now bug #65189.


___

Reply to this item at:

  

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

[bug #65190] [man, mdoc] revise implementation of continuous rendering mode

[Dave]

Follow-up Comment #3, bug#65190 (group groff):

This seems like a specific case of the general enhancement bug #61453 seeks.


___

Reply to this item at:

  

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

[bug #65189] grotty: table output broken after movement of one row

[G. Branden Robinson]

Follow-up Comment #3, bug#65189 (group groff):

Hi Dirk,

[comment #2 comment #2:]
> Sorry that I forgot to mention it: groff-1.23.0 is what I am using
> here.

Thanks for confirming that.  The problem you describe goes way back. :-O

> Because I wondered why man(1) has no problems in formatting the
> attached lsp-help.1 whereas
> 

> $ nroff -t -man lsp-help.broken.1


> 
> has, I had a closer look and here on my system (Gentoo) nroff(1) is
> called with *-mandoc*.  Depending on the current size of the terminal
> more options are used, e.g.:
> 

> nroff -mandoc -c -rLL=143n -rLT=143n -Tutf8


> 
> I now noticed that for some sizes everything is OK and for others the
> problems arise.
> 
> I mention this, because I had a look at the discussion in bug #65190
> mentioning a patch for *an.tmac* but not *andoc.tmac*.

The "-mandoc" argument is a red herring in this case; what matters is
configuration of the terminal width, something man-db man(1) does
automatically.

"andoc.tmac" is an unlikely site to patch for this problem.

See the "Files" section of groff_man(7):

   /usr/share/groff/1.23.0/tmac/andoc.tmac
  This brief groff program detects whether the man or mdoc
  macro package is being used by a document and loads the
  correct macro definitions, taking advantage of the fact
  that pages using them must call .TH or .Dd, respectively,
  before any other macros.  A man program or user typing,
  for example, “groff -mandoc page.1”, need not know which
  package the file page.1 uses.  Multiple man pages, in
  either format, can be handled; andoc reloads each macro
  package as necessary.

> I tried your suggested workaround and it works here.

Glad to hear it!

> I will try to follow all the discussions, because at least I learn a
> lot from it.

If you have any questions about anything to do with groff, please feel
free to post them to the groff at gnu dot org mailing list.

Regards,
Branden



___

Reply to this item at:

  

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

[bug #65189] grotty: table output broken after movement of one row

[Dirk Gouders]

Follow-up Comment #2, bug#65189 (group groff):

Hi Branden,

thank you for your very informative reply and the workaround.

Sorry that I forgot to mention it: groff-1.23.0 is what I am using here.

Because I wondered why man(1) has no problems in formatting the attached
lsp-help.1 whereas


$ nroff -t -man lsp-help.broken.1


has, I had a closer look and here on my system (Gentoo) nroff(1) is called
with *-mandoc*.
Depending on the current size of the terminal more options are used, e.g.:


nroff -mandoc -c -rLL=143n -rLT=143n -Tutf8


I now noticed that for some sizes everything is OK and for others the problems
arise.

I mention this, because I had a look at the discussion in bug #65190
mentioning a patch for *an.tmac* but not *andoc.tmac*.



I tried your suggested workaround and it works here.

I will try to follow all the discussions, because at least I learn a lot from
it.

Regards,

Dirk



___

Reply to this item at:

  

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

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Tuesday, 23 January 2024 02:46:50 GMT G. Branden Robinson wrote:
> [self-follow-up]
> 
> > Or: Should device control commands affect the environment?
> > 
> > Recall the definition of the \X escape sequence from CSTR #54 (1992).
> > 
> > 10.7.  Transparent output.  The sequence \X'anything' copies anything
> > to the output, as a device control function of the form x X anything
> > (§22).  Escape sequences in anything are processed.
> 
> [...]
> 
> > I therefore propose to change this, and have the `\X` escape sequence
> > read its argument in copy mode.  That will make it work like the
> > `device` request in groff 1.23.0 and earlier[1].
> 
> It's looking like we _will_ be giving up something with this change:
> 
> The ability to use a newline as an escape sequence delimiter with the \X
> escape sequence.
> 
> I would argue that this change is of vanishingly small impact.
> 
> 1.  Likely few people knew you could use a newline as a delimiter with
> this escape sequence in the first place.
> 2.  You couldn't do that in DWB troff anyway.[1]
> 3.  The opposite problem is of greater interest to practical users:
> _embedding_ newlines inside device control commands.  \X didn't
> support that anyway, neither in DWB troff nor groff.[2]

Hi Branden,

Just to be sure, can you confirm your intention is to return .device to its 
1.23.0 state, and mirror that behaviour for \X, so we will have no more red 
seepage.

Cheers 

Deri

mom example documents PDF conversions in Fedora 39 distribution

[Oliver Corff]

Hi,

I just happened to notice that the PDF targets of the example documents
of mom in my /usr/share/doc/groff/examples/mom/ directory (Fedora 39)
seem to have been compiled without the -k option even though README.txt
has the example command lines as well as an explicit mention of the -k
option.

Who can be notified of this issue? Is it the package maintainers at Fedora?

Best regards,

Oliver.

--
Dr. Oliver Corff
mailto:oliver.co...@email.de