[bug #65961] pre-html.cpp: suppress spurious warnings from buggy pnmcrop

[Dave]

Update of bug #65961 (group groff):

 Summary: pre-html.cpp: use option "-blank-image=pass" for
"pnmcrop" to avoid  warnings => pre-html.cpp: suppress spurious warnings from
buggy pnmcrop

___

Follow-up Comment #1:

As Ingo has said more than once, silencing warnings on its own should never be
the goal.  Dealing with the situation that provokes the warning should be the
goal.

In this case we're faced with a buggy pnmcrop that generates spurious
warnings.  But groff cannot (easily, or perhaps at all) distinguish between a
legitimate and a spurious warning from another package.  And some other bug
could certainly result in a malformed image where that pnmcrop warning is
legitimate, which would then be lost if the warning were suppressed
unilaterally.

The pnmcrop bug is unfortunate, but suppressing the warning would require a
plan to make sure it happens only in cases where it's known to be spurious. 
The proposal presented here does not do that, so I'm removing it from the the
Summary.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65936] [grohtml] litters working directory with 0-length image files

[Dave]

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

[comment #4 comment #4:]
> I carelessly rendered Git HEAD's version of "ms.ms" in comment #3.
> 
> When I render 1.23.0's "ms.ms" with 1.23.0, I do get _some_
> complaints from _pnmcrop_ and _pnmtopng_, and _some_ zero-length
> files, but not 59 of them.

I see the same.  (My results in comment #1 were using the git HEAD version of
ms.ms.)  The test I mentioned using groff 1.22.4 also used the git HEAD ms.ms,
as that document didn't exist until after 1.22.4.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65936] [grohtml] litters working directory with 0-length image files

[Dave]

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

[comment #3 comment #3:]
> We do have the following recent note in our "PROBLEMS" file
> (unfortunately, I think most distributors don't ship it, and
> to be fair we don't install it).

Bug #61950 seeks to give user-relevant items in this file more visibility.

> * When I run "groff -Thtml", I get complaints from pnmcrop.
> 
>   pnmcrop: The image is entirely background; there is nothing to crop.
> 
> This appears to be two bugs in Netpbm 11.01.00 through 11.3.5 at least;

The "at least" range can potentially be widened: I have Netpbm 10.70.0 and get
the warning, though only when giving -Thtml to the latest groff, not groff
1.22.4.  But because this item was only recently added to PROBLEMS, I presume
some recent groff change provoked the warning.

> the diagnostic is spurious, and pnmcrop is ignoring or overriding the
> "-quiet" option that the pre-grohtml(1) program passes to it.

The diagnostic certainly seems to be spurious for me; as I mentioned, my
generated .png files look fine.

Curiously, "-quiet" seems to be an undocumented option in this version of
pnmcrop.

$ pnmcrop -quiet /dev/null
pnmcrop: Error reading magic number from Netpbm image stream.  Most often,
this means your input file is empty.
$ pnmcrop -loud /dev/null
unrecognized option '-loud'.  Recognized options are: -black -white -sides
-left -right -top -bottom -verbose -margin -borderfile




___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65962] [troff] want stack limit reduced to <=100

[Dave]

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

Since the value is user-configurable, and since the reason for the default
_is_ documented (and reasonable for the reasons Branden mentioned), I agree it
shouldn't be changed.

But the source code does lack a comment where DEFAULT_INPUT_STACK_LIMIT is
defined citing the user documentation that addresses this limit.  I'm not sure
how important this is: _most_ users will look at user documentation before
browsing source code.  But there's a lot of user documentation, and some
details might not stick in one's brain, and a short comment here pointing to
the relevant part of the manual might be useful to future developers who have
spent fewer years polishing the manual than Branden has.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

[Dave]

Follow-up Comment #13, bug #64043 (group groff):

Sounds good.  While the bug has been Rejected for over a year, the discussion
seemed have been left in limbo, so I wanted to make sure everything that might
have been resolved has been resolved.

Only one other potentially loose thread that I see: one of your emails
includes the statement "I can see a reason for displays (and equations
displayed with EQ/EN) in ms documents to permit pre-heading space to
accumulate with inter-display distance.  For that matter, we could expose a
new register to enable user control of pre-heading vertical space."  This
appears not to have been done (s.tmac has had only four commits since that was
written, none of which say anything about a new register).  Should it be?


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

[Dave]

Follow-up Comment #10, bug #64043 (group groff):

Additional discussion on the email list can be found in the threads starting
at:
* http://lists.gnu.org/r/groff/2023-04/msg00074.html (the start of a thread
linked in the original submission)
* http://lists.gnu.org/r/groff/2023-04/msg00137.html
* http://lists.gnu.org/r/groff/2023-04/msg00193.html
Christof Meerwald drove these discussions.  He has has neither confirmed nor
denied that he is this bug report's submitter, but the points raised by both
(and the writing styles) are largely the same.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #64043] [ms] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT troff

[Dave]

Update of bug #64043 (group groff):

 Summary: mixing formatting requests with macro calls produces
different unspecified behavior with groff than with AT troff => [ms] mixing
formatting requests with macro calls produces different unspecified behavior
with groff than with AT troff

___

Follow-up Comment #9:

[comment #6 comment #6:]
> The application of inter-display distance after equations does not
> appear to be documented in _groff_, however, and I'm happy to do that.

I'm not sure whether this was done. 
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=1c39f5d80 Commit
1c39f5d80] (pushed about a month after comment #6 was posted here) included
"Describ[ing] the handling of display distance in more detail."  It doesn't
address equations specifically, but they may be included under the umbrella of
"display macros."

Here's a recap of the relevant changes, which were made in the Texinfo manual,
the ms.ms document, and the groff_ms(7) man page.

The clause "The distance stored in the 'DD' register is inserted before and
after each pair of display macros, replacing any adjacent inter-paragraph
distance" had the phrase after the comma removed.  A new sentence was then
inserted after this one, expanding that phrase into: "In 'groff' 'ms', this
distance replaces any adjacent inter-paragraph distance or subsequent spacing
prior to a section heading."  (The wording has since been tweaked but retains
that essence.)

Branden, was this intended to address the above-quoted documentation update
you offered to make?

Submitter, does the text added in this commit address the changes in vertical
space you observe between groff 1.22.4 and 1.23.0?


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65955] [troff] enable "input" warning category by default and add one-off alert

[Dave]

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

