Re: [bug #65115] U-BMI and U-BMR show switched font names in fonts_{n,x}.pdf

2024-01-03 Thread G. Branden Robinson
I'm unable to use Savannah effectively due to backend errors,[1] so
someone else may need to update this ticket.

Here are the changes that should be made.

Summary: -> [bjarnigroff] U-BMI and U-BMR show switched font names in 
fonts_{n,x}.pdf
Item Group: -> Incorrect behavior
Status: -> Invalid
Assigned to: gbranden
Open/Closed: -> Closed

Comment:

This must be a problem with your private branch.

The GNU _groff_ build does not generate "fonts_n.pdf" or "fonts_x.pdf"
artifacts.  (It does produce PostScript versions thereof.)

Further, the _grops_(1) in GNU _groff_ does not (yet) support alternate
foundries.  See bug #58969.

Resolving as invalid.

At 2024-01-03T19:56:52-0500, Bjarni Ingi Gislason wrote:
> URL:
>   
> 
>  Summary: U-BMI and U-BMR show switched font names in 
> fonts_{n,x}.pdf
>Group: GNU roff
>Submitter: bjarniig
>Submitted: Thu 04 Jan 2024 12:56:52 AM UTC
> Category: Font devpdf
> Severity: 3 - Normal
>   Item Group: None
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>  Planned Release: None
> 
> 
> ___
> 
> Follow-up Comments:
> 
> 
> ---
> Date: Thu 04 Jan 2024 12:56:52 AM UTC By: Bjarni Ingi Gislason 
> Subject: U-BMI and U-BMR show switched font names in
>  fonts_{n,x}.pdf
> 
>   Noticed in build/contrib/hdtbl/fonts_{n,x}.pdf pages 41 and 42.
> 
>   groff font name U-BMI
> 
>   internalname URWBookman-Light
> 
> and
> 
>   groff font name U-BMR
> 
>   internalname URWBookman-LightItalic
> 
> 
>   There was a correction (for BMI/BMR) applied to
> font/devpdf/Foundry.in in
> 
> commit e9bcfb1f855af8e9817b4bb22a659926750da28b
> Author: Colin Watson ...
> Date:   Tue Apr 28 18:14:16 2020 +0100
>  
>   to correct this, but the similar correction for the URW fonts
> (later in the file) were not applied.
> 
> BMI|N|i|text.map|text.enc|URWBookman-Light.t1!URWBookman-Light!URWBookmanL-LighItal!b018032l.pfb
> BMR|N|r|text.map|text.enc|URWBookman-LightItalic.t1!URWBookman-LightItalic!URWBookmanL-Ligh!b018012l.pfb

[1] https://savannah.nongnu.org/support/index.php?111000


signature.asc
Description: PGP signature


Re: [bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread G. Branden Robinson
Savannah is still angry (just with me?) so I can't reply to the ticket
via the web interface.[1]

---

Paydirt!

The trig example in _eqn_(1) and the missing glyphs listed in comment #0
are all restored!

I have no idea how to describe the change, though.  Happy to commit with
you as author, but I am slackjawed as to what to write in the
ChangeLog... 

Care to reveal your secret? :D

Regards,
Branden

[1] https://savannah.nongnu.org/support/?111000

At 2024-01-04T00:29:19-0500, Deri James wrote:
> Follow-up Comment #5, bug#65112 (group groff):
> 
> Try this.
> 
> diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
> index e26bc6b43..d55bc1e00 100644
> --- a/src/devices/gropdf/gropdf.pl
> +++ b/src/devices/gropdf/gropdf.pl
> @@ -4733,7 +4733,11 @@ sub subs_call
>  my $n2=$charstr->[++$j];
>  push(@c,[$n2,0]);
>  
> -if ($n2==6) # seac
> +if ($n2==16)# callothersub
> +{
> +$c[$#c-4]->[0]=MarkSub("#$c[$#c-4]->[0]") if
> ($c[$#c-4]->[1]);
> +}
> +elsif ($n2==6) # seac
>  {
>  my $ch=$StdEnc{$c[$#c-2]->[0]};
>  my $chf;
> 
> 
> 
> 
> ___
> 
> Reply to this item at:
> 
>   
> 
> ___
> Message sent via Savannah
> https://savannah.gnu.org/


signature.asc
Description: PGP signature


[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread Deri James
Follow-up Comment #5, bug#65112 (group groff):

Try this.

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index e26bc6b43..d55bc1e00 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4733,7 +4733,11 @@ sub subs_call
 my $n2=$charstr->[++$j];
 push(@c,[$n2,0]);
 
-if ($n2==6) # seac
+if ($n2==16)# callothersub
+{
+$c[$#c-4]->[0]=MarkSub("#$c[$#c-4]->[0]") if
($c[$#c-4]->[1]);
+}
+elsif ($n2==6) # seac
 {
 my $ch=$StdEnc{$c[$#c-2]->[0]};
 my $chf;




___

Reply to this item at:

  

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




[bug #65117] [pdfmark] premature page brake in "pdfmark.ms" output with page size A4

2024-01-03 Thread Bjarni Ingi Gislason
URL:
  

 Summary: [pdfmark] premature page brake in "pdfmark.ms"
output with page size A4
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 04 Jan 2024 01:53:56 AM UTC
Category: Macro - others/general
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 04 Jan 2024 01:53:56 AM UTC By: Bjarni Ingi Gislason 
Subject: [pdfmark] premature page brake in "pdfmark.ms" output
with page size A4

Page 14.

  The page is advanced after

invokes ``.pdfsync O'' to ensure that the outline for the

  although there it plenty of space left on the page.

  The next page begins with the last line of the previous
paragraph (widow).








___

Reply to this item at:

  

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




[bug #65115] U-BMI and U-BMR show switched font names in fonts_{n, x}.pdf

2024-01-03 Thread Bjarni Ingi Gislason
URL:
  

 Summary: U-BMI and U-BMR show switched font names in 
fonts_{n,x}.pdf
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 04 Jan 2024 12:56:52 AM UTC
Category: Font devpdf
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 04 Jan 2024 12:56:52 AM UTC By: Bjarni Ingi Gislason 
Subject: U-BMI and U-BMR show switched font names in
 fonts_{n,x}.pdf

  Noticed in build/contrib/hdtbl/fonts_{n,x}.pdf pages 41 and 42.

  groff font name U-BMI

  internalname URWBookman-Light

and

  groff font name U-BMR

  internalname URWBookman-LightItalic


  There was a correction (for BMI/BMR) applied to
font/devpdf/Foundry.in in

commit e9bcfb1f855af8e9817b4bb22a659926750da28b
Author: Colin Watson ...
Date:   Tue Apr 28 18:14:16 2020 +0100
 
  to correct this, but the similar correction for the URW fonts
(later in the file) were not applied.

BMI|N|i|text.map|text.enc|URWBookman-Light.t1!URWBookman-Light!URWBookmanL-LighItal!b018032l.pfb
BMR|N|r|text.map|text.enc|URWBookman-LightItalic.t1!URWBookman-LightItalic!URWBookmanL-Ligh!b018012l.pfb








___

Reply to this item at:

  

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




[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread G. Branden Robinson
Follow-up Comment #4, bug#65112 (group groff):

[comment #3 comment #3:]
> Ooh, a proper bug. Please can you look in font/devpdf/download file and send
me whichever file is assigned to the Symbol font. I can't duplicate the
problem with three different versions of the Symbol font file but you may have
a fourth.

Sure thing.


$ grep -i symbol build/font/devpdf/download 
Symbol  */usr/share/fonts/type1/gsfonts/s05l.pfb


> I have a suspicion of where the bug probably lies

I'm throwing my money on


4662 if ($sec{"/$n"}->[0] != $i) 
4663 {   
4664 # duplicate glyph name !!! discard ???  
4665 $lines->[$i]=undef; 
4666 }


like a roulette player.  :P

> but I need a font which causes it.

Attached.

(file #55521)

___

Additional Item Attachment:

File name: s05l.pfb   Size:32 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-64f71c9e61c99f5e0fa8f7988d21ea179eb554bc.tar.gz


___

Reply to this item at:

  

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




[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread Deri James
Follow-up Comment #3, bug#65112 (group groff):

Ooh, a proper bug. Please can you look in font/devpdf/download file and send
me whichever file is assigned to the Symbol font. I can't duplicate the
problem with three different versions of the Symbol font file but you may have
a fourth. I have a suspicion of where the bug probably lies but I need a font
which causes it.


___

Reply to this item at:

  

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




[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread G. Branden Robinson
Follow-up Comment #2, bug#65112 (group groff):

Hi Deri,

[comment #1 comment #1:]
> Please can you attach the pdf produced, but first could you try the
> run with -P-e.

It's already generated with `-P -e`.

doc/doc.am:


doc/groff-man-pages.pdf: $(GROFF_MAN_PAGES_ALL) eqn pic tbl \
  $(TMAC_PACKAGE_MAN) $(TMAC_PACKAGE_MDOC) font/devps/freeeuro.pfa
$(GROFF_V)$(DOC_GROFF) -pet -mandoc -dHF=HB -rC1 \
  -rCHECKSTYLE=3 -Tpdf -P-e \
  $(GROFF_MAN_PAGES1) \
  $(tmac_srcdir)/sv.tmac $(GROFF_MAN_PAGES2) \
  $(tmac_srcdir)/en.tmac $(GROFF_MAN_PAGES3) > $@


> Without this, all the fonts used (except symbol
> slanted) are base fonts so no fonts are embedded (so no subsetting
> either), and its pot luck if your pdf viewer picks a font which
> contains all the glyphs required.
> 
> I have run groff_char.7 here:-
>
> [derij@pip build (deri-gropdf-ng)]$ ./test-groff man/groff_char.7 -Tpdf -t
-man -P-e |okular -
> troff:man/groff_char.7:1046: warning: special character '.j' not defined
> troff:man/groff_char.7:1468: warning: special character 'vA' not defined
> troff:man/groff_char.7:1598: warning: special character 'bs' not defined
> troff:man/groff_char.7:1771: warning: special character '-+' not defined
> troff:man/groff_char.7:1820: warning: special character 'coproduct' not
defined
> troff:man/groff_char.7:1915: warning: special character '+e' not defined

Yup.  These 6 diagnostics are expected, and documented in the "PROBLEMS"
file.

> /home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning: Using
nospace mode for font 'EURO'

Yup.  We're covering that one in bug #65111.

> /home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning:
> unable to embed font file for 'Symbol-Slanted' (SS) (missing entry in
> 'download' file?)

I don't get this one, yet, but that is I think because I have not
cherry-picked the relevant support from your branch onto master yet.

> Along with the known missing glyphs there is the warning about EURO
> (dealt with separately) and I also have not added SlantedSymbol to the
> download file. I've attached a png showing the fonts used by okular.

I'm using Okular as well.

The attachment would be 1.5MiB large (a savings of nearly 3 megs over
"old generation" gropdf!) and I don't think Savannah will accept that.
However you can find the file at my Dropbox account.

https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?dl=0

It's "groff-man-pages.2024-01-03.pdf".

Let me know how I can be of further assistance.

Regards,
Branden



___

Reply to this item at:

  

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




[bug #65111] [gropdf] "warning: Using nospace mode for font 'EURO'"

2024-01-03 Thread G. Branden Robinson
Follow-up Comment #2, bug#65111 (group groff):

Hi Deri,

[comment #1 comment #1:]
> As I have documented elsewhere gropdf has to behave a little
> differently if a particular font does not define a space glyph. 

That statement does sound familiar.

The idea of a "space glyph" is a difficult fit for *roff-descended
typography.

> This is because it can use a slightly more compact format if the font
> defines "space" or "u0020" as a glyph. In a "Hello World" example the
> difference is "(Hello World)" (glyph defined) and "(Hello) move
> horizontal (World)" (glyph undefined).

As you know, the latter is the only way a space is represented in *roff
internally and in device-independent output ("trout", "grout").

> The distance moved is set by troff, I assume this is the purpose of
> spacewidth in the groff font.

Yes.

> Some CJK fonts also don't have a space glyph. It is just a warning,
> and was useful in debugging, to know gropdf had switched to a slightly
> less efficient output format, the message could be removed, although
> knowing which mode gropdf was operating in if I am debugging a user's
> issue could be useful.

Since there is nothing the user normally needs to do, or even _can_ do
without undertaking a mild form of digital font development, I would
prefer that we demote this from a warning to debugging output.

It strikes me as somewhat similar to the erstwhile "can't write node in
transparent throughput" and the other diagnostic like that; the user
isn't asking for nonsense, and is powerless to do anything about the
diagnostic.

What do you think?

Regards,
Branden



___

Reply to this item at:

  

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




[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread Deri James
Follow-up Comment #1, bug#65112 (group groff):

Please can you attach the pdf produced, but first could you try the run with
-P-e. Without this, all the fonts used (except symbol slanted) are base fonts
so no fonts are embedded (so no subsetting either), and its pot luck if your
pdf viewer picks a font which contains all the glyphs required.

I have run groff_char.7 here:-

[derij@pip build (deri-gropdf-ng)]$ ./test-groff man/groff_char.7 -Tpdf -t
-man -P-e |okular -
troff:man/groff_char.7:1046: warning: special character '.j' not defined
troff:man/groff_char.7:1468: warning: special character 'vA' not defined
troff:man/groff_char.7:1598: warning: special character 'bs' not defined
troff:man/groff_char.7:1771: warning: special character '-+' not defined
troff:man/groff_char.7:1820: warning: special character 'coproduct' not
defined
troff:man/groff_char.7:1915: warning: special character '+e' not defined
/home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning: Using
nospace mode for font 'EURO'
/home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning: unable to
embed font file for 'Symbol-Slanted' (SS) (missing entry in 'download' file?)

Along with the known missing glyphs there is the warning about EURO (dealt
with separately) and I also have not added SlantedSymbol to the download file.
I've attached a png showing the fonts used by okular.

(file #55520)

___

Additional Item Attachment:

File name: Fonts.png  Size:96 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-739efcb88d2528965d3c4e746313c5dd0a172b9e.tar.gz


___

Reply to this item at:

  

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




[bug #65111] [gropdf] "warning: Using nospace mode for font 'EURO'"

2024-01-03 Thread Deri James
Follow-up Comment #1, bug#65111 (group groff):

As I have documented elsewhere gropdf has to behave a little differently if a
particular font does not define a space glyph. This is because it can use a
slightly more compact format if the font defines "space" or "u0020" as a
glyph. In a "Hello World" example the difference is "(Hello World)" (glyph
defined) and "(Hello) move horizontal (World)" (glyph undefined). The distance
moved is set by troff, I assume this is the purpose of spacewidth in the groff
font. Some CJK fonts also don't have a space glyph. It is just a warning, and
was useful in debugging, to know gropdf had switched to a slightly less
efficient output format, the message could be removed, although knowing which
mode gropdf was operating in if I am debugging a user's issue could be useful.


___

Reply to this item at:

  

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




[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

2024-01-03 Thread G. Branden Robinson
URL:
  

 Summary: [gropdf] glyphs missing from groff_char(7) but not
warned about
   Group: GNU roff
   Submitter: gbranden
   Submitted: Wed 03 Jan 2024 12:48:17 PM UTC
Category: Driver gropdf
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 03 Jan 2024 12:48:17 PM UTC By: G. Branden Robinson 
This may have to do with the not-yet-merged SlantedSymbol PDF font, but what
is present and missing seems mighty odd if that's the case.


\[AN] logical and
\[**] mathematical asterisk
\[=~] approximately equal to
\[ap] similar to, tilde operator
\[~~] almost equal to
\[~=] "
\[Re] blackletter R, real part
\[*B] uppercase beta
\[*E] uppercase epsilon
\[*U] uppercase upsilon
\[*a] lowercase alpha
\[*b] lowercase beta
\[*d] lowercase delta
\[*e] lowercase epsilon
\[*z] lowercase zeta
\[*y] lowercase eta
\[*c] lowercase xi
\[+h] variant theta
\[+f] variant phi
\[ts] terminal lowercase sigma
\[CL] solid club suit


Did something go wrong with the font subsetting, and it got too aggressive?







___

Reply to this item at:

  

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




[bug #65111] [gropdf] "warning: Using nospace mode for font 'EURO'"

2024-01-03 Thread G. Branden Robinson
URL:
  

 Summary: [gropdf] "warning: Using nospace mode for font
'EURO'"
   Group: GNU roff
   Submitter: gbranden
   Submitted: Wed 03 Jan 2024 12:40:51 PM UTC
Category: Font - 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 03 Jan 2024 12:40:51 PM UTC By: G. Branden Robinson 
Seen during _groff_ build.  The Euro glyphs show up fine.


gropdf:man/groff_char.7: warning: Using nospace mode for font 'EURO'


Figure out what do about this.







___

Reply to this item at:

  

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




[bug #65110] [gropdf] should not include full argv[0] in diagnostic messages

2024-01-03 Thread G. Branden Robinson
URL:
  

 Summary: [gropdf] should not include full argv[0] in
diagnostic messages
   Group: GNU roff
   Submitter: gbranden
   Submitted: Wed 03 Jan 2024 12:39:16 PM 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: Wed 03 Jan 2024 12:39:16 PM UTC By: G. Branden Robinson 

troff:man/groff_char.7:1927: warning: special character '+e' not defined
fonts_n.roff: listing font 'PR'...
fonts_x.roff: listing font 'SS'...
/home/branden/src/GIT/groff/build/gropdf:man/groff_char.7: warning: Using
nospace mode for font 'EURO'









___

Reply to this item at:

  

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




[bug #64592] [troff] registers .m and .M contain no initial value

2024-01-03 Thread G. Branden Robinson
Follow-up Comment #12, bug#64592 (group groff):

If no one objects to my proposed change in comment #10, please set this
ticket's status to "Confirmed" and I'll take care of it.

Or someone else can.  It's a one-liner!  But I don't know what _mom_(7) will
need to do.

Adding Peter to CC list accordingly.


___

Reply to this item at:

  

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




[bug #65098] merge branch deri-gropdf-ng to master

2024-01-03 Thread G. Branden Robinson
Update of bug#65098 (group groff):

  Status:None => In Progress

___

Follow-up Comment #5:

Made some headway here.


8d320bd7b gropdf(1): Recast `pagenumbering` description.
8dc1df406 [gropdf]: Add `pdfpagenumbering` macro.
7256dfb9f gropdf(1): Update.
fbde1f13b [build]: Increment Perl dependency to 5.8.
77fb2e809 [gropdf]: Add font subsetting and Type 1 parser.




___

Reply to this item at:

  

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




[bug #64316] [mm] does not implement DWB mm's ".WC -FB"

2024-01-03 Thread G. Branden Robinson
Update of bug#64316 (group groff):

  Item Group:  Feature change => Incorrect behaviour
 Summary: [mm] WC "FB" and "-FB" arguments appear to be dead
letters => [mm] does not implement DWB mm's ".WC -FB"

___

Follow-up Comment #2:

Bug #64336 is fixed.  So, returning to this...

The following input produces the same output in GNU _nroff_ mode whether the
first line has "FB", "-FB", or is commented out.


.WC -FB
.P
This is my paragraph.
.DF
.TS
L.
This is my big table.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
.TE
.DE
.P
This concludes my paper.


But there is a difference in DWB _nroff_, so this seems like a legit bug. 
".WC FB" is indeed the default behavior, and ".WC -FB" changes the
formatting.


$ diff -u floating-keep-no-WC-FB.txt floating-keep-WC-FB.txt && echo SAME
SAME
$ diff -U1 floating-keep-WC-FB.txt floating-keep-WC-minus-FB.txt
--- floating-keep-WC-FB.txt 2024-01-03 04:18:58.396207730 -0600
+++ floating-keep-WC-minus-FB.txt   2024-01-03 04:18:58.400207719 -0600
@@ -7,4 +7,2 @@
 
-   This is my paragraph.
-
This is my big table.
@@ -58,2 +56,4 @@
48
+   49
+   50
 
@@ -73,4 +73,2 @@
 
-   49
-   50
51
@@ -78,2 +76,4 @@
 
+   This is my paragraph.
+
This concludes my paper.


It's a neat trick to push material _before_ the float after it.  Is a
diversion involved?  Does DWB _mm_ divert all paragraphs by default??


___

Reply to this item at:

  

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




[bug #64594] [troff] "warning: cannot select font 'C'"

2024-01-03 Thread G. Branden Robinson
Update of bug#64594 (group groff):

  Status:   Need Info => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

The aspect of https://github.com/cpuguy83/go-md2man/issues/99 that is relevant
to this ticket was resolved in October.

The GitHub issue is still open because they're either having a problem with
failing to tell _man_(1) to run the _tbl_(1) preprocessor (though I think
man-db _man_ always runs it anyway), or running _groff_ directly on
_tbl_-using man pages but failing to specify the `-t` option to preprocess
them with _tbl_.

Closing as invalid; that is, this ticket not a _groff_ bug, but a problem with
how people are _using_ _groff_.  And one that people are resolving,
fortunately!


___

Reply to this item at:

  

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