[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[G. Branden Robinson]

Follow-up Comment #4, bug #65601 (group groff):

[comment #3 comment #3:]
> It is very simple!

> [derij@pip build (master)]$ echo "This is the arabic alef with a madda above
-> آ"|groff -Tutf8 -Kutf8 -z
> troff::1: error: cannot format glyph: 'u0627_0653' is not a
valid composite character


Yes, thank you--that's helpful.

> It is no longer possible to output this particular utf-8 character (along
with hundreds of others), all perfectly valid utf-8 to the utf-8 device.

Apparently.  Bummer.

> I can't believe that is your intention, to police which particular parts of
unicode are acceptable to you.

But you can contemplate it seriously enough to put it into words.

It would help if you didn't assume autocratic motives behind my code changes.

This is the complete repertoire of composite components known to _groff_ for
quite a while now.


87909b1715 (Werner LEMBERG  2003-03-01 07:34:52 +  1) .\"
composite.tmac
87909b1715 (Werner LEMBERG  2003-03-01 07:34:52 +  2) .
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  3) .do composite ga
u0300
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  4) .do composite ` 
u0300
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  5) .do composite aa
u0301
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  6) .do composite ' 
u0301
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  7) .do composite a^
u0302
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  8) .do composite ^ 
u0302
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 +  9) .do composite a~
u0303
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 10) .do composite ~ 
u0303
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 11) .do composite a-
u0304
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 12) .do composite - 
u0304
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 13) .do composite ab
u0306
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 14) .do composite a.
u0307
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 15) .do composite . 
u0307
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 16) .do composite ad
u0308
94c91fca8c (Werner LEMBERG  2006-02-28 13:04:27 + 17) .do composite : 
u0308
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 18) .do composite ao
u030A
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 19) .do composite a"
u030B
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 20) .do composite " 
u030B
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 21) .do composite ah
u030C
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 22) .do composite ac
u0327
be90ad7557 (Werner LEMBERG  2003-12-19 23:30:02 + 23) .do composite , 
u0327
77d9af6df8 (Werner LEMBERG  2003-03-12 23:00:25 + 24) .do composite ho
u0328
87909b1715 (Werner LEMBERG  2003-03-01 07:34:52 + 25) .
47fc0a18b8 (G. Branden Robinson 2017-11-18 17:49:36 -0500 26) .\" Local
Variables:
47fc0a18b8 (G. Branden Robinson 2017-11-18 17:49:36 -0500 27) .\" mode: nroff
47fc0a18b8 (G. Branden Robinson 2017-11-18 17:49:36 -0500 28) .\" fill-column:
72
47fc0a18b8 (G. Branden Robinson 2017-11-18 17:49:36 -0500 29) .\" End:
47fc0a18b8 (G. Branden Robinson 2017-11-18 17:49:36 -0500 30) .\" vim: set
filetype=groff textwidth=72:


If a policeman's baton is being swung here, it's not mine.  (Though Keith
Marshall might disagree as regards editor settings.)
 
> Just in case the character in the above example gets mangled by savannah,
here's the equivalent:

It came through fine for me, fortunately.

> I hope this gives you enough information to fix this bug.

Yup, I'll revert the change.  At some point I would like to validate the
segregated/spacey/whatever form of escape sequence differently.

Or, if it's too hard, not at all.  That also would be a bummer.

Some notes, probably mainly for my own benefit.  Not particularly
PDF-relevant.

This problem has clarified my thinking around what the formatter needs to know
to delegate grapheme cluster composition to the device,[1][2] and strengthens
my suspicion that HTML output should take place in nroff mode.  This is
because font families and type sizes are less HTML's job than CSS's, and we
might as well communicate such things to the document via different means
("tags", but not exactly as the Mulley/Lemberg solution has applied them). 
Moreover, stylesheet selection should probably be an option in the output
driver, with a stock one generated or embedded in the absence of a user's
choice.  (This isn't too different from how _grops_ uses a PostScript
prologue, for example.)

[1] We won't have problems if grapheme cluster composition can't turn a
half-width character into a full-width one or vice versa (mostly an issue for
terminals), and moreover the formatter doesn't need to know how wide a
grapheme cluster is if it's not responsible for line breaking decisions.  And
for HTML, it isn't.

[2] 

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

[Dave]

Update of bug #62826 (group groff):

  Item Group:None => Documentation  
  Status:None => Need Info  

___

Follow-up Comment #4:

Classifying this as a documentation issue, since the two instances of the bug
#44714 workaround already present in tmac/andoc.tmac should indeed be
documented as such.


___

Reply to this item at:

  

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

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

[Dave]

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

In the cited email thread, a bug occurs only when the deleted sed script
[http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/strip.sed?id=8fc53e4fd397f210a210fa006eaa5bc8e8012044
tmac/strip.sed] is applied to
[http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/andoc.tmac
tmac/andoc.tmac].  This sed script is no longer shipped or supported (bug
#55091).

Bjarni, can you post a test case that demonstrates buggy behavior using
supported tools?

I do agree that until bug #44714 is fixed, the empty control lines to work
around it should be commented.  But the rest of the proffered patch appears to
be to support a local customization.

And even for that purpose, it looks like overkill.  Why have the .ie and two
separate branches, simply to include or exclude the bug-workaround line?  That
line should have no effect regardless of the compatibility-mode setting, so
why not simply always include it and eliminate the conditional?


___

Reply to this item at:

  

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

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[Deri James]

Update of bug #65601 (group groff):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #3:

It is very simple!

[derij@pip build (master)]$ echo "This is the arabic alef with a madda above
-> آ"|groff -Tutf8 -Kutf8 -z
troff::1: error: cannot format glyph: 'u0627_0653' is not a
valid composite character

It is no longer possible to output this particular utf-8 character (along with
hundreds of others), all perfectly valid utf-8 to the utf-8 device. I can't
believe that is your intention, to police which particular parts of unicode
are acceptable to you.

Just in case the character in the above example gets mangled by savannah,
here's the equivalent:-

[derij@pip build (master)]$ echo "This is the arabic alef with a madda above
-> \[u0622]"|groff -Tutf8 -z
troff::1: error: cannot format glyph: 'u0627_0653' is not a
valid composite character

I hope this gives you enough information to fix this bug.


___

Reply to this item at:

  

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

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[G. Branden Robinson]

Update of bug #65601 (group groff):

  Status:None => Need Info  
 Summary: Bogus 'bogus composite' errors introduced by commit
6008b6b7aa => [troff] bogus 'bogus composite' errors introduced by commit
6008b6b7aa

___

Follow-up Comment #2:

[comment #0 original submission:]
> If preconv produces a valid composite character groff should not reject it.
Of course if the composite is not available in any available font

Unfortunately that's not the way GNU _troff_ works.  (Or I'm not understanding
the bug report.)

The list of composite characters is global.

Here's what our Texinfo manual says in Git HEAD.


 -- Escape sequence: \[base-glyph combining-component ...]
...
 GNU 'troff' resolves '\[...]' with more than a single component as
 follows:

* Any component that is found in the GGL [groff glyph list --GBR]
  is converted to the 'u' form.

* Any component 'u' that is found in the list of
  decomposable glyphs is decomposed.

* The resulting elements are then concatenated with '_' in
  between, dropping the leading 'u' in all elements but the
  first.

 No check for the existence of any component (similar to 'tr'
 request) is done.

 Examples:

 '\[A ho]'
  'A' maps to 'u0041', 'ho' maps to 'u02DB', thus the final
  glyph name would be 'u0041_02DB'.  This is not the expected
  result: the ogonek glyph 'ho' is a spacing ogonek, but for a
  proper composite a non-spacing ogonek (U+0328) is necessary.
  Looking into the file 'composite.tmac', one can find
  '.composite ho u0328', which changes the mapping of 'ho' while
  a composite glyph name is constructed, causing the final glyph
  name to be 'u0041_0328'.

 '\[^E u0301]'
 '\[^E aa]'
 '\[E a^ aa]'
 '\[E ^ ']'
  '^E' maps to 'u0045_0302', thus the final glyph name is
  'u0045_0302_0301' in all forms (assuming proper calls of the
  'composite' request).

 It is not possible to define glyphs with names like 'A ho' within a
 'groff' font file.  This is not really a limitation; instead, you
 have to define 'u0041_0328'.
...
 -- Request: .composite c1 c2
 Map ordinary or special character name C1 to C2 when C1 is a
 combining component in a composite character.  See above for
 examples.  This is a strict rewriting of the special character
 name; no check is performed for the existence of a glyph for
 either.  Typically, 'composite' is used to map a spacing character
 to a combining one.  A set of default mappings for many accents can
 be found in the file 'composite.tmac', loaded by the default
 'troffrc' at startup.

 You can obtain a report of mappings defined by 'composite' on the
 standard error stream with the 'pcomposite' request.  *Note
 Debugging::.



> Personally I see little value in this error,

I do find value in it; in the ChangeLog entry, I provided my rationale.  In
the commit message I even provided exhibits of cases that should have produced
a diagnostic but did not.


[troff]: Diagnose bogus composite character escape sequences.  That is,
when a composite character escape sequence like \[a ~] has a bogus
modifier (as opposed to base) character, meaning one that has not been
defined as the source _or_ destination of a `composite` request, warn
about it.  For instance, \[a $] is nonsense, barring a request like
`.composite $ \[uFF00]`, which would map `$`, when used as a modifier
character in a composite special character escape sequence, to U+FF00,
which would be a modifier form of the dollar sign in an alternate
universe.
...
Input:
.nf
\[A a~]
\[A ~]
\[u0041_0301]
\[u0041_007E] \" should fail because 007E is explicitly spacing
\[u0041_0041] \" same reason, more obviously
\[u0041_0301_0301] \" should fail, would have a different meaning
\[u0041_007E_0301] \" both problems above

groff 1.23.0 and earlier:
$ groff -T ps -z EXPERIMENTS/composite_character_construction.groff
troff:...:5: warning: special character 'u0041_007E' not defined
troff:...:6: warning: special character 'u0041_0041' not defined
troff:...:7: warning: special character 'u0041_0301_0301' not defined
troff:...:8: warning: special character 'u0041_007E_0301' not defined
$ groff -Tutf8 -z EXPERIMENTS/composite_character_construction.groff
[no output due to Savannah #65109]

Now:
$ ./build/test-groff -T ps -z
EXPERIMENTS/composite_character_construction.groff
troff:...:5: warning: special character 'u0041_007E' not defined
troff:...:6: error: cannot format glyph: 'u0041_0041' is not a valid
composite character
troff:...:7: warning: special character 'u0041_0301_0301' not defined

[bug #65619] [afmtodit] want a default value for space width if unspecified

[G. Branden Robinson]

Update of bug #65619 (group groff):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Invalid
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 
 Summary: Provide a default value for afmtodit(1) -w, when
unspecified => [afmtodit] want a default value for space width if unspecified

___

Follow-up Comment #2:

Looks like Deri's right.

Lines 28-37 and 485-487 seem to do this work.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/utils/afmtodit/afmtodit.pl?h=1.23.0#n28
https://git.savannah.gnu.org/cgit/groff.git/tree/src/utils/afmtodit/afmtodit.pl?h=1.23.0#n485

Closing as invalid; the desired behavior is already present in _groff_ 1.23.0,
and in fact it looks like I'm the one who implemented it, back in November
2022, though I have no recollection of putting in the logic to deduce it from
the hash first.


commit 5a5a447b2a834f92112609a67821c1a37fdc66cd
Author: G. Branden Robinson 
Date:   Fri Nov 11 15:49:24 2022 -0600

[afmtodit]: Implement "-w" command-line option.

* src/utils/afmtodit/afmtodit.pl: Add new command-line option to specify
  the generated font description's "spacewidth" parameter; in commit
  bf7f6862c3, 2021-09-24, I made libgroff complain if this directive is
  missing (since any font, even a "special" one, can be selected as
  current and the formatter's behavior when encountering an input space
  should be well-defined under that circumstance).  Adding this option
  enables a well-formed font description to be produced.

* src/utils/afmtodit/afmtodit.pl (usage):
* src/utils/afmtodit/afmtodit.1.man (Synopsis, Options): Document it.

* NEWS: Add item.


The other half of this is that output drivers will compute a space width even
if the font description files generated by _afmtodit_(1) lack them.


commit bf7f6862c384f9cff80737cccf6b8fafd4197e1c
Author: G. Branden Robinson 
Date:   Fri Sep 24 17:48:26 2021 +1000

[libgroff]: Make `spacewidth` mandatory.

* src/libs/libgroff/font.cpp (font::load): Throw error if a font
  description file is missing a `spacewidth` directive, since it is now
  re-documented as mandatory.  Atypically, we don't return false in this
  scenario; instead we proceed with the existing logic to compute a
  space width for the font based on typical practices for Western
  alphabetic fonts (see, e.g., .

Thanks to Deri James for the discussion.




___

Reply to this item at:

  

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

[bug #65654] [preconv] want a warning if code '0xA0' is used in the input

[G. Branden Robinson]

Update of bug #65654 (group groff):

Severity:  3 - Normal => 1 - Wish   


___

Reply to this item at:

  

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

[bug #65654] [preconv] want a warning if code '0xA0' is used in the input

[G. Branden Robinson]

Update of bug #65654 (group groff):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[bug #65654] [preconv] want a warning if code '0xA0' is used in the input

[G. Branden Robinson]

Update of bug #65654 (group groff):

  Status:   Need Info => Rejected   
 Assigned to:None => gbranden   
 Summary: preconv.cpp: Issue a warning if code '0xA0' is used
in the input and thus changed to '\~' => [preconv] want a warning if code
'0xA0' is used in the input

___

Follow-up Comment #3:

Dave has convinced me.

If the input code point U+00A0, which is valid as _groff_ input, is not
desired in a source file, write a Makefile/shell script to detect it.

Same as if you wanted to compose a document without using, say, an asterisk. 
(Good luck with string interpolations, though.)

Closing as rejected.

[comment #2 comment #2:]
> ...there is no reason for preconv to warn about this.  The same issue exists
no matter what Unix tool processes input containing both characters.  Users
may choose to avoid U+00A0 in their input files for this reason, or they may
use other strategies to deal with it.  It is not preconv's job to police this
usage.  Users who desire such warnings can write a simple preprocessor (using
grep or sed, perhaps) to emit them.
> 
> Once you start down the rabbit hole of "warn the user about characters that
are hard to visually tell apart," where do you stop?  In the monospace fonts
used in most terminals, you'd be hard-pressed to distinguish U+2012 FIGURE
DASH from U+2013 EN DASH.  Unicode has a plethora of space-like and dash-like
characters.  Should preconv warn about all of these?  That seems absurd.


___

Reply to this item at:

  

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

[bug #65666] tmac/html-end.tmac: numeric overflow when formatting for 'ps' device

[G. Branden Robinson]

Update of bug #65666 (group groff):

  Status:None => Invalid
 Open/Closed:Open => Closed 
 Summary: tmac/html-end.tmac: numeric overflow with 'groff' =>
tmac/html-end.tmac: numeric overflow when formatting for 'ps' device

___

Follow-up Comment #1:


test-groff -ww -z h*.tmac |& less 


This is not a legitimate application of GNU _troff_.

Here are the files you're reading, assuming Git HEAD:


$ ls -1 tmac/h*
tmac/html-end.tmac
tmac/html.tmac
tmac/hyphen.cs
tmac/hyphen.den
tmac/hyphen.det
tmac/hyphen.en
tmac/hyphen.es
tmac/hyphen.fr
tmac/hyphen.it
tmac/hyphen.ru
tmac/hyphen.sv
tmac/hyphenex.cs
tmac/hyphenex.en
tmac/hyphenex.pl


So from the very outset, under groff's default configuration, you are reading
a macro file specific to the "html" output device when the selected output
device is "ps".

"ps" uses a much larger resolution than "html" does--I direct their DESC files
to your attention--and that is why a numeric overflow occurs.

The remainder of this grievance is a duplicate of bug #64301.

Closing as invalid.




___

Reply to this item at:

  

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

[bug #65664] tmac/an-ext.tmac: missing test for a definition of variable 'mG'

[G. Branden Robinson]

Update of bug #65664 (group groff):

  Status:None => Rejected   
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:


> There is a missing test after the comment about 'mG'

I don't agree.

an-ext.tmac is not a stand-alone macro file; like mdoc/doc-common, it is meant
only to be sourced by its parent.

> test-nroff -ww -z an-ext.tmac

The foregoing is (1) therefore an invalid experiment and (2) there is no such
thing as "test-nroff" in GNU _roff_.

> .if !r mG

This uses extended _groff_ syntax and is not portable to AT/DWB/Solaris
10/Plan 9 _troffs_.

The point of this file is to be portable to such formatters.

_groff_man_(7):

   /.../share/groff/1.23.0/tmac/an-ext.tmac
  Except for .SB, definitions of macros described above as
  extensions are contained in this file; in some cases, they
  are simpler versions of definitions appearing in an.tmac,
  and are ignored if the formatter is GNU troff.  They are
  written to be compatible with AT troff and permissively
  licensed—not copylefted.  To reduce the risk of name space
  collisions, string and register names begin only with “m”.
  We encourage man page authors who are concerned about
  portability to legacy Unix systems to copy these
  definitions into their pages, and maintainers of troff
  implementations or work‐alike systems that format man
  pages to re‐use them. ...


An AT formatter will define the `mG` register as zero upon its
first interpolation, which produces intended results.

Rejecting.



___

Reply to this item at:

  

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

[bug #65666] tmac/html-end.tmac: numeric overflow with 'groff'

[Bjarni Ingi Gislason]

URL:
  

 Summary: tmac/html-end.tmac: numeric overflow with 'groff'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 01 May 2024 04:28:16 PM UTC
Category: Macro - others/general
Severity: 3 - Normal
  Item Group: Crash/Unresponsive
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 01 May 2024 04:28:16 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/html-end.tmac: numeric overflow with 'groff'

cd tmac

test-groff -ww -z h*.tmac |& less

troff:html-end.tmac:20: error: numeric overflow
/home/bg/git/groff/build/groff: error: troff: Illegal instruction
(core dumped)

.pl 9i

  This does not happen with "test-nroff".








___

Reply to this item at:

  

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

[bug #65077] [ms] unexpected suppression of `sp` effect after `DE` call

[Dave]

Update of bug #65077 (group groff):

  Status:   Need Info => Rejected   
 Assigned to:None => barx   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Closing with no response from submitter in four months.  Submitter, please
feel free to comment here if you have additional information, and this bug
report can be reopened if necessary.


___

Reply to this item at:

  

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

[bug #65664] tmac/an-ext.tmac: missing test for a definition of variable 'mG'

[Bjarni Ingi Gislason]

URL:
  

 Summary: tmac/an-ext.tmac: missing test for a definition of
variable 'mG'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 01 May 2024 03:36:33 PM UTC
Category: Macro - others/general
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: Wed 01 May 2024 03:36:33 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/an-ext.tmac: missing test for a definition of
variable 'mG'

cd tmac

"test-nroff -ww -z an-ext.tmac" shows

troff:an-ext.tmac:112: warning: register 'mG' not defined

  There is a missing test after the comment about 'mG':

.if !r mG .nr mG 0








___

Reply to this item at:

  

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

[bug #62826] [PATCH] [tmac] options "-mandoc" and '-C' are not compatible

[Dave]

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

[comment #1 comment #1:]
> .\" Due to a bug in GNU troff it necessary to have a no-op line between
> .\" '.do' and '\*'.

This is bug #44714.

> +.  do ie \\n[.cp] \{\
> +.do als TH reload-man
> +.hw\"DO NOT REMOVE the line, see an earlier comment about a bug
> +\\*(Dd\\

The current andoc.tmac demonstrates that an empty control line is sufficient
to work around #44714.  A control line with only a comment also works.  Using
a bare .hw as a no-op, although it acts as one, unnecessarily complicates the
code and confuses readers.


___

Reply to this item at:

  

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

[bug #44714] compatibility mode: .do request and macro expansion via \* collide

[Dave]

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

[comment #1 comment #1:]
> I don't understand why '.do tm' is going to the next input line
> to collect arguments.  'tm' is not documented in CSTR #54 as
> behaving this way.

It's not the behavior of .tm that's at issue, but of .do.

This is the bug that's referred to in this comment in
[http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/andoc.tmac
tmac/andoc.tmac]: "Due to a bug in GNU troff it necessary to have a no-op line
between `.do' and `\*'."

This comment was added in
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=42c866a3f commit
42c866a3f] (which was part of the fix for bug #44708) and refers to these
changes in the commit:

-.  als TH reload-man
-\\*[Dd]\\
+.  do als TH reload-man
+.
+\\*(Dd\\


-.  als Dd reload-doc
-\\*[TH]\\
+.  do als Dd reload-doc
+.
+\\*(TH\\

Indeed, removing these two empty control lines wreaks havoc, showing that a
.tm isn't necessary to trigger the bug.

Probably until this is fixed (which may be a while if it proves as intractable
as Werner predicts), the andoc.tmac comment should cite this ticket rather
than vaguely referring to "a bug in GNU troff."

[comment #2 comment #2:]
>   Why does '.tm' need a '.do'?

It doesn't; that's just a minimal test case to illustrate the bug.  The
situation in andoc.tmac is a real-world case but not a minimal one.


___

Reply to this item at:

  

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