public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	bpf@vger.kernel.org, Jakub Wilk <jwilk@jwilk.net>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	linux-man@vger.kernel.org
Subject: Re: [PATCH bpf-next v3] bpf: Fix a few typos in BPF helpers documentation
Date: Fri, 26 Aug 2022 19:17:40 +0200	[thread overview]
Message-ID: <67989b1b-712a-6110-b0a4-7d855179e17c@gmail.com> (raw)
In-Reply-To: <c94959da-67f6-da66-1d46-ae9dfdc0e674@isovalent.com>


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

Hi Quentin,

On 8/26/22 11:44, Quentin Monnet wrote:
> On 25/08/2022 23:12, Alejandro Colomar wrote:
>> Hi Quentin,
>>
> 
>>> - *        ctx. Providing an *len_diff* adjustment that is larger than
>>> the
>>
>> I just noticed:  groff(1) uses double spaces after an end-of-sentence
>> period.  Otherwise, it is understood as something like initials, or an
>> abbreviature, and it causes some issues.  Please check the whole
>> document, as I've seen a mix of styles.
>>
>> Search for something like '.\. [^ ]'
> 
> This is a strange restriction in my opinion, but I can look into this as
> a follow-up. I've not noticed issues with the rendered page so far, out
> of curiosity what issues are we talking about?

It's not so visible, and I'm not a groff(1) expert, so maybe there are 
more issues than the ones I know, but I'll explain it as I understand it:

For groff's output, there are two kinds of spaces: interword and 
intersentence spaces.  Interword space is normally a single character in 
monospaced fonts.  Intersentence is also a single space by default in 
monospace fonts, but it is not substituting interword space, but rather 
adding to it, so effectively the intersentence separation is two spaces 
in a monospaced font.  That can be configured, and one can for example 
ask their intersentence space to be 2 chars, and therefore have an 
intersentence effective sepparation of 3 chars.

In PDF output, the difference may be also noticeable slightly differently.

I prepared a simple file that will show you how it can make sentences 
much more readable, even if the theoretical difference might not be 
noticeable at first glance to the untrained eye:

$ cat sp.man
.TH spaces 7 today experiments
.SH correct spacing
Hello world!  Today is Friday.  This are extra words to fill.
And even more words.
.SH incorrect spacing
Hello world! Today is Monday. This are extra words to fill. And even 
more words.
$ man -P cat ./sp.man
spaces(7)          Miscellaneous Information Manual          spaces(7)

correct spacing
        Hello  world!   Today is Friday.  This are extra words to fill.
        And even more words.

incorrect spacing
        Hello world! Today is Monday. This are extra words to fill. And
        even more words.

experiments                      today                       spaces(7)



Notice how the first one is much more nicely rendered.  I rendered it in 
a 72-col terminal because my mailer would wrap at that boundary anyway. 
You can render the file at 80 columns and see a different rendering, 
where it is even bigger the difference in favor of the correctly written 
one.


> 
> Also before that, it would be good to sync and see what other formatting
> elements need be addressed on the page, so we can fix them in a batch
> rather than submitting them one after the other like we're doing.

Sure!  It'll take some time from my side, but I'll try to come up with a 
list of issues in that page.

> 
> Quentin


Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

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

  reply	other threads:[~2022-08-26 17:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 22:08 [PATCH bpf-next v3] bpf: Fix a few typos in BPF helpers documentation Quentin Monnet
2022-08-25 22:12 ` Alejandro Colomar
2022-08-26  9:44   ` Quentin Monnet
2022-08-26 17:17     ` Alejandro Colomar [this message]
2022-08-27  5:20 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67989b1b-712a-6110-b0a4-7d855179e17c@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jwilk@jwilk.net \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=quentin@isovalent.com \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox