[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

[Bjarni Ingi Gislason]

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

  This is a mistake of mine.

  I somehow thought that some man pages were created (from '*.in' files) and
needed a '*.tmac' file for that.

  So this ticket is invalid.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65990] [mm] macro 'init@reset' is still used but not defined

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65990>

 Summary: [mm] macro 'init@reset' is still used but not
defined
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 14 Jul 2024 07:33:48 PM UTC
Category: Macro package mm
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: Sun 14 Jul 2024 07:33:48 PM UTC By: Bjarni Ingi Gislason 
Subject: [mm] macro 'init@reset' is still used but not defined

ChangeLog:  * m.tmac (init@reset): Rename this macro...
ChangeLog:  * m.tmac (init@reset, debug, debug-all, SA, pg@header)
ChangeLog:  (PE): Replace `init@reset` call with `PY` (and then space by
ChangeLog:  * added init@reset for LT-macros so .S works for letters
ChangeLog:  *   Do .init@reset first thing to initialize the default
environment.
mm/4.MT:.   init@reset
mm/ms.cov:. init@reset
mm/ms.cov:. init@reset


ChangeLog:  * m.tmac (init@reset): Rename this macro...
ChangeLog:  * m.tmac (init@reset, debug, debug-all, SA, pg@header)
ChangeLog:  (PE): Replace `init@reset` call with `PY` (and then space by
ChangeLog:  * added init@reset for LT-macros so .S works for letters
ChangeLog:  *   Do .init@reset first thing to initialize the default
environment.
mm/4.MT:.   init@reset
mm/ms.cov:. init@reset
mm/ms.cov:. init@reset








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65990>

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


signature.asc
Description: PGP signature

[bug #65989] [mm] m.tmac: error in the update of the file

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65989>

 Summary: [mm] m.tmac: error in the update of the file
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 14 Jul 2024 06:49:31 PM UTC
Category: Macro package mm
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: Sun 14 Jul 2024 06:49:31 PM UTC By: Bjarni Ingi Gislason 
Subject:m.tmac: error in the update of the file

Directory: contrib/mm

commit 5da71ef6eff0294fadded6268eef54744057d3d6 from Sat Jul 6 19:48:49 2024
-0500

@@ -543,7 +543,7 @@ http://savannah.gnu.org/bugs/?group=groff.
 .if !r line*ac\\n[.z] .nr line*ac\\n[.z] 0
 .ie \\n[.$] \{\
 .  if !\B'\\$1' .@error \\$0: argument is not numeric: '\\$1'
-.  if (\\$1 < 0) .@error \\$0: negative motion '\\$1' not supported
+.  if \\$1<0) .@error \\$0: negative motion '\\$1' not supported

  Example:

.if -1<0) .tm something is less than zero
.pl \n(nlu

 gives:

) .tm something is less than zero









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65989>

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


signature.asc
Description: PGP signature

[bug #65988] [Makefile] some tmac files are not listed as dependencies for compilations

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65988>

 Summary: [Makefile] some tmac files are not listed as
dependencies for compilations
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 14 Jul 2024 05:52:25 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 14 Jul 2024 05:52:25 PM UTC By: Bjarni Ingi Gislason 
Subject: [Makefile] some tmac files are not listed as dependencies for
compilations

  For example 'an.tmac' and 'm.tmac'

  These file are not created.

  There should not be a need to 'make distclean' when they are updated!

  Only 'doc/groff_man-pages...' are updated if 'an.tmac' is "touched".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65988>

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


signature.asc
Description: PGP signature

[bug #65975] pre-html.cpp: null destination pointer [-Wformat-truncation=]

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65975>

 Summary: pre-html.cpp: null destination pointer
[-Wformat-truncation=]
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 10 Jul 2024 10:46:40 PM UTC
Category: Preprocessor html
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 10 Jul 2024 10:46:40 PM UTC By: Bjarni Ingi Gislason 
Subject: pre-html.cpp: null destination pointer [-Wformat-truncation=]

Directory: src/preproc/html

Source: git upstream

CC=/usr/bin/gcc-14 (gcc-14 (Debian 14-20240330-1) 14.0.1 20240330
(experimental) [master r14-9728-g6fc84f680d0]

[...]
  CXX  src/preproc/html/pre-html.o
../src/preproc/html/pre-html.cpp: In function 'char* make_string(const char*,
...)':
../src/preproc/html/pre-html.cpp:420:16: warning: null destination pointer
[-Wformat-truncation=]
  420 |   n = vsnprintf(p, size, fmt, ap);
  |   ~^~
[...]


  I don't get this warning.  I use the latest version of GNULIB and more
gnulib modules than upstream does.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65975>

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


signature.asc
Description: PGP signature

[bug #65962] input.cpp: reduce stack limit to <=100

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65962>

 Summary: input.cpp: reduce stack limit to <=100
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 07 Jul 2024 02:05:36 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 07 Jul 2024 02:05:36 PM UTC By: Bjarni Ingi Gislason 
Subject: input.cpp: reduce stack limit to <=100

Directory: src/roff/troff

  Bug #65930 "[me] large values of register 'tv' cause infinite trap
recursion"

  uses about 1000 recursions before it gives up.

  I have not seen the reasoning for this high value.

  As I have noticed before, documenting the reasons for a concrete decision
is lacking in too many places in source files, which is the right place to
explain the used algorithms or concrete numbers.

  How many items in a stack are minimally needed for a correctly functioning
input file?

  I have run the build of groff with reduced values of the constant
"DEFAULT_INPUT_STACK_LIMIT"

and it needs > 25 < 50 stack elements.

If it needs more, I would suspect a bug, or a bad coding (algorithm) to be
the cause.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65962>

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


signature.asc
Description: PGP signature

[bug #65961] pre-html.cpp: use option "-blank-image=pass" for "pnmcrop" to avoid warnings

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65961>

 Summary: pre-html.cpp: use option "-blank-image=pass" for
"pnmcrop" to avoid  warnings
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 07 Jul 2024 12:48:19 PM UTC
Category: Preprocessor html
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: Sun 07 Jul 2024 12:48:19 PM UTC By: Bjarni Ingi Gislason 
Subject: pre-html.cpp: use option "-blank-image=pass" for "pnmcrop" to avoid
warnings

Directory: src/preproc/html

  From "pnmcrop(1)" concerning the warning

nmcrop: The image is entirely background; there is nothing to crop.

(copied from the file PROBLEMS.)

-blank-image={abort|pass|minimize|maxcrop}
   This determines how pnmcrop handles an image which is entirely
 background (blank), a case where cropping doesn't make much sense.

The remark in the file "PROBLEMS" should then be revised (dropped).








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65961>

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


signature.asc
Description: PGP signature

[bug #65960] pre-html.cpp: replace "pnmcut" with "pamcut"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65960>

 Summary: pre-html.cpp: replace "pnmcut" with "pamcut"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 07 Jul 2024 12:27:22 PM UTC
Category: Preprocessor html
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 07 Jul 2024 12:27:22 PM UTC By: Bjarni Ingi Gislason 
Subject: pre-html.cpp: replace "pnmcut" with "pamcut"

Directory: src/preproc/html

  "pamcut" has deprecated "pnmcut", see "pnmcut(1)".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65960>

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


signature.asc
Description: PGP signature

Re: Proposed: next-generation alignment and adjustment control

[Bjarni Ingi Gislason]

  The bug is shown in the example by

.ad l 
mno pqr\p
.na
stu vwx\p
.ad
yza bcd\p

  Result is (links, no adjustment, unchanged=previous)

yza   bcd

  instead of

yza bcd

  With my patch it is

yza bcd

  with other parts unchanged from upstream.

  All the different implementations (also "plan9") just have the same bug.

Re: Documenting a set of functions with -man

[Bjarni Ingi Gislason]

On Fri, Jun 21, 2024 at 02:52:22PM +, Lennart Jablonka wrote:
> Quoth Anton Shepelev:
> > What is the covenstional way of documenting a set of C
> > functions with -man?  Have you any recommendations or
> > examples about typesetting function declaraions, their
> > return types and aruguments in a classic man-page?  The .SY
> > macro does not seem to work well for C, because its function
> > declarations start with the return type.
> 
> Do take a look at .SY, but also note that it???s possible to do something
> like this.

> .TH MMAP 2
> .SH NAME
> mmap \- map pages of memory
> .SH SYNOPSIS
> .ad l
> #include 
> .HP
> void *mmap(\
> void\ *addr,
> size_t\ len,
> int\ prot,
> int\ flags,
> int\ filedes,
> off_t\ off);
> .HP "\w'void *mmap('u"
> void *mmap(\
> void\ *addr,
> size_t\ len,
> int\ prot,
> int\ flags,
> int\ filedes,
> off_t\ off);
> .ad

  There are two issues here,

1) wrong use of the adjustment requests

2) still not fixed bug #55579 (patch in bug #59795).

About

1) '.ad' only works with '.na' so the right use is

.na\" instead of '.ad l'
...
.ad

2) the fix in item 1 does not work if the adjustment before '.na' is 'left',
as the adjustment is then switched to 'both'.

  The patch in #59795 (comment #0) is simple enough to apply it with an
editor.

grolbp.1.man: Some remarks about this man page

[Bjarni Ingi Gislason]

Package: groff
Version: upstream
Severity: minor

Dear Maintainer,

   * What led up to the situation?

 Checking for defects with

[test-]groff -mandoc -t -K utf8 -rF0 -rHY=0 -ww -b -z < "man page"

  [test-groff is a script in the repository for "groff"] (local copy and
"troff" slightly changed by me).

   * What was the outcome of this action?

troff: backtrace: file '':184
troff::184: warning: trailing space in the line
troff: backtrace: file '':188
troff::188: warning: trailing space in the line
troff: backtrace: file '':189
troff::189: warning: trailing space in the line


   * What outcome did you expect instead?

 No output (warnings).

-.-

  General remarks and further material (declared as a "diff" file) are in the
attachments.
  Any program (person), that produces man pages, should check its content for
defects by using

groff -mandoc -t -ww -b -z -K utf8 

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any generator should check its products with the above mentioned
'groff' and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The generator may have to be corrected to get a better man page,
the source file may, and any additional file may.

  Common errors:

  Not removing trailing spaces (in in- and output).
  The reason for these trailing spaces should be found and eliminated.

  Not beginning each input sentence
(that is not confined to a markup)
in the first column.
Line length should thus be reduced.

-.-

The difference between the formatted outputs can be seen with:

  nroff -mandoc  > 
  nroff -mandoc  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "

instead of "nroff -mandoc"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint grolbp.1.man": (possibly shortened list)

mandoc: grolbp.1.man:92:2: WARNING: skipping paragraph macro: PP empty
mandoc: grolbp.1.man:102:2: WARNING: skipping paragraph macro: PP empty

-.-.

Output from "test-groff -b -mandoc -rF0 -rHY=0 -K utf8 -t -ww -z ":

troff: backtrace: file '':184
troff::184: warning: trailing space in the line
troff: backtrace: file '':188
troff::188: warning: trailing space in the line
troff: backtrace: file '':189
troff::189: warning: trailing space in the line

  In current groff (1.23.0), table is rendered thus


+---+-++--+--+
|   Typeface|  Roman  |  Bold  |  Italic  |  Bold-Italic |
+---+-++--+--+
| Dutch |  TR |  TB|  TI  |  TBI |
+---+-++--+--+
| Swiss |  HR |  HB|  HI  |  HBI |
+---+-++--+--+
| Swiss Narrow  |  HNR|  HNB   |  HNI |  HNBI|
+---+-++--+--+
| Courier   |  CR |  CB|  CI  |  |
+---+-++--+--+
| Elite |  ER |  EB|  EI  |  |
+---+-++--+--+
 
  There is thus no need to format all columns in the header line as
"centered" (C).

  That will also eliminate the creation of a trailing space in the last header
column.

  Adding a '\&' as a data in the last (empty) column in the last two lines
will also eliminate unnecessary trailing space
(which is removed each time this man page is rendered,
instead of never creating it;
not reported by the upstream version).

[bug #65886] repeated word in some man pages

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65886>

 Summary: repeated word in some man pages
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 16 Jun 2024 09:26:37 PM UTC
Category: General
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 16 Jun 2024 09:26:37 PM UTC By: Bjarni Ingi Gislason 
Subject: repeated word in some man pages

! ./man/groff.7.man: 5736 --> to
! ./man/groff.7.man: 8438 --> by

! ./man/groff_diff.7.man: 772 --> to
! ./man/groff_diff.7.man: 1021 --> is

! ./src/devices/grodvi/grodvi.1.man: 329 --> are

! ./src/devices/gropdf/gropdf.1.man: 1498 --> be

! ./tmac/groff_www.7.man: 470 --> the








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65886>

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

[bug #65885] env.cpp: warning about "-Woverloaded-virtual="

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65885>

 Summary: env.cpp: warning about "-Woverloaded-virtual="
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sat 15 Jun 2024 06:47:07 PM UTC
Category: Core
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 15 Jun 2024 06:47:07 PM UTC By: Bjarni Ingi Gislason 
Subject: env.cpp: warning about "-Woverloaded-virtual="

Directory: src/roff/troff

gcc-14 (Debian 14-20240330-1) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]

[...]
  CXX  src/roff/troff/env.o
In file included from ../src/roff/troff/env.cpp:29:
../src/roff/troff/reg.h:23:16: warning: 'virtual bool reg::get_value(units*)'
was hidden [-Woverloaded-virtual=]
   23 |   virtual bool get_value(units *);
  |^
../src/roff/troff/env.cpp:3184:8: note:   by 'bool
unsigned_env_reg::get_value(unsigned int*)'
 3184 |   bool get_value(unsigned *val);
  |^
  CXXLDtroff
[...] 








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65885>

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

[bug #65809] extend 'soelim' to deal with compressed files like 'zsoelim' does

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65809>

 Summary: extend 'soelim' to deal with compressed files like
'zsoelim' does
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 29 May 2024 11:14:24 PM UTC
Category: Preprocessor soelim
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: Wed 29 May 2024 11:14:24 PM UTC By: Bjarni Ingi Gislason 
Subject: extend 'soelim' to deal with compressed files like 'zsoelim' does

  It should be more appropriate to have (need) only one version of a
'soelim' software.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65809>

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

[bug #59980] soelim(1): replace an '.EX /.EE' block containing a diagram with a table

[Bjarni Ingi Gislason]

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

  This is not the same as bug #59962.

  Why is it stated as being so?

  One should not use manually formatted input,
but the preprocessors and man macros to produce the final output.

  Manual pages do get translated, which means strings change their length.



___

Reply to this item at:

  

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

[bug #65788] gropdf: warning: PDF Dict Key 'User' does not start with '/'

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65788>

 Summary: gropdf: warning: PDF Dict Key 'User' does not start
with '/'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Fri 24 May 2024 09:10:23 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: Fri 24 May 2024 09:10:23 PM UTC By: Bjarni Ingi Gislason 
Subject: gropdf: warning: PDF Dict Key 'User' does not start with '/'

man -Tpdf pamaltsat


gropdf:-: warning: PDF Dict Key 'User' does not start with '/'
/usr/bin/man: command exited with status 1: (cd /usr/share/man &&
/usr/libexec/man-db/zsoelim) | (cd /usr/share/man &&
/usr/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd
/usr/share/man && preconv -e UTF-8) | (cd /usr/share/man &&
/home/bg/git/groff/build/tbl) | (cd /usr/share/man && test-groff -b -ww -s
-mandoc -rCHECKSTYLE=5 -dpaper=a4
-M/home/bg/git/groff/build/s-tmac:/home/bg/git/groff/tmac -rF=0 -rLL=90m
-dAD=l -rHY=0 -rLT=90m -dMF=R -Tpdf)

-.-

pamaltsat: Using libnetpbm from Netpbm Version: Netpbm 11.6.1
pamaltsat: Built from source dated 2024-05-05 15:58:05
pamaltsat: Built by Debian
pamaltsat: BSD defined
pamaltsat: RGB_ENV='RGBDEF'
pamaltsat: RGBENV= 'RGBDEF' (env vbl is unset)








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65788>

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

[bug #65761] macro TP with '\c' and a single-font macro in the tag fails to format correctly

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65761>

 Summary: macro TP with '\c' and a single-font macro in the
tag fails to format correctly
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 20 May 2024 01:00:14 AM UTC
Category: Macro package man
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: Mon 20 May 2024 01:00:14 AM UTC By: Bjarni Ingi Gislason 
Subject: an.tmac: macro TP with '\c' and a single-font
macro in the tag fails to format correctly

  Example:

.TH TP-bug 1 2024-05-19 testen
.SH NAME
testman \- test some macros
.PP
1)
.TP
.B \-\-\~\c
.RI [ args ]
.PP
2)
.TP
.B X\~\c
.RI A Z B
.PP
3)
.TP
.BR X \~A\c
.IR Z B
.PP
4)
.TP
.BR \-\-\~ [\c
.IR args ]
.
.pl \n[nl]u

-.-

  Result:

TP-bug(1)General Commands Manual  
TP-bug(1)

NAME
 testman - test some macros

 1)

 -- [args]

 2)

 X  AZB

 3)

 X AZB

 4)

 -- [args]

