[bug #55708] [PATCH] broken Makefile dependency for doc/automake.pdf on Cygwin

2023-02-25 Thread G. Branden Robinson
Update of bug #55708 (project groff):

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

___

Follow-up Comment #2:

Cygwin people are talking to us again!

Per Brian Inglis,

> No longer an issue - perhaps did not run bootstrap (hey good guess - that
exists on sv!) after git pull, or autoreconf before building from download,
etc.

https://lists.gnu.org/archive/html/groff/2023-02/msg00156.html

Resolving as invalid.


___

Reply to this item at:

  

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




[bug #55708] broken Makefile dependency for doc/automake.pdf on Cygwin

2023-02-25 Thread G. Branden Robinson
Update of bug #55708 (project groff):

 Summary: [PATCH] broken Makefile dependency for
doc/automake.pdf on Cygwin => broken Makefile dependency for doc/automake.pdf
on Cygwin


___

Reply to this item at:

  

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




[bug #63808] configure gives incorrect information regarding pdf generation

2023-02-25 Thread G. Branden Robinson
Follow-up Comment #65, bug #63808 (project groff):

Things are looking good on Debian bullseye

Here's the revised last commit, with ChangeLog and proper commit message.


commit a887a4eda48d0b90a0203355497faa9f9f83cc6d (HEAD -> master)
Author: G. Branden Robinson 
Date:   Sat Feb 25 02:08:57 2023 -0600

[devpdf]: Revise tests.

* font/devpdf/tests/check-default-foundry.sh.in: Test only the base 14
  fonts of the PDF standard unconditionally.  Test the remainder from
  the set of 35 commonly distributed only if a Ghostscript interpreter
  was detected at configuration time, because the latter fonts _must_ be
  embedded in PDF documents.  If they're not present, skip the test
  rather than failing it.
* font/devpdf/tests/check-urw-foundry.sh.in: Skip test if no URW fonts
  detected at configuration time, rather than failing it.
* m4/groff.m4 (GROFF_GROPDF_PROGRAM_NOTICE, GROFF_URW_FONTS_NOTICE):
  Drop warnings of expected test failures.  The tests no longer fail in
  the anticipated circumstances.

diff --git a/ChangeLog b/ChangeLog
index 0323d7c99..738f0bc51 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2023-02-25  G. Branden Robinson 
+
+   [devpdf]: Revise tests.
+
+   * font/devpdf/tests/check-default-foundry.sh.in: Test only the
+   base 14 fonts of the PDF standard unconditionally.  Test the
+   remainder from the set of 35 commonly distributed only if a
+   Ghostscript interpreter was detected at configuration time,
+   because the latter fonts _must_ be embedded in PDF documents.
+   If they're not present, skip the test rather than failing it.
+   * font/devpdf/tests/check-urw-foundry.sh.in: Skip test if no URW
+   fonts detected at configuration time, rather than failing it.
+   * m4/groff.m4 (GROFF_GROPDF_PROGRAM_NOTICE)
+   (GROFF_URW_FONTS_NOTICE): Drop warnings of expected test
+   failures.  The tests no longer fail in the anticipated
+   circumstances.
+
 2023-02-24  G. Branden Robinson 
 
[devpdf]: Generate tests from template files, so we can populate
diff --git a/font/devpdf/tests/check-default-foundry.sh.in
b/font/devpdf/tests/check-default-foundry.sh.in
index 1ddd83d0b..026cc012a 100755
--- a/font/devpdf/tests/check-default-foundry.sh.in
+++ b/font/devpdf/tests/check-default-foundry.sh.in
@@ -18,19 +18,42 @@
 # along with this program. If not, see .
 #
 
-# Ensure that groff's PDF device has font description files for the
-# default (unnamed) foundry's PostScript Level 2 base 35 fonts, plus
-# groff's EURO.
-#
-# These font descriptions should be available in any gropdf
-# configuration because they can be copied from the devps font
-# descriptions even if the URW fonts are not available.
-#
-# Another test script checks the "U" (URW) foundry.
-
 devpdf_fontbuilddir="${abs_top_builddir:-.}"/font/devpdf
+ghostscript=@GHOSTSCRIPT@
+
+wail () {
+echo ...FAILED >&2
+fail=yes
+}
+
+fail=
+
+# The are the base 14 fonts required by the PDF standard.  They should
+# _always_ be present and supported.  If their corresponding Type 1 font
+# files are available, they too can be embedded in a PDF using gropdf's
+# "-e" option.  groff's "EURO" font is always available; we ship it.
+mandatory_fonts='CB
+CBI
+CI
+CR
+HB
+HBI
+HI
+HR
+S
+TB
+TBI
+TI
+TR
+ZD'
 
-fonts='AB
+# These fonts are commonly, but not universally, available; if used,
+# their corresponding Type 1 font files must be embedded in a document.
+#
+# Their groff font descriptions will always be available: we ship them.
+# But they are not usable with gropdf(1) if the Type 1 files are absent.
+# We thus will not test them if they are not expected to work.
+supplementary_fonts='AB
 ABI
 AI
 AR
@@ -38,19 +61,10 @@ BMB
 BMBI
 BMI
 BMR
-CB
-CBI
-CI
-CR
-EURO
-HB
-HBI
-HI
 HNB
 HNBI
 HNI
 HNR
-HR
 NB
 NBI
 NI
@@ -59,24 +73,25 @@ PB
 PBI
 PI
 PR
-S
-TB
-TBI
-TI
-TR
-ZCMI
-ZD'
+ZCMI'
 
-fail=
+for f in $mandatory_fonts
+do
+printf "checking for font description %s...\n" "$f" >&2
+test -f "$devpdf_fontbuilddir"/"$f" || wail
+done
+
+if [ "$ghostscript" = no ] || [ "$ghostscript" = missing ]
+then
+echo "Ghostscript not available; skipping check for any further" \
+ "fonts in the default foundry" >&2
+exit 77 # skip
+fi
 
-for f in $fonts
+for f in $supplementary_fonts
 do
 printf "checking for font description %s...\n" "$f" >&2
-if ! [ -f "$devpdf_fontbuilddir"/"$f" ]
-then
-echo FAILED >&2
-fail=yes
-fi
+test -f "$devpdf_fontbuilddir"/"$f" || wail
 done
 
 test -z "$fail"
diff --git a/font/devpdf/tests/check-urw-foundry.sh.in
b/font/devpdf/tests/check-urw-foundry.sh.in
index 9d4e514bf..d31b3aa3e 100755
--- a/font/devpdf/tests/check-urw-foundry.sh.in
+++ b/font/devpdf/tests/check-urw-foundry.sh.in
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2022 Free Software Foundation, Inc.
+# Copyright (C) 2022-2023 Free Software Foundat

[bug #63827] withdraw contrib/pdfmark

2023-02-25 Thread Keith Marshall
Follow-up Comment #9, bug #63827 (project groff):

[comment #8 comment #8:]
> [comment #6 comment #6:]
> > [comment #3 comment #3:]
> > > ...
> > > groff's man pages all have that logic at the top and bottom that
> > > takes the body of the page out of compatibility mode, ...
> > As already noted in bug #63133 comment #1
, your code, to do that:
> [snip]
> > doesn't work on groff-1.22.x and earlier, (because those older
> > groff versions do not grok the 'cp' register).
> 
> [suggested replacement]:
> 
> .\" Save and disable compatibility mode (e.g., for Solaris 10/11).
> .nr _C \n(.C
> .do rnn _C *groff_pdfroff_1_man_C
> .cp 0
> 
> 
> This is similar to something I've had in my man.local for quite a while.
> 
> 
> .if \n(.x=1&\n(.y<23 \{
> .  \" Construct an equivalent of groff 1.23's .cp register.
> .  nr }{ \n(.C
> .  do nr .cp \n(}{
> .\}
> 
> 
> I'm not sure which I like better.  Yours does have appeal.
Either _should_ work, I think.  As you might expect, I tend to favour mine,
not just because it is _mine_, but because:
* It doesn't introduce any conditional version dependency; (feature test
conditions should _always_ trump version tests, but it doesn't even depend of
a feature test).
* It doesn't pollute the register namespace with a 'cp' register, which
wouldn't otherwise be present, and shouldn't be needed, (_unless_ there is
_another_ version dependency, within the document stream, which requires it).


___

Reply to this item at:

  

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




[bug #63808] configure gives incorrect information regarding pdf generation

2023-02-25 Thread G. Branden Robinson
Follow-up Comment #66, bug #63808 (project groff):

macOS looks good.

Solaris 10 and 11 are kind of meh.

Everything is fine except the check-default-foundry.sh test, which fails.  But
this was already raised in comment #43.

Apparently the problem is the use of %rom%.  The font files are hidden away
where our configure script and BuildFoundries can't get to them.  At least not
yet.

On the system to which I have access, the Ghostscript installation is also
geriatric.  9.15.

I'm not regarding this as a release blocker.


GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc.  All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
 -dNOPAUSE   no pause after page   | -q   `quiet', fewer messages
 -gx  page size in pixels   | -r  pixels/inch resolution
 -sDEVICE=  select device | -dBATCH  exit after last file
 -sOutputFile= select output file: - for stdout, |command for pipe,
 embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3
PDF
Default output device: x11alpha
Available devices:
   alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 ap3250 appledmp
   atx23 atx24 atx38 bbox bit bitcmyk bitrgb bitrgbtags bj10e bj10v bj10vh
   bj200 bjc600 bjc800 bjc880j bjccmyk bjccolor bjcgray bjcmono bmp16 bmp16m
   bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8 ccr cdeskjet cdj1600 cdj500
   cdj550 cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono cdnj500 cfax
   chp2200 cif cljet5 cljet5c cljet5pr coslw2p coslwxl cp50 cups declj250
   deskjet devicen dfaxhigh dfaxlow dj505j djet500 djet500c dl2100 dnj650c
   epl2050 epl2050p epl2120 epl2500 epl2750 epl5800 epl5900 epl6100 epl6200
   eplcolor eplmono eps2write eps9high eps9mid epson epsonc escp escpage
   faxg3 faxg32d faxg4 fmlbp fmpr fpng fs600 gdi hl1240 hl1250 hl7x0
   hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500 hpdj500c hpdj510
   hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c hpdj670c hpdj680c
   hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus hpdjportable ibmpro
   ijs imagen inferno ink_cov inkcov itk24i itk38 iwhi iwlo iwlq jetp3852
   jj100 jpeg jpegcmyk jpeggray la50 la70 la75 la75plus laserjet lbp310
   lbp320 lbp8 lex2050 lex3200 lex5700 lex7000 lips2p lips3 lips4 lips4v
   lj250 lj3100sw lj4dith lj4dithp lj5gray lj5mono ljet2p ljet3 ljet3d ljet4
   ljet4d ljet4pjl ljetplus ln03 lp1800 lp1900 lp2000 lp2200 lp2400 lp2500
   lp2563 lp3000c lp7500 lp7700 lp7900 lp8000 lp8000c lp8100 lp8200c lp8300c
   lp8300f lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900 lp9000b
   lp9000c lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600 lp9600s
   lp9800c lps4500 lps6500 lq850 lxm3200 lxm5700m m8510 mag16 mag256
   md1xMono md2k md50Eco md50Mono md5k mgr4 mgr8 mgrgray2 mgrgray4 mgrgray8
   mgrmono miff24 mj500c mj6000c mj700v2c mj8000c ml600 necp6 npdl nullpage
   oce9050 oki182 oki4w okiibm oprp opvp paintjet pam pamcmyk32 pamcmyk4 pbm
   pbmraw pcl3 pcx16 pcx24b pcx256 pcx256 pcx2up pcxcmyk pcxgray pcxmono
   pdfwrite pdfwrite pdfwrite pgm pgmraw pgnm pgnmraw photoex picty180 pj
   pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw plan plan9bm planc plang
   plank planm png16 png16m png256 png48 pngalpha pnggray pngmono pnm pnmraw
   ppm ppmraw pr1000 pr1000_4 pr150 pr201 ps2write psdcmyk psdcmykog psdrgb
   pwgraster pxlcolor pxlmono r4081 rinkj rpdl samsunggdi sgirgb sj48
   spotcmyk st800 stcolor sunhmono t4693d2 t4693d4 t4693d8 tek4696 tiff12nc
   tiff24nc tiff32nc tiff48nc tiff64nc tiffcrle tiffg3 tiffg32d tiffg4
   tiffgray tifflzw tiffpack tiffscaled tiffsep tiffsep1 txtwrite uniprint
   x11 x11alpha x11cmyk x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono
   x11rg16x x11rg32x xcf xes xpswrite
Search path:
   %rom%Resource/Init/ : %rom%lib/ :
   /opt/csw/share/ghostscript/9.15/Resource/Init :
   /opt/csw/share/ghostscript/9.15/lib :
   /opt/csw/share/ghostscript/9.15/Resource/Font :
   /opt/csw/share/ghostscript/fonts : /opt/csw/share/ghostscript/fonts
Ghostscript is also using fontconfig to search for font files
Initialization files are compiled into the executable.
For more information, see /opt/csw/share/ghostscript/9.15/doc/Use.htm.
Please report bugs to bugs.ghostscript.com.





___

Reply to this item at:

  

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




[bug #63827] withdraw contrib/pdfmark

2023-02-25 Thread Dave
Follow-up Comment #10, bug #63827 (project groff):

Should the 1.23 announcement/news mention that:
* the pdfmark bundled with this release of groff is not the latest code (and
provide a pointer to that code)?
* this is the last groff release that will have pdfmark bundled with it?


___

Reply to this item at:

  

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




[bug #63808] configure gives incorrect information regarding pdf generation

2023-02-25 Thread G. Branden Robinson
Follow-up Comment #67, bug #63808 (project groff):

Hi Deri,

Regarding the %rom% issue, it looks likely to me that the "rom filesystem
built into the executable"  isn't
really in the executable, but in the libgs9 dynamic shared object instead.  At
20 MB it's way too big to attach on Savannah.


$ size ~/tmp/gs-solaris10 ~/tmp/libgs.so.9.15-solaris10 
   textdata bss dec hex filename
   3025 236 3283589 e05 /home/branden/tmp/gs-solaris10
4760075 14791376   3368 1955481912a6203
/home/branden/tmp/libgs.so.9.15-solaris10
$ objdump -x ~/tmp/libgs.so.9.15-solaris10|grep -F .data|grep gs_romfs
00a0cb34 g O .data  0004  gs_romfs_buildtime
00a16ad8 g O .data.rel.local03f8  gs_romfs
$ objdump -x /usr/lib/x86_64-linux-gnu/libgs.so.9.53|grep -F .data|grep
gs_romfs || echo NO MATCHES
NO MATCHES
$ size /usr/lib/x86_64-linux-gnu/libgs.so.9.53
   textdata bss dec hex filename
5936697 10509080   3808 16449585 fb0031
/usr/lib/x86_64-linux-gnu/libgs.so.9.53


So that's 14MB of data in the Solaris library, and 10MB in the Debian one.

4.3MB happens to be the size of the gs-fonts.tgz file you put up.

Coincidence?

Is there anything I can do to help you root out the data you're looking for?


___

Reply to this item at:

  

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




Re: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered

2023-02-25 Thread Brian Inglis

On 2023-02-21 08:16, Brian Inglis wrote:

On 2023-02-21 00:04, G. Branden Robinson wrote:

At 2023-02-20T21:59:33-0700, Brian Inglis wrote:

Another data point from current official release; instead of:
.TE
.TS
allbox tab(:);
l lx.
splitting the man table using:
.T&
l lx.
behaves the same as if the table was not split: fine on utf8,
disappears on other output devices/file formats.



I'm not quite sure what you're reporting.
It sounds like it _might_ be this bug affecting tbl output on nroff
devices:
https://savannah.gnu.org/bugs/index.php?49390
...which, fortunately, is fixed in groff 1.23.0 (as of today, at release
candidate 3).
If that isn't it, can you supply me with a malfunctioning specimen, and
describe what you expected?


Just another data point for issues with long -man page multi-"page" tables not 
rendering on non-tty devices/file formats.


Hi Branden,

Still issues with latest man/tbl/groff-rc3 rendering of long tables on HTML 
outputs.
Try any apropos {cp125{1,2},iso{-,_}8859-{1..16},latin{1..10}} charset encoding 
like man -H latin1 or groff equivalent and only last "page" of table renders.

At least man -Tps generates decent table content.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry



Re: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered

2023-02-25 Thread G. Branden Robinson
[looping groff@gnu discussion list]

At 2023-02-25T13:53:35-0700, Brian Inglis wrote:
> > Just another data point for issues with long -man page multi-"page"
> > tables not rendering on non-tty devices/file formats.
[...]
> Still issues with latest man/tbl/groff-rc3 rendering of long tables on
> HTML outputs.

Unfortunately, this is not a surprise.  It also is not a regression
since groff 1.22.4, at least not for me--if you have a groff that
handles this correctly, I'm intensely interested to have a look at the
patches!

> Try any apropos {cp125{1,2},iso{-,_}8859-{1..16},latin{1..10}} charset
> encoding like man -H latin1 or groff equivalent and only last "page"
> of table renders.

Yes.  I don't have a better assessment for this situation than "it
sucks".

I think the best way forward on this is Savannah #60052.

https://savannah.gnu.org/bugs/index.php?60052

> At least man -Tps generates decent table content.

I believe _all_ other groff output devices render tbl(1) output
correctly, modulo some known minor nits in nroff mode, which can be seen
at the following URL.

https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=100&advsrch=0&status_id=1&resolution_id=0&assigned_to=0&category_id=109&bug_group_id=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=25&history_date_monthfd=2&history_date_yearfd=2023&chunksz=50&spamscore=5&boxoptionwanted=1#options

I'll file a ticket for this one though, as we don't seem to have one for
it.

Regards,
Branden


signature.asc
Description: PGP signature


[bug #63837] [grohtml] only the last page of multi-page tables is rendered

2023-02-25 Thread G. Branden Robinson
URL:
  

 Summary: [grohtml] only the last page of multi-page tables is
rendered
   Group: GNU roff
   Submitter: gbranden
   Submitted: Sat 25 Feb 2023 09:31:16 PM UTC
Category: Preprocessor html
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: Sat 25 Feb 2023 09:31:16 PM UTC By: G. Branden Robinson 
Affects groff 1.22.4.

Brian Inglis pointed out that only the last page of multi-page table is
rendered in grohtml.

I _suspect_ that this is a preprocessor problem (pre-grohtml).

It _might_ have to do with the noise we often get about "suppression limit
registers".


troff: suppression limit registers span more than one page;
image description 1 will be wrong


I think the real fix is to stop using this preprocessor to render anything at
all, a pretty severe re-architecting of grohtml.  But grohtml already supports
rendering equations to MathML for XHTML output, and it is apparently no longer
true that PostScript images are used for drawing horizontal rules.

That leaves _only_ tbl as a reason for pre-grohtml to exist.

However, in the meantime, we might be able to salvage things by setting the
page length to a very large value.

Reported in https://lists.gnu.org/archive/html/bug-groff/2023-02/msg00258.html
.







___

Reply to this item at:

  

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




[bug #63837] [grohtml] only the last page of multi-page tables is rendered

2023-02-25 Thread G. Branden Robinson
Follow-up Comment #1, bug #63837 (project groff):

Adding Brian to CC.


___

Reply to this item at:

  

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




Re: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered

2023-02-25 Thread Brian Inglis

On 2023-02-25 14:20, G. Branden Robinson wrote:

[looping groff@gnu discussion list]

At 2023-02-25T13:53:35-0700, Brian Inglis wrote:

Just another data point for issues with long -man page multi-"page"
tables not rendering on non-tty devices/file formats.

[...]

Still issues with latest man/tbl/groff-rc3 rendering of long tables on
HTML outputs.


Unfortunately, this is not a surprise.  It also is not a regression
since groff 1.22.4, at least not for me--if you have a groff that
handles this correctly, I'm intensely interested to have a look at the
patches!


Try any apropos {cp125{1,2},iso{-,_}8859-{1..16},latin{1..10}} charset
encoding like man -H latin1 or groff equivalent and only last "page"
of table renders.


Yes.  I don't have a better assessment for this situation than "it
sucks".

I think the best way forward on this is Savannah #60052.

https://savannah.gnu.org/bugs/index.php?60052


At least man -Tps generates decent table content.


I believe _all_ other groff output devices render tbl(1) output
correctly, modulo some known minor nits in nroff mode, which can be seen
at the following URL.

https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=100&advsrch=0&status_id=1&resolution_id=0&assigned_to=0&category_id=109&bug_group_id=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=25&history_date_monthfd=2&history_date_yearfd=2023&chunksz=50&spamscore=5&boxoptionwanted=1#options

I'll file a ticket for this one though, as we don't seem to have one for
it.


Even man -X100 looks good, but the Motif theme looks so Windows 3/95!

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry




[bug #63838] [tbl] doesn't warn if table entry ends with \z escape sequence

2023-02-25 Thread G. Branden Robinson
URL:
  

 Summary: [tbl] doesn't warn if table entry ends with \z
escape sequence
   Group: GNU roff
   Submitter: gbranden
   Submitted: Sun 26 Feb 2023 12:48:50 AM UTC
Category: Preprocessor tbl
Severity: 3 - Normal
  Item Group: Warning/Suspicious behaviour
  Status: In Progress
 Privacy: Public
 Assigned to: gbranden
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 26 Feb 2023 12:48:50 AM UTC By: G. Branden Robinson 
Seen in mandoc(1) regression tests.

We don't warn about this.  We should.


$ cat ATTIC/escape-z-at-end-of-table-data.roff 
.\" inspired by a mandoc(1) regression test
.TS
tab(:);
LL.
foo:bar
baz\z:qux
.TE
.pl \n(nlu


Fix pending.  Time for a post-1.23.0 branch!







___

Reply to this item at:

  

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