I raised a concern about discontinuing native ISO 8859-1 support on the email
list (http://lists.gnu.org/r/groff/2024-05/msg00030.html).  There were no
further replies in the thread.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

Follow-up Comment #12, bug #65930 (group groff):

It might also be worth your confirming that the patch file I attached (comment
#5) matches the one you're applying, just to verify that I edited it
correctly.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

Follow-up Comment #11, bug #65930 (group groff):

Using the bug-65930b.me test file from comment #8, I can reproduce the problem
in groff 1.22.4; using tv-stack-limit.me from comment #2, I cannot.

$ groff --version | head -n 1
GNU groff version 1.22.4
$ cat bug-65930b.me
.\"mso e.tmac
.br
.nr $v 421
.fo 'foo'bar'baz'
.lp
You get the diplomatic treatment
.br
You get the force-fed future
.br
You get the funk after death
.br
You get the weisenheimer brainstorm
$ groff -z -me ./bug-65930b.me
troff: fatal error: input stack limit exceeded (probable infinite loop)
$ groff -z -me ./tv-stack-limit.me
$ diff tv-stack-limit.me bug-65930b.me
1c1,3
< .nr $v 1640u
---
> .\"mso e.tmac
> .br
> .nr $v 421

As I noted in the [comment #0 original submission], for me "the bug only
happens with the .br request present" (_before_ the .nr, I should have
clarified).  So the diff above, showing the absence of the triggering .br,
makes me not surprised to see the respective results above.

But I _am_ surprised that you're seeing the bug triggered in 1.22.4 with both
files (with and without the initial .br).

With my recent inability to reproduce a different bug using seemingly the same
input file and command invocation as the submitter (bug #65936), I have to
wonder if I've Bjarnied my system somehow.  I checked the obvious things, like
making sure I hadn't hacked on my 1.22.4 e.tmac file.  I do have various
modifications to local font files, but I can't see how those matter, and
indeed I get the same results even if I remove them.

So if you can confirm the bug shows up for you regardless of the
presence/absence of the .br before the .nr, then we need to dig into what
separates our 1.22.4s.  (Looking at an older release might seem like a wild
goose chase, but since I'm also seeing different results from you using the
patched -me on bleeding-edge groff, I think finding the difference between our
systems in an official release might be easier than finding what could be
different in independent new builds.)


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

Follow-up Comment #10, bug #65930 (group groff):

[comment #9 comment #9:]
> These aren't exercising the formatter in the same way; they're
> using different output drivers

Yes, the intent was to show that I didn't see the bug with either the devps or
devascii output driver.  Sorry I was unclear about that.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

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

OK.  So.

The patch has no effect on my original test file.  Test fails with it, fails
without it.

Your updated test file (from comment #2) does not generate the error under any
circumstances for me.  Not with patched -me, not with unpatched, not with a
stock 1.22.4.

$ cat tv-stack-limit.me
.nr $v 1640u
.fo 'foo'bar'baz'
.lp
You get the diplomatic treatment
.br
You get the force-fed future
.br
You get the funk after death
.br
You get the weisenheimer brainstorm
$ groff --version | head -1
GNU groff version 1.22.4
$ groff -me tv-stack-limit.me | wc
249 7056268
$ groff -Tascii -me tv-stack-limit.me | uniq -c
 20 
  1 You get the diplomatic treatment
 13 
  1 You get the force-fed future
 13 
  1 You get the funk after death
 13 
  1 foo  bar baz
 23 
  1 You get the weisenheimer brainstorm
 41 
  1 foo  bar baz
  3 




___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

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

[comment #2 comment #2:]
> Try this patch:

First speed bump: patch fails to apply.  This turns out to be because the tab
characters in the patch have been reduced to strings of spaces.

I initially suspected being bitten by
http://savannah.nongnu.org/support/?110582, but the workaround mentioned in
that ticket still did not give me my tabs, so I now suspect there was a copy
or paste translation error when pasting the patch into comment #2.

But I was able to fix the patch manually and get it to apply, so this speed
bump was minor.  For posterity I'm attaching my patched patch here.

Now to actually run the patched -me code and see what happens!

(file #56226)

___

Additional Item Attachment:

File name: me.65930.patch Size: 656B



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-05dcad1214d86f0cdb09953df600b098f3426851.tar.gz


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

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

[comment #2 comment #2:]
> Try this patch:

Thanks!  I'll give this a shot once I'm done chasing down a bash issue.

> If I'm right about Allman not contemplating multi-line headers/footers

His "-me Reference Manual" explicitly addressed such things when talking about
the .$h (and, by reference, .$f) macro: "May be redefined to provide fancy
(e.g., multi-line) headers."  Intriguingly, "someone" has removed this text
from the groff version of the manual, perhaps in an attempt to hide his
contemplation of such an abomination.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65936] [grohtml] grohtml litters working directory with 0-length image files

[Dave]

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

What version of groff are you running?  I can't reproduce this under either
1.22.4 or a recent git build (1.23.0.1262-4c62e-dirty).  That is, I do get 59
.png files, but they all have content (file sizes vary from 553 to 28196
bytes), and some are referred to by the generated HTML code.  (It's unclear to
me the purpose of the rest--the vast majority--if the HTML doesn't use them.)

When running your command, the newer groff does generate 59 lines of "pnmcrop:
The image is entirely background; there is nothing to crop" on stderr.  But
the images look OK despite these diagnostics.

Do you know if your system has pnmcrop installed (this is part of netpbm, not
groff)?


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65936] [grohtml] grohtml litters working directory with 0-length image files

[Dave]

Update of bug #65936 (group groff):

Category:None => Driver grohtml 
  Item Group:None => Incorrect behaviour


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65930] [me] Large values of register "tv" cause fatal error

[Dave]

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

 Summary: [me] Large values of register "tv" cause fatal error
   Group: GNU roff
   Submitter: barx
   Submitted: Sat 29 Jun 2024 03:48:35 PM CDT
Category: Macro package me
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 29 Jun 2024 03:48:35 PM CDT By: Dave 
This bug is in at least 1.22.4 and 1.23.  The below example uses the register
name "$v" rather than its more modern alias "tv", so that the example works
the same in current and pre-1.23 code (which had not yet defined "tv").

$ cat stack-limit.me
.mso e.tmac
.br
.nr $v 421
$ groff stack-limit.me | wc
troff: fatal error: input stack limit exceeded (probable infinite loop)
238 7804673

Observations:
* The bug only happens with the .br request present.
* Values 420 and lower do not trigger the bug.  Values 421 and higher do.
* This applies to output on the ps device.  On the ascii device, 421 
does not
trigger the bug, but 440 does.
* If any text is appended to the input file (either with or without a -me
paragraphing macro), that text _is_ present in the output, despite the error
above it being "fatal."

Yes, 421 is higher than most real-world values for the $v/tv register, so I
don't have a problem with this exceeding a supported limit.  But exceeding
that limit shouldn't provoke an ostensibly fatal error.  And "stack limit
exceeded" is a peculiar error for this to trigger.







___

Reply to this item at:

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

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


signature.asc
Description: PGP signature

[bug #65929] groff.texi.in: .linetabs example input has vestigial line

[Dave]

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

 Summary: groff.texi.in: .linetabs example input has vestigial
line
   Group: GNU roff
   Submitter: barx
   Submitted: Fri 28 Jun 2024 09:43:11 PM CDT
Category: Core
Severity: 2 - Minor
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 28 Jun 2024 09:43:11 PM CDT By: Dave 
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=ce4ec3b65 Commit
ce4ec3b65] added this example:

.de Tabs
.  ds x a\t\c
.  ds y b\t\c
.  ds z c
.  ta 1i 3i
\\*x
\\*y
\\*z
..
.Tabs
.br
.linetabs
.Tabs

[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=ad2dd7226 Commit
ad2dd7226] later simplified this example by removing the macro definition, but
it left one instance of the .Tabs macro call.

Running the current example code with warnings enabled produces the given
output, and on stderr the line "troff::10: warning: macro
'Tabs' not defined".







___

Reply to this item at:

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

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


signature.asc
Description: PGP signature

[bug #65910] Some dashed ellipse sizes produce irregular dashes

[Dave]

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

(spawned from bug #65901)


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #60052] [tbl] want option to output HTML

[Dave]

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

[comment #0 original submission:]
> That would render groff_hdbtl(7) unnecessary

s/hdbtl/hdtbl/, to get to an existent man page.

But I wonder if there is also a thinko here: elsewhere (e.g., bug #63837) it
seems like tbl having this functionality is meant to obsolete pre-grohtml, not
groff_hdtbl.

(groff_hdtbl is controversial on its own merits anyway: see bug #64772.)


___

Reply to this item at:

  

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

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

[Dave]

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

[comment #0 original submission:]
> That leaves _only_ tbl as a reason for pre-grohtml to exist.

Bug #60052 seeks to abolish that reason.


___

Reply to this item at:

  

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

[bug #63587] [troff] set .R register to maximum representable integer

[Dave]

Follow-up Comment #10, bug #63587 (group groff):

[comment #5 comment #5:]
> I can think of no situation where a user might need 10,001
> registers, so, despite this number having no clear connection to
> any internal groff limit, it's probably a reasonable limit to
> _claim_ to the user who asks.  It will enable the processing of
> any ancient roff documents that do test this register,

I have to backpedal on my own argument here: this point, as far as I can see
now, remains just as true no matter what big number .R holds.  Groff having no
fixed register limit, 10,000 and INT_MAX are equally wrong values to return,
but equally useful in terms of back compatibility to documents for ancient
troffs.


___

Reply to this item at:

  

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

[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:  3 - Normal => 2 - Minor  


___

Reply to this item at:

  

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

[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:   2 - Minor => 3 - Normal 

___

Follow-up Comment #3:

("cc" bug that affects this ticket (and probably others) reported in
http://savannah.nongnu.org/support/?111079)


___

Reply to this item at:

  

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

[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:  3 - Normal => 2 - Minor  

___

Follow-up Comment #2:

[comment #1 comment #1:]
> I suspect this may be low priority,

I agree.

> perhaps so low that it's not worth doing, because _as deployed_,
> all of _groff_'s full-service macro packages are prepared to
> format documents using the basic Latin character set.

Although documents in languages using Latin alphabets are likely groff's
biggest use, I think it's hard to justify declining to fix (as opposed to
deferring fixing) known bugs when it's used for non-Latin-alphabet languages,
especially as groff moves toward supporting such languages in other ways (the
fixed bug #63076, the pending bug #62830).

> I'm also still a bit undecided whether we should have a
> syntactically sweeter way of doing string comparisons.

Like you, I dislike the idea of adding basic language constructs to do
something the language can already do, and also find the way the language
already does this rather ugly.  So I'm no help in deciding.

> It grabs the symbol '~' for use as an operator in a conditional
> expression

This breaks back compatibility with ~'s current use as a synonym (along with
myriad other characters) for the ' conditional operator.  That doesn't
disqualify it, IMHO, but it is another strike against it.

> I suggest that nothing about it is a priority for 1.24.

I agree with this too.  Lowered the severity to reflect this.


___

Reply to this item at:

  

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

[bug #65886] repeated word in some man pages

[Dave]

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

Not all repeated words are erroneous.  You have to look at the context.

[comment #0 original submission:]
> ! ./man/groff.7.man: 5736 --> to
> ! ./man/groff_diff.7.man: 772 --> to

These are both copies of the same sentence, the relevant phrase of which is
"drawing position that GNU troff automatically returned to to close the
figure."  It a shorthand (but perfectly idiomatic) way of writing "drawing
position to which GNU troff automatically returned in order to close the
figure."

The rest do seem to be typos.


___

Reply to this item at:

  

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

[bug #24050] [mm] footnote/end-of-page problem

[Dave]

Update of bug #24050 (group groff):

  Depends on: => bugs #56499

___

Follow-up Comment #5:

[comment #3 comment #3:]
> This (mis)behavior is consistent with DWB 3.3 and Heirloom Doctools mm.

Bug #56499 also exists across at least three troffs (DWB troff is not surveyed
over there, but Plan 9 troff is).  And one symptom reported there is the
end-of-page trap being ignored.  So, while I can't definitively say that that
bug is the culprit here, it's a strong enough probability that I'm making this
bug dependent on that one: there's not much point in digging into this mm
problem further until #56499 is fixed.  If it persists after that, this can be
looked into anew.


___

Reply to this item at:

  

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

[bug #24050] [mm] footnote/end-of-page problem

[Dave]

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

Problem originally reported on bug-groff
(http://lists.gnu.org/r/bug-groff/2007-07/msg00010.html).  That report offers
no additional information about the problem, but does tell who reported it. 
There were no follow-ups on the list.


___

Reply to this item at:

  

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

[bug #65710] [preconv] require disambiguation of U+00A0 on input

[Dave]

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

[comment #3 comment #3:]
> Bjarni's prescription was much too strong.

Bjarni's "prescription" was an editorial recommendation to users that had no
bearing on his proposed code change.  Users would be free to ignore it.

The current proposal--to upgrade his proposed warning to a fatal error--only
intensifies the problems.  As I said over there, preconv should not be in the
business of policing which parts of valid Unicode users use.  The new proposal
kicks that policing from a written warning up to jail time.  It's wildly out
of proportion with the offense.

> _Maybe_ they mean `\ ` (an unadjustable space).  It's
> impossible to know, which is why they should disambiguate it.

It's technically ambiguous, in the same way that "We're going to spend the
week in a cabin" is technically ambiguous: that person could be talking about
either a house in the woods or the interior of an airplane.  But anyone
hearing it will know exactly what they mean--crucially, because if they did
mean the latter, they'd specifically note it.  When you say something mildly
ambiguous, but with one meaning far more likely than another, it's only the
exceptional meaning that tends to need to be disambiguated.

Even the roff language--hardly a paragon of DWIM design--understands this. 
You need only say ".sp 4" to space down four lines; you don't have to specify
"4v" because roff gives the request a sensible default unit.

Likewise, \~ is the sensible default meaning for U+00A0: in almost all normal
situations, the user will want \~.  The documentation clearly spells out how
to get different {units for .sp / types of nonbreaking spaces}, so users who
want the rarer \space in certain places can explicitly say so.

Making the user edit a bunch of valid Unicode characters (or valid ISO 8859-1,
or 8859-2, or any other encoding in the ISO 8859 family) only impedes
preconv's ability to import text from another source and use it directly.  We
should be making this easier for users, not putting up needless roadblocks in
the name of semantic purity, certainly not without wider discussion.

> And if there are multiple U+00A0 characters in sequence, the
> author might be better off supplying a `\h` sequence to
> express what it is they want, precisely.

Sure.  But the formatter allows \~\~\~\~\~ without complaint, and adding a
complaint here is beyond what this ticket is proposing, so this is tangential.


___

Reply to this item at:

  

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

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #13, bug #55154 (group groff):

[comment #11 comment #11:]
> I presume this is due to this explanation in the Texinfo manual:
> 
>  -- Request: .char c ['"'][contents]
>  Every time C is to be output, CONTENTS is processed in a
> temporary environment and the result encapsulated in a node.
> 
> The temporary environment being unaware of the rest of the line,
> it can only turn \~ into a node that is the width of an ordinary
> unbreakable space.

The below (requiring a recent groff build, as it uses .pline) is consistent
with this hypothesis (though not proof of it, as the precise content of the
two composite_node nodes is unknown).

$ cat 55154.tr
.char b \~
abc cba
.pline
.brp
.tm
a\~c c\~a
.pline
.brp
$ groff 55154.tr > /dev/null
{type: line_start_node, diversion level: 0},
{type: glyph_node, character: "a", diversion level: 0},
{type: composite_node, diversion level: 0},
{type: glyph_node, character: "c", diversion level: 0},
{type: word_space_node, diversion level: 0},
{type: glyph_node, character: "c", diversion level: 0},
{type: composite_node, diversion level: 0},
{type: glyph_node, character: "a", diversion level: 0}

{type: line_start_node, diversion level: 0},
{type: glyph_node, character: "a", diversion level: 0},
{type: unbreakable_space_node, diversion level: 0},
{type: glyph_node, character: "c", diversion level: 0},
{type: word_space_node, diversion level: 0},
{type: glyph_node, character: "c", diversion level: 0},
{type: unbreakable_space_node, diversion level: 0},
{type: glyph_node, character: "a", diversion level: 0}




___

Reply to this item at:

  

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

[bug #65865] [mm] `AF` macro has no effect

[Dave]

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

[comment #0 original submission:]
> Problem affects groff 1.22.3, 1.22.4, and 1.23.0.

In fact, goes back to at least 1.19.2, and I'd bet much further than that.


___

Reply to this item at:

  

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

[bug #65861] add macro set to support German national standard DIN 5008

[Dave]

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

 Summary: add macro set to support German national standard
DIN 5008
   Group: GNU roff
   Submitter: barx
   Submitted: Sun 09 Jun 2024 04:06:06 PM CDT
Category: Macro package - others/general
Severity: 1 - Wish
  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 09 Jun 2024 04:06:06 PM CDT By: Dave 
A proposal for a macro set to support German national standard DIN 5008 was
put forth on the email list a few months ago
(http://lists.gnu.org/r/groff/2024-01/msg00022.html).  In this thread, Alexis
(copied on this ticket) indicated having a working prototype of a set of
macros.

It's unclear how many (if any) of the informal requirements for contrib
inclusion that Brendan posted later in the thread have been met, so there are
still any number of reasons this may not become part of groff.  But since
discussion indicated groff inclusion was a possibility, this ticket exists to
keep that on the radar.







___

Reply to this item at:

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

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

Re: How to configure how groff hyphenates man pages (was: tctest.1 man page hyphenation comments)

[Dave Kemper]

On Mon, Jun 3, 2024 at 9:06 PM G. Branden Robinson
 wrote:
> [1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n50
>
> The foregoing line number will get stale with time.  Look for the
> text "hydefault".

You can stale-proof git URLs that point to line numbers by specifying
a particular revision of the file.

http://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=b8fff80f84cb70c38f7b5840332febe0f51ff399#n50

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #12, bug #55154 (group groff):

[comment #11 comment #11:]
> While everything here appears to be working as designed, I'm
> tempted to open a new bug report anyway,

Succumbed to temptation: bug #65829


___

Reply to this item at:

  

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

[bug #65829] Want way to translate a character to \~

[Dave]

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

 Summary: Want way to translate a character to \~
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 03 Jun 2024 12:06:58 AM CDT
Category: Core
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 03 Jun 2024 12:06:58 AM CDT By: Dave 
Comments 10 and 11 of bug #55154 point out that due to the way .tr and .char
and their ilk handle translations, there is no way to translate an input
character to a stretchable unbreakable space.

The use case presented there (of working around the now-fixed bug #62300 in
older preconvs) would not be helped by a fix to this bug, since this fix would
not be available in older groffs.  But there are other reasons one might want
to translate an input character to \~.

As Bjarni points out in bug #65654, many common Unix text-display tools make
U+0020 and U+00A0 visually indistinguishable, so the user might choose to have
a different character represent U+00A0 and let groff translate it
appropriately.  While this is a simple translation to preprocess before groff
sees the input, it's such a simple translation that groff ought to be able to
handle it itself.







___

Reply to this item at:

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

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

[bug #65800] bootstrap oddity: .gitignore discrepancy

[Dave]

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

The groff version reported by this build is 1.23.0.1262-4c62e-dirty.


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #65809 (group groff):

Severity:  3 - Normal => 1 - Wish   


___

Reply to this item at:

  

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

[bug #65800] bootstrap oddity: .gitignore discrepancy

[Dave]

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

 Summary: bootstrap oddity: .gitignore discrepancy
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 27 May 2024 07:54:09 PM CDT
Category: Core
Severity: 2 - Minor
  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 27 May 2024 07:54:09 PM CDT By: Dave 
I haven't built a groff since 1.23.  When I did so recently
(http://lists.gnu.org/r/groff/2024-05/msg00042.html), the first step produced
a query I hadn't seen in a groff build before.

$ ./bootstrap
/bin/mv: overwrite '.gitignore'?

I said "y" to this, and the result was that the top-level .gitignore file
gained a "/build-aux" line at the top, before the first comment.  The line
"/build-aux/" (with the trailing slash), already in the file in the "artifacts
expected in a clean tree" section, remained unaltered, so "/build-aux" now
appears twice, once with the trailing slash and once without.

This has no effect I could discern on the rest of the bootstrap or build.  I
don't know whether it constitutes a bug, but it seems weird for the bootstrap
script to require user input to continue, especially devoid of any context
about the significance of the decision, or even which of the tree's many
.gitignore files it refers to.







___

Reply to this item at:

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

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

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

[Dave]

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

Correcting my earlier statement:

[comment #2 comment #2:]
> 0xA0 appears to refer to the Latin-1 character NO-BREAK SPACE
> (Unicode U+00A0)--but there is no reason to run preconv if the
> file is in Latin-1 encoding,

My Latin-1 (ISO 8859-1) blinders were on: the byte 0xA0 is also the no-break
space in encodings ISO 8859-2, ISO 8859-3, ISO 8859-4, etc., any of which
would require preconv.

> Nonetheless, his point remains:

This makes the preceding (mis)statement mostly moot, but I wanted to correct
the record.


___

Reply to this item at:

  

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

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

[Dave]

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

This proposal (with the warning upgraded to a fatal error) has been offered as
one of the solutions to bug #65710.


___

Reply to this item at:

  

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

[bug #65710] [preconv] require disambiguation of U+00A0 on input

[Dave]

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

[comment #0 original submission:]
> In my opinion preconv should either:
> 
> 1.  Fail and force the user to edit the input to make a real
> choice, eliminating U+00A0 in the input.

This option seems materially the same as the rejected bug #65654, except with
that bug's proposed warning upgraded to a fatal error.  (Granted, #65654 was
rejected a few days before bug #65693 (the current ticket's inciting report)
was opened.)


___

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 '/'

[Dave]

Update of bug #65788 (group groff):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[bug #65762] configure check has erroneous code

[Dave]

Update of bug #65762 (group groff):

Category:None => Core   
  Item Group:None => Build/Installation 


___

Reply to this item at:

  

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

[bug #64155] Specifying -fZD on command line generates warnings

[Dave]

Update of bug #64155 (group groff):

Category:Core => Macro package -
others/general
 Summary: [troff] specifying -fZD on command line generates
warnings => Specifying -fZD on command line generates warnings


___

Reply to this item at:

  

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

[bug #65763] Do actual string comparisons in macro packages

[Dave]

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

 Summary: Do actual string comparisons in macro packages
   Group: GNU roff
   Submitter: barx
   Submitted: Sun 19 May 2024 11:27:44 PM CDT
Category: Macro package - 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: Sun 19 May 2024 11:27:44 PM CDT By: Dave 
Bug #64155 fixed fallbacks.tmac and troffrc-end to make tests that were
intended only to compare strings do so without formatting the comparands, so
that such comparisons work regardless of whether the current font contains all
the characters in the strings.

It turns out most of the other macro packages need this refinement as well.

$ groff -ms -fZD < /dev/null
troff:tmac/s.tmac:2203: warning: character 'p' not defined
troff:tmac/s.tmac:2203: warning: character 's' not defined
troff:tmac/s.tmac:2203: warning: character 'h' not defined
troff:tmac/s.tmac:2203: warning: character 't' not defined
troff:tmac/s.tmac:2203: warning: character 'm' not defined
troff:tmac/s.tmac:2203: warning: character 'l' not defined
$ groff -mm -fZD < /dev/null
troff:contrib/mm/m.tmac:1294: warning: character 'p' not defined
troff:contrib/mm/m.tmac:1294: warning: character 's' not defined
troff:contrib/mm/m.tmac:1294: warning: character 'h' not defined
troff:contrib/mm/m.tmac:1294: warning: character 't' not defined
troff:contrib/mm/m.tmac:1294: warning: character 'm' not defined
troff:contrib/mm/m.tmac:1294: warning: character 'l' not defined
$ groff -me -fZD < /dev/null
troff:tmac/e.tmac:115: warning: character 'p' not defined
troff:tmac/e.tmac:115: warning: character 's' not defined
troff:tmac/e.tmac:115: warning: character 'h' not defined
troff:tmac/e.tmac:115: warning: character 't' not defined
troff:tmac/e.tmac:115: warning: character 'm' not defined
troff:tmac/e.tmac:115: warning: character 'l' not defined

(-fZD is a useful test, as this font ships with groff, but a likelier
real-world scenario is users formatting documents containing only CJK
characters.)

-man, -mdoc, and -mom exhibit similar behavior.  The first two of those
operate in a specialized domain where the problem may not be applicable, and
-mom has her own set of rules that may preclude specifying -f on the command
line.  Peter is cc:ed so he can address this.

I didn't test all the auxiliary packages, but, for example, pdf.tmac and
ps.tmac are clean while tty.tmac is not.







___

Reply to this item at:

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

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

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #45, bug #64155 (group groff):

[comment #44 comment #44:]
> I suspect you're not using _echo_(1) the way you think you are.

I admit I didn't consider its portability, but on my system it output what I
intended.

> Because the default style is 'R', and the font 'ZDR' exists (on
> the  "ps" default output device), this actually works.

Yes, I misinterpreted my results earlier.  In fact groff does fail on a bogus
family.

$ groff -fBOGUS
troff: fatal error: invalid default font family 'BOGUS'

So there's nothing more to be done here.  Sorry for the red herring.


___

Reply to this item at:

  

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

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #43, bug #64155 (group groff):

[comment #41 comment #41:]
> Now:
> 
> $ echo | ./build/test-groff -fZD -a
> 

A vast improvement!

But maybe a little _too_ quiet: groff disregards the -fZD flag without telling
the user it's doing so.

echo "\N'110'" | groff -ww -fZD

This fails to load the ZD family (because there is no such thing) or the ZD
font (because that's not what -f does), so outputs an "n" rather than a solid
square.  The invalid -f ought to at least provoke a warning, at least when all
warnings are activate.

This could reasonably be considered a separate bug, so I'm happy to open a new
report if warranted.


___

Reply to this item at:

  

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

bootstrap oddity: .gitignore discrepancy

[Dave Kemper]

I haven't built a groff since 1.23.  When I did so today, the first
step produced a query I hadn't seen in a groff build before.

$ ./bootstrap
/bin/mv: overwrite '.gitignore'?

I said "y" to this, and the result was that the top-level .gitignore
file gained a "/build-aux" line at the top, before the first comment.
The line "/build-aux/" (with the trailing slash), already in the file
in the "artifacts expected in a clean tree" section, remained
unaltered, so "/build-aux" now appears twice, once with the trailing
slash and once without.

This has no effect I could discern on the rest of the bootstrap or build.

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #11, bug #55154 (group groff):

[comment #10 comment #10:]
> Bizarrely, while it accepts the second translation, it doesn't
> actually honor it.

It gets worse: even .char fails at this.

$ cat char-test
.char b \~
abc cba\p
$ nroff char-test | cat -s
a c   c a

$ 

I presume this is due to this explanation in the Texinfo manual:

 -- Request: .char c ['"'][contents]
 Every time C is to be output, CONTENTS is processed in a temporary
environment and the result encapsulated in a node.

The temporary environment being unaware of the rest of the line, it can only
turn \~ into a node that is the width of an ordinary unbreakable space.

This is frustrating, because it means there is no way within groff to work
around bug #62300 (fixed in 1.23.0) for UTF-8 documents that need to work
under earlier preconvs.  Another tool has to preprocess the file before
preconv gets to it.  While everything here appears to be working as designed,
I'm tempted to open a new bug report anyway, because the design thwarts such a
seemingly straightforward way to handle pre-1.23 preconv output for the input
character U+00A0.

Hopefully I'm wrong about something above, and someone wiser will set me
straight.


___

Reply to this item at:

  

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

Multiline @cindex entries misrender in groff Texinfo manual

[Dave Kemper]

In a few places, the groff Texinfo manual uses a line-ending @ to
continue a @cindex entry.  An example is:

  @DefreqList {tm, message}
  @DefreqItemx {tm1, [@code{"}]message}
  @DefreqListEndx {tmc, [@code{"}]message}
  @cindex print to the standard error stream (@code{tm}, @code{tm1},@
  @code{tmc})
  @cindex standard error stream, write to (@code{tm}, @code{tm1},@
  @code{tmc})
  @cindex stream, standard error, write to (@code{tm}, @code{tm1},@
  @code{tmc})
  Send @var{message}, which consumes the remainder of the input line and

My version of makeinfo (texi2any (GNU texinfo) 6.7) doesn't render
this as desired:

  -- Request: .tm message
  -- Request: .tm1 ['"']message
  -- Request: .tmc ['"']message
  'tmc') 'tmc') 'tmc') Send MESSAGE, which consumes the remainder of
  the input line and ...

That is, the continued @code{} tags are being put into the output
rather than considered part of the index entry.

I don't know enough about the Texinfo language to know whether this is
a bug in our manual or in makeinfo.  Does this render correctly in
newer makeinfo versions?  makeinfo 6.7 is fairly old, but the groff
manual appears to require only 5.0 (as of commit 986d2a5b2, Apr 2020
(http://git.savannah.gnu.org/cgit/groff.git/commit/?id=986d2a5b2)).

[bug #55154] .tr has undocumented and inconsistent space-character restrictions

[Dave]

Follow-up Comment #10, bug #55154 (group groff):

[comment #0 original submission:]
> .tr a 
> .tr b\~
> .tr c\ 
> .tr d\|
> .tr e\^
> .tr f\0
> 
> This attempts to translate six alphabetic characters to six
> different types of space characters.  What it does instead is
> accept the first two translations and reject the last four:

Bizarrely, while it accepts the second translation, it doesn't actually honor
it.

$ cat tr-test
.tr b\~
abc cba\p
$ nroff tr-test | cat -s
a c   c a

$ 

I'm not sure what to think of this.  On the one hand, comment #2 argues this
shouldn't work; even the texinfo manual says a .tr target should be a glyph,
which \~ isn't.  On the other hand, given that fact, the translation failing
outright (as the subsequent lines of the original submission do) would make
sense, whereas silently converting a stretchable space to an unstretchable one
surely does not.

The deprecation proposed in bug #64337 would make this moot.


___

Reply to this item at:

  

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

[bug #62916] list things to deprecate

[Dave]

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

Related: bug #65724 seeks to deprecate EBCDIC.  However, if it goes through as
contemplated, it won't make it onto the list proposed by this ticket, because
there won't be a release where it's deprecated but still functional.


___

Reply to this item at:

  

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

Re: ripping out EBCDIC (cp1047)/preparing for UTF-8 input

[Dave Kemper]

On Tue, May 14, 2024 at 8:53 AM G. Branden Robinson
 wrote:
> I aim to drop EBCDIC a.k.a.
> code page (CCSID) 1047 support from groff 1.24.

No objection to this.

> The idea is, for 1.24, to get everybody migrating to pure ASCII input
> documents (as might be generated by preconv(1)) by the time GNU troff
> sees them.

I don't strongly object, but I wonder about the advisability of
requiring preconv on a wide swath of documents that didn't previously
require it while Savannah #59442 (preconv vs soelim) and #65108
(handling encoding of filenames) are unresolved.

This set of intertwined problems doesn't go away even when groff
accepts UTF-8 natively: files included via .so still might use Latin-1
-- especially any files dating from before 2026 (or whenever 1.24
comes out), where that was the native input encoding -- and the
underlying file system might use a different encoding for filenames.

Are support for EBCDIC and for Latin-1 tightly enough coupled in the
code that it's unnecessarily complex to remove the former while
retaining the latter?

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #30, bug #63018 (group groff):

[comment #29 comment #29:]
> When it is a separate make target (bug #65698), if we wish to
> retain the epsilon kerns the make target must either re-apply
> the shell script after the font generation, or these "gold" AFMs
> should have the extra kerns added once before we pour aspic on them.

[s/epsilon/ellipsis]

Ah, I see.  In theory I can't see a reason it would matter which way it's done
(though my font knowledge is far smaller than yours).  In practice, the script
for fixing up the kernpairs section post-afmtodit already exists and has been
tested (bug #58897).

> As far as I can tell the "slant" parameter does nothing for
> composite (e.g. a glyph plus an accent glyph on top of each
> other) placement.

As far as I can tell, too, but the sentence in afmtodit(1) says otherwise. 
Perhaps it's erroneous.

> What it does do is affect both italic
> correction factors and the subscript correction,

That makes more sense to me.  But it still doesn't explain why, as you
observed in comment #26, TI should have such a significant adjustment to the
slant value (more than halving the original) but TBI have none.  The metrics
between the two shouldn't be that different.


___

Reply to this item at:

  

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

[bug #65702] tmac/doc.tmac: compatibility mode not restored at end

[Dave]

Update of bug #65702 (group groff):

  Status:   Need Info => None   


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #28, bug #63018 (group groff):

[comment #27 comment #27:]
> And Dave just happens to be right here, ready for the spotlight. ;-)

Oh, heavens no, I still need at least 15 more minutes in makeup.  Have the
emcee stall!

[If there's a question for me here, I'm not sure what it is.]

> > Maybe some people on the list may know.
> 
> I'm afraid I don't have any insight into that decision.

Everything I know about it is in bug #57506.  It would help if afmtodit(1)'s
claim "the slant ("angle") parameter in the font description file...is used by
groff in the positioning of accents" were more forthcoming on just how groff
uses this value so.


___

Reply to this item at:

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

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

[bug #65724] drop support for CCSID (code page) 1047 (EBCDIC)

[Dave]

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

[comment #0 original submission:]
> See discussion with Mike Fulton of IBM on the _groff_ list a year ago.
> 
> https://lists.gnu.org/archive/html/groff/2023-03/msg00113.html

Discussion continues at http://lists.gnu.org/r/groff/2023-04/msg3.html
with more background on the affected OSes.


___

Reply to this item at:

  

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

Re: Hungarumlauts in built-in fonts

[Dave Kemper]

On Fri, May 10, 2024 at 1:50 AM Gáspár Gergő  wrote:
> I realized, however, that the "hungarumlauts" on the ő Ő ű and Ű glyphs are 
> placed incorrectly in the built-in fonts of groff used for the pdf device.

Does this mean the problem doesn't happen for the ps device?  Or have
you not tried that?

[bug #65693] exceptions to NBSP statement in groff_char(7) should be documented

[Dave]

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

Given the arguments in favor of the U+00A0 to \~ mapping presented in bug
#58962 and bug #65710, I now wonder if groff might be better off doing
something heretical like ignoring the u00A0 glyph in a font and applying its
own mapping to that character.  That is, rather than documenting the exception
to the cited groff_char(7) sentence, make that sentence universally true.


___

Reply to this item at:

  

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

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #39, bug #64155 (group groff):

Self-followup:

[comment #37 comment #37:]
> in a way back compatible to almost any older troff.

Obviously, this specific example is not AT due to the long names,
but the logic can be written portably.


___

Reply to this item at:

  

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

[bug #65710] [preconv] require disambiguation of U+00A0 on input

[Dave]

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

[comment #0 original submission:]
> an input U+00A0...: is it a fixed-width non-breakable space, or a
> variable-width non-breakable space?  Unicode does not distinguish.

Unicode intentionally provides some latitude to rendering engines to make the
best typographical decisions they can.  That is, Unicode is not really a
driving factor here; the only Unicode requirement of U+00A0 is that it be
nonbreaking, and both "\ " and "\~" meet that requirement.

Since 2003 ([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=48615a44
commit 48615a44]), groff_char(7) has said "the ISO Latin-1 no-break space is
mapped to `\~', the stretchable space character."  While this claim was
erroneous until bug #58962 addressed it (and remains erroneous with certain
fonts, per bug #65693), it has always been the most typographically sound
solution.

I think groff should strive to do by default what makes most typographic
sense, and (as #58962 argued) there are few if any situations where "\ " is
preferable to "\~".

> This is analogous to how we don't know whether a man page
> author means a hyphen or a minus sign when they type `-`.

Weakly analogous:
* Hyphens and minus signs are different semantically.  The two types of
nonbreaking spaces are different only presentationally.
* Hyphens and minus signs must copy to the clipboard as different characters;
both types of nonbreaking spaces will possibly copy as U+00A0, though more
probably (and more usefully to the user in most cases) copy as an ordinary
space.

> 2.  Add an option instructing preconv which escape sequence to
> transform U+00A0 into.

I don't oppose an option to _override_ the default escape preconv uses, but
its current default is sound.  (Still, I would question the need for such an
option, since users can always specify either escape directly in the source,
and preconv won't touch it.)


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #23, bug #63018 (group groff):

Don't read too much into my opening multiple tickets: they're not saying
"THESE THINGS MUST BE DONE" but giving venues to consider and discuss separate
issues without cluttering this bug.  At least that was the theory. ;-}  Any
ticket can be closed without action taken if that ultimately seems the right
approach.

[comment #22 comment #22:]
> If vintage afm files are not forthcoming, then (2 - makefile
> target) is moot.

Perhaps, or perhaps it's worth implementing anyway so as to be ready if the
files ever materialize.  Either way, that discussion has little to do with
this ticket's focus (the ZD characters).

> But this already has its own bug #65659 which is assigned to
> me and I'm doing font research.

(This presumably means bug #65619, as 65659 is for another project.)

Bug #65619 seems to cover different ground than bug #65697.  Neither one seems
dependent on the other to me, though if I'm wrong, savannah now allows showing
bug dependencies.


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #65702 (group groff):

  Status:None => Need Info  

___

Follow-up Comment #1:

This situation dates back to primordial groff.

The current .cp line was introduced in the 2001 rewrite of doc.tmac in
[http://git.savannah.gnu.org/cgit/groff.git/commit/?id=058f72af8 commit
058f72af8].  That rewritten version did not save/restore the previous mode,
and no one seems to have added such logic subsequently.

The pre-2001 doc.tmac file was imported (from a Berkeley version) in 1992 in
groff 1.05 ([http://git.savannah.gnu.org/cgit/groff.git/commit/?id=a48ab7b6d
commit a48ab7b6d]), when it lived at macros/tmac.doc.  This version of the
file also blindly did a ".cp 0" without saving or restoring the previous mode
(presumably a James Clark customization of the Berkeley file).

So it seems intentional, or at least hasn't caused any reported misbehavior in
over 30 years.  Do you see any properly formed mdoc document misbehaving
because of the hard-coded mode?

[comment #0 original submission:]
> previous state of compatibility (register '.cp') is not restored 

The request to change the mode is ".cp".  The corresponding register is ".C".


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #21, bug #63018 (group groff):

True for the third ticket of that trio, but the first two can be implemented
regardless of the fate of the old AFM files.

As for the third, it documents a different issue from this ticket and should
have its own venue, so that when this ticket is closed, side conversations
about development goals aren't forgotten.  If a fix proves not doable --
whether because the original AFM files are lost in the mists of time, or for
any other reason -- that ticket can document the reason(s).


___

Reply to this item at:

  

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

[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

[Dave]

Follow-up Comment #15, bug #57506 (group groff):

[comment #2 comment #2:]
> It seems to me that these files should be regenerated, if not
> on every build, then at least for every release.

Now bug #65699.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #19, bug #63018 (group groff):

[comment #13 comment #13:]
> In fact I see two issues springing thence.  So, to summarize.
> 
> 1.  Make comment headers of font description files we generate
> with tools more informative.

Now bug #65697.

> 2.  Add "maintainer-font-descriptions" _make_(1) targets for
> _afmtodit_ and maybe _hpdftodit_ and _tfmtodit_.

Now bug #65698.

> 3.  Update the procedure documented in "FOR-RELEASE" to include
> the effects of item 2 above.

Now bug #65699, depending on the previous one.


___

Reply to this item at:

  

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

[bug #65699] Update the procedure documented in "FOR-RELEASE"

[Dave]

Update of bug #65699 (group groff):

  Depends on: => bugs #65698


___

Reply to this item at:

  

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

[bug #65699] Update the procedure documented in "FOR-RELEASE"

[Dave]

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

 Summary: Update the procedure documented in "FOR-RELEASE"
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:18:05 AM CDT
Category: Utilities
Severity: 1 - Wish
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 11:18:05 AM CDT By: Dave 
Branden wrote in bug #63018:

Update the procedure documented in "FOR-RELEASE" to include the effects of
[bug #65698, which proposes to add new make(1) targets for *todit utilities].







___

Reply to this item at:

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

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

[bug #65698] Add "maintainer-font-descriptions" make(1) targets for *todit utilities

[Dave]

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

 Summary: Add "maintainer-font-descriptions" make(1) targets
for *todit utilities
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:12:29 AM CDT
Category: Utilities
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 11:12:29 AM CDT By: Dave 
Branden wrote in bug #63018:

Add "maintainer-font-descriptions" _make_(1) targets for _afmtodit_ and maybe
_hpdftodit_ and _tfmtodit_.  (This might depend on what source material we
already have in the tree.  If such material is missing (or so stale we should
toss it out), we might need to document further maintainer-mode build
dependencies in "INSTALL.REPO".)







___

Reply to this item at:

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

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

[bug #65697] Add info to comment headers of font description files groff tools generate

[Dave]

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

 Summary: Add info to comment headers of font description
files groff tools generate
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 11:03:53 AM CDT
Category: Utilities
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 11:03:53 AM CDT By: Dave 
As mentioned in bug #63018, afmtodit's generated headers could additionally
include the names of the source files that generate them, and the
presence/values of command-line options that affect the generated contents.

Branden also notes there, "Could affect _afmtodit_, _hpftodit_, _tfmtodit_,
_addftinfo_, and _xtotroff_."







___

Reply to this item at:

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

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

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

[Dave]

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

[comment #7 comment #7:]
> if the above is in fact the case, one of us should open a new bug report.

Bug #65693


___

Reply to this item at:

  

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

[bug #65693] exceptions to NBSP statement in groff_char(7) should be documented

[Dave]

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

 Summary: exceptions to NBSP statement in groff_char(7) should
be documented
   Group: GNU roff
   Submitter: barx
   Submitted: Mon 06 May 2024 02:06:11 AM CDT
Category: Core
Severity: 2 - Minor
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 06 May 2024 02:06:11 AM CDT By: Dave 
groff_char(7) states, "a no-break space... is mapped to \~, the adjustable
non-breaking space escape sequence."

But as Deri and Bjarni point out in bug #62300, some fonts (including many URW
fonts groff installs for devpdf) include a u00A0 glyph, which is necessarily
of a fixed width.

Demonstration (when using -Tpdf):

.ft U-TR
a b c
.brp
a b\~c
.brp
a b\[u00A0]c
.brp

The results are the same if "\[u00A0]" is replaced with the corresponding
Latin-1 character.







___

Reply to this item at:

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

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

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

[Dave]

Follow-up Comment #11, bug #59442 (group groff):

It sounds like a decision is needed on which is the cart and which the horse. 
Should this bug take priority -- as comment #1 points out, "The whole point of
soelim is to get preprocessors to run on `.so`ed files" -- and then bug #65108
has to figure out how to work within that framework?  Or should filename
handling take priority, and then this bug needs to figure out how to implement
the comment #1 precept within that new framework?


___

Reply to this item at:

  

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

[bug #64155] [troff] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #37, bug #64155 (group groff):

[comment #34 comment #34:]
> Maybe it is time for a proper string equality operator in our
> conditional expressions.

While that would be a useful addition to the language, equivalent
functionality can be achieved in user space, in a way back compatible to
almost any older troff.

.de string_compare
.  ft TR
.  ie '\\$1'\\$2' .nr strings_equal 1
.  el .nr strings_equal 0
.  ft P
..
.
.ft ZD
.
.if 'foo'foo' .tm foo = foo, via output comparison operator
.if 'foo'bar' .tm foo = bar, via output comparison operator
.
.string_compare foo foo
.if \n[strings_equal] .tm foo = foo, via string_compare macro
.string_compare foo bar
.if \n[strings_equal] .tm foo = bar, via string_compare macro




___

Reply to this item at:

  

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

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

[Dave]

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

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

This is now covered by bug #62826.


___

Reply to this item at:

  

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

[bug #62826] [tmac] clearly comment bug #44714 workaround in andoc.tmac

[Dave]

Update of bug #62826 (group groff):

Severity:  3 - Normal => 2 - Minor  
  Status:   Need Info => None   
 Summary: [PATCH] [tmac] options "-mandoc" and '-C' are not
compatible => [tmac] clearly comment bug #44714 workaround in andoc.tmac

___

Follow-up Comment #6:

Thanks for the clarification, Bjarni.

Since the patch is not relevant to anyone running groff tools as distributed,
I'm removing the "[PATCH]" indicator.

The one thing this patch does that IMO is worth keeping is commenting the two
empty lines that implement the bug #44714 workaround, especially as that bug
report predicts it will be challenging to fix, suggesting the workaround will
be in place quite a while.  And as I posted over there, the andoc.tmac comment
near the top should cite bug #44714 rather than vaguely referring to "a bug in
GNU troff."  (Or if the two empty lines themselves are given sufficiently
detailed comments, this leading comment may not be needed anymore.)

So I'm altering this bug's Summary to reflect this reduced scope.

[comment #5 comment #5:]
>   The test for such a change is
> 
> test-nroff -mandoc -ww -z -t -C tmac/groff_mdoc.7

As Branden noted in the email thread linked in comment #1, test-nroff is your
own script, not groff's.  (See bug #55941.)


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #16, bug #63018 (group groff):

[comment #14 comment #14:]
> I'm quite happy to put something in the header like "unicode
> names added by Deri 2024", but I certainly would not suggest
> removing the afmtodit header which documents the version used,

I agree, all metadata concerning the data's origins should be preserved, and
documenting not just that the file was subsequently hand-edited, but
specifically which part, is useful.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #12, bug #63018 (group groff):

[comment #11 comment #11:]
> It might help if we said so in the comment.  We could
> furthermore include in that comment the presence/values of
> command-line options that affect the generated contents.

If you're talking about modifying afmtodit to include that information in its
output, that seems like a good idea but well outside this ticket's scope.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Follow-up Comment #10, bug #63018 (group groff):

[comment #9 comment #9:]
> I understood Deri as proposing to update "dingbats.map" _and_
> regenerating the ZD file using _afmtodit_ with it...

Ah.  I did not grasp that the latter was generated from the former.  But that
makes a lot more sense DRYly.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #31, bug #64155 (group groff):

[comment #27 comment #27:]
> it would be good to know if/how Dave's original report in
> comment #0 was invalid.

I'm fine with -fZD failing on the grounds that groff doesn't consider ZD a
family, but the failure mechanism should be cleaner.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

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

To clarify: my objection isn't the stale afmtodit version (I doubt refreshing
the file will change the data), but that the line claims afmtodit generated it
at all: once Deri's ZD is committed, precious little of its content will be
from afmtodit.


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #65619 (group groff):

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

___

Follow-up Comment #4:

Reopening since comment #3 raises an objection to -w's current behavior and
suggests a "useful change to afmtodit," which based on comment #1 would solve
the problem Alex is seeing.

It's not clear (to me), though, how the below case should be handled, or if
this is the proper use case for -w:

[comment #1 comment #1:]
> Other CJK fonts have proportional western glyphs and fixed width
> CJK, with no space glyph defined, this is when afmtodit fails to
> write a spacewidth parameter. See font TakaoPGothic as an example).


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Dave]

Update of bug #63018 (group groff):

 Summary: font/devps/ZD: make glyphs accessible via their
Unicode spellings => [PATCH] make glyphs in ZD font accessible via their
Unicode spellings

___

Follow-up Comment #6:

Thanks, Deri!  I hadn't known about font/devps/generate/dingbats.map -- that
should definitely be covered as well.

The attached "ZD" and "dingbats.map" being drop-in replacements for the
existing files, I'm notating this bug as containing a patch.

Comparing your and Dorai's ZD files shows them to be substantively the same,
with yours including the two lines proposed by comment #3:

$ diff <(sed '1,/^charset$/d' ZD.deri | cut -f1-5) <(sed '1,/^charset$/d'
ZD.dorai)
13d12
< u261E "
22d20
< u2713 "

The nonsubstantive difference (elided by the "cut" command above) is the
presence of the comment fields.  Personally I'd rather see the comment
indicator ("--") omitted on lines with no comment content, but that's a style
preference.  That change could be made via

sed 's/\t--$//' ZD

The introductory comment line should probably also be amended, since it
currently says "This file has been generated with GNU afmtodit (groff) version
1.20.1" and that's no longer true for 99% of the file's content.


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #62826 (group groff):

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

___

Follow-up Comment #4:

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


___

Reply to this item at:

  

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

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

[Dave]

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

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

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

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

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


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #65077 (group groff):

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

___

Follow-up Comment #3:

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


___

Reply to this item at:

  

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

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

[Dave]

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

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

This is bug #44714.

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

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


___

Reply to this item at:

  

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

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

[Dave]

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

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

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

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

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

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


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

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

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

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

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


___

Reply to this item at:

  

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

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

[Dave]

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

Bjarni is talking about input, not output.  But the example is still slightly
confusing, because 0xA0 appears to refer to the Latin-1 character NO-BREAK
SPACE (Unicode U+00A0)--but there is no reason to run preconv if the file is
in Latin-1 encoding, as groff can read this directly.

Nonetheless, his point remains: many common Unix tools display the characters
U+0020 and U+00A0 indistinguishably.

But there is no reason for preconv to warn about this.  The same issue exists
no matter what Unix tool processes input containing both characters.  Users
may choose to avoid U+00A0 in their input files for this reason, or they may
use other strategies to deal with it.  It is not preconv's job to police this
usage.  Users who desire such warnings can write a simple preprocessor (using
grep or sed, perhaps) to emit them.

Once you start down the rabbit hole of "warn the user about characters that
are hard to visually tell apart," where do you stop?  In the monospace fonts
used in most terminals, you'd be hard-pressed to distinguish U+2012 FIGURE
DASH from U+2013 EN DASH.  Unicode has a plethora of space-like and dash-like
characters.  Should preconv warn about all of these?  That seems absurd.


___

Reply to this item at:

  

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

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

[Dave]

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

[comment #6 comment #6:]
> the font defines operators for the glyph, which results in a
> space of a certain width.

This is a fixed width?  If so, such fonts provide an undocumented exception to
this statement in groff_char(7): "a no-break space... is mapped to \~, the
adjustable non-breaking space escape sequence."

This ticket being closed, if the above is in fact the case, one of us should
open a new bug report.


___

Reply to this item at:

  

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

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Dave]

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

[comment #0 original submission:]
> defining aliases (probably in tmac/ps.tmac) for \[OK] and \[rh] so
> that they can also be represented respectively by \[u2713] \[u261E]

On further thought, because these aliases should apply to both the ps and pdf
devices, they shouldn't be in a file that only the ps device reads.

Luckily, the font description file itself includes a mechanism to define
aliases for the same glyph.  From the info manual:

   A line in the 'charset' section can also have the form

 NAME "

identifying NAME as another name for the glyph mentioned in the preceding
line.

(On first blush, it may seem that defining this alias in font/devps/ZD still
only applies to the ps device.  However, font/devpdf is populated from
font/devps, so aliases in the devps font description file propagate to the
devpdf one.)


___

Reply to this item at:

  

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

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

[Dave]

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

[comment #2 comment #2:]
> The input sequence '\[u00A0]' is _syntactically_ valid...but
> like '\[u]' and '\[u]', it's not _meaningful_

Dear future me: next time you run across this comment and think "I responded
to this somewhere" but can't remember where: it's in comment 13 of bug #58930.


___

Reply to this item at:

  

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

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

[Dave]

Follow-up Comment #10, bug #59442 (group groff):

Sorry, I did read comment #5 before posting but missed the implication of its
effect on the soelim proposal.


___

Reply to this item at:

  

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

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

[Dave]

Update of bug #59442 (group groff):

  Status:   Need Info => None   

___

Follow-up Comment #7:

This was made "Need Info" when Branden asked "Can anyone else think of any
objections?"  As none have arisen in over three years, I'm resetting the
status.

With no theoretical problems on the table, perhaps the best way to shake out
any actual problems is to go ahead and make the change, giving any unforeseen
issues ample opportunity to raise their ugly heads in testing from developers
now, and from a wider audience later when groff goes into rc mode.


___

Reply to this item at:

  

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

Re: Problems building the unifont PFA and DIT files for the PDF book

[Dave Kemper]

On Sat, Apr 20, 2024 at 5:21 PM Alejandro Colomar  wrote:
> >  It does occur
> > to me that we might enhance afmtodit make of use of it as the
> > default "spacewidth".
>
> That sounds like a great idea.

Would you be willing to open a savannah request for this feature?

https://savannah.gnu.org/bugs/?group=groff=additem

afmtodit falls under category "Utilities."

[bug #63028] document nroff \o limitations in modern terminal emulators

[Dave]

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

[comment #0 original submission:]
> they should think about the order in which they specify the
> characters, as only the last one is likely to end up visible.

An exception is (at least some) space-like characters.

$ echo "\o'abcd'efg" | nroff | cat -s
defg

$ echo "\o'abc\0'efg" | nroff | cat -s
cefg

$ echo "\o'abc\ 'efg" | nroff | cat -s
cefg


Groff and Heirloom's nroff produce identical results with those inputs.  Where
they diverge is when \o is given an ordinary space:

$ echo "\o'abc 'efg" | nroff | cat -s
troff::1: error: expected ordinary or special character, got a
space
cefg


Heirloom nroff's output is the same, but it doesn't throw the error.  If that
holds of ancestor nroffs as well, groff objecting to this formerly permitted
construction should be documented in groff_diff(7).


___

Reply to this item at:

  

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

[bug #63354] Refine fallbacks.tmac

[Dave]

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

[comment #36 comment #36:]
> I still see no way around the first,

Ha, because I'm _still_ overthinking it.  Groff offers a shorthand for
\h^\w'0'u^ -- and that is \0.  Thus the comment #36 suggestion reduces to:

.fchar \[u2012] \o'-\0'

This also eliminates the need for the conditional for nroff/troff output: this
fallback works in either environment.

(It seems like it shouldn't work in nroff with the overstruck characters
ordered as above: as bug #63028 readers are aware, it is the last character in
an overstruck sequence that nroff outputs.  But nroff seems to make an
exception for space characters:

$ echo "\o'abcd'efg" | nroff | cat -s
defg

$ echo "\o'abc\0'efg" | nroff | cat -s
cefg

$ echo "\o'abc\ 'efg" | nroff | cat -s
cefg


I'll add this to the list of things that #63028 should document.)


___

Reply to this item at:

  

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

[bug #65099] 1.24.0 release goals

[Dave]

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

I submit bug #63827 as something that should be addressed in some manner
before release, even if only in the form of a stopgap like resyncing groff's
pdfmark subtree with the substantially updated code upstream.


___

Reply to this item at:

  

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

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

[Dave]

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

[comment #0 original submission:]
>   See "https://lists/gnu.org/archive/html/groff/2024-01/msg00106.html;

This URL is malformed and should be
https://lists.gnu.org/archive/html/groff/2024-01/msg00106.html

(A followup, not linked from that URL, is at
http://lists.gnu.org/r/groff/2024-02/msg3.html)

However, it's not clear to me whether/how the reported deficiency in the
Fedora example files is related to the README.txt content, unless Bjarni is
assuming the Fedora packagers build their examples by copy/pasting commands
from README.txt rather than using the included makefiles, which as noted in
comment #1 were updated in 2022.  So this might be an unrelated issue, and one
in the Fedora package rather than in groff.


___

Reply to this item at:

  

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

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

[Dave]

Update of bug #65198 (group groff):

  Status: Invalid => None   
 Assigned to:gbranden => PTPi   
 Open/Closed:  Closed => Open   
 Summary: [bjarnigroff] mom/examples/*.txt: change '-k' to '-K
utf8' => mom/examples/*.txt: change '-k' to '-K utf8'

___

Follow-up Comment #4:

Comment #3 appears to misunderstand the point of comment #2: this ticket
doesn't concern
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/mom.am
contrib/mom/mom.am] itself, but merely uses that file's build options as a
template for what ought to appear in
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/README.txt
contrib/mom/examples/README.txt] (and its
[http://git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/README-fr.txt
README-fr.txt] counterpart).  That is, it's suggesting changes akin to:

diff --git a/contrib/mom/examples/README.txt
b/contrib/mom/examples/README.txt
index 851a9a27a..34e06153c 100644
--- a/contrib/mom/examples/README.txt
+++ b/contrib/mom/examples/README.txt
@@ -21,9 +21,9 @@ files with pdfmom(1).
 pdfmom mom-pdf.mom > mom-pdf.pdf
 pdfmom sample_docs.mom > sample_docs.pdf
 pdfmom slide-demo.mom > slide-demo.pdf
-pdfmom -k letter.mom > letter.pdf
-pdfmom -k mon_premier_doc.mom > mon_premier_doc.pdf
-pdfmom -k typesetting.mom > typesetting.pdf
+pdfmom -K utf8 letter.mom > letter.pdf
+pdfmom -K utf8 mon_premier_doc.mom > mon_premier_doc.pdf
+pdfmom -K utf8 typesetting.mom > typesetting.pdf
 
 The files themselves
 
@@ -78,8 +78,8 @@ all PDF readers.
 
 The file, mon_premier_doc.mom, is a simple example in French showing
 the use of common elements: section headings, paragraphs, lists, table
-of contents and clickable links.  It should be generated with option -k
-as there are some accented letters.
+of contents and clickable links.  It should be generated with option
+"-K utf8" as there are some accented letters.
 
 A few settings were also changed for this French document:
 ATTRIBUTE_STRING is used to replace "by" by "par" in the document

To my eyes, this appears to be a legitimate refinement, as -K is more reliable
than -k for known encodings.  But Peter is in charge of the content of these
files, so I'm reassigning this to him so he can make that call.


___

Reply to this item at:

  

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