Ingo Schwarze wrote:
> Hi Yuri, Mateusz, Benjamin,
> 
> Yuri Pankov wrote on Fri, Nov 23, 2018 at 11:35:41PM +0300:
> 
>> Reported by Mateusz Piotrowski in
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232779:
>>
>> A simple
> 
> This is very far from simple.  ;-)
> 
>> rendering issue -- two spaces are displayed after a period and
>> closing bracket,
> 
> Brackets would behave differently in this respect - we are talking
> about a closing parenthesis here.

Indeed, sorry.

>> *and* there's a new line, i.e. `printf "foo.)\nbar" |
>> mandoc` displays "foo.)  bar".
> 
> Yes, that is a feature.

Thanks for the detailed (as always) answer.

> Mandoc does some heuristics to guess where sentences end, and so
> does groff, traditionally, even though the behaviour of both is not
> completely identical.  When these programs detect the (likely) end
> of a sentence, they insert a double space into the output,
> conforming to traditional typewriter conventions, even though
> this is no longer common practice in proportional-font typesetting.
> But i do think the double space after the end of a sentence still
> makes reading text in monospace fonts easier.
> 
> The basic idea is to assume the end of a sentence when a full stop,
> an exclamation mark, or a question mark appears at the end of an
> input line.  If that character is preceded by an alphanumeric
> character (assumed to be the end of a word), it is even assumed
> to be the end of a sentence when followed by one or more closing
> delimiters.  They said, "Like in this case."
> 
> There are many subtleties, in particular when macros are involved.
> 
> That said, in your minimal example "foo.)\nbar", the double space
> is unambigously correct.
> 
> The case reported by Mateusz, "port...)\ncan be used" is slightly
> less clear.  Then again, an ellipsis often marks the end of a
> sentence, like in this case...  So mandoc treats it just like the
> full stop when it appears at the end of an input line.
> 
> 
> Benjamin Kaduk wrote:
> 
>> The rendering changes if you put a space before the ellipsis, FWIW.
> 
> Yes, in that case, mandoc no longer feels sure whether this is a
> sentence, because in English text, the punctuation marking the end
> end of a sentence is supposed to follow the last word without
> intervening whitespace.
> 
>> Escaping the '.'s with backslashes also works.
> 
> Do *NOT* do that, if "\." appears in a manual page, that is almost
> always wrong and rarely has the effect intended by the author.
> 
> If you need to escape a delimiter (including a dot) such that it
> is not treated as a delimiter, put a zero-width space "\&" next
> to it - conventionally, it is put before the dot in trailing
> macro arguments (e.g. .Sq \&.) and after the dot to prevent end
> of sentence detection (e.g. e.g.\&), but either order works.
> For details, see
> 
>   https://man.openbsd.org/mdoc.7#Delimiters
>   https://man.openbsd.org/roff.7#Sentence_Spacing
> 
> So if you really want to prevent end of sentence detection here,
> you would say
> 
>   Any netmap port type (physical interface,
>   VALE switch, pipe, monitor port...\&)
>   can be used.
> 
> While i admit there are some weird cases and some groff-mandoc
> differences in this area, i don't see anything to fix in the specific
> case you report.  Also, groff and mandoc behave identically for
> this input file:
> 
> .Dd November 23, 2018
> .Dt TEST 1
> .Os
> .Sh NAME
> .Nm test
> .Nd test
> .Sh DESCRIPTION
> Any netmap port type (physical interface, VALE switch, pipe, monitor port...)
> can be used.
> 
> Both emit the double space.
> 
> Yours,
>   Ingo
>