testen 2024-05-19 
TP-bug(1)

-.-

  The '[args]' is not part of the tag!

  If '.B ' is replaced with '\fB' then it works correctly.

  If the first tag line uses a _two-fonts_ macro and a '\c',
it is processed correctly (at least in the above example).








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65761>

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

Re: Greek in Groff

[Bjarni Ingi Gislason]

  Thanks.

  Some remarks.

1) All input files should have the same encoding or an including
(higher order) one

2) 'groff' can only deal with 'ascii' and 'latin1' encodings
itself

3) therefor all other encodings must be converted to ascii (7
bit encoding) with 'preconv', for example with the option '-K
' for 'groff' or explicitly with 'preconv -e ''
 > 

4) in your example

preconv -e iso88597 doc.ref > 

  or to simplify

mv doc.ref > raw.doc.ref (or doc.ref.raw, etc.)

preconv -e iso88597 raw.doc.ref > doc.ref

  and the rest as usual.

  So the 'doc.ref' file becomes

.lf 1 raw.doc.ref
%K ecb24space
%Q European Central Bank
%C Main
%D 2022
%T Study on the payment attitudes of consumers in the euro area (SPACE) - 2022
%O \[u03A0]\[u03B7]\[u03B3]\[u03AE]: 
http://web.archive.org/web/2024051216if_/https://www.ecb.europa.eu/stats/ecb_surveys/space/html/ecb.spacereport202212~783ffdf46e.en.html
 
\[u03A0]\[u03C1]\[u03BF]\[u03C3]\[u03C0]\[u03B5]\[u03BB]\[u03AC]\[u03C3]\[u03C4]\[u03B7]\[u03BA]\[u03B5]
 \[u03C3]\[u03C4]\[u03B9]\[u03C2] 12 \[u039C]\[u03B1]\[u03CA]\[u03BF]\[u03C5] 
24]

Re: Greek in Groff

[Bjarni Ingi Gislason]

On Thu, May 16, 2024 at 09:19:00PM +0300, Nikos Parafestas wrote:
[...]
> After changing the doc.ref encoding from UTF-8 to ISO8859-7 the
> references fonts change but they are still unreadable.
> 
> I also tested the following command:
> 
> groff -k -ms -R -Tutf8 doc.ms | cat -s
> 
> which also has the same results.
> 
> Greek fonts renter as expected in the document body but not in
> references.
> 
> Is there something wrong happening when refer (-R) encodes Greek
> characters?
> 
[...]

  All characters in the 'doc.ref' file are displayed as being
from the IS-8859-1 code page (Latin1).

N.B.

  Put provided input files (also) in the attachments.

[bug #65729] an.tmac: macro 'EX' is defined with 'de1' but 'EE' is not

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65729>

 Summary: an.tmac: macro 'EX' is defined with 'de1' but 'EE'
is not
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 13 May 2024 12:23:15 AM UTC
Category: Macro package man
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: Mon 13 May 2024 12:23:15 AM UTC By: Bjarni Ingi Gislason 
Subject: an.tmac: macro 'EX' is defined with 'de1' but 'EE' is not

  Seen with the output from

  gzip -d -c /usr/share/man/man3/adjtime.3.gz | \
test-groff -mandoc -t -ww -b -z -C

troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':807:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: register '[' not defined
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':809:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: macro 're' not defined
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':818:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: macro 'fa' not defined
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':818:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: macro '[' not defined
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':819:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: cannot select font '0a'
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':825:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: empty left operand to '*'
operator
troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':825:
macro 'EE'
troff: backtrace: file '':47
troff::47: warning: expected numeric expression,
got character 'i'








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65729>

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

Re: Hungarumlauts in built-in fonts

[Bjarni Ingi Gislason]

On Sat, May 11, 2024 at 07:10:43PM -0500, Nate Bargmann wrote:
> I discovered the U-* fonts were missing once I upgraded to Debian 12
> (Bookworm) last year:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051248
> 
> I don't think that is in any way this is any way related to the Void
> package, however.
> 
[...]

  The 'ghostscript' is not automatically installed with 'groff',
it is just recommended.  Therefore my call for "Make 'groff' depend
on 'ghostscript'".

  You must install it explicitly, which is the only explanation I
have for the absence of the 'fonts-urw-base35', and that the
Debian's maintainer has not answered.

Re: Hungarumlauts in built-in fonts

[Bjarni Ingi Gislason]

On Sat, May 11, 2024 at 06:18:44PM +0200, Gáspár Gerg?? wrote:
> Thanks for the reply! 
> 
> I already have ghostscript installed. I checked the dependencies, on Void, 
> the package you are referring to is called "gfonts" (the description says 
> "URW+ base35 fonts").
> 
> I also tried using the ps device instead and piping the result through 
> ps2pdf, and but I still got the same error with the URW fonts. When using the 
> font names without U- though, this got them to actually render the different 
> fonts (with ??,??,?? and ?? still not working properly).
> 

  Your 'groff' does not find the U-* files.

  What does 'locate U-AB' show

  I get

/home/bg/development/groff-1.22.4/build/font/devpdf/U-AB
/home/bg/development/groff-1.22.4/build/font/devpdf/U-ABI
/home/bg/git/groff/build/font/devpdf/U-AB
/home/bg/git/groff/build/font/devpdf/U-ABI
/home/bg/git/master-groff/groff/build/font/devpdf/U-AB
/home/bg/git/master-groff/groff/build/font/devpdf/U-ABI
/home/bg/src/groff-1.22.4/build/font/devpdf/U-AB
/home/bg/src/groff-1.22.4/build/font/devpdf/U-ABI
/usr/share/groff/1.23.0/font/devpdf/U-AB
/usr/share/groff/1.23.0/font/devpdf/U-ABI

  The last two are relevant for installed 'groff' (in Debian).

-.-

N.B.

  Your lines are too long.

make 'groff' depend on 'ghostscript'

[Bjarni Ingi Gislason]

  1) to get the URW-fonts

  2) to avoid people having to ask on a groff-list

  3) to elevate status of 'ghostscript' from 'recommends' to
'depends' (Debian)

  4) the configure script already asks about it

  5) groff's default output is PostScript.

  6) the packet 'groff' produces some 'ps' files, like (in Debian
/usr/share/doc/groff):

./examples/hdtbl/col_rowspan_colors.ps.gz
./examples/hdtbl/fonts_x.ps.gz
./examples/hdtbl/fonts_n.ps.gz
./examples/hdtbl/color_transitions.ps.gz
./examples/hdtbl/mixed_pickles.ps.gz
./examples/hdtbl/short_reference.ps.gz
./examples/hdtbl/color_table_cells.ps.gz
./examples/hdtbl/color_nested_tables.ps.gz
./examples/hdtbl/color_boxes.ps.gz
./examples/hdtbl/chess_board.ps.gz
./examples/hdtbl/rainbow.ps.gz
./examples/mom/penguin.ps.gz
./examples/webpage.ps.gz
./examples/grnexmpl.ps.gz
./pic.ps.gz
./meintro.ps.gz
./meref.ps.gz
./meintro_fr.ps.gz
./ms.ps.gz

Re: Hungarumlauts in built-in fonts

[Bjarni Ingi Gislason]

  I should have mentioned that the package 'ghostscript' must be
installed.  The 'configure' script tests for its existence.

  'ghostscript' depends on 'fonts-urw-base35'.

  The names are based on Debian.

