[bug #64233] [troff] make requests' treatment of Boolean arguments more consistent

[G. Branden Robinson]

Update of bug #64233 (project groff):

  Item Group:None => Warning/Suspicious
behaviour


___

Reply to this item at:

  

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

[bug #64216] [eqn] "{thick, thin}_space" parameters affect full- and half-width spaces ~ and ^

[G. Branden Robinson]

Update of bug #64216 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #4:

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=c2acb948e8ddd0b656c4c39755174437e34da83d


___

Reply to this item at:

  

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

[bug #64209] [PATCH] [mm] ".LO SJ" doesn't put a blank line after a letter's subject

[G. Branden Robinson]

Update of bug #64209 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #2:

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=87128ac534aff1911636d98b2faf5559cc514f91


___

Reply to this item at:

  

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

[bug #64207] [PATCH] [mm] internal `pg@next-page` macro should invoke `br` before `ne`

[G. Branden Robinson]

Update of bug #64207 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #2:

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=6a2e3a59087c103524dd3410c3f148b506c11bbc


___

Reply to this item at:

  

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

[bug #64205] [mm] `INITI` validates arguments poorly

[G. Branden Robinson]

Update of bug #64205 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #2:

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=b2cc8e87917273158cad41329d71da9dbd50c9fa


___

Reply to this item at:

  

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

[bug #64104] [troff] you can set the escape, control, and no-break control characters to the same thing

[G. Branden Robinson]

Update of bug #64104 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #5:

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=e11d28855651a3a51541242aed1791ec2b4478b8
https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=02c16c96854b657c7df92eaddf2f9900c0e80a41


___

Reply to this item at:

  

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

[bug #64166] [troff] emboldening request `bd` is broken

[G. Branden Robinson]

Update of bug #64166 (project groff):

  Status: In Progress => Ready for Merge

___

Follow-up Comment #1:

To be explicit, this was a regression from groff 1.22.4.

Pushed to my private branch.

https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-05-22&id=2f64c66509b1a542311a7161ea23ac031c6b


___

Reply to this item at:

  

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

[bug #64232] stop assigning `*[a-ik-uw-z]` special characters to italic fonts

[Deri James]

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

I believe the behaviour changes in 1.23.0 (for pdf). If the lowercase Greek
characters are found in the current (text) font they are no longer forced to
italics, see commit d58625a25f2c1732b863d64a259d04a4e61c829d. This could be
further refined to apply only to font S, using .fschar but I could not get it
to work!


___

Reply to this item at:

  

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

[bug #64202] [man pages] groff_man(7) inconsistently (and redundantly) guards some .MR references with '\%'

[Keith Marshall]

Follow-up Comment #5, bug #64202 (project groff):

[comment #4 comment #4:]
> [comment #3 comment #3:]
> > [comment #1 comment #1:]
> > > Hi Keith,
> > > 
> > > I'm aware of this.  It's deliberate insofar as it's a consequence of
other decisions.
> > > 
> > > The main facts are these:
> > > 
> > > 1.  The new `MR` macro unconditionally prefixes its first argument with
a `\%` escape sequence to suppress hyphenation.
> > 
> > That's what I thought.  Consequently, there is _absolutely_ no need for
references, such as '.MR \%topic n', to _ever_ add that redundant '\%' prefix
to the topic name.
> 
> ...and there are no cases of it doing so in the groff tree,
Seriously?  Is your day job related to government, in some shape or form?  You
certainly seem to exhibit the politician's proclivity to spew verbiage, with
little. or no, bearing on the issue at hand.

> $ git grep 'MR.*\\%' || echo NONE
> NONE

A badly designed experiment, testing a bogus hypothesis, might be viewed as
disingenuous obfuscation ... perhaps not so in this case, but rather a
misunderstanding of the issue?  In reality, there _are_ 197 cases arising from
abuse of '.MR @g@...', and one further, from abuse of '.MR @PSPRINT@ ...'

$ hg grep '^\. *MR  *@g@' | wc -l
197

$ hg grep '^\. *MR  *@' | wc -l
198

$ hg grep '^\. *MR  *@[^g]'
src/roff/groff/groff.1.man:.MR @PSPRINT@ 1 .


> [...irrelevant verbiage snipped...]

> The purpose is not being subverted.
I guess we'll just have to agree to disagree, on that conclusion.
> You said yourself that the "seat" of this behavior is Makefile rules for
generating .[157] from .man.  It would be wrong to do so in
"makevarescape.sed", for instance, because '@g@' and friends get expanded in
contexts other than _roff_ sources.  Moreover, valid _roff_ input is indeed
being produced.
> 
> [...more verbiage snipped...]

> This is why I mentioned the following point in comment #1.
> 
> > You do not _need_ to sanitize content destined for device control escape
sequences (or the `device` request) of the `\%` escape sequence.  The
formatter will ignore this escape sequence in that context, skipping over it
without diagnostic, and it will not appear in the "x X" commands that GNU
troff produces.  This is already the case in groff 1.22.4 and therefore I
suspect it's been true for many years.

Well, it _does_ propagate through pdfmark output to grops.  Perhaps the
pdfmark macro _should_ sanitize its output, but that seems like a huge
overhead in tmac code ... every single byte of pdfmark throughput would need
to be inspected, just to weed out a miniscule few rogues.

> Are you wrapping or replacing the `MR` macro
Yes, and ...
> and "sanitizing" its first argument for some other purpose?
...no; it's a consequence of _not_ sanitizing the first argument, coupled with
your abuse of '@g@', (and maybe also of '@PSPRINT@'), in man page source, that
allows the unwanted '\%' to propagate.
> You said:
> 
> > (which, in its present state of development, does not incur any address
sanitizer overhead)
> 
> ...which I didn't completely understand, as ASAN doesn't seem relevant to
the present discussion of _roff_ macro processing.
> 
> Leaving in "Need Info" status, as I'm stuck; I don't agree with your
implication that repeated leading \% escape sequences in a word are invalid
_roff_ input,
I neither said, nor even remotely implied, any such thing.
> and I don't have enough insight into the implementation you're working on to
offer advice.  Maybe you could share some of its code.
I'll post it on OSDN, when I get it to a "commit-ready" state.  I do have it
working, quite nicely, now, but with my MR macro override "uglified" by the
need to filter out '\%' prefixes, from its first argument.


___

Reply to this item at:

  

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

[bug #64232] stop assigning `*[a-ik-uw-z]` special characters to italic fonts

[G. Branden Robinson]

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


[comment #1 comment #1:]
> I believe the behaviour changes in 1.23.0 (for pdf). If the lowercase Greek
characters are found in the current (text) font they are no longer forced to
italics, see commit d58625a25f2c1732b863d64a259d04a4e61c829d.

As they used to say, "if my calculations are correct," ...that commit will no
longer be necessary and should even be reverted.

The idea behind this ticket is to get parity of the slants of lowercase Greek
letters via another route.

>  This could be further refined to apply only to font S, using .fschar but I
could not get it to work!

Yes, I think that will bear looking into, for _eqn_'s benefit in particular. 
Maybe the request is broken and needs to be fixed.  Then this ticket can be
postponed too and we'll have a chain of three...


___

Reply to this item at:

  

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

[bug #64236] [eqn] "digit" type seems to have a bad name

[G. Branden Robinson]

URL:
  

 Summary: [eqn] "digit" type seems to have a bad name
   Group: GNU roff
   Submitter: gbranden
   Submitted: Mon 22 May 2023 01:56:49 PM UTC
Category: Preprocessor eqn
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 22 May 2023 01:56:49 PM UTC By: G. Branden Robinson 
>From my working copy:


+(The
+.RB \[lq] digit \[rq]
+type is not used by default,
+but is available for customization.)
+.\" XXX: How would you actually customize it, though?  There doesn't
+.\" seem to be a means of replacing the font associated with a type.
+.\" Is the "digit" type just cruft?


"digit" seems to really mean "non-letter".  Maybe "nonletter" would be a
better name.  See the only test of its value.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/text.cpp?h=1.23.0.rc4#n496








___

Reply to this item at:

  

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

[bug #60233] doc/groff.texi: ambiguity in .tkf documentation

[Dave]

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

[comment #3 comment #3:]
> the concept introduction accurately says, "'Track kerning'
> expands or reduces the space between glyphs."

This doesn't say how this space is distributed--nor should it, IMHO: see bug
#61828.


___

Reply to this item at:

  

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

[bug #64229] [troff] I haz a DoS attack

[G. Branden Robinson]

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

I'm impressed with how badly Heirloom handled that.


$ time { printf '.di foo\n.nf\n'; yes abcdefghijklm; } | ./bin/nroff
Killed

real1519m49.629s
user1518m54.699s
sys 0m40.179s




___

Reply to this item at:

  

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

[bug #64238] [docs] Simplify the explanations of "italic corrections"

[Bjarni Ingi Gislason]

URL:
  

 Summary: [docs] Simplify the explanations of "italic
corrections"
   Group: GNU roff
   Submitter: bjarniig
   Submitted: Tue 23 May 2023 12:28:35 AM 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: Tue 23 May 2023 12:28:35 AM UTC By: Bjarni Ingi Gislason 
Subject: [docs] Simplify the explanations of "italic corrections"

  I find the explanations of the "italic corrections" (escape sequences
'\/' and '\,') too complicated and not easy to remember.

  Suggestion:

  \/

  Used to adjust space between a slanting (italic, oblique, (symbol
)) glyph and an upright one (symbol <|>), or pictorially: \/<|>.
  Or to remember: the slanting line segments are alternating and
a slanting line segment is next to <|>.

  \,

  Used to adjust space between an upright glyph (symbol <|>) an a
slanting one (symbol , or pictorially: <|>\,.
  Or to remember: the slanting line segments are alternating and
a slanting line segment is next to <|>.








___

Reply to this item at:

  

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

[bug #64238] [docs] Simplify the explanations of "italic corrections"

[G. Branden Robinson]

Update of bug #64238 (project groff):

Severity:  3 - Normal => 1 - Wish   


___

Reply to this item at:

  

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