[groff] 07/12: [docs]: Revise discussion of diversions.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit a0c63e3fbc61d2f350cea8dc3e7e61ec20174089
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:17:21 2024 -0600

[docs]: Revise discussion of diversions.

* doc/groff.texi (Diversions): Note that the top-level diversion is
  nameless (interpolates `\n[.z]` emptily).  Update examples.  Clarify
  that it is diversion requests, not the diversions themselves, that are
  nestable.  Add example of doing so.  Annotate area of underspecified
  semantics (Savannah #64728).  Improve presentation of `\!` and `\?`.
  Favor Texinfo command @result in example over prose in running text.
  Migrate terminology: "escape" -> "escape sequence".
  Recast and tighten wording.  Use Texinfo @command command, not @code,
  to discuss "troff".

* man/groff.7.man (Diversions): Sync with the foregoing.

* man/groff_diff.7.man (Escape sequences): Sync discussion of `\?` with
  the foregoing.
---
 doc/groff.texi   | 125 +--
 man/groff.7.man  |  51 ++---
 man/groff_diff.7.man |  23 +++---
 3 files changed, 132 insertions(+), 67 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index 05eb8f913..eb49d86b4 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -15357,9 +15357,10 @@ from occurring at an inconvenient place by forcing a 
set of output lines
 to be set as a group), footnotes, tables of contents, and indices.
 @cindex top-level diversion
 @cindex diversion, top-level
-For orthogonality it is said that GNU @code{troff} is in the
+For orthogonality it is said that GNU @command{troff} is in the
 @dfn{top-level diversion} if no diversion is active (that is, formatted
-output is being ``diverted'' immediately to the output device).
+output is being ``diverted'' immediately to the output device).  The
+top-level diversion has no name.
 
 Dereferencing an undefined diversion will create an empty one of that
 name and cause a warning in category @samp{mac} to be emitted.
@@ -15368,7 +15369,6 @@ A diversion does not exist for the purpose of testing 
with the @code{d}
 conditional operator until its initial definition ends (@pxref{Operators
 in Conditionals}).  The following requests are used to create and alter
 diversions.
-@c END Keep (roughly) parallel with subsection "Diversions" of groff(7).
 
 @DefreqList {di, [@Var{name}]}
 @DefreqListEndx {da, [@Var{name}]}
@@ -15394,21 +15394,25 @@ current diversion, a warning in category @samp{di} is 
produced.
 @xref{Warnings}, regarding the enablement and suppression of warnings.
 
 @Example
-Before the diversion.
-.di yyy
-In the diversion.
+.ll 56n
+Ahoy, me hearties,
+I traveled unto a distant isle,
+.br
+.di HT
+and thereupon I lay a vast treasure,
 .br
 .di
-After the diversion.
+.HT
 .br
-@result{} After the diversion.
-.yyy
-@result{} Before the diversion.  In the diversion.
+which none o' ye shall ever see.
+@result{} Ahoy, mateys, I traveled unto a distant isle,
+@result{} and thereupon I lay a vast treasure,
+@result{} which none o@quoteright{} ye shall ever see.
 @endExample
 @endDefreq
 
 @cindex box (diversion operation)
-GNU @code{troff} supports @dfn{box} requests to exclude a partially
+GNU @command{troff} supports @dfn{box} requests to exclude a partially
 collected line from a diversion, as this is often desirable.
 
 @DefreqList {box, [@Var{name}]}
@@ -15419,17 +15423,21 @@ included in the diversion.  Without an argument, stop 
diverting output;
 any pending output line inside the diversion is discarded.
 
 @Example
-Before the box.
-.box xxx
-In the box.
+.ll 56n
+Ahoy, mateys,
+I traveled unto a distant isle,
+.br
+.box SECRET
+and thereupon I lay a vast treasure,
 .br
-Hidden treasure.
+accurst wi' neutron activation,
 .box
-After the box.
+.SECRET
 .br
-@result{} Before the box.  After the box.
-.xxx
-@result{} In the box.
+which none o' ye shall ever see.
+@result{} Ahoy, mateys, I traveled unto a distant isle,
+@result{} and thereupon I lay a vast treasure,
+@result{} which none o@quoteright{} ye shall ever see.
 @endExample
 @endDefreq
 
@@ -15447,11 +15455,33 @@ interchangeably.
 @cindex vertical position in diversion register (@code{.d})
 @cindex position, vertical, in diversion, register (@code{.d})
 @cindex diversion, vertical position in, register (@code{.d})
-Diversions may be nested.  The read-only string-valued register
+Diversion requests may be nested.  The read-only string-valued register
 @code{.z} contains the name of the current diversion.  The read-only
-register @code{.d} contains the current vertical place in the diversion.
-If the input text is not being diverted, @code{.d} reports the same
-location as the register @code{nl}.
+register @code{.d} contains the vertical drawing position in the
+diversion.  If the input text is not being diverted, @code{.d} reports
+the same location as the 

[groff] 12/12: [docs]: Update discussion of AT/GNU differences.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit d67b7d7a8b82a3474ab133531e70f0499babf937
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:47:10 2024 -0600

[docs]: Update discussion of AT/GNU differences.

Motivate the material a bit more.  Get the organization a bit more
parallel, but to continue down this road will require relocation of
text.
---
 doc/groff.texi   | 25 +++--
 man/groff_diff.7.man | 30 --
 2 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index fef257741..04aa89d52 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -17457,20 +17457,25 @@ extension requests, @code{open}, @code{opena}, and 
@code{pso}.
 @cindex compatibility mode
 @cindex mode, compatibility
 
+Some implementation differences between GNU and @acronym{AT}
+@command{troff}s are thought too important to neglect; @code{groff}
+therefore makes available a @dfn{compatibility mode} in an effort to
+keep documents prepared for AT @command{troff} rendering well.
+
 @cindex long names
 @cindex names, long
 @cindex @code{\*}, incompatibilities with @acronym{AT} @code{troff}
 @cindex @code{\n}, incompatibilities with @acronym{AT} @code{troff}