[bug #65717] tmac/andoc.tmac is not protected against compatibility mode

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65717>

 Summary: tmac/andoc.tmac is not protected against
compatibility mode
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 09 May 2024 04:54:35 PM UTC
Category: Macro package mdoc
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 09 May 2024 04:54:35 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/andoc.tmac is not protected against compatibility
mode

  A test for showing a macro file not being protected against
compatibility mode is

test-nroff -mandoc -t -ww -z -C tmac/groff_mdoc.7

  where 'test-nroff' can be created with a script

#!/usr/bin/sh
export GROFF_TEST_GROFF=
nroff $*
exit

cd groff/build/tmac

test-nroff -mandoc -t -ww -z -C groff_mdoc.7

  Result:

troff: warning: macro 'c-check-depth' not defined
troff: warning: register '[' not defined
troff: warning: expected numeric expression, got character 'c'
troff: warning: macro 'c-break-page-with-new-number' not defined

N.B.
  File name and line number are missing from the warnings!








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65717>

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

[bug #65702] tmac/doc.tmac: previous state of compatibility (register '.cp') is not restored at end

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65702>

 Summary: tmac/doc.tmac: previous state of compatibility
(register '.cp') is not restored at end
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 06 May 2024 08:36:27 PM UTC
Category: Macro package mdoc
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: Mon 06 May 2024 08:36:27 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/doc.tmac: previous state of compatibility (register
'.cp') is not restored at end

  There is only this

.do if d Dd .nx
.
.
.cp 0
.
.
.\" Define a string for use in diagnostic messages.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65702>

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

[bug #65701] tmac/doc.tmac: extra '.ec'

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65701>

 Summary: tmac/doc.tmac: extra '.ec'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 06 May 2024 08:25:51 PM UTC
Category: Macro package mdoc
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 08:25:51 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/doc.tmac: extra '.ec'

.ec
.
.blm doc-empty-line
.
.
.ec
.
.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65701>

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

[bug #65692] tmac/mdoc.tmac: fix minor differences from the "mandoc" software

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65692>

 Summary: tmac/mdoc.tmac: fix minor differences from the
"mandoc" software
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 05 May 2024 10:59:36 PM UTC
Category: Macro package mdoc
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: Sun 05 May 2024 10:59:36 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/mdoc.tmac: fix minor differences from the "mandoc"
software

  Fix minor differences in the output between 'nroff' and
'mandoc' using 'tmac/groff_mdoc.7' as an example.

  Reduce the number of these differences.

  They are best displayed with 'less -R'.

  The output of 'mandoc' should have priority and thus the
tmac/mdoc.tmac should be adjusted for the simplest differences.

  This is to facilitate the comparison of the output of files with
the 'mandoc' requests.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65692>

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

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

[Bjarni Ingi Gislason]

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

  I do not have a case example as I use stripping (expanded
'tmac/strip.sed') to avoid the repeated removal of non-essential
characters.

  Example is file 'tmac/doc.tmac'.

  Size

162336 mar 27 12:39 tmac/doc.tmac

  Stripped size

 90253 maí  5 17:52 build/s-tmac/doc.tmac

  I can get rid of my '.hw' (and thus the '.' in tmac/doc.tmac)
line and the comments by changing '.de' to '.de1' for three
macros in 'tmac/mdoc/doc-common'

  The test for such a change is

test-nroff -mandoc -ww -z -t -C tmac/groff_mdoc.7

N.B.

  cd tmac/mdoc

  The files in this directory have to be changed to
non-compatibility mode like some other tmac files.



___

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:
  <https://savannah.gnu.org/bugs/?65666>

 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:

  <https://savannah.gnu.org/bugs/?65666>

___
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:
  <https://savannah.gnu.org/bugs/?65664>

 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:

  <https://savannah.gnu.org/bugs/?65664>

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

[bug #65654] preconv.cpp: Issue a warning if code '0xA0' is used in the input and thus changed to '\~'

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65654>

 Summary: preconv.cpp: Issue a warning if code '0xA0' is used
in the input and thus changed to '\~'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 28 Apr 2024 06:58:35 PM UTC
Category: Preprocessor preconv
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 28 Apr 2024 06:58:35 PM UTC By: Bjarni Ingi Gislason 
Subject: preconv.cpp: Issue a warning if code '0xA0' is used in
the input and thus changed to '\~'

File: "src/preproc/preconv/preconv.cpp"
Subroutine: unicode_entity(int u)

  The code '0xA0' is displayed as a normal space, and is thus
visually the same as it.

  So authors better use '\~' directly in their files.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65654>

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

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

[Bjarni Ingi Gislason]

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

  The glyph 'u00A0' is defined in "groff/build/font/devpdf/U-*"
except in  U-ZD:


U-AB:u00A0  280,0   0   690 uni00A0 --  
U-ABI:u00A0 280,0,0,0,500   690 uni00A0 --  
U-AI:u00A0  277,0,0,0,500   690 uni00A0 --  
U-AR:u00A0  277,0   0   690 uni00A0 --  
U-BMB:u00A0 340,0   0   690 uni00A0 --  
U-BMBI:u00A0340,0,0,0,500   690 uni00A0 --  
U-BMI:u00A0 300,0   0   690 uni00A0 --  
U-BMR:u00A0 320,0,0,0,500   690 uni00A0 --  
U-CB:u00A0  600,0   0   690 uni00A0 --  
U-CBI:u00A0 600,0,0,0,-336  0   690 uni00A0 --  
U-CI:u00A0  600,0,0,0,-269  0   690 uni00A0 --  
U-CR:u00A0  600,0   0   690 uni00A0 --  
U-HB:u00A0  278,0   0   690 uni00A0 --  
U-HBI:u00A0 278,0,0,17,-195,17  0   690 uni00A0 --  
U-HI:u00A0  278,0,0,0,-163  0   690 uni00A0 --  
U-HNB:u00A0 228,0   0   690 uni00A0 --  
U-HNBI:u00A0228,0,0,0,960   690 uni00A0 --  
U-HNI:u00A0 228,0,0,0,960   690 uni00A0 --  
U-HNR:u00A0 228,0   0   690 uni00A0 --  
U-HR:u00A0  278,0   0   690 uni00A0 --  
U-NB:u00A0  287,0   0   690 uni00A0 --  
U-NBI:u00A0 287,0,0,0,500   690 uni00A0 --  
U-NI:u00A0  278,0,0,0,500   690 uni00A0 --  
U-NR:u00A0  278,0   0   690 uni00A0 --  
U-PB:u00A0  250,0   0   690 uni00A0 --  
U-PBI:u00A0 250,0,0,0,-75   0   690 uni00A0 --  
U-PI:u00A0  250,0,0,0,-75   0   690 uni00A0 --  
U-PR:u00A0  250,0   0   690 uni00A0 --  
U-TB:u00A0  250,0   0   690 uni00A0 --  
U-TBI:u00A0 250,0,0,0,-75   0   690 uni00A0 --  
U-TI:u00A0  250,0,0,0,-75   0   690 uni00A0 --  
U-TR:u00A0  250,0   0   690 uni00A0 --  
U-ZCMI:u00A0220,0,0,0,500   690 uni00A0 --  




___

Reply to this item at:

  

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

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

Follow-up Comment #17, bug #65474 (group groff):

  My posting (comment #14) was an answer to comment #11 (Paul Eggert).

  The example, with a possible explanation

.pl 3
.de MY
.ie '\\$1'a' CASE a
.el .ie '\\$1'b' CASE b
.el  CASE z
..
.ie '1'1' \{\
. ie '1'2' .el .MY a\" groff processes this according to the output
.\". el .MY a
.\}
.el NOTREACHED

The ".ie '1'2' .el .MY a" is probably processed as

".ie '1'2' & .el .MY a"

  Tested with that line.

  So the probable execution is

.ie '1'1 \{\ 
\" true
.ie '1'2' .el .MY a\" false
.\}
.el NOTREACHED

.NB.  The whole text can be used as a input to nroff.



___

Reply to this item at:

  

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

[bug #65474] [troff] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

Follow-up Comment #14, bug #65474 (group groff):

  The example shows a bug in groff or an interpretation as in some
other language.

  That interpretation is not mentioned in
"https://troff.org/54.pdf; (Troff User's Manual, Nov 1992;
chapter 16).

  The 'ie' request has nothing to process on the same (logical) line,
so it grabs the next line.

Test, by adding some text on the same (logical) line as the 'ie'
request.

N.B.

  Similar "skipping the new line character" is also shown with
'\{' at the end of a line, instead of '\{\' (block begins on the
next line).



___

Reply to this item at:

  

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

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

Follow-up Comment #7, bug #65474 (group groff):

  I sent my contribution to the groff list for more people to
read, with title

"An exercise for the brain(-software) (bug #65474)".



___

Reply to this item at:

  

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

An exercise for the brain(-software) (bug #65474)

[Bjarni Ingi Gislason]

  Give more people a chance to see, think and learn.

  The following is from the groff bug report #65474

spurious "warning: unbalanced 'el' request" when formatting zic(8)
from TZBD project

  What I forgot to write in the contribution was:

Another language has polluted the code, as written.
  
-.-.
>From comment # 3:

  This is neither a spurious nor a "false positive" but a
legitimate remark about the code.

  I don't see a balance (like a two arm weight balance) with 
separate left and right loads.

  The warning is falsely interpreted (translated) by humans.

  The translator is not happy about how the instructions are
written, they are not informative enough for an unambiguous
processing.

  The writer's duty is to supply the translator with all
necessary information to make its work efficient, correct and
without any doubt.

  When humans look at the code, they add (get, have) information
that the translator does not have.

.ie \n(.g groff
.el .ie t troff
.el neither groff nor troff

  So simply adding the needed information for a unique
interpretation is

.ie \n(.g groff
.el \{ .ie t troff
.el neither groff nor troff \}

  which is not visible enough and not an enough structured style,
changing to 

.ie \n(.g groff
.el \{\
.  ie t troff
.  el neither groff nor troff
.\}

makes the "balance" visible at first glance.

  In this case one can look at "groff" as being a (minimal) "code
and style checker".

  The false interpretation (translation) of warnings by humans is
thus more common than one might suspect.

  Changing the code in "groff" to eliminate such a warning is
simply censorship and sabotage.

N.B.

  The showed warning "el" (code = 16) should be elevated to
a default status.

-.-.

N.B.

  Another exercise is bug #42675 (2014-07-03)

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

Follow-up Comment #6, bug #65474 (group groff):

  What I forgot to write:

Another language has polluted the code, as written.



___

Reply to this item at:

  

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

[bug #65474] spurious "warning: unbalanced 'el' request" when formatting zic(8) from TZDB project

[Bjarni Ingi Gislason]

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

  This is neither a spurious nor a "false positive" but a
legitimate remark about the code.

  I don't see a balance (like a two arm weight balance) with 
separate left and right loads.

  The warning is falsely interpreted (translated) by humans.

  The translator is not happy about how the instructions are
written, they are not informative enough for an unambiguous
processing.

  The writer's duty is to supply the translator with all
necessary information to make its work efficient, correct and
without any doubt.

  When humans look at the code, they add (get, have) information
that the translator does not have.

.ie \n(.g groff
.el .ie t troff
.el neither groff nor troff

  So simply adding the needed information for a unique
interpretation is

.ie \n(.g groff
.el \{ .ie t troff
.el neither groff nor troff \}

  which is not visible enough and not an enough structured style,
changing to 

.ie \n(.g groff
.el \{\
.  ie t troff
.  el neither groff nor troff
.\}

makes the "balance" visible at first glance.

  In this case one can look at "groff" as being a (minimal) "code
and style checker".

  The false interpretation (translation) of warnings by humans is
thus more common than one might suspect.

  Changing the code in "groff" to eliminate such a warning is
simply censorship and sabotage.

N.B.

  The showed warning "el" (code = 16) should be elevated to
a default status.



___

Reply to this item at:

  

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

[bug #63354] Refine fallbacks.tmac

[Bjarni Ingi Gislason]

Follow-up Comment #34, bug #63354 (group groff):

  The register "lfiguredash" can be incorporated into the
definition string.

  There is no extra output with a correct definition of the
character "figuredash".

  An example is in the attachment.


(file #55788)

___

Additional Item Attachment:

File name: prof.figure.dash   Size:0 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-04b18e1179b14c0ef710c8e9c8e59d1e4bcd7bd0.tar.gz


___

Reply to this item at:

  

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

Re: Font Palatino

[Bjarni Ingi Gislason]

  The manual pages for gropdf and grops should gave you enough
information.

  Looking at "fonts_x.ps" and "fonts_n.ps" shows you how the
glyphs look like

in the groff package hdtbl,
residing in the build directory ".../contrib/hdtbl/examples" in
the git repository and

in Debian
"/usr/share/doc/groff-base/examples/hdtbl".

  The Palatino fonts are on pages [26,29].

Re: mailing list archive link in manual appears to have rotted

[Bjarni Ingi Gislason]

On Wed, Feb 28, 2024 at 02:56:19PM +, ropers wrote:
> Hello GNU,
> 
> In your GROFF manual, the following place contains a mailing list archive 
> link:
> https://www.gnu.org/software/groff/manual/groff.html#FOOT2
> 
> That link is https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html
> and it appears to have rotted.
> 
>[...]

  Change 'minnie' to 'www'.

Re: mom example documents PDF conversions in Fedora 39 distribution

[Bjarni Ingi Gislason]

On Tue, Jan 23, 2024 at 11:32:30AM +0100, Oliver Corff wrote:
> Hi,
> 
> I just happened to notice that the PDF targets of the example documents
> of mom in my /usr/share/doc/groff/examples/mom/ directory (Fedora 39)
> seem to have been compiled without the -k option even though README.txt
> has the example command lines as well as an explicit mention of the -k
> option.
> 

  The example is out of date.  "mom" uses now the '-K utf8'
(generally '-K ') option.

  See for a history the bug tracker
https://savannah.gnu.org/bugs/?group=groff
and use the 'Search' window on the left side for bug numbers
64877, 65198, 65199, and 62975.

  See also "Baffling accented glyphs issue" in
https://lists.gnu.org/archive/html/groff/2013-08/msg00135.html
(26 Aug 2023) and later.

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

  The maintainer is Peter Schaffter at
http://www.schaffter.ca/mom.
Follow the instructions.

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

[Bjarni Ingi Gislason]

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

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

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

  The user should have control, not a committer.

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

  See also

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

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

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

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

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

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

[Bjarni Ingi Gislason]

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


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

  How does the command change the ascii text?



___

Reply to this item at:

  

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

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

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65199>

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


___

Follow-up Comments:


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

  The option '-k' is superfluous,

1) the input file must be readable

2) thus the encoding can be found

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

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

Actions:

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

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

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







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65199>

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

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

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65198>

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


___

Follow-up Comments:


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

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

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








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65198>

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

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

[Bjarni Ingi Gislason]

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

  The examples "lsp-help.1" and "lsp-help.broken.1" render OK
with the patch in bug #63960, which I installed in my repository
at that time.



___

Reply to this item at:

  

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

[bug #65180] [xditview, groff] warnings from -Wanalyzer-null-dereference -fanalyzer

[Bjarni Ingi Gislason]

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

   The whole file is 23401 bytes.  The following is the part about
"groff/pipeline.c" and is in the attachment.


(file #55587)

___

Additional Item Attachment:

File name: groff.analyzer.pipeline.bugSize:10 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-edeaddc2ab68531921c20d76d8ba9389dff945c4.tar.gz


___

Reply to this item at:

  

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

[bug #65180] make output with CFLAGS += -Wanalyzer-null-dereference -fanalyzer

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65180>

 Summary: make output with CFLAGS +=
-Wanalyzer-null-dereference  -fanalyzer
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 18 Jan 2024 09:40:01 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 18 Jan 2024 09:40:01 PM UTC By: Bjarni Ingi Gislason 
Subject: make output with CFLAGS += -Wanalyzer-null-dereference
 -fanalyzer

  The file is in the attachment.






___
File Attachments:


---
Name: groff.analyzer.bug  Size: 23KiB
<http://savannah.gnu.org/bugs/download.php?file_id=55586>

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-edeaddc2ab68531921c20d76d8ba9389dff945c4.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65180>

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

[bug #65097] gropdf: one 'ps:' tag is now not processed

[Bjarni Ingi Gislason]

Follow-up Comment #5, bug#65097 (group groff):

  I have added this to my version of "gropdf":

elsif ($par=~m/exec decornone/)
{
#   skip processing
}
elsif ($par=~m/exec 0 setlinejoin/)
{
#   skip processing, already processed earlier
}
elsif ($par=~m/def grops begin/)
{
#   skip processing
}



___

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

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65117>

 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:

  <https://savannah.gnu.org/bugs/?65117>

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

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

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65115>

 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:

  <https://savannah.gnu.org/bugs/?65115>

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

[bug #65097] gropdf: one 'ps:' tag is now not processed

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65097>

 Summary: gropdf: one 'ps:' tag is now not processed
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sat 30 Dec 2023 07:20:51 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: Sat 30 Dec 2023 07:20:51 PM UTC By: Bjarni Ingi Gislason 
Subject: gropdf: one 'ps:' tag is now not processed

Examples of an unprocessed ps-tag (shown by an additional "else"
clause in "gropdf.pl at the end of "ifelse" clauses.

  GROFFdoc/automake.pdf
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 15.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 91.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 185.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 1032.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 2209.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 3356.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 4420.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 5237.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 6690.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 7847.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 8831.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 9517.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 9940.
\X'ps: exec 0 setlinejoin' was not processed at
/home/bg/git/groff/build/gropdf line 1121, <> line 9953.

  This does not fit in with the recently changed test

-   elsif ($par=~m/exec (\d) setlinejoin/)
+   elsif ($par=~m/exec.*? (\d) setlinejoin/)
 








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65097>

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

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

[Bjarni Ingi Gislason]

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

  Thanks.
  I had not changed the "fontpath" from
"top_srcdir/font" to "top_builddir/font when I copied ".roff.ps"
to ".roff.pdf" in "hdtbl.am".

  The "fonts_{n,x}.pdf" have 71 pages versus 38 for the PS files.

  This ticket is now resolved.


___

Reply to this item at:

  

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

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65095>

 Summary: gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sat 30 Dec 2023 08:53:42 AM 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: Sat 30 Dec 2023 08:53:42 AM UTC By: Bjarni Ingi Gislason 
Subject: gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

  After patching "gropdf" the files "fonts_n.pdf" and
"fonts_x.pdf" show now empty output with "xpdf".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65095>

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

[bug #65094] gropdf: hdtbl, picture "gnu.eps" is now missing in "mixed_pickles.pdf"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65094>

 Summary: gropdf: hdtbl, picture "gnu.eps" is now missing in
"mixed_pickles.pdf"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sat 30 Dec 2023 08:36:07 AM 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: Sat 30 Dec 2023 08:36:07 AM UTC By: Bjarni Ingi Gislason 
Subject: gropdf: hdtbl, picture "gnu.eps" is now missing in
"mixed_pickles.pdf"

  cd contrib/hdtbl

  DOC_GNU_EPS=../../build/doc

  test-groff -Tpdf -mhdtbl -I $DOC_GNU_EPS examples/mixed_pickles.roff > 

  OR run "make" after updating the "gropdf".

  "test-groff" with the patched gropdf.

  Instead of the picture "gnu.eps" there is text "gnu.eps".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65094>

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

[bug #65092] Some text, testing

[Bjarni Ingi Gislason]

  bug-groff ticket #65092
  This has not happened before, therefore I repeat by sending
this through the web interface
"https://savannah.gnu.org/bugs/?group=groff;.

  If I send this with e-mail to bug-groff@gnu.org, there was
(is?) also some misdirection, that I do not remember what was.

The subject is: [bug #65092] Some text, testing

[bug #65081] [ms] doc/ms.ms: line length can't be changed for "groff" output

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65081>

 Summary: [ms]  doc/ms.ms: line length can't be changed for
"groff" output
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 26 Dec 2023 07:31:30 PM UTC
Category: Macro ms
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: Tue 26 Dec 2023 07:31:30 PM UTC By: Bjarni Ingi Gislason 
Subject: doc/ms.ms: line length can't be changed for "groff"
output

groff -ms -t -p -rLL=87n -dFAM=H -ww -b -z doc/ms.ms

  shows

doc/ms.ms:543: warning: table wider than line length minus indentation

  My version of "test-groff" and "tmac/s.tmac" shows

doc/ms.ms:543: warning: table wider than line length minus indentation
  .l = 79n (435000u) .i = 0u TW (table width)= 86n (475544u)

  Putting ".nr LL 87n" after ".if n \{...\}" in "ms.ms" changes
nothing.









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65081>

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

[bug #65073] [core] warnings and errors reported by "cppcheck"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?65073>

 Summary: [core] warnings and errors reported by "cppcheck"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Fri 22 Dec 2023 06:43:47 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 22 Dec 2023 06:43:47 PM UTC By: Bjarni Ingi Gislason 
Subject: warnings and errors reported by "cppcheck"

Cppcheck 2.12.0

cd src
cppcheck *


preproc/grn/hgraph.cpp:835:15: warning: Uninitialized variable: deltaz
[uninitvar]
  deltaz[0] = deltaz[npoints - 1];
  ^
preproc/grn/hgraph.cpp:831:17: note: Assuming condition is false
  for (i = 1; i < npoints; ++i) {
^
preproc/grn/hgraph.cpp:835:15: note: Uninitialized variable: deltaz
  deltaz[0] = deltaz[npoints - 1];
  ^
preproc/grn/hgraph.cpp:905:15: warning: Uninitialized variable: deltaz
[uninitvar]
  deltaz[0] = deltaz[npoints - 1];
  ^
preproc/grn/hgraph.cpp:902:17: note: Assuming condition is false
  for (i = 1; i < npoints; ++i) {
^
preproc/grn/hgraph.cpp:905:15: note: Uninitialized variable: deltaz
  deltaz[0] = deltaz[npoints - 1];
  ^
preproc/pic/lex.cpp:25:1: error: There is an unknown macro here somewhere.
Configuration is required. If declare_ptable is a macro then please configure
it. [unknownMacro]
declare_ptable(char)
^
preproc/pic/object.cpp:952:3: error: There is an unknown macro here somewhere.
Configuration is required. If PTABLE_ITERATOR is a macro then please configure
it. [unknownMacro]
  PTABLE_ITERATOR(place) iter(tbl) ;
  ^
roff/troff/env.cpp:1322:5: error: Memory leak: sizes [memleak]
return;
^
roff/troff/input.cpp:2654:10: error: Uninitialized variable: buf [uninitvar]
if ((buf[0] = tok.ch()) != 0) {
 ^
roff/troff/input.cpp:2702:10: warning: Uninitialized variable: buf
[uninitvar]
if ((buf[i] = tok.ch()) == 0 || buf[i] == end)
 ^
roff/troff/input.cpp:2683:15: note: Assignment 'buf=abuf', assigned value is

  char *buf = abuf;
  ^
roff/troff/input.cpp:2702:10: note: Uninitialized variable: buf
if ((buf[i] = tok.ch()) == 0 || buf[i] == end)
 ^
roff/troff/input.cpp:5366:10: warning: Uninitialized variable: buf
[uninitvar]
if ((buf[i] = tok.ch()) == 0) {
 ^
roff/troff/input.cpp:5344:15: note: Assignment 'buf=abuf', assigned value is

  char *buf = abuf;
  ^
roff/troff/input.cpp:5364:2: note: Assuming condition is false
 && (compatible_flag || input_stack::get_level() == start_level))
 ^
roff/troff/input.cpp:5366:10: note: Uninitialized variable: buf
if ((buf[i] = tok.ch()) == 0) {
 ^
utils/tfmtodit/tfmtodit.cpp:429:5: error: Resource leak: fp [resourceLeak]
return 0;
^
utils/xtotroff/xtotroff.c:109:50: error: Uninitialized variable: name1
[legacyUninitvar]
if (!CanonicalizeFontName(names[i], 0 == i ? name1 : name2)) {
 ^
utils/xtotroff/xtotroff.c:109:58: error: Uninitialized variable: name2
[legacyUninitvar]
if (!CanonicalizeFontName(names[i], 0 == i ? name1 : name2)) {
 ^
devices/grohtml/post-html.cpp:316:1: error: The one definition rule is
violated, different classes/structs have the same name 'style'
[ctuOneDefinitionRuleViolation]
struct style {
^
devices/grops/ps.cpp:492:1: note: The one definition rule is violated,
different classes/structs have the same name 'style'
struct style {
^
devices/grohtml/post-html.cpp:316:1: note: The one definition rule is
violated, different classes/structs have the same name 'style'
struct style {
^
devices/grohtml/post-html.cpp:354:1: error: The one definition rule is
violated, different classes/structs have the same name 'char_block'
[ctuOneDefinitionRuleViolation]
struct char_block {
^
preproc/html/pre-html.cpp:432:1: note: The one definition rule is violated,
different classes/structs have the same name 'char_block'
struct char_block {
^
devices/grohtml/post-html.cpp:354:1: note: The one definition rule is
violated, different classes/structs have the same name 'char_block'
struct char_block {
^
preproc/eqn/lex.cpp:362:1: error: The one definition rule is violated,
different classes/structs have the same name 'top_input'
[ctuOneDefinitionRuleViolation]
class top_input : public macro_input {
^
preproc/pic/main.cpp:45:1: note: The one definition rule is violated,
different classes/structs have the same name 'top_input'
class top_input : public input {
^
preproc/eqn/lex.cpp:362:1: note: The on

Re: Groff hdtbl tables disappear near the footer

[Bjarni Ingi Gislason]

  There are bugs in "page-a.ms".  The last one is for a trailing
space.

  Found by using the options "-ww -b -z" (except the trailing
space) and patched HDTBL macros.

--- page-a.ms   2023-12-16 17:42:06.0 +
+++ page-a.new.ms   2023-12-16 18:06:58.0 +
@@ -3,7 +3,7 @@
 ..
 \Z'\
 \h'-1i'\v'10.52i'\
-\X'ps: import floral-border.eps 0 0 595 842 594000'
+\X'ps: import floral-border.eps 0 0 595 842 594000''
 .so macros.ms
 \#.fam source
 .sp -.5c
@@ -21,10 +21,10 @@
 \Z'\v'0.5m'\D'P 0 -1.7m \n[bwd]u 0 0 1.7m -\n[bwd]u 0'\v'-0.5m''\
 \X'ps: exec 1 setgray'\0with Open Source Software\0
 \Z'\
-
+'
 \#.PSPIC -C page-symbol.eps 2i
 .LP
-\*[DGREY]\f[B]Duis ac purus elementum, posuere metus nec, porttitor mauris 
aliquam scelerisque lacus ultrice.\f[R] Sollicitudin libero a, iaculis augue. 
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam condimentum 
luctus urna vel sodales. Etiam leo justo, lacinia id vehicula eu, facilisis sit 
amet nunc. 
+\*[DGREY]\f[B]Duis ac purus elementum, posuere metus nec, porttitor mauris 
aliquam scelerisque lacus ultrice.\f[R] Sollicitudin libero a, iaculis augue. 
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam condimentum 
luctus urna vel sodales. Etiam leo justo, lacinia id vehicula eu, facilisis sit 
amet nunc.
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam condimentum 
luctus urna vel sodales. Etiam leo justo, lacinia id vehicula eu, facilisis sit 
amet nunc. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam 
condimentum luctus urna vel sodales.
 .br
 .po .93i

Re: gropdf : missing colour when used with HDTBL macros

[Bjarni Ingi Gislason]

On Thu, Dec 14, 2023 at 11:02:50PM +, Deri wrote:
> On Thursday, 14 December 2023 22:35:26 GMT Bjarni Ingi Gislason wrote:
> >   File examples in
> > 
> > https://list.gnu.org/archive/html/groff/2023-12/msg00013.html
> > 
> > with subject "Groff hdtbl tables disappear near the footer".
> > 
> >   /usr/bin/groff -Tpdf -ms -mhdtbl hdtbl-issue.ms > hdtbl-issue.pdf
> > 
> >   Output does not have a "coloured" header "Professional
> > Experience" (but black on white background) as the PostScript
> > output file.
> > 
> > -.-.
> > 
> > /usr/bin/groff -Tpdf --version:
> > 
> > GNU groff version 1.23.0
> > Copyright (C) 2022 Free Software Foundation, Inc.
> > [...]
> > called subprograms:
> > 
> > GNU troff (groff) version 1.23.0
> > GNU gropdf (groff) version 1.23.0
> 
> Hi Bjarni,
> 
> If you look in hdtbl-issue-macros.ms you will see:-
> 
> .ds ACCENT "\X'ps: exec .1 .3 .6 setrgbcolor'
> .ds GREY "\X'ps: exec .7 .7 .7 setrgbcolor'
> .ds DGREY "\X'ps: exec .3 .3 .3 setrgbcolor'
> .ds RED "\X'ps: exec 1 0 0 setrgbcolor'
> .ds BLUE "\X'ps: exec 0 0 1 setrgbcolor'
> .ds BLACK "\X'ps: exec 0 0 0 setrgbcolor'
> .ds WHITE "\X'ps: exec 1 1 1 setrgbcolor'
> .defcolor textcolor rgb #353535
> .defcolor linecolor rgb #a1a1a1
> 
> The first 7 lines are defined as postscript commands which are not parsed by 
> gropdf. Its man page documents the particular \X'ps: ..." which are 
> understood.
> 
> The last two colours use normal groff colour definitions. I'm not too sure 
> why 
> most of the colours are done as postscript commands, but this sort of 
> postscript used to be the only way to get colours from groff, before Werner 
> added the colour commands, so it may be old code.
> 
> Cheers 
> 
> Deri
> 
> 
> 
  Thanks for this enlightenment.

  Thus, the "gropdf" should warn if it can't complete the
conversion, for example by adding a case where the tag 'ps:' does
not match any processed case.

  The same for any tag, that is not processed.

  And the manual should not state that 
" All other ps: tags are silently ignored."

gropdf : missing colour when used with HDTBL macros

[Bjarni Ingi Gislason]

  File examples in

https://list.gnu.org/archive/html/groff/2023-12/msg00013.html

with subject "Groff hdtbl tables disappear near the footer".

  /usr/bin/groff -Tpdf -ms -mhdtbl hdtbl-issue.ms > hdtbl-issue.pdf

  Output does not have a "coloured" header "Professional
Experience" (but black on white background) as the PostScript
output file.

-.-.

/usr/bin/groff -Tpdf --version:

GNU groff version 1.23.0
Copyright (C) 2022 Free Software Foundation, Inc.
[...]
called subprograms:

GNU troff (groff) version 1.23.0
GNU gropdf (groff) version 1.23.0

Re: Groff hdtbl tables disappear near the footer

[Bjarni Ingi Gislason]

On Wed, Dec 13, 2023 at 02:59:15AM +0100, Tadziu Hoffmann wrote:
> 
> 
> > Here is another example where, when the table doesn't fit on the page,
> > it vanishes and is not carried over to the following page.
> 
> As far as I can tell, hdtbl does not start a new page by itself
> when a table does not fit, but invoking t*hm will output any
> held tables.  The way you have set this up to be called from
> pg@top will print the table, but you have to explicitly request
> a new page with .bp at the end, or provide more running text
> (not inside TBL/ETB) so that ms will eventually start a new page.
> 
  The reason are bugs in the hdtbl macros as shown in the bug
ticket #64772 (comment #9, 2013-11-07), named "[hdtbl] consider
deprecating", in the attached file "hdtbl.tmac.diff"
(https://savannah.gnu.org/bugs/?group=groff).

  Also look a bug ticket #64967 grops.1.man..."HDTBL"

> However, I think that in this particular case the problem is
> not having the page length correctly set.  Can you try using
> .pl 29.7c somewhere near the top?
> 
> 

  The page format does not fix the bugs in the hdtbl macros.

  Simpler is to change the page size on the command line by adding

-dpaper=a4 -P-pa4

  define "paper" for the formatter, add option "-pa4" for the
output device.

  The default paper size should be defined in "tmac/troffrc"
before "papersize.tmac" is sourced, for example with

.  do if !d paper .do ds paper A4\" use $(PAGE) to configure

Re: Groff hdtbl tables disappear near the footer

[Bjarni Ingi Gislason]

  I get a somewhat different result as the paragraph "Company
Four" is entirely on the first page.  That is without any change
to the provided files.

  There are also these warning, but the do not seem to interfere
with the output.

  The pdf-file with "Page size = letter" is in the attachment.

groff -b -ww -z ...

troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':19
troff:hdtbl-issue.ms:19: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':19
troff:hdtbl-issue.ms:19: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':19
troff:hdtbl-issue.ms:19: warning: numeric expression missing
troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':28
troff:hdtbl-issue.ms:28: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':28
troff:hdtbl-issue.ms:28: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':28
troff:hdtbl-issue.ms:28: warning: numeric expression missing
troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':37
troff:hdtbl-issue.ms:37: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':37
troff:hdtbl-issue.ms:37: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':37
troff:hdtbl-issue.ms:37: warning: numeric expression missing
troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':46
troff:hdtbl-issue.ms:46: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':46
troff:hdtbl-issue.ms:46: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':46
troff:hdtbl-issue.ms:46: warning: numeric expression missing
troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':55
troff:hdtbl-issue.ms:55: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':55
troff:hdtbl-issue.ms:55: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':55
troff:hdtbl-issue.ms:55: warning: numeric expression missing
troff: backtrace: 'hdtbl-issue-macros.ms':113: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':64
troff:hdtbl-issue.ms:64: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':115: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':64
troff:hdtbl-issue.ms:64: warning: missing closing delimiter in output 
comparison operator (got a newline)
troff: backtrace: 'hdtbl-issue-macros.ms':117: macro 'WORKBL'
troff: backtrace: file 'hdtbl-issue.ms':64
troff:hdtbl-issue.ms:64: warning: numeric expression missing


hdtbl-issue.latest.pdf
Description: Adobe PDF document

[bug #64954] groff.texi: spelling errors found by "codespell"

[Bjarni Ingi Gislason]

Follow-up Comment #4, bug #64954 (project groff):

  This was (and is) not my suggestion, but that of "codespell".
  My thought was to let it stand as I saw it to be wrong in the context.

  Brandon should have begun (from the start) to check his spelling with a
spell checker.


___

Reply to this item at:

  

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

[bug #64967] [PATCH] grops.1.man: add information about the glyph tables from "HDTBL"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64967>

 Summary: [PATCH] grops.1.man: add information about the glyph
tables from  "HDTBL"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 03 Dec 2023 12:04:27 AM UTC
Category: Driver grops
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 03 Dec 2023 12:04:27 AM UTC By: Bjarni Ingi Gislason 
>From 102c262ba494fda59b4b0b45fd8be0875fbf4af1 Mon Sep 17 00:00:00 2001
From: Bjarni Ingi Gislason 
Date: Sat, 2 Dec 2023 23:15:54 +
Subject: [PATCH] grops.1.man: add information about the glyph tables from
 "HDTBL"

Directory "src/devices/grops/".

  All PostScript glyphs are shown in tables from the hdtbl
directory "examples".
---
 src/devices/grops/grops.1.man | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/devices/grops/grops.1.man b/src/devices/grops/grops.1.man
index 634f1616f..711b0873a 100644
--- a/src/devices/grops/grops.1.man
+++ b/src/devices/grops/grops.1.man
@@ -626,6 +626,13 @@ some older printers.
 .SS Typefaces
 .\" 
 .

+All provided PostScript glyphs are shown in the tables
+.I fonts_n.ps
+and
+.I fonts_x.ps
+in the directory
+.IR @EXAMPLEDIR@/\:hdtbl/ .
+.P
 Styles called
 .BR R ,
 .BR I ,
@@ -1790,6 +1797,16 @@ can produce glyphs like eth (\[Sd]) and thorn (\[Tp])
that older
 PostScript printers do not natively support.
 .
 .
+.TP
+.I @EXAMPLEDIR@/\:hdtbl/fonts_n.ps
+shows the glyphs sorted by their decimal number in a table.
+.
+.
+.TP
+.I @EXAMPLEDIR@/\:hdtbl/fonts_x.ps
+shows the glyphs sorted by their hexadecimal number in a table.
+.
+.
 .P
 .I grops
 creates temporary files using the template
-- 
2.42.0

Patch also in the attachment






___
File Attachments:


---
Date: Sun 03 Dec 2023 12:04:27 AM UTC  Name:
0001-grops.1.man-add-information-about-the-glyph-tables-f.patch.txt  Size:
1KiB   By: bjarniig

<http://savannah.gnu.org/bugs/download.php?file_id=55394>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64967>

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

[bug #64954] groff.texi: spelling errors found by "codespell"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64954>

 Summary: groff.texi: spelling errors found by "codespell"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 30 Nov 2023 11:02:27 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 30 Nov 2023 11:02:27 PM UTC By: Bjarni Ingi Gislason 
Subject: groff.texi: spelling errors found by "codespell"

groff.texi:7399: disard ==> discard
groff.texi:7448: disard ==> discard
groff.texi:10450: slecting ==> selecting, electing
groff.texi:11682: charcters ==> characters
groff.texi:14258: coresponding ==> corresponding
groff.texi:14446: othe ==> other
groff.texi:18543: incorprate ==> incorporate








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64954>

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

[bug #64906] libgroff.am: "charset.alias" is created (almost empty) with wrong value of "$HOST"

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64906 (project groff):

>From baf66e7e75a5332f311f043fab849fe7e668779d Mon Sep 17 00:00:00 2001
From: Bjarni Ingi Gislason 
Date: Fri, 24 Nov 2023 22:03:00 +
Subject: [PATCH] libgroff.am: "charset.alias" needs the variable
 'host' (defined) instead of 'HOST'

Directory "src/libs/libgroff".

  Variable 'host' is defined by "automake" in "Makefile.in".

Signed-off-by: Bjarni Ingi Gislason 
---
 src/libs/libgroff/libgroff.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libs/libgroff/libgroff.am b/src/libs/libgroff/libgroff.am
index 8dbccecd4..1a50a6991 100644
--- a/src/libs/libgroff/libgroff.am
+++ b/src/libs/libgroff/libgroff.am
@@ -125,7 +125,7 @@ all: charset.alias ref-add.sed ref-del.sed
 
 charset.alias: $(libgroff_srcdir)/config.charset
$(AM_V_GEN)$(SHELL) $(libgroff_srcdir)/config.charset \
-   '$(HOST)' > t-$@ \
+   '$(host)' > t-$@ \
  && mv t-$@ $@
 
 ref-add.sed: $(libgroff_srcdir)/ref-add.sin
-- 
2.42.0

  The patch is (also) in the attachment.


(file #55353)

___

Additional Item Attachment:

File name: 0001-libgroff.am-charset.alias-needs-the-variable.patch.txt Size:0
KB
   
<https://file.savannah.gnu.org/file/0001-libgroff.am-charset.alias-needs-the-variable.patch.txt?file_id=55353>



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64906>

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

[bug #64913] Makefile.am: variable "HOST" is not created by "automake"

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64913 (project groff):

>From 960c22e6f75db890ce3ed5a00037c1f9712dff36 Mon Sep 17 00:00:00 2001
From: Bjarni Ingi Gislason 
Date: Thu, 23 Nov 2023 21:53:08 +
Subject: [PATCH]   The automake program defines a variable named 'host' with
 the canonical host specification and not a variable named 'HOST'.

Signed-off-by: Bjarni Ingi Gislason 
---
 Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e15a8ff0f..b61de154e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,8 +35,8 @@
 
 # top_builddir
 
-# HOST
-# `HOST' is the canonical host specification,
+# host
+# `host' is the canonical host specification,
 #CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
 # or
 #CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
-- 
2.42.0

The patch is also in the attachment

(file #55352)

___

Additional Item Attachment:

File name: 0001-The-automake-program-defines-a-variable-named-host-w.txt
Size:0 KB
   
<https://file.savannah.gnu.org/file/0001-The-automake-program-defines-a-variable-named-host-w.txt?file_id=55352>



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64913>

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

[bug #64906] libgroff.am: "charset.alias" is created (almost empty) with wrong value of "$HOST"

[Bjarni Ingi Gislason]

Follow-up Comment #1, bug #64906 (project groff):

  Using "host" instead of "HOST" (host is earlier defined as
"x86_64-pc-linux-gnu") in

charset.alias: $(libgroff_srcdir)/config.charset
$(AM_V_GEN)$(SHELL) $(libgroff_srcdir)/config.charset \
'$(HOST)' > t-$@ \
  && mv t-$@ $@

produces

# This file contains a table of character encoding aliases,
# suitable for operating system 'linux-gnu'.
# It was automatically generated from config.charset.
# Packages using this file:
ISO_646.IRV:1983 ASCII


  This is still using "config.charset" which should be substituted by
the GNU GNULIB module "localcharset" (?).

  Or this is superfluous.

  The only use of "charset.alias" is in "(un)install_charset_data" which
installs it and "t-charset.alias".

  Neither of these file is in Debian testing
"/var/lib/dpkg/info/{groff,groff-base}.*"



___

Reply to this item at:

  

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

[bug #64913] Makefile.am: variable "HOST" is not created by "automake"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64913>

 Summary: Makefile.am: variable "HOST" is not created by
"automake"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 20 Nov 2023 06:26:58 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 20 Nov 2023 06:26:58 PM UTC By: Bjarni Ingi Gislason 
Subject: Makefile.am: variable "HOST" is not created by "automake"

  But "host" ("host_triplet = @host@" and host = @host@ in
Makefile.in) is.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64913>

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

Re: building groff 1.23.0 on z/OS

[Bjarni Ingi Gislason]

  I have this in my private branch

Date:   Mon Aug 7 17:19:42 2023 +

src/devices/grodvi/dvi.cpp: add "#include " at the
beginning

Error from clang++-16

  CXX  src/devices/grodvi/dvi.o
In file included from ../src/devices/grodvi/dvi.cpp:19:
In file included from ./lib/assert.h:78:
./lib/stddef.h:107:3: error: "Please include config.h first."
 #error "Please include config.h first."
  ^
 
diff --git a/src/devices/grodvi/dvi.cpp b/src/devices/grodvi/dvi.cpp
index 2b47f5d21..350258cd6 100644
--- a/src/devices/grodvi/dvi.cpp
+++ b/src/devices/grodvi/dvi.cpp
@@ -16,6 +16,7 @@ for more details.
 You should have received a copy of the GNU General Public License
 along with this program.  If not, see .
*/

+#include 
 #include 

 #include "driver.h"

[bug #64906] libgroff.am: "charset.alias" is created (almost empty) with wrong value of "$HOST"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64906>

 Summary: libgroff.am: "charset.alias" is created (almost
empty) with wrong value of "$HOST"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 19 Nov 2023 01:15:24 AM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sun 19 Nov 2023 01:15:24 AM UTC By: Bjarni Ingi Gislason 
Subject: libgroff.am: charset.alias is created (almost empty) with
wrong value of "$HOST"

  "charset.alias" is created in

  src/libs/libgroff/libgroff.am

  with

charset.alias: $(libgroff_srcdir)/config.charset
$(AM_V_GEN)$(SHELL) $(libgroff_srcdir)/config.charset \
'$(HOST)' > t-$@ \
  && mv t-$@ $@

Content is:
---cut---
# This file contains a table of character encoding aliases,
# suitable for operating system 'kassi'.
# It was automatically generated from config.charset.
# Packages using this file:
---cut---

  "kassi" is the value of the environmental variable HOST, which is the
name of the computer.

  It is documented in the Makefile as being

# HOST
# `HOST' is the canonical host specification,
#CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or
#CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM

  and should therefore have the same content as 

build_triplet = x86_64-pc-linux-gnu
host_triplet = x86_64-pc-linux-gnu

build = x86_64-pc-linux-gnu

host = x86_64-pc-linux-gnu

  or

host_cpu = x86_64
host_os = linux-gnu
host_vendor = pc

  The file "config.charset" is from GNU GNULIB, which removed it 

2018-05-19  Bruno Haible   (in Changelog)

* lib/config.charset: Remove file.















___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64906>

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

[bug #64892] [tbl] alloc-dealloc-mismatch with "-fsanitize=address"

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64892 (project groff):

  "strcpy.3" is the same as "strcpy(3)".

  If other man pages are used, that do not use "tbl",
a memory leak is reported.



___

Reply to this item at:

  

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

[bug #64892] [tbl] alloc-dealloc-mismatch with "-fsanitize=address"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64892>

 Summary: [tbl] alloc-dealloc-mismatch with
"-fsanitize=address"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 13 Nov 2023 11:47:02 PM UTC
Category: Preprocessor tbl
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: Mon 13 Nov 2023 11:47:02 PM UTC By: Bjarni Ingi Gislason 
Subject: tbl: alloc-dealloc-mismatch with "-fsanitize=address"

  The software was compiled with gcc ((Debian 13.2.0-5) 13.2.0) with
"-fsanitize=address" giving warnings, and when running "test-groff -t
-man -ww -z strcpy.3""


=
==91730==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete []) on 0x60400010
#0 0x7f4c462d9c68 in operator delete[](void*)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:155
#1 0x55e441522d45 in block_entry::~block_entry()
(/home/bg/git/groff/build/tbl+0x23d45) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#2 0x55e441543742 in left_block_entry::~left_block_entry()
(/home/bg/git/groff/build/tbl+0x44742) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#3 0x55e441526ca1 in table::~table()
(/home/bg/git/groff/build/tbl+0x27ca1) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#4 0x55e44151e161 in process_table(table_input&)
(/home/bg/git/groff/build/tbl+0x1f161) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#5 0x55e44151e970 in process_input_file(_IO_FILE*)
(/home/bg/git/groff/build/tbl+0x1f970) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#6 0x55e44150f31d in main (/home/bg/git/groff/build/tbl+0x1031d) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#7 0x7f4c45c456c9 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#8 0x7f4c45c45784 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x55e44150fb60 in _start (/home/bg/git/groff/build/tbl+0x10b60)
(BuildId: 7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)

0x60400010 is located 0 bytes inside of 45-byte region
[0x60400010,0x6040003d)
allocated by thread T0 here:
#0 0x7f4c462d85bf in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x55e44154cfa3 in string::extract() const
(/home/bg/git/groff/build/tbl+0x4dfa3) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#2 0x55e441529ad1 in table::add_entry(int, int, string const&,
entry_format const*, char const*, int) (/home/bg/git/groff/build/tbl+0x2aad1)
(BuildId: 7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#3 0x55e44151ab34 in process_data(table_input&, format*, options*)
(/home/bg/git/groff/build/tbl+0x1bb34) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#4 0x55e44151e141 in process_table(table_input&)
(/home/bg/git/groff/build/tbl+0x1f141) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#5 0x55e44151e970 in process_input_file(_IO_FILE*)
(/home/bg/git/groff/build/tbl+0x1f970) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#6 0x55e44150f31d in main (/home/bg/git/groff/build/tbl+0x1031d) (BuildId:
7ab334cfd6181c9ca70b997de2ca11b5dc765cd7)
#7 0x7f4c45c456c9 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
../../../../src/libsanitizer/asan/asan_new_delete.cpp:155 in operator
delete[](void*)
==91730==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==91730==ABORTING
troff: warning: expected numeric expression, got end of input
troff: error: automatically ending diversion '3table' on exit
troff: error: can't continue page ejection because vertical position traps
disabled
troff: error: can't continue page ejection because vertical position traps
disabled

[...]









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64892>

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

[bug #64891] doc/groff.texi: not understanding a sentence in lines 16618-16619

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64891 (project groff):

  The explanation makes the intention of the clause clear,
but it (the clause) is still too vague for me to understand.

The word order is also uncommon.

  I find this expression better:

the last configured margin character, before the line is output, is
used.

  Simplifying "the last ..., before ..., is used" or
"the last ... is used".



___

Reply to this item at:

  

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

[bug #64891] doc/groff.texi: not understanding a sentence in lines 16618-16619

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64891>

 Summary: doc/groff.texi: not understanding a sentence in
lines 16618-16619
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 13 Nov 2023 08:22:02 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 13 Nov 2023 08:22:02 PM UTC By: Bjarni Ingi Gislason 
Subject: doc/groff.texi: not understanding a sentence in lines
16618-16619

doc/groff.texi, line nr. 16618:

The margin character is a property of the output line; the margin
character last configured when the line is output controls.  If the

The second sentence "the margin character ...", I can't get a meaning
from it.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64891>

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

[bug #64889] warnings from new texinfo, version 7.1

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64889>

 Summary: warnings from new texinfo, version 7.1
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sun 12 Nov 2023 11:15:38 PM UTC
Category: Utilities
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: Sun 12 Nov 2023 11:15:38 PM UTC By: Bjarni Ingi Gislason 
Subject: warnings from new texinfo, version 7.1

  GEN  doc/groff.info
groff.texi:2510: warning: @noindent is useless inside of a paragraph
groff.texi:2515: warning: @noindent is useless inside of a paragraph
groff.texi:2521: warning: @noindent is useless inside of a paragraph
groff.texi:4849: warning: use @comma{} instead of \, in macro arg
groff.texi:4884: warning: use @comma{} instead of \, in macro arg
groff.texi:5258: warning: unexpected argument on @iftex line: @
groff.texi:11778: warning: use @comma{} instead of \, in macro arg
  GEN  doc/groff.txt
groff.texi:2510: warning: @noindent is useless inside of a paragraph
groff.texi:2515: warning: @noindent is useless inside of a paragraph
groff.texi:2521: warning: @noindent is useless inside of a paragraph
groff.texi:4849: warning: use @comma{} instead of \, in macro arg
groff.texi:4884: warning: use @comma{} instead of \, in macro arg
groff.texi:5258: warning: unexpected argument on @iftex line: @
groff.texi:11778: warning: use @comma{} instead of \, in macro arg
  GEN  doc/groff.html
groff.texi:2510: warning: @noindent is useless inside of a paragraph
groff.texi:2515: warning: @noindent is useless inside of a paragraph
groff.texi:2521: warning: @noindent is useless inside of a paragraph
groff.texi:4849: warning: use @comma{} instead of \, in macro arg
groff.texi:4884: warning: use @comma{} instead of \, in macro arg
groff.texi:5258: warning: unexpected argument on @iftex line: @
groff.texi:11778: warning: use @comma{} instead of \, in macro arg
groff.texi:2510: warning: @noindent is useless inside of a paragraph
groff.texi:2515: warning: @noindent is useless inside of a paragraph
groff.texi:2521: warning: @noindent is useless inside of a paragraph
groff.texi:4849: warning: use @comma{} instead of \, in macro arg
groff.texi:4884: warning: use @comma{} instead of \, in macro arg
groff.texi:5258: warning: unexpected argument on @iftex line: @
groff.texi:11778: warning: use @comma{} instead of \, in macro arg
  GEN  doc/groff.dvi
groff.texi:2510: warning: @noindent is useless inside of a paragraph
groff.texi:2515: warning: @noindent is useless inside of a paragraph
groff.texi:2521: warning: @noindent is useless inside of a paragraph
groff.texi:4849: warning: use @comma{} instead of \, in macro arg
groff.texi:4884: warning: use @comma{} instead of \, in macro arg
groff.texi:5258: warning: unexpected argument on @iftex line: @
groff.texi:11778: warning: use @comma{} instead of \, in macro arg

[...ö

Writing index file groff.ky
[133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144]
[145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156]
[157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168]
[169] [170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180]
[181] [182] [183] [184] [185] [186] [187] [188] [189] [190] [191] [192]
[193] [194] [195] [196] [197] [198] [199] [200] [201] [202] [203] [204]
[205] [206] [207] [208] [209] [210] [211] [212] [213] [214] [215] [216]
[217] Warning: unbalanced square brackets in @def...
Overfull \hbox (13.73018pt too wide) in paragraph at lines 18510--18510
 [][] @texttt This paragraph is marked with a margin character.  |[] 

Overfull \hbox (13.73018pt too wide) in paragraph at lines 18512--18512
 [][] @texttt As seen above, vertical space isn't thus marked.   |[] 

Overfull \hbox (13.73018pt too wide) in paragraph at lines 18513--18513
 [][]@texttt |[] 

Overfull \hbox (13.73018pt too wide) in paragraph at lines 18514--18514
 [][] @texttt An output line that is present, but empty, is. |[] 

  The page format is A4.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64889>

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

[bug #64869] [bjarnigroff] master branch, is the version from "nroff -v" always the same as from "groff -v"?

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64869 (project groff):

  The difference is caused by using "make distclean" the most time and
then not, when no patch updates the "nroff" script.

  This report can be closed a "resolved".



___

Reply to this item at:

  

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

[bug #64877] src/roff/groff/groff.1.man: use "-K enc" instead of "-k"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64877>

 Summary: src/roff/groff/groff.1.man: use "-K enc" instead of
"-k"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 09 Nov 2023 07:18:20 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 09 Nov 2023 07:18:20 PM UTC By: Bjarni Ingi Gislason 
Subject: src/roff/groff/groff.1.man: use "-K enc" instead of "-k"

  See for example

https://lists.gnu.org/archive/html/groff/2023-08/msg00135.html
  and more with the same subject "Baffling accented glyphs issue",
  and
.../2023-11/msg00010.hmml.

  Instead of

.B \-k
Run
.MR preconv @MAN1EXT@
preprocessor.
.
Refer to its man page for its behavior if neither of

  write something like

.B \-k
Use "-K enc" instead of "-k" when the encoding (enc) is known.  
.
Refer to
.MR preconv's @MAN1EXT@
man page for its behavior if neither of
+verbatim+
  The user can know what encoding is used in the input files,
but groff (preconv) can't with just "-k".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64877>

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

[bug #64869] master branch, is the version from "nroff -v" always the same as from "groff -v"?

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64869>

 Summary: master branch, is the version from "nroff -v" always
the same as from "groff -v"?
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 06 Nov 2023 10:09:33 PM UTC
Category: General
Severity: 3 - Normal
  Item Group: Test
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 Nov 2023 10:09:33 PM UTC By: Bjarni Ingi Gislason 
Subject: master branch, is the version from "nroff -v" always the same
as from "groff -v"?

  I sometimes get the older version from "nroff -v", this time after the
commits from today (Mon Nov 6th).

  The test-suite.log shows

FAIL: src/roff/nroff/tests/verbose_option_works.sh
==

nroff: 1.23.0.rc4.9597-3fddd
groff: 1.23.0.rc4.9607-37630
FAIL src/roff/nroff/tests/verbose_option_works.sh (exit status: 1)








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64869>

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

[bug #64772] [hdtbl] consider deprecating

[Bjarni Ingi Gislason]

Follow-up Comment #9, bug #64772 (project groff):

  I will have a shot at this.  The current difference between my branch
and that of master is in the attachments.

  Most of it is an addition to the bugs #54538, #54539,
#55007, #55027, #55044, and #55732.

  What remains to do is using the examples as test files,
copying manually previous PS files to "*.prev" and comparing the
future new ones with them.

  The difference should only be with comments in the PS files, like

%%Creator:

  and

%%CreationDate:


(file #55296, file #55297)

___

Additional Item Attachment:

File name: hdtbl.examples.diffSize:16 KB


File name: hdtbl.tmac.diffSize:8 KB




___

Reply to this item at:

  

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

[bug #64844] doc/groff.texi: missing explanation of '\c\R' and '\c\k'

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64844>

 Summary: doc/groff.texi: missing explanation of '\c\R' and
'\c\k'
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Mon 30 Oct 2023 10:36:42 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 30 Oct 2023 10:36:42 PM UTC By: Bjarni Ingi Gislason 
  I do not see anything about this

* \R, after \c:  Line Continuation.   (line  40)
 
  nor

\k, after \c

in the output of "info groff" (version 1.23.0)

  See bug #51609.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64844>

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

[bug #64815] gxditview renders '\-' as '-' (a short line segment like a hyphen)

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64815>

 Summary: gxditview renders '\-' as '-' (a short line segment
like a hyphen)
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 25 Oct 2023 11:59:59 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Rendering/Cosmetics
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 25 Oct 2023 11:59:59 PM UTC By: Bjarni Ingi Gislason 
Subject: gxditview renders '\-' as '-' (a short line segment like a hyphen)

  In groff/build/src/devices/xditview/

1) groff -man -Z -TX100-12 gxditview.1 > gxditview.1.Z

2) gxditview gxditvew.1.Z

  For this device the font S must be selected for the character '\-'.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64815>

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

[bug #64798] [troff] "warning" with or without a colon in a diagnostic message?

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64798>

 Summary: [troff] "warning" with or without a colon in a
diagnostic message?
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 19 Oct 2023 10:29:09 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 19 Oct 2023 10:29:09 PM UTC By: Bjarni Ingi Gislason 
Subject: "warning" with or without a colon in a diagnostic message?

  The gcc compiler uses a colon, so does "clang" in their "message" part
of an diagnostics.

  The "GNU coding standards" (https://www.gnu.org/prep/standards/)
does not show an example for the message part.

  It is better to be able to seek only one version of "warning?" and
"error?" than two.

Examples from src/...

src/roff/troff/input.cpp:  fprintf(stderr, "warning [page %d, line %d",
src/roff/troff/input.cpp:  fprintf(stderr, "warning [page %d, %.1f%c", s








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64798>

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

[bug #64790] [troff] use default value zero for ligatures and kerning in nroff mode

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64790>

 Summary:  [troff] use default value zero for ligatures and
kerning in nroff mode
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Wed 18 Oct 2023 06:45:21 PM UTC
Category: Core
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: Wed 18 Oct 2023 06:45:21 PM UTC By: Bjarni Ingi Gislason 
Subject: [troff] use default value zero for ligatures and kerning in
nroff mode

  Currently both "global_ligature_mode" and "global_kerning_mode" (in
src/roff/troff/node.cpp) are set to the value one (1, true) for both
nroff and troff mode.

  But in nroff mode the fonts do neither have ligatures nor kerning
data,
so the software is executing code, that in effect changes nothing,
but uses energy for nothing.

  The forgoing variables should therefore be initialised to zero
(0, false) in nroff mode.

  Also add a warning when ligature or kerning is asked for when in
nroff mode.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64790>

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

[bug #64772] [hdtbl] consider deprecating

[Bjarni Ingi Gislason]

Follow-up Comment #4, bug #64772 (project groff):

  Deprecated means in my dictionary "undesirable".

  When declared deprecated, users should stop using it and use another
(newly added) feature (command) instead.
  The next step is declaring it obsolete.

  I added diagnostic options (-ww -b) to the "groff" command (bug
#54461, 2018-08-07) in "hdtbl.am" to find out where defects could be
present, and added patches to fix those.
  I am just compiling the software.

  "hdtbl" uses the groff-machinery, so I find a close neighbourhood to
be advantageous, showing what can be done with the help of "groff".

  What makes "hdtbl" different from all the other software in the
"contrib" category?

  What will then replace the "fonts_n.ps" and "fonts_x.ps" files,
which show all the characters in the fonts provided by groff?



___

Reply to this item at:

  

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

[bug #64772] [hdtbl] consider deprecating

[Bjarni Ingi Gislason]

Follow-up Comment #1, bug #64772 (project groff):

  I see no need to abandon "hdtbl".
The code produces the examples without an error, that I can see.

"groff -ww" reported some warnings, which I have provided patches for
(one has to be corrected).

  I have also adjusted some values of variables to make the result more
pleasant(?).

  If abandoning, what will be the replacement?

  This software is in the "contrib" category, those who want to use it
are more or less on their own.

  And the may provide patches and bug (defects) reports.



___

Reply to this item at:

  

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

Re: 1.23 prints some strange error

[Bjarni Ingi Gislason]

On Wed, Oct 04, 2023 at 10:20:57PM +, Bjarni Ingi Gislason wrote:
>   Latin1 iacute has the utf8 code 'í'
> and the hexadecimal code is C3AD which is "LATIN CAPITAL LETTER A WITH
> TILDE" and "SOFT HYPHEN"
> 
> "groff" turns "soft hyphen" into "HYPHEN-MINUS" (0x2D)
> 

Correction, it is turned into '\%'

Re: 1.23 prints some strange error

[Bjarni Ingi Gislason]

  Latin1 iacute has the utf8 code 'í'
and the hexadecimal code is C3AD which is "LATIN CAPITAL LETTER A WITH
TILDE" and "SOFT HYPHEN"

"groff" turns "soft hyphen" into "HYPHEN-MINUS" (0x2D)

More is in the attachment.
file list.tr

.hw a-hÃ-
.hw a-ño
.hw ár-bol
.hw cu-brÃ--a
.hw e-té-re-o
.hw ca-mión
.hw ú-te-ro
.hw pin-güi-no

Output from "preconv -e utf8  list.tr

.lf 1 list.tr
.hw a-h\[uFFFD]-
.hw a-\[u00F1]o
.hw \[u00E1]r-bol
.hw cu-br\[uFFFD]--a
.hw e-t\[u00E9]-re-o
.hw ca-mi\[u00F3]n
.hw \[u00FA]-te-ro
.hw pin-g\[u00FC]i-no

Translate "list.tr" to latin1

iconv -f utf8 -f latin1 list.tr

.hw a-h

iconv: illegal input sequence at position 7

\[uFFFD] is called "replacement character".

-.-

  Latin1 iacute has the utf8 code 'í'
and the hexadecimal code is C3AD which is "LATIN CAPITAL LETTER A WITH
TILDE" and "SOFT HYPHEN"

"groff" turns "soft hyphen" into "HYPHEN-MINUS" (0x2D)

[bug #64730] [html] pre-grohtml: fatal error: 'pre-grohtml' exited with status 2;

[Bjarni Ingi Gislason]

Follow-up Comment #3, bug #64730 (project groff):


>  The "groff" software, as a typesetting one, should not deal with
producing other formats like "html".
For that, software for converting between different formats is the
right choice.

  If people want "html" format they should do it themselves with
software like "pdftohtml" (Debian package "poppler-utils").

What other softwares for typesetting produce themselves formats like
"html"?

N.B.
  man (man-db) relies on "groff" to produce "html", but should (must)
it?

Software, that converts a format to "html", that I have on my Debian
testing computer is (man -k convert):

asciidoctor (1)  - converts AsciiDoc source files to HTML, DocBook, and
other formats
enscript (1) - convert text files to PostScript, HTML, RTF, ANSI, and
overstrikes
pamtohtmltbl (1) - convert pnm/pam visual image to an HTML table
pdftohtml (1)- program to convert PDF files into HTML, XML and PNG
images
pod2html (1) - convert .pod files to .html files
rst-buildhtml (1)- convert many reST documents to HTML
rst2html (1) - convert reST documents to XHTML
rst2html4 (1)- convert reST documents to XHTML
rst2html5 (1)- convert reST documents to HTML 5
rstpep2html (1)  - convert reST Python Enhancement Proposals to HTML
wvHtml (1)   - convert msword documents to HTML4.0
xmlmantohtml (1) - xml to html converter

-.-

  Compiling groff-1.23.0 shows these warnings, that do not show up in my
groff branch with my usual configuration and are not dependent on the C
or C++ standard that I use.

  CXX  src/preproc/html/pre-html.o
In file included from /usr/include/stdio.h:906,
 from ./lib/stdio.h:43,
 from ../src/include/getopt.h:35,
 from ../src/include/lib.h:44,
 from ../src/preproc/html/pre-html.cpp:24:
In function 'int vsnprintf(char*, size_t, const char*, __va_list_tag*)',
inlined from 'char* make_string(const char*, ...)' at
../src/preproc/html/pre-html.cpp:408:16:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:68:36: warning: null destination
pointer [-Wformat-truncation=]
   68 |   return __builtin___vsnprintf_chk (__s, __n, __USE_FORTIFY_LEVEL -
1,
  | 
~~^~~
   69 | __glibc_objsize (__s), __fmt,
__ap);
  |
~~~
  CXX  src/preproc/html/pushback.o

-.-

../src/preproc/tbl/table.cpp:1057:45: warning: extra ';' after in-class
function definition [-Wextra-semi]
 1057 |   virtual int is_single_line() { return 0; };

and more of this type (-Wextra-semi).

.-.

  GROFFcontrib/pdfmark/pdfmark.pdf
troff:/home/bg/Sottar.skrar/groff-1.23.0/build/../doc/../contrib/pdfmark/pdfmark.ms:374:
warning [p 1, 5.0i]: cannot adjust line
troff:/home/bg/Sottar.skrar/groff-1.23.0/build/../doc/../contrib/pdfmark/pdfmark.ms:374:
warning [p 1, 4.6i]: cannot adjust line

  This is caused by ".CW \n(.F ,", where the "string" ".F" does not have
any '\:' in it.  (I use PAGE=A4).



___

Reply to this item at:

  

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

[bug #64730] [html] pre-grohtml: fatal error: 'pre-grohtml' exited with status 2;

[Bjarni Ingi Gislason]

Follow-up Comment #1, bug #64730 (project groff):

  This is probably a bug in the gcc with one of the options
-fsanitize=undefined, -fsanitize=bounds, and -fsanitize=bounds-strict,
as the error is absent with default flags "-g -O2".

  This default warning remains:

warning: ISO C++ forbids converting a string constant to 'char*'
[-Wwrite-strings]

  The line number and name of the source file is missing in the error
message:

  GROFFdoc/pic.html
failed to replace fd=1 with -1
pre-grohtml: fatal error: dup2: Bad file descriptor

  and

  GROFFdoc/webpage.html
failed to replace fd=1 with -1
pre-grohtml: fatal error: dup2: Bad file descriptor



___

Reply to this item at:

  

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

[bug #64730] [html] pre-grohtml: fatal error: 'pre-grohtml' exited with status 2;

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64730>

 Summary: [html] pre-grohtml: fatal error: 'pre-grohtml'
exited with status 2;
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Sat 30 Sep 2023 10:27:31 PM UTC
Category: Preprocessor html
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 30 Sep 2023 10:27:31 PM UTC By: Bjarni Ingi Gislason 
Subject: pre-grohtml: fatal error: 'pre-grohtml' exited with status 2;

N.B.

Additional information is in the attachment.

Full message is:

pre-grohtml: fatal error: 'pre-grohtml' exited with status 2; re-run
with a different output driver to see diagnostic messages

  "groff" compiled with one of the following additional flags:
-fsanitize=undefined or -fsanitize=bounds or -fsanitize=bounds-strict.

  From the output of "make groff":

[...]
  GROFFdoc/pic.html pre-grohtml: fatal error: 'pre-grohtml' exited
with status 2; re-run with a different output driver to see diagnostic
messages
make[2]: *** [Makefile:17307: doc/pic.html] Error 1
[...]

s-tmac: stripped tmac files.

MFLAG = -M$(abs_top_builddir)/s-tmac -M$(abs_top_builddir)/tmac
-M$(abs_top_srcdir)/tmac

FFLAG = -F$(abs_top_builddir)/font -F$(abs_top_srcdir)/font

DOC_GROFF = \
  GROFF_COMMAND_PREFIX= \
  GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
  $(GROFFBIN) -M $(doc_srcdir) $(MFLAG) $(FFLAG) -ww -b

Makefile:17307:

doc/pic.html: $(doc_srcdir)/pic.ms $(TMAC_PACKAGE_MS)
$(GROFF_V)$(MKDIR_P) $(doc_builddir) \
&& cd $(doc_builddir) \
&& $(DOC_GROFF) -pet -P-Ipic -P-Dimg -P-jpic -Thtml -ms \
  $(doc_srcdir)/pic.ms > pic.html

 






___
File Attachments:


---
Date: Sat 30 Sep 2023 10:27:31 PM UTC  Name: pre-grohtml.bug  Size: 9KiB   By:
bjarniig

<http://savannah.gnu.org/bugs/download.php?file_id=55181>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64730>

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

[bug #62078] [grops] option "-fsanitize=bounds" causes a run-time error

[Bjarni Ingi Gislason]

Follow-up Comment #1, bug #62078 (project groff):

  This does not occur with gcc version (Debian 13.2.0-4) 13.2.0



___

Reply to this item at:

  

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

[bug #61643] grops: core dump when running and compiled with -Wsanitize=undefined

[Bjarni Ingi Gislason]

Follow-up Comment #6, bug #61643 (project groff):

  This does not occur with gcc version (Debian 13.2.0-4) 13.2.0



___

Reply to this item at:

  

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

[bug #64720] www.tmac.in: blue text on a black background is illegible

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64720>

 Summary: www.tmac.in: blue text on a black background is
illegible
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 26 Sep 2023 10:26:53 PM UTC
Category: Macro man
Severity: 3 - Normal
  Item Group: Rendering/Cosmetics
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 26 Sep 2023 10:26:53 PM UTC By: Bjarni Ingi Gislason 
Subject: www.tmac.in: blue text on a black background is illegible

  The default value is

.LINKSTYLE blue CR \[la] \[ra]

  This is probably a case for "man.local" (and "doc.local") to define
string "www:color" and use

.if !d www:color \{\
.  ds www:color \\$1\"
.\}

in the LINKSTYLE macro in "www.tmac.in".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64720>

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

[bug #64719] tmac/www.tmac.in: missing a word in a comment

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64719>

 Summary: tmac/www.tmac.in: missing a word in a comment
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 26 Sep 2023 09:42:46 PM UTC
Category: Macro man
Severity: 3 - Normal
  Item Group: Lint
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 26 Sep 2023 09:42:46 PM UTC By: Bjarni Ingi Gislason 
Subject: tmac/www.tmac.in: missing a word in a comment

.\" LINKSTYLE color [fontstyle [openglyph closeglyph]]
.\"
.\"   Initialize www.tmac so that when this macro set is used with
.\"   non-HTML devices the urls are rendered the user defined
.\"   attributes.  For example:
.\"
.\"   LINKSTYLE blue CR < >

The sentence "are rendered the user defined attributes." is probably
lacking the word "with".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64719>

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

[bug #64701] [doc] clang-16 dumps core when creating "doc/groff-man-pages.pdf"

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64701 (project groff):

  The file that caused the core dump is "tmac/groff_mdoc.7".

  Compiling without my extra flags does not cause a core dump.

  So this is a defect in the clang-16 compiler(?).

  From config.clang.out*

GNU roff version 1.23.0.rc4.9430-4cf0
--
 installation directory prefix: /usr/local
 C++ compiler and options : /usr/bin/clang++ -Wabi -Walloca -Wall
-Wextra -Wformat=2 -Wattribute-warning -Wdate-time -Wformat-security
-Wfree-nonheap-object -Wimplicit-fallthrough -Wmissing-noreturn
-Wredundant-decls -Wshadow-all -Wshift-overflow -Wuninitialized -Wunused
-Wunused-parameter -Wvla -fsanitize=bool -fsanitize=enum
-fsanitize=signed-integer-overflow
-fsanitize=integer-divide-by-zero,shift,null
-fsanitize-undefined-trap-on-error -fno-sanitize=pointer-overflow
-fsanitize=return -fsanitize=alignment,object-size,pointer-overflow -O2
-fstack-protector-strong -fno-common -fstack-clash-protection -ftrapv
-funsigned-char -ggdb3 -fsanitize=null -fsanitize=nonnull-attribute
-fno-builtin -fsanitize=undefined  -fcheck-new -Wmismatched-new-delete
-Wredundant-decls -Wdelete-incomplete -std=c++2a  -D_FORTIFY_SOURCE=2
-DGNULIB_NO_VLA 
 use libgroff's memory allocator  : no
 C compiler and options   : /usr/bin/clang -Wabi -Walloca -Wall
-Wextra -Wformat=2 -Wattribute-warning -Wdate-time -Wformat-security
-Wfree-nonheap-object -Wimplicit-fallthrough -Wmissing-noreturn
-Wredundant-decls -Wshadow-all -Wshift-overflow -Wuninitialized -Wunused
-Wunused-parameter -Wvla -fsanitize=bool -fsanitize=enum
-fsanitize=signed-integer-overflow
-fsanitize=integer-divide-by-zero,shift,null
-fsanitize-undefined-trap-on-error -fno-sanitize=pointer-overflow
-fsanitize=return -fsanitize=alignment,object-size,pointer-overflow -O2
-fstack-protector-strong -fno-common -fstack-clash-protection -ftrapv
-funsigned-char -ggdb3 -fsanitize=null -fsanitize=nonnull-attribute
-fno-builtin -fsanitize=undefined  -Wmissing-prototypes -Wold-style-definition
-Wstrict-prototypes  -Wout-of-line-declaration  -std=c17  -D_FORTIFY_SOURCE=2
-DGNULIB_NO_VLA 
 Perl interpreter version : 5.36.0
 X11 support  : enabled
 X11 app defaults directory   : /usr/local/lib/X11/app-defaults
 default paper format : A4
 'groff -l' uses print spooler: no
 use URW fonts for PDF output : yes
 URW fonts directory  : /usr/share/fonts/type1/urw-base35/
 preconv can use uchardet library : yes
 can build groff.dvi, groff.pdf   : yes
--




___

Reply to this item at:

  

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

[bug #64701] [doc] clang-16 dumps core when creating "doc/groff-man-pages.pdf"

[Bjarni Ingi Gislason]

URL:
  <https://savannah.gnu.org/bugs/?64701>

 Summary: [doc] clang-16 dumps core when creating 
"doc/groff-man-pages.pdf"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Thu 21 Sep 2023 12:27:07 AM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 21 Sep 2023 12:27:07 AM UTC By: Bjarni Ingi Gislason 
Subject: [doc] clang-16 dumps core when creating
 "doc/groff-man-pages.pdf"

Debian clang version 16.0.6 (15)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Makefile is in the attachment.

[...]
  GROFFdoc/groff-man-pages.pdf
/home/bg/git/groff/build/groff: error: troff: Illegal instruction (core
dumped)
make[2]: *** [Makefile:17190: doc/groff-man-pages.pdf] Error 2
make[2]: *** deleting file 'doc/groff-man-pages.pdf'
make[2]: Leaving directory '/home/bg/git/groff/build'
make[1]: *** [Makefile:12529: all-recursive] Error 1
make[1]: Leaving directory '/home/bg/git/groff/build'
make: *** [Makefile:6992: all] Error 2
[...]


[
  5664  DOC_GROFF = \
  5665GROFF_COMMAND_PREFIX= \
  5666GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
  5667$(GROFFBIN) -M $(doc_srcdir) $(MFLAG) $(FFLAG) -ww -b

  [ s-tmac: stripped tmac files ]
  5203  MFLAG = -M$(abs_top_builddir)/s-tmac -M$(abs_top_builddir)/tmac
-M$(abs_top_srcdir)/tmac
  
  5201  FFLAG = -F$(abs_top_builddir)/font -F$(abs_top_srcdir)/font
]

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



 12528  $(am__recursive_targets):
 12529  @fail=; \
 12530  if $(am__make_keepgoing); then \
 12531failcom='fail=yes'; \

  6991  all: $(BUILT_SOURCES)
  6992  $(MAKE) $(AM_MAKEFLAGS) all-recursive
  6993  








___
File Attachments:


---
Date: Thu 21 Sep 2023 12:27:07 AM UTC  Name: Makefile  Size: 998KiB   By:
bjarniig

<http://savannah.gnu.org/bugs/download.php?file_id=55155>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64701>

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