.sp 1 in strerror.3 (and probably more pages)

.sp 1 in strerror.3 (and probably more pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 522 bytes --]

Hi Branden,

While trying to apply a patch that touches some table, I found an '.sp 1'
after a table.

I tried removing it to see what it does, but it seems nothing changed.

However, in the PDF version, there's some change (using .sp 1 produces
a larger space before the next section heading).

Should we keep that thing, should we replace it by something else, or
should we remove it?

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .sp 1 in strerror.3 (and probably more pages)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

Hi Alex,

At 2023-08-13T17:19:59+0200, Alejandro Colomar wrote:
> While trying to apply a patch that touches some table, I found an '.sp
> 1' after a table.
> 
> I tried removing it to see what it does, but it seems nothing changed.
> 
> However, in the PDF version, there's some change (using .sp 1 produces
> a larger space before the next section heading).
> 
> Should we keep that thing, should we replace it by something else, or
> should we remove it?

I would take it out.  If you need vertical space after a table, use a
paragraphing macro.

The reason for the difference is this.

groff_man(7):

   Horizontal and vertical spacing
[...]
     Several macros insert vertical space: .SH, .SS, .TP, .P (and its
     synonyms), .IP, and the deprecated .HP.  The default inter‐section
     and inter‐paragraph spacing is is 1v for terminal devices and 0.4v
     for typesetting devices.  (The deprecated macro .PD can change this
     vertical spacing, but its use is discouraged.)  Between .EX and .EE
     calls, the inter‐paragraph spacing is 1v regardless of output
     device.

Does this help?

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .sp 1 in strerror.3 (and probably more pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1843 bytes --]

Hi Branden,

On 2023-08-13 17:28, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2023-08-13T17:19:59+0200, Alejandro Colomar wrote:
>> While trying to apply a patch that touches some table, I found an '.sp
>> 1' after a table.
>>
>> I tried removing it to see what it does, but it seems nothing changed.
>>
>> However, in the PDF version, there's some change (using .sp 1 produces
>> a larger space before the next section heading).
>>
>> Should we keep that thing, should we replace it by something else, or
>> should we remove it?
> 
> I would take it out.

Okay.  But I'd like to understand why Michael used it.  Since we already
have a blank without it, why would have he added it?  Or did 1.22.4 have
a bug that didn't produce that blank?

Here's what Michael's commit says:

    # ".sp 1" ==> ensure a blank line before the next section heading

(c466875ecd64 ("Various pages: Improve formatting in ATTRIBUTES"))

>  If you need vertical space after a table, use a
> paragraphing macro.
> 
> The reason for the difference is this.
> 
> groff_man(7):
> 
>    Horizontal and vertical spacing
> [...]
>      Several macros insert vertical space: .SH, .SS, .TP, .P (and its
>      synonyms), .IP, and the deprecated .HP.  The default inter‐section
>      and inter‐paragraph spacing is is 1v for terminal devices and 0.4v
>      for typesetting devices.  (The deprecated macro .PD can change this
>      vertical spacing, but its use is discouraged.)  Between .EX and .EE
>      calls, the inter‐paragraph spacing is 1v regardless of output
>      device.
> 
> Does this help?

Yep, it explains the difference, although it doesn't explain why Michael
added it.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .sp 1 in strerror.3 (and probably more pages)

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

Hi Alex,

At 2023-08-13T18:06:15+0200, Alejandro Colomar wrote:
> On 2023-08-13 17:28, G. Branden Robinson wrote:
> > At 2023-08-13T17:19:59+0200, Alejandro Colomar wrote:
> >> While trying to apply a patch that touches some table, I found an
> >> '.sp 1' after a table.
> >>
> >> I tried removing it to see what it does, but it seems nothing
> >> changed.
> >>
> >> However, in the PDF version, there's some change (using .sp 1
> >> produces a larger space before the next section heading).
> >>
> >> Should we keep that thing, should we replace it by something else,
> >> or should we remove it?
> > 
> > I would take it out.
> 
> Okay.  But I'd like to understand why Michael used it.  Since we already
> have a blank without it, why would have he added it?  Or did 1.22.4 have
> a bug that didn't produce that blank?
> 
> Here's what Michael's commit says:
> 
>     # ".sp 1" ==> ensure a blank line before the next section heading
> 
> (c466875ecd64 ("Various pages: Improve formatting in ATTRIBUTES"))

Thanks for the context; it helps.

> Yep, it explains the difference, although it doesn't explain why
> Michael added it.

Since the Linux man-pages "ATTRIBUTES" section uses a boxed table, I'm
betting it was working around Savannah #49390.

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

The overprinting was invisible if there was no text on the line after
the table, but it would _look_ like the omission of the space that
normally precedes a subsequent section heading.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .sp 1 in strerror.3 (and probably more pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]

Hi Branden,

On 2023-08-13 18:20, G. Branden Robinson wrote:
[...]

>> Here's what Michael's commit says:
>>
>>     # ".sp 1" ==> ensure a blank line before the next section heading
>>
>> (c466875ecd64 ("Various pages: Improve formatting in ATTRIBUTES"))
> 
> Thanks for the context; it helps.

I had a terminal where I had nicely prepared a lot of stuff to show you,
but it seems I completely forgot about it.  I had a lot more than that.  :/

> 
>> Yep, it explains the difference, although it doesn't explain why
>> Michael added it.
> 
> Since the Linux man-pages "ATTRIBUTES" section uses a boxed table, I'm
> betting it was working around Savannah #49390.
> 
> https://savannah.gnu.org/bugs/index.php?49390

Yeah, that's what I suspected.  I've killed them now.  The only pages with
call now are the tz ones and bpf-helpers.7 (generated from .rst, itself
generated from kernel headers).

Cheers,
Alex

> 
> The overprinting was invisible if there was no text on the line after
> the table, but it would _look_ like the omission of the space that
> normally precedes a subsequent section heading.
> 
> Regards,
> Branden

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]