-Long identifier names may be GNU @code{troff}'s most obvious innovation.
-@acronym{AT} @code{troff} interprets @samp{.dsabcd} as defining a
-string @samp{ab} with contents @samp{cd}.  Normally, GNU @code{troff}
-interprets this as a call of a macro named @code{dsabcd}.
-@acronym{AT} @code{troff} also interprets @samp{\*[} and @samp{\n[} as
-an interpolation of a string or register, respectively, named @samp{[}.
-In GNU @code{troff}, however, the @samp{[} is normally interpreted as
-delimiting a long name.  In compatibility mode, GNU @code{troff}
-interprets names in the traditional way; they thus can be two characters
-long at most.
+Identifier names of arbitrary length may be GNU @code{troff}'s most
+obvious innovation.  @acronym{AT} @code{troff} interprets
+@samp{.dsabcd} as defining a string @samp{ab} with contents @samp{cd}.
+Normally, GNU @code{troff} interprets this as a call of a macro named
+@code{dsabcd}.  @acronym{AT} @code{troff} also interprets @samp{\*[}
+and @samp{\n[} as an interpolation of a string or register,
+respectively, named @samp{[}.  In GNU @code{troff}, however, the
+@samp{[} is normally interpreted as delimiting a long name.  In
+compatibility mode, GNU @code{troff} interprets names in the traditional
+way; they thus can be two characters long at most.
 
 @DefreqList {cp, [@Var{n}]}
 @DefregListEndx {.C}
diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index 8700e9c9d..81c20fdf2 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -5298,7 +5298,7 @@ to the standard error stream.
 .
 .
 .\" 
-.SH "Implementation differences"
+.SH "Other differences"
 .\" 
 .
 .\" TODO: Resync with the node of this name in our Texinfo manual.
@@ -5366,8 +5366,23 @@ GNU
 has no such restriction.
 .
 .
+.\" 
+.SH "Compatibility mode"
+.\" 
+.
+Some implementation differences between GNU and AT
+.IR troff s \" generic
+are thought too important to neglect;
+.I groff
+therefore makes available a
+.I "compatibility mode"
+in an effort to keep documents prepared for AT
+.I troff \" AT
+rendering well.
+.
+.
 .P
-Long names may be GNU
+Identifier names of arbitrary length may be GNU
 .IR troff 's \" GNU
 most obvious innovation.
 .
@@ -5556,7 +5571,7 @@ See section \[lq]Miscellaneous\[rq] above.
 .
 .
 .P
-In compatibility mode,
+Further,
 the escape sequences
 .BR \[rs]f ,
 .BR \[rs]H ,
@@ -5566,13 +5581,8 @@ the escape sequences
 .BR \[rs]s ,
 and
 .B \[rs]S
-are transparent at the beginning of an input line for the purpose of
-recognizing a control character,
-because they modify formatter state
-.RB ( \[rs]R )
-or properties of the environment
-(the rest)
-and therefore do not create output nodes.
+are transparent at the beginning of an input line only in compatibility
+mode.
 .
 .
 .P

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


[groff] 09/12: [docs]: Recast presentation of `nx` request.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 0c5a9c17f03b542e6583a593cea1209958eae5d4
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:26:57 2024 -0600

[docs]: Recast presentation of `nx` request.
---
 doc/groff.texi  | 5 ++---
 man/groff.7.man | 7 ---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index 7b240c7b2..de789cc31 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -16240,9 +16240,8 @@ from becoming part of the diversion 
(@pxref{Diversions}).
 @cindex read next file (@code{nx})
 @cindex file, next, read (@code{nx})
 @cindex next file, read (@code{nx})
-Force @command{gtroff} to continue processing of the file specified as
-an argument.  If no argument is given, immediately jump to the end of
-file.
+Stop processing the input file.  If @var{file} is specified, read it;
+otherwise, read the next pending input file, if any.
 @endDefreq
 
 @Defreq {rd, [@Var{prompt} [@Var{arg1} @Var{arg2} @dots{}]]}
diff --git a/man/groff.7.man b/man/groff.7.man
index 3bc24b2fc..03fa7cfa7 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -3827,12 +3827,13 @@ See
 .
 .TPx
 .REQ .nx
-Immediately jump to end of current file.
+Stop processing the input file and read the next,
+if any.
 .
 .TPx
 .REQ .nx file
-Stop formatting current file and begin reading
-.I file.
+Stop processing the input file and read
+.IR file .
 .
 .TPx
 .REQ .open "ident file"

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


[groff] 08/12: doc/groff.texi: Fix markup nit.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit fbc9003095fcae17f6b9f5692f11082986dc7488
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:26:18 2024 -0600

doc/groff.texi: Fix markup nit.

Migrate more instances of @code{troff} to @command{troff}.
---
 doc/groff.texi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index eb49d86b4..7b240c7b2 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -15799,7 +15799,7 @@ test
 
 Usually, it is not predictable whether a diversion contains one or more
 output lines, so this mechanism should be avoided.  With @acronym{AT}
-@code{troff}, this was the only solution to strip off a final newline
+@command{troff}, this was the only solution to strip off a final newline
 from a diversion.  Another disadvantage is that the spaces in the copied
 string are already formatted, preventing their adjustment.  This can
 cause ugly results.
@@ -15811,9 +15811,10 @@ cause ugly results.
 @cindex horizontal space, unformatting
 @cindex space, horizontal, unformatting
 @cindex unformatting horizontal space
-A clean solution to this problem is available in GNU @code{troff}, using
-the requests @code{chop} to remove the final newline of a diversion, and
-@code{unformat} to make the horizontal spaces adjustable again.
+A clean solution to this problem is available in GNU @command{troff},
+using the requests @code{chop} to remove the final newline of a
+diversion, and @code{unformat} to make the horizontal spaces adjustable
+again.
 
 @Example
 .box xxx

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


[groff] 03/12: [man]: Handle another case of ill-formed input.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 594bd1979d1151ad53db37e8c4c0eb11627ad3f0
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 13:59:55 2024 -0600

[man]: Handle another case of ill-formed input.

* tmac/an.tmac (TH): Set up end macro unconditionally here...
  (an-set-up-continuous-rendering): ...instead of here.

* tmac/tests/an_TP-works.sh: Add test case for the specimen of
  ill-formed input that the foregoing remedies (ending input with a
  pending input line trap and continuous rendering disabled).
---
 ChangeLog | 9 +
 tmac/an.tmac  | 2 +-
 tmac/tests/an_TP-works.sh | 9 -
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f284f4f08..781ef88e8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-02-02  G. Branden Robinson 
+
+   * tmac/an.tmac (TH): Set up end macro unconditionally here...
+   (an-set-up-continuous-rendering): ...instead of here.
+
+   * tmac/tests/an_TP-works.sh: Add test case for the specimen of
+   ill-formed input that the foregoing remedies (ending input with
+   a pending input line trap and continuous rendering disabled).
+
 2024-02-02  G. Branden Robinson 
 
* src/roff/troff/env.cpp (print_hyphenation_exceptions): Flush
diff --git a/tmac/an.tmac b/tmac/an.tmac
index 1e48b3c95..4679a03b2 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -147,7 +147,6 @@
 .  rn bp an-real-bp
 .  rn an-ne ne
 .  rn an-bp bp
-.  em an-end
 ..
 .
 .de an*reset-hyphenation-mode
@@ -381,6 +380,7 @@
 .\}
 .  \}
 .
+.  em an-end
 .  nr an*need-titles-reset 1
 ..
 .
diff --git a/tmac/tests/an_TP-works.sh b/tmac/tests/an_TP-works.sh
index 5623b3b27..90739055a 100755
--- a/tmac/tests/an_TP-works.sh
+++ b/tmac/tests/an_TP-works.sh
@@ -51,7 +51,14 @@ echo "$output" | grep -Eq 'tag +ordinary tagged paragraph' 
|| wail
 echo "checking ill-formed tagged paragraph" >&2
 echo "$output" | grep -q 'ill-formed but still renderable' || wail
 
-echo "checking paragraph tag dangling at end of document" >&2
+echo "checking paragraph tag dangling at end of document (-rcR=1)" >&2
+echo "$output" | grep -q 'foobar' || wail
+
+output=$(printf "%s" "$input" \
+| "$groff" -ww -Tascii -P-cbou -rcR=0 -man)
+echo "$output"
+
+echo "checking paragraph tag dangling at end of document (-rcR=0)" >&2
 echo "$output" | grep -q 'foobar' || wail
 
 test -z "$fail"

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


[groff] 01/12: ChangeLog: Fix typo.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 1c6b28ea0f844608e47eff27ca9acaa5e7546e32
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 14:03:46 2024 -0600

ChangeLog: Fix typo.
---
 ChangeLog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index d103fd649..f0430bf5c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -6,7 +6,7 @@
on" when they shouldn't, and the extra difficulty of managing
nested traps (`TP` followed by `UR`, for example) is proving
tricky to sort out.  On top of that, the man(7) package
-   historically has no cognizance of color issues and it's doesn't
+   historically has no cognizance of color issues and it doesn't
seem like a good time to start, particularly if we only do it
for the 'pdf' output device.  Unfortunately, "pdf.tmac" doesn't
expose a clean abstraction for "link starts here" and "link

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


[groff] 02/12: [troff]: Flush stderr at end of `phw` request.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit dae6a4ac64dd9aef5f161b00eeb77e09c7c07924
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 13:10:16 2024 -0600

[troff]: Flush stderr at end of `phw` request.

* src/roff/troff/env.cpp (print_hyphenation_exceptions): Flush the
  standard error stream once the list is written.
---
 ChangeLog  | 5 +
 src/roff/troff/env.cpp | 1 +
 2 files changed, 6 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index f0430bf5c..f284f4f08 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-02-02  G. Branden Robinson 
+
+   * src/roff/troff/env.cpp (print_hyphenation_exceptions): Flush
+   the standard error stream once the list is written.
+
 2024-02-02  G. Branden Robinson 
 
[man]: Back away from color management concerns.
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index ea3f0d9cf..dbaf2d1a9 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -3710,6 +3710,7 @@ static void print_hyphenation_exceptions()
   errprint("\t*");
 errprint("\n");
   }
+  fflush(stderr);
   skip_line();
 }
 

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


[groff] 05/12: groff_rfc1345(7): Fix, future-proof stale claim.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit b644bca1a63411aa6b6290310dea18b5f2cdf0d5
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 14:02:53 2024 -0600

groff_rfc1345(7): Fix, future-proof stale claim.
---
 contrib/rfc1345/groff_rfc1345.7.man | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/rfc1345/groff_rfc1345.7.man 
b/contrib/rfc1345/groff_rfc1345.7.man
index c04cad94e..a7752cd4e 100644
--- a/contrib/rfc1345/groff_rfc1345.7.man
+++ b/contrib/rfc1345/groff_rfc1345.7.man
@@ -138,7 +138,7 @@ These have also been added to
 .
 .PP
 .I rfc1345.tmac
-contains a total of 1,696 glyph names.
+contains about 1,700 glyph names.
 .
 It is not an
 error to load

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


[groff] 10/12: [docs]: Fix typos and tighten wording.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 524768a4e343f3ec0ae7772683d24474360f0c62
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:38:37 2024 -0600

[docs]: Fix typos and tighten wording.
---
 doc/groff.texi   | 22 ++
 man/groff.7.man  |  4 ++--
 man/groff_diff.7.man |  2 +-
 3 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index de789cc31..5ff964977 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -16566,7 +16566,7 @@ discussed above).  @code{use_charnames_in_special} is 
currently employed
 only by @code{grohtml}.
 @endDefesc
 
-GNU @command{troff} also permits the interpolatation of macro contents
+GNU @command{troff} also permits the interpolation of macro contents
 as a device control command.
 
 @DefreqList {devicem, name}
@@ -16973,9 +16973,8 @@ or for instrumentation while troubleshooting.  The 
@code{ex} and
 exit codes respectively, to halt further processing when continuing
 would be fruitless.  Examine the state of the formatter with requests
 that write lists of defined names (macros, strings, and diversions),
-defined colors, composite characters, environments, hyphenation
-exceptions, registers, and page location traps to the standard error
-stream.
+colors, composite characters, environments, hyphenation exceptions,
+registers, and page location traps to the standard error stream.
 @c END Keep parallel with section "Debugging" of groff(7).
 
 @Defreq {lf, line [@Var{file}]}
@@ -17099,8 +17098,8 @@ strings, and diversions with their sizes in bytes.
 @Defreq {pnr, }
 @cindex dumping registers (@code{pnr})
 @cindex registers, dumping (@code{pnr})
-Report the names and contents of all currently defined registers to the
-standard error stream.
+Report the names and contents of all defined registers to the standard
+error stream.
 @endDefreq
 
 @Defreq {ptr, }
@@ -17161,7 +17160,7 @@ Consider the following in a file @file{test}.
 
 The @option{-b} option of GNU @code{troff} causes a backtrace to be
 generated on each error or warning.  Some warnings have to be enabled;
-@xref{Warnings}.
+see @ref{Warnings}.
 @endDefreq
 
 @Defreg {slimit}
@@ -17571,11 +17570,10 @@ delimited arguments, but not in compatibility mode.
 @cindex @code{\H}, incompatibilities with @acronym{AT} @code{troff}
 @cindex @code{\s}, incompatibilities with @acronym{AT} @code{troff}
 @cindex @code{\S}, incompatibilities with @acronym{AT} @code{troff}
-Furthermore, the escape sequences @code{\f}, @code{\H}, @code{\m},
-@code{\M}, @code{\R}, @code{\s}, and @code{\S} are transparent for the
-purpose of recognizing a control character at the beginning of a line
-only in compatibility mode.  For example, this code produces bold output
-in both cases, but the text differs.
+Further, the escape sequences @code{\f}, @code{\H}, @code{\m},
+@code{\M}, @code{\R}, @code{\s}, and @code{\S} are transparent at the
+beginning of a line only in compatibility mode.  For example, this code
+produces bold output in both cases, but the text differs.
 
 @Example
 .de xx
diff --git a/man/groff.7.man b/man/groff.7.man
index 03fa7cfa7..a43ff60a6 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -8033,7 +8033,7 @@ is currently employed only by
 .P
 GNU
 .I troff \" GNU
-also permits the interpolatation of macro contents as a device control
+also permits the interpolation of macro contents as a device control
 command.
 .
 The
@@ -8346,7 +8346,7 @@ defined names\[em]macros,
 strings,
 and
 .RB diversions\[em]( .pm );
-defined colors
+colors
 .RB ( .pcolor );
 composite characters
 .RB ( .pcomposite );
diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index 593a8de61..8700e9c9d 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -5290,7 +5290,7 @@ environments
 .RB ( pev ),
 hyphenation exceptions
 .RB ( phw ),
-defined registers
+registers
 .RB ( pnr ),
 and page location traps
 .RB ( ptr )

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


[groff] 04/12: groff(1): Fix content nits.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 1cf7f2981b592d7da3b241db257addfcc7967800
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 14:01:29 2024 -0600

groff(1): Fix content nits.

Recategorize pdfmom(1) since Deri has generalized it.  Migrate
terminology: "intermediate" -> "device-independent" output.
---
 src/roff/groff/groff.1.man | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/roff/groff/groff.1.man b/src/roff/groff/groff.1.man
index 3a52cb62b..e65613f2c 100644
--- a/src/roff/groff/groff.1.man
+++ b/src/roff/groff/groff.1.man
@@ -2375,7 +2375,6 @@ Macro packages and package-specific utilities:
 .MR groff_mmse @MAN7EXT@ , \" # 11
 .MR mmroff @MAN1EXT@ , \" #12
 .MR groff_mom @MAN7EXT@ , \" #13
-.MR pdfmom @MAN1EXT@ , \" #30
 .MR groff_ms @MAN7EXT@ , \" #58
 .MR groff_rfc1345 @MAN7EXT@ , \" 16
 .MR groff_trace @MAN7EXT@ , \" #59
@@ -2401,7 +2400,7 @@ and GNU extensions:
 .
 .
 .TP
-Intermediate output language:
+Device-independent output language:
 .MR groff_out @MAN5EXT@ \" #21
 .
 .
@@ -2414,6 +2413,7 @@ Formatter program:
 Formatter wrappers:
 .\".MR groff @MAN1EXT@ , \" 42 -- this page
 .MR @g@nroff @MAN1EXT@ , \" #44
+.MR pdfmom @MAN1EXT@ , \" #30
 .MR pdfroff @MAN1EXT@ \" #14
 .
 .

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


[groff] 11/12: doc/groff.texi (Debugging): Discuss `fl` more.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit d975d283a4d8382ea437a31aeb92b0f6c70cb22a
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 19:39:49 2024 -0600

doc/groff.texi (Debugging): Discuss `fl` more.
---
 doc/groff.texi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/groff.texi b/doc/groff.texi
index 5ff964977..fef257741 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -17129,6 +17129,19 @@ Break the line and flush any pending output line 
immediately.  The
 effect is the same as the @code{br} request unless the no-break control
 character is used; @samp{'br} does nothing, whereas @samp{'fl} writes
 the pending output line without further updating the drawing position.
+However, the @emph{reported} horizontal drawing position is still
+reckoned from the start of the input line.
+
+@Example
+foo bar \n(hp
+foo bar \c
+'fl
+\n(hp
+@result{} foo bar 192 foo bar 0
+@endExample
+
+The timing of a flush is most easily perceived in GNU @command{troff}'s
+device-independent output.
 
 Historically, @code{fl} was used with @code{rd} to produce interactive
 @command{nroff} documents.  GNU @command{troff} does not easily support

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


[groff] 06/12: [docs]: Document another AT troff difference.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 451705d95ada36c09317a0ec903ff43e366f1e29
Author: G. Branden Robinson 
AuthorDate: Fri Feb 2 18:58:10 2024 -0600

[docs]: Document another AT troff difference.

* doc/groff.texi (Other Differences):
* man/groff_diff.7.man (Implementation differences): Do it.

Exhibit:

$ DWBHOME=. ./bin/nroff defeat-end-of-sentence-detection.roff|cat -s
In the input, this  sentence  will  end  with  a  period  and  no
trailing  space.   This  sentence  will  end  with a period and a
trailing space. How did they set?
---
 doc/groff.texi   | 11 ++-
 man/groff_diff.7.man | 16 
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/doc/groff.texi b/doc/groff.texi
index dce38736d..05eb8f913 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -464,7 +464,7 @@ Documentation License''.
 @title groff
 @subtitle The GNU implementation of @code{troff}
 @subtitle Edition 1.23.0+Git
-@subtitle January 2024
+@subtitle February 2024
 @author Trent@tie{}A.@: Fisher
 @author Werner Lemberg
 @author G.@tie{}Branden Robinson
@@ -17607,6 +17607,15 @@ GNU @code{troff} does not allow the use of the escape 
sequences
 does.  The @code{\A} escape sequence (@pxref{Identifiers}) may be
 helpful in avoiding use of these escape sequences in names.
 
+@cindex trailing space, on input lines, difference from @acronym{AT} 
@code{troff}
+@cindex space, trailing, on input lines, difference from @acronym{AT} 
@code{troff}
+@cindex end-of-sentence detection, cancellation, on @acronym{AT} @code{troff}
+@cindex sentence, cancelling detection of end of, on @acronym{AT} 
@code{troff}
+@acronym{AT} @command{troff} discards trailing spaces from input
+lines, like GNU @command{troff}, but if it does so, @acronym{AT}
+@command{troff} also cancels end-of-sentence detection.  Use of the
+dummy character escape sequence @code{\&} is more portable.
+
 @cindex adjustment to both margins, difference from @acronym{AT} @code{troff}
 @cindex rivers
 When adjusting to both margins, @acronym{AT} @code{troff} at first
diff --git a/man/groff_diff.7.man b/man/groff_diff.7.man
index ef294bdf4..3c3e96e52 100644
--- a/man/groff_diff.7.man
+++ b/man/groff_diff.7.man
@@ -5323,6 +5323,22 @@ are supported by other implementations.
 .
 .
 .P
+AT
+.I troff \" AT
+discards trailing spaces from input lines,
+like GNU
+.IR troff , \" GNU
+but if it does so,
+AT
+.I troff \" AT
+also cancels end-of-sentence detection.
+.
+Use of the dummy character escape sequence
+.B \[rs]&
+is more portable.
+.
+.
+.P
 When adjusting to both margins,
 AT
 .I troff \" AT

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


[bug #60930] Integrate Peter Schaffter's font installer script into groff

2024-02-02 Thread Dave
Follow-up Comment #7, bug#60930 (group groff):

Branden mentioned two more to-do items in the email cited in comment #5:
* giving it a less name-space-stomperific name ("groff-font-install" or
"groff-install-font" would be clear enough, but I think either would annoy me
[and other users] when tab-completing "groff")
* giving distribution packaging folks enough guidance that they will
understand how to correctly call our tool from their package triggers or
"postinst"s or similar
The first of these is trivial.  The second seems worthwhile but shouldn't be a
barrier to getting something out the door that users can use.  In fact, if
others agree there's value in deferring the task of POSIXifying the entire
script, writing distro-facing documentation should probably depend on that.

Kurt, do the points above and in comment #6 make a first cut seem more
manageable?


___

Reply to this item at:

  

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




[bug #60930] Integrate Peter Schaffter's font installer script into groff

2024-02-02 Thread Dave
Follow-up Comment #6, bug#60930 (group groff):

[comment #0 original submission:]
> * Make the script portable by removing dependencies on
> bash-specific features

I'm now wondering if there's some wisdom to doing a first cut that simply
checks whether bash is available and bails gracefully if not.  This would
leave some users out in the cold, but it would serve a lot of them, and that's
got to be an improvement over serving none.  And it wouldn't require a bash
install dependency for groff, just a run-time one for one groff utility that
provides functionality groff didn't provide before anyway.

> * Write a man page

Four years ago, James K. Lowden volunteered to do this
(http://lists.gnu.org/r/groff/2020-04/msg00071.html).  I'm adding him to the
cc to see if he's still up for this.  Divide and conquer!

> * Write some test cases to ensure it works as expected

It's possible Peter Schaffter, the script's developer, has some he's used
privately and would be willing to share.  Putting him on cc as well.


___

Reply to this item at:

  

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




[bug #62921] want another monospaced font in the default set

2024-02-02 Thread Dave
Follow-up Comment #9, bug#62921 (group groff):

[comment #8 comment #8:]
> Thanks (to whoever that anonymous submitter was ;-) )!

You've probably deduced this, but the reason I sometimes file groff bugs
"anonymously" is not to evade credit/blame, but so that I'm not forever tied
to a bug I have no stake in.  Savannah seems to support a submitter removing
themself from the cc list (in that there's a button for it, though I've never
tried it), but the Submitter field is immutable.

> That's not exactly true as I understand it.

I'm glad to be wrong about that.

> (Probably the former; continuing AT's abbreviation-happy tradition is
> likely to lead to collisions.)

...and less meaningful to human eyes, of course.


___

Reply to this item at:

  

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




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

2024-02-02 Thread Dave
Follow-up Comment #8, bug#65190 (group groff):

[comment #6 comment #6:]
> I've heard no demand expressed for continuously rendered
> ms/me/mm/mom documents.

Less self-serving instances:
* http://lists.gnu.org/r/groff/2006-05/msg00102.html
* http://lists.gnu.org/r/groff/2008-03/msg00012.html
* http://lists.gnu.org/r/groff/2020-04/msg00072.html
There may well be more, but it's not an easy thing to search because there's
no historically consistent terminology for the concept.


___

Reply to this item at:

  

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




[bug #65242] [gropdf] should validate and diagnose ill-formed "download" files

2024-02-02 Thread G. Branden Robinson
URL:
  

 Summary: [gropdf] should validate and diagnose ill-formed
"download" files
   Group: GNU roff
   Submitter: gbranden
   Submitted: Sat 03 Feb 2024 12:32:11 AM UTC
Category: Driver gropdf
Severity: 3 - Normal
  Item Group: Warning/Suspicious behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 03 Feb 2024 12:32:11 AM UTC By: G. Branden Robinson 
If I slip to _gropdf_ a "download" file with only two tab-separated fields
instead of three, I get the following spew.


Use of uninitialized value $file in substr at
/home/branden/groff-HEAD/bin/gropdf line 1167, <__ANONIO__> line 1.
Use of uninitialized value $file in substr at
/home/branden/groff-HEAD/bin/gropdf line 1174, <__ANONIO__> line 1.
Use of uninitialized value $file in concatenation (.) or string at
/home/branden/groff-HEAD/bin/gropdf line 1174, <__ANONIO__> line 1.


In my opinion, _gropdf_ should check that the lines in the "download" file are
of satisfactory form, and throw a complaining diagnostic if they aren't.







___

Reply to this item at:

  

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




[bug #62921] want another monospaced font in the default set

2024-02-02 Thread G. Branden Robinson
Follow-up Comment #8, bug#62921 (group groff):

[comment #7 comment #7:]
> [comment #1 comment #1:]
> > groff's _ms_ and _me_ have support for bold-italic already (and have
> > for decades), and it wouldn't be hard to add it to our _mm_ either;
> 
> This has been filed as bug #65241.

Thanks (to whoever that anonymous submitter was ;-) )!

> [comment #5 comment #5:]
> > Ideally, distributors like Fedora and Debian would have "package
> > triggers", scripts that hook up the plumbing between TrueType
> > fonts installed on the system, and the _grops_ and _gropdf_
> > output drivers.  But even after almost 30 years this has never
> > happened.  The reason may be that the specialized knowledge
> > required is fairly scarce,
> 
> Other possible reasons:
> * Supporting groff for anything other than displaying man pages on
> terminals has never been a high priority / something that distro
> managers are even aware it can do.

Fair point.  Maybe in the 1.24.0 release announcement we can get a few
more people to wake up and smell the PDF.

> * To be useful, the triggers would have to be bidirectional, running
> whenever a new groff or a new font is installed.  While the target
> code could be largely the same, the triggers themselves would be two
> mostly non-overlapping development efforts.

That's not exactly true as I understand it.  While RPM had a thing
called "triggers" first, Debian's had them as well for...15 years or
something.  And the way they work is that package A can lay a trigger
that any packages B, C, or D will step on it and cause action.  (To this
day I'm not sure exactly how triggers work--they came in right after my
heyday of intense involvement with complex package development.)  Any
time I install or remove a package that supplies a man page, dpkg
dutifully runs the "man-db" package's trigger afterward.

The scenario I think you're describing is not a trigger--it's just what
in Debian is called a "postinst" script, and those have been around
since practically the first Debian pre-release ever, in 1993 or so.
Before even _my_ time...

However, in working on Robin Haberkorn's recent problem with Russian
documents (bug #65323), I've noticed that some cooperation from
font-providing packages is likely necessary anyway, to solve the problem
of picking a groff font name for installed faces.  Should
"LiberationSerif-Regular" be named "LiberationSerifR" or "LSR"?

(Probably the former; continuing AT's abbreviation-happy tradition is
likely to lead to collisions.)

Regards,
Branden



___

Reply to this item at:

  

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




[bug #62921] want another monospaced font in the default set

2024-02-02 Thread Dave
Follow-up Comment #7, bug#62921 (group groff):

[comment #1 comment #1:]
> groff's _ms_ and _me_ have support for bold-italic already (and have
> for decades), and it wouldn't be hard to add it to our _mm_ either;

This has been filed as bug #65241.

[comment #5 comment #5:]
> Ideally, distributors like Fedora and Debian would have "package
> triggers", scripts that hook up the plumbing between TrueType
> fonts installed on the system, and the _grops_ and _gropdf_
> output drivers.  But even after almost 30 years this has never
> happened.  The reason may be that the specialized knowledge
> required is fairly scarce,

Other possible reasons:
* Supporting groff for anything other than displaying man pages on terminals
has never been a high priority / something that distro managers are even aware
it can do.
* To be useful, the triggers would have to be bidirectional, running whenever
a new groff or a new font is installed.  While the target code could be
largely the same, the triggers themselves would be two mostly non-overlapping
development efforts.


___

Reply to this item at:

  

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




[bug #65241] [mm] support bold-italic

2024-02-02 Thread G. Branden Robinson
Update of bug#65241 (group groff):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

[comment #0 original submission:]
> Buried in the novella that is bug #62921 is this observation:
> 
> "groff's _ms_ and _me_ have support for bold-italic already (and have
> for decades), and it wouldn't be hard to add it to our _mm_ either"
> 
> (This ticket merely notes that Branden has noted the feature gap.  I
> know of no -mm users who have requested this feature, and the
> functionality is already available to -mm users with appropriate base
> roff requests or escapes.)

I'm personally unlikely to tackle this due to its implications for the
_mm_ macro name space.

Consider first that _mm_ has macros for selecting roman, bold, and
italic faces called `R`, `B`, and `I`, respectively.

Next consider that _mm_ also has font alternation macros like _man_;
these are `BI`, `BR`, `IB`, `IR`, `RB`, and `RI`.

Notice the preƫxisting status of a macro called `BI`.

Finally, consider that even we had a macro for switching to the
bold-italic face (maybe `FBI`), orthogonality would suggest that we'd
need to add several more, to complete the Cartesian product of
alternation with the new `BI` font.

BBI
BIB
BIR
RBI
IBI
BII

I think this would become hard to decipher.

What I would suggest to _groff mm_ users instead is to temporarily remap
fonts in a context where bold-italic is desired.  My suspicion is that
in most practical typesetting contexts, this will arise mainly in
situations where the non-italic face is already bold anyway.  That is
the shape of solutions I have applied in _groff man_, which doesn't
expose the bold-italic face, but does _use_ it in (sub)section headings
if it infers that the configured heading font (`HF` string) represents a
bold typeface.  It then temporarily remaps `I` to `BI` when setting the
headings.

Regards,
Branden



___

Reply to this item at:

  

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




[bug #62921] want another monospaced font in the default set

2024-02-02 Thread Dave
Update of bug#62921 (group groff):

  Status:   Need Info => None   

___

Follow-up Comment #6:

This bug was put into Need Info status with comment #1, which asked for
feedback that the submitter supplied in comment #4.  I don't readily notice
any other info this bug report is waiting on, so I'm resetting the status.  If
it's "waiting on" anything, it's a resolution to this question that only groff
developers can decide:

[comment #5 comment #5:]
> It is a question of whether it is a good idea for the _groff_
> project, which is not drowning in developers, to expand its
> charter to get into the general purpose font distribution business.


___

Reply to this item at:

  

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




Re: Ornamented Page Borders

2024-02-02 Thread Deri
On Thursday, 1 February 2024 16:59:36 GMT Emilia Stoyanova wrote:
> Greetings everyone,
> 
> Do any of you have experience with creating ornamented page borders?
> I have looked through the mailing list[^1] and through both mom's and
> utmac's
> documentation but I couldn't find exactly what I have in mind.
> 
> I have attached a pdf document, together with its pic(1) source code,
> to illustrate exactly what I am going for.
> 
> I also tried looking through cstr54 and UTP to maybe figure out how I might
> do
> that myself with pure troff requests, but I gave up after a while, since I'm
> still a bit of a neophyte here . . .
> 
> Also, does anyone perhaps have/host a collection of pic decorations one
> might
> browse and/or add to? I don't even know if using pic for that is standard
> o.o
> 
> Kind Regards,
> Emilia
> ---
> [^1]: https://lists.gnu.org/r/groff/2022-09/msg00088.html

Hi Emilia,

Everyone has probably got a different way of doing this. Tadziu gave you a 
pure pic way of doing the edge ornamentation, but the resulting pdf was over 
100kb, which is why he would program the pattern in postscript. Peter offered 
a method using a suitable repeated glyph from a font, which resulted in a 
9.5kb file. The big reduction is because the actual stroking of the pattern is 
stored in the font so the actual pattern is only stored once but used many 
times.

There is a way of pinching that idea of storing the pattern once and using it 
again and again, but using a single pic instance of your pattern rather than a 
font glyph. There are 3 stages:-

A) First run ornsingle.tr which produces ornsingle.pdf with this command:-

groff -Tpdf -p ornsingle.tr -P-p.35i,.35i >orn.pdf

Notice the custom paper size (.35 inch square) which is big enough to 
encompass one instance of your pattern, which, on its own is 2.9kb.

B) Now run ornpage.tr which generates an A4 page containing many copies of the 
pattern in ornpage.pdf, using groff commands. Use:-

groff -Tpdf -P-pa4 ornpage.tr > ornpage.pdf

Note the 4 lines at the top of the groff script which can affect the pattern 
generated. Now the whole page of patterns is 4.1kb.

C) Is to use ornpage.pdf as a type of watermark to ornament your document. 
There are several pdf utility programs which could do this job after groff has 
produced the document you want to ornament. But there is a way to get groff to 
do this while it is producing your document. The trick is to hook some code 
into whichever macro deals with starting a new page, for whichever macro 
language you use, that includes ornpage.pdf on every page. If you include the 
same pdf multiple times gropdf only stores it once and links to it if you use 
it again. The file ornmom.tr is a very crude example of this. Since it hooks 
into the START macro it is really only useful for single page simple 
documents, something much more sophisticated would be required for multi-page 
documents, possibly hooking in to NEWPAGE as well. You can run the example 
like this:-

groff -Tpdf -mom -k -P-pa4 ornmom.tr /usr/share/doc/groff-1.23.0/examples/mom/
letter.mom > letter.pdf

The document, including the letter, is now 6.3kb.

Cheers 

Deri
.ig
	groff -Tpdf -p ornsingle.tr -P-p.35i,.35i >orn.pdf
..
.po 1p
.vs 1p
.PS 		\" Scale width for close fit

define orn { [
	# Variables
	sideLength = $1/2;
	cupRad = $1/10;
	petalRad = $1/16.6;
	cornerRad = $1/20;
	splineLength = sideLength/5;
	splineTravel = splineLength * 2;
	rodLength = splineTravel;
	danglyFstRad = sideLength / 10;
	danglySndRad = danglyFstRad/2;
	danglyTrdRad = danglySndRad/2;

	Diamond: [
		NE: line down sideLength right sideLength;
		SE: line down sideLength left sideLength;
		SW: line up sideLength left sideLength;
		NW: line up sideLength right sideLength;
	];

	# Flower in the middle (Cup & Petals)
	Cup: circle rad cupRad at Diamond;
	circle rad petalRad with .s at Cup.n;
	circle rad petalRad with .sw at Cup.ne;
	circle rad petalRad with .w at Cup.e;
	circle rad petalRad with .nw at Cup.se;
	circle rad petalRad with .n at Cup.s;
	circle rad petalRad with .ne at Cup.sw;
	circle rad petalRad with .e at Cup.w;
	circle rad petalRad with .se at Cup.nw;

	# Corner Circles
	N: circle rad cornerRad at Diamond.NE.start;
	E: circle rad cornerRad at Diamond.SE.start;
	W: circle rad cornerRad at Diamond.SW.start;
	S: circle rad cornerRad at Diamond.NW.start;

	# Side splines
	move to N down splineTravel left splineTravel;
	spline left splineLength then down splineLength;
	move to N down splineTravel right splineTravel;
	spline right splineLength then down splineLength;
	move to W up splineTravel right splineTravel;
	spline right splineLength then up splineLength;
	move to W up splineTravel left splineTravel;
	spline left splineLength then up splineLength;

	# Side dangly bits
	Lnw: line up rodLength left rodLength at Diamond.NW.center;
	arc rad danglyFstRad from Lnw.end; arc rad danglySndRad; arc rad danglyTrdRad;
	arc cw rad danglyFstRad from Lnw.end; arc cw rad 

[bug #65241] [mm] support bold-italic

2024-02-02 Thread anonymous
URL:
  

 Summary: [mm] support bold-italic
   Group: GNU roff
   Submitter: None
   Submitted: Fri 02 Feb 2024 11:11:40 PM UTC
Category: Macro mm
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: Fri 02 Feb 2024 11:11:40 PM UTC By: Anonymous
Buried in the novella that is bug #62921 is this observation:

"groff's _ms_ and _me_ have support for bold-italic already (and have for
decades), and it wouldn't be hard to add it to our _mm_ either"

(This ticket merely notes that Branden has noted the feature gap.  I know of
no -mm users who have requested this feature, and the functionality is already
available to -mm users with appropriate base roff requests or escapes.)







___

Reply to this item at:

  

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




Proposed: new registers .it, .itc, .itm

2024-02-02 Thread G. Branden Robinson
This time I come with a patch.

I propose to implement the following new read-only registers.

.it Interpolates the number of lines remaining in the input trap.
.itcInterpolates 1 if the input trap respects \c, 0 otherwise.
.itmInterpolates the name of the macro bound to the input trap.

The above data are reported in `pev` output but there is no way to
expose this information to a *roff document.  The foregoing new
registers would do so.

Any objections to this extension?

Regards,
Branden
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index ea3f0d9cf..2dfe5e1ab 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -427,6 +427,21 @@ int environment::get_no_number_count()
   return no_number_count;
 }
 
+int environment::get_input_trap_line_count()
+{
+  return input_trap_count;
+}
+
+int environment::get_input_trap_respects_continuation()
+{
+  return continued_input_trap;
+}
+
+const char *environment::get_input_trap_macro()
+{
+  return input_trap.contents();
+}
+
 void environment::add_italic_correction()
 {
   if (current_tab) {
@@ -691,7 +706,7 @@ environment::environment(symbol nm)
   have_temporary_indent(0),
   underline_lines(0),
   underline_spaces(0),
-  input_trap_count(0),
+  input_trap_count(-1),
   continued_input_trap(false),
   line(0),
   prev_text_length(0),
@@ -784,7 +799,7 @@ environment::environment(const environment *e)
   have_temporary_indent(0),
   underline_lines(0),
   underline_spaces(0),
-  input_trap_count(0),
+  input_trap_count(-1),
   continued_input_trap(false),
   line(0),
   prev_text_length(e->prev_text_length),
@@ -865,7 +880,7 @@ void environment::copy(const environment *e)
   temporary_indent = 0;
   underline_lines = 0;
   underline_spaces = 0;
-  input_trap_count = 0;
+  input_trap_count = -1;
   continued_input_trap = false;
   prev_text_length = e->prev_text_length;
   width_total = 0;
@@ -2589,7 +2604,8 @@ void no_adjust()
 
 void do_input_trap(bool respect_continuation)
 {
-  curenv->input_trap_count = 0;
+  curenv->input_trap_count = -1;
+  curenv->input_trap = 0 /* nullptr */;
   if (respect_continuation)
 curenv->continued_input_trap = true;
   else
@@ -2598,7 +2614,7 @@ void do_input_trap(bool respect_continuation)
   if (has_arg() && get_integer()) {
 if (n <= 0)
   warning(WARN_RANGE,
-	  "number of lines for input trap must be greater than zero");
+	  "input trap line count must be greater than zero");
 else {
   symbol s = get_name(true /* required */);
   if (!s.is_null()) {
@@ -3520,6 +3536,9 @@ void init_env_requests()
   init_hunits_env_reg(".i", get_indent);
   init_hunits_env_reg(".in", get_saved_indent);
   init_int_env_reg(".int", get_prev_line_interrupted);
+  init_int_env_reg(".it", get_input_trap_line_count);
+  init_int_env_reg(".itc", get_input_trap_respects_continuation);
+  init_string_env_reg(".itm", get_input_trap_macro);
   init_int_env_reg(".linetabs", get_line_tabs);
   init_hunits_env_reg(".lt", get_title_length);
   init_int_env_reg(".j", get_adjust_mode);
diff --git a/src/roff/troff/env.h b/src/roff/troff/env.h
index 65b9f0103..0777a3c6b 100644
--- a/src/roff/troff/env.h
+++ b/src/roff/troff/env.h
@@ -314,6 +314,9 @@ public:
   hunits get_hyphenation_space();
   hunits get_hyphenation_margin();
   int get_center_lines();
+  int get_input_trap_line_count();
+  int get_input_trap_respects_continuation();
+  const char *get_input_trap_macro();
   int get_right_justify_lines();
   int get_no_number_count();
   int get_prev_line_interrupted() { return prev_line_interrupted; }


signature.asc
Description: PGP signature


[bug #61434] [man] want support for hyperlinked paragraph tags

2024-02-02 Thread G. Branden Robinson
Follow-up Comment #5, bug#61434 (group groff):

Hi Deri,

[comment #4 comment #4:]
> [comment #3 comment #3:]
> > This was an important follow-up commit.

> > commit 52a5a89c0da9f90c83441b8eb8020344a8468686
> > Author: G. Branden Robinson 
> > Date:   Thu Feb 1 23:23:45 2024 -0600
> > 
> ...
> > Unfortunately, "pdf.tmac" doesn't
> > expose a clean abstraction for "link starts here" and "link stops
here",
> > instead implementing a hugely featured `pdfhref` macro that attempts
to
> > do everything--except support bracketing the link text in a
diversion,
> > which our man(7) design requires.


> Is this accurate?

To the best of my knowledge, yes. 
[https://git.savannah.gnu.org/cgit/groff.git/commit/?id=dc265728eee39db3bf5e2f3b09f8f124880f8f05
The GNU MT/ME and UR/UE extensions date back to 2007]; MR is much more recent,
and the design of the last is deliberately closely modeled on plan9port's
macro (originally named `IM`, I think, but they renamed it to `MR` at my
request), which in turn looks very much like the `BR` and `IR` calls people
have been writing for man page cross references forever.

So the fact that `MR` is in the shape that the `pdfhref` approach expects is
largely a happy coincidence.

But it also makes sense for the other foregoing macros to work as _they_ do. 
The link text of `MR` won't sprawl due to its nature, whereas someone might
want to hyperlink an arbitrary run of text to a URL or an email address.

[https://git.savannah.gnu.org/cgit/groff.git/commit/contrib/pdfmark/pdfmark.tmac?id=f9503b9746b93a624339d488ebb29b77a4fbf667
That `pdfhref` didn't anticipate this in 2004 is unfortunate.]

> It was true before my commit d71f9264 which enabled .MT and .UR to be
hyperlinks (both of which used diversions) and provided a means to "bracket"
the resulting text as a hotspot. Maybe the mechanism of using the pipe
character to "open" the bracket needs further promulgation,

...I'm a little uneasy with that, in part because it constitutes in-band
signaling.  What if a document author wants to hyperlink a pipe sign?  This is
unlikely in conventional prose, but what if someone has a table of punctuation
glyphs, like an ASCII code chart?  Maybe each cell in the grid could hyperlink
to (a section of) a document explaining the history of the code point.

> or perhaps we should add a pair of macros to pdf.tmac, something like:-

> .de pdflinkstart
> .  ds pdf:col \\n[.m]
> .  pdfhref \\$1 -D \\$2 "|"
> ..
> .
> .de pdflinkend
> .  nop \X'pdf: markend'\m[\\*[pdf:col]]\c
> ..


> Which could be used as:-

> .pdflinkstart W http://bbc.co.uk
> .nf
> A multi
> line hotlink (possibly from a diversion)
> .fi
> .pdflinkend


> Just a thought.

I like this much better, but you might go further and have "pdflinkstart"
employ a "markstart" command so that you don't have to impute special meaning
to "|".

I think this aspect of the pdfmark API constitutes technical debt (from a
contributor who declines to work with us any longer, moreover) and I encourage
you to develop your own ideas for _groff_ support of PDF features.

Best regards,
Branden


___

Reply to this item at:

  

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




[bug #61434] [man] want support for hyperlinked paragraph tags

2024-02-02 Thread Deri James
Follow-up Comment #4, bug#61434 (group groff):

[comment #3 comment #3:]
> This was an important follow-up commit.

> commit 52a5a89c0da9f90c83441b8eb8020344a8468686
> Author: G. Branden Robinson 
> Date:   Thu Feb 1 23:23:45 2024 -0600
> 
...
> Unfortunately, "pdf.tmac" doesn't
> expose a clean abstraction for "link starts here" and "link stops
here",
> instead implementing a hugely featured `pdfhref` macro that attempts to
> do everything--except support bracketing the link text in a diversion,
> which our man(7) design requires.

Is this accurate? It was true before my commit d71f9264 which enabled .MT and
.UR to be hyperlinks (both of which used diversions) and provided a means to
"bracket" the resulting text as a hotspot. Maybe the mechanism of using the
pipe character to "open" the bracket needs further promulgation, or perhaps we
should add a pair of macros to pdf.tmac, something like:-

.de pdflinkstart
.  ds pdf:col \\n[.m]
.  pdfhref \\$1 -D \\$2 "|"
..
.
.de pdflinkend
.  nop \X'pdf: markend'\m[\\*[pdf:col]]\c
..

Which could be used as:-

.pdflinkstart W http://bbc.co.uk
.nf
A multi
line hotlink (possibly from a diversion)
.fi
.pdflinkend

Just a thought. 


___

Reply to this item at:

  

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




[bug #64597] [mom] spurious newline after image label

2024-02-02 Thread G. Branden Robinson
Follow-up Comment #10, bug#64597 (group groff):


commit 11016d37f1e16fa71407f9802b105c016263128c
Author: Peter Schaffter 
Date:   Sat Aug 26 14:25:38 2023 -0400

[mom]: Fixes captions not attaching to PDF_IMAGE labels.




___

Reply to this item at:

  

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




[bug #57515] [troff] "-Wdeprecated-copy" warning in node.cpp

2024-02-02 Thread G. Branden Robinson
Update of bug#57515 (group groff):

Severity:  3 - Normal => 2 - Minor  
  Item Group:  Build/Installation => Lint   


___

Reply to this item at:

  

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




[bug #65215] [man] .MT/.ME and .UR/.UE should make hyperlinks in PDF

2024-02-02 Thread G. Branden Robinson
Update of bug#65215 (group groff):

 Planned Release:None => 1.24.0 


___

Reply to this item at:

  

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




[bug #61434] [man] want support for hyperlinked paragraph tags

2024-02-02 Thread G. Branden Robinson
Follow-up Comment #3, bug#61434 (group groff):

This was an important follow-up commit.


commit 52a5a89c0da9f90c83441b8eb8020344a8468686
Author: G. Branden Robinson 
Date:   Thu Feb 1 23:23:45 2024 -0600

[man]: Back away from color management concerns.

Hyperlink colors in PDF were showing a tendency to get "stuck on" when
they shouldn't, and the extra difficulty of managing nested traps (`TP`
followed by `UR`, for example) is proving tricky to sort out.  On top of
that, the man(7) package historically has no cognizance of color issues
and it's doesn't seem like a good time to start, particularly if we only
do it for the 'pdf' output device.  Unfortunately, "pdf.tmac" doesn't
expose a clean abstraction for "link starts here" and "link stops here",
instead implementing a hugely featured `pdfhref` macro that attempts to
do everything--except support bracketing the link text in a diversion,
which our man(7) design requires.

* tmac/an.tmac (an-input-trap): Set stroke color to default after
  springing `TP`'s supporting trap.

  (an*begin-hyperlink, MR): Stop saving the stroke color.

  (an*end-hyperlink, MR): Stop restoring the saved stroke color.  Set it
  to the default instead after formatting the link text.




___

Reply to this item at:

  

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




[groff] 01/01: [man]: Back away from color management concerns.

2024-02-02 Thread G. Branden Robinson
gbranden pushed a commit to branch master
in repository groff.

commit 52a5a89c0da9f90c83441b8eb8020344a8468686
Author: G. Branden Robinson 
AuthorDate: Thu Feb 1 23:23:45 2024 -0600

[man]: Back away from color management concerns.

Hyperlink colors in PDF were showing a tendency to get "stuck on" when
they shouldn't, and the extra difficulty of managing nested traps (`TP`
followed by `UR`, for example) is proving tricky to sort out.  On top of
that, the man(7) package historically has no cognizance of color issues
and it's doesn't seem like a good time to start, particularly if we only
do it for the 'pdf' output device.  Unfortunately, "pdf.tmac" doesn't
expose a clean abstraction for "link starts here" and "link stops here",
instead implementing a hugely featured `pdfhref` macro that attempts to
do everything--except support bracketing the link text in a diversion,
which our man(7) design requires.

* tmac/an.tmac (an-input-trap): Set stroke color to default after
  springing `TP`'s supporting trap.

  (an*begin-hyperlink, MR): Stop saving the stroke color.

  (an*end-hyperlink, MR): Stop restoring the saved stroke color.  Set it
  to the default instead after formatting the link text.
---
 ChangeLog| 22 ++
 tmac/an.tmac | 19 +++
 2 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0dc65ba62..d103fd649 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,25 @@
+2024-02-02  G. Branden Robinson 
+
+   [man]: Back away from color management concerns.
+
+   Hyperlink colors in PDF were showing a tendency to get "stuck
+   on" when they shouldn't, and the extra difficulty of managing
+   nested traps (`TP` followed by `UR`, for example) is proving
+   tricky to sort out.  On top of that, the man(7) package
+   historically has no cognizance of color issues and it's doesn't
+   seem like a good time to start, particularly if we only do it
+   for the 'pdf' output device.  Unfortunately, "pdf.tmac" doesn't
+   expose a clean abstraction for "link starts here" and "link
+   stops here", instead implementing a hugely featured `pdfhref`
+   macro that attempts to do everything--except support bracketing
+   the link text in a diversion, which our man(7) design requires.
+
+   * tmac/an.tmac (an-input-trap): Set stroke color to default
+   after springing `TP`'s supporting trap.
+   (an*begin-hyperlink, MR): Stop saving the stroke color.
+   (an*end-hyperlink, MR): Stop restoring the saved stroke color.
+   Set it to the default instead after formatting the link text.
+
 2024-02-01  G. Branden Robinson 
 
[man]: Fix Savannah #61434.
diff --git a/tmac/an.tmac b/tmac/an.tmac
index 04873aebf..1e48b3c95 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -685,7 +685,10 @@ contains unsupported escape sequence
 .  \"   .TP
 .  \"   .B foo
 .  \" for instance.
-.  if '\\n[.z]'an*paragraph-tag' .an*TP-trap
+.  if '\\n[.z]'an*paragraph-tag' \{\
+.an*TP-trap
+.gcolor \m[default]
+.  \}
 ..
 .
 .\" The TP macro _requires_ a one-line input trap.
@@ -1135,10 +1138,7 @@ contains unsupported escape sequence
 .\" Start diversion in a new environment.
 .nr an*is-in-link-text-diversion 1
 .ev an*link-text-env
-.if '\*[.T]'pdf' \{\
-.  ds an*saved-stroke-color \\n[.m]\"
-.  nop \&\m[\\*[PDFHREF.TEXT.COLOUR]]\c
-.\}
+.if '\*[.T]'pdf' \&\m[\\*[PDFHREF.TEXT.COLOUR]]\c
 .di an*link-text
 .ll (\\n[an*saved-line-length]u - \\n[an*saved-indentation]u)
 .  \}
@@ -1176,10 +1176,7 @@ contains unsupported escape sequence
 .nop \X'html:'\c
 .  if \\n[an*is-output-terminal] \
 .nop \X'tty: link'\c
-.  if '\*[.T]'pdf' \{\
-.nop \X'pdf: markend'\m[\\*[an*saved-stroke-color]]\c
-.rm an*saved-stroke-color
-.  \}
+.  if '\*[.T]'pdf' \X'pdf: markend'\m[default]\c
 .\}
 .\" If there was no link text, format URI as its own link text.  We
 .\" don't add angle brackets here.
@@ -1281,7 +1278,6 @@ contains unsupported escape sequence
 .if '\*[.T]'html' \
 .  nop \X'html:'\c
 .if '\*[.T]'pdf' \{\
-.  ds an*saved-stroke-color \\n[.m]\"
 .  nop \&\m[\\*[PDFHREF.TEXT.COLOUR]]\c
 .  pdfhref W -D \\*[an*url] -- "|"
 .\}
@@ -1293,8 +1289,7 @@ contains unsupported escape sequence
 .if '\*[.T]'html' \
 .  nop \X'html:'\c
 .if '\*[.T]'pdf' \{\
-.  nop \X'pdf: markend'\m[\\*[an*saved-stroke-color]]\c
-.  rm an*saved-stroke-color
+.  nop \X'pdf: markend'\m[default]\c
 .\}
 .if \\n[an*is-output-terminal] \
 .  nop \X'tty: link'\c

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