* two spaces after a period, closing bracket, and a newline @ 2018-11-23 20:35 Yuri Pankov 2018-11-23 22:42 ` Ingo Schwarze 0 siblings, 1 reply; 3+ messages in thread From: Yuri Pankov @ 2018-11-23 20:35 UTC (permalink / raw) To: mandoc-discuss [-- Attachment #1.1: Type: text/plain, Size: 275 bytes --] Reported by Mateusz Piotrowski in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232779: A simple rendering issue -- two spaces are displayed after a period and closing bracket, *and* there's a new line, i.e. `printf "foo.)\nbar" | mandoc` displays "foo.) bar". [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: two spaces after a period, closing bracket, and a newline 2018-11-23 20:35 two spaces after a period, closing bracket, and a newline Yuri Pankov @ 2018-11-23 22:42 ` Ingo Schwarze 2018-11-24 16:00 ` Yuri Pankov 0 siblings, 1 reply; 3+ messages in thread From: Ingo Schwarze @ 2018-11-23 22:42 UTC (permalink / raw) To: Yuri Pankov; +Cc: mandoc-discuss, Mateusz Piotrowski, Benjamin Kaduk 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. > *and* there's a new line, i.e. `printf "foo.)\nbar" | > mandoc` displays "foo.) bar". Yes, that is a feature. 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 -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: two spaces after a period, closing bracket, and a newline 2018-11-23 22:42 ` Ingo Schwarze @ 2018-11-24 16:00 ` Yuri Pankov 0 siblings, 0 replies; 3+ messages in thread From: Yuri Pankov @ 2018-11-24 16:00 UTC (permalink / raw) To: Ingo Schwarze; +Cc: mandoc-discuss, Mateusz Piotrowski, Benjamin Kaduk [-- Attachment #1.1: Type: text/plain, Size: 3731 bytes --] 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 > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-11-24 16:00 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-23 20:35 two spaces after a period, closing bracket, and a newline Yuri Pankov 2018-11-23 22:42 ` Ingo Schwarze 2018-11-24 16:00 ` Yuri Pankov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).