"G. Branden Robinson" <g.branden.robin...@gmail.com> writes:
> I observe the following in "lib/Pod/Man.pm".
> .\" Escape single quotes in literal strings from groff's Unicode transform.
> .ie \n(.g .ds Aq \(aq
> .el .ds Aq '
> Do you think it would be worthwhile to do the following as well?
> .ie \n(.g .ds Dq \(dq
> .el .ds Dq ""\" two double quotes because `ds` strips the first
> I don't understand the patterns where you're replacing ` and ' in POD
> input to make them `\*(Aq` in *roff output well enough to make a literal
> suggestion for `\*(Dq` here, unfortunately.
I went back and reviewed more of the thread. I'm not entirely sure that I
understand the context correctly, but it sounds like you're proposing
removing " from the list of characters that are skipped over when
determining if a period (and related characters) indicate the end of a
sentence for the purposes of applying intersentence spacing.
I don't really understand how that is a solution to the problem that the
thread started with, which was that \[dq] was not skipped over for this
determination. Maybe it's not, and it was an unrelated thing that you
noticed while looking at the issues raised in that message?
The position I have taken in Pod::Man is that people writing pure ASCII
POD should use " for quotation marks (not `` or '' or anything else). That
character is then copied directly to the output (with escaping as
necessary for macro arguments). At present, this produces reasonable
behavior with groff. Earlier versions of Pod::Man attempted to do other
things to enable typographic paired quotes, and those efforts were a
fragile maintenance disaster with all sorts of failing edge cases. All of
that code was removed in 5.00 and v6.0.0.
(This is basically the same problem as the much-discussed problem with
hyphen-minus.)
If people writing POD want proper typographic quotes (and I do understand
the desire for that), then my position is that they should use:
=encoding utf-8
and then use “Unicode quotes” in the input POD. This allows the author to
unambiguously indicate their intent, rather than relying on software
making often-erroneous guesses that may misinterpret " quotes in, for
example, code samples.
For better or for ill, the definition of POD never said that people should
use `` and '' (or anything else other than ") as quote characters, unlike
*roff and TeX, and therefore the vast majority of existing POD documents
do not. There is no reliable way to tell from the POD source what the
intent of a given " character is, so the only supportable treatment (IMO)
is to handle it as a neutral double quote.
> But I think substituting `"` with `\*(Dq` would produce better results
> in most cases--I'll cover a (possibly notional) exception below--and be
> backward compatible to groff 1.23 and earlier, and correct regardless of
> whether groff 1.24 makes the `cflags` change to the `"` character, for
> man pages only, as proposed in this thread.
I think you are making an assumption that " in *roff input is mostly only
used for code. This is probably true for the universe of documents written
directly in *roff, since that has (always?) been part of the *roff
language, but it's false for the universe of *roff generated from POD,
where " is used for nearly all English double quotation marks. I believe
making this change is quite likely to result in inconsistent sentence
spacing for lots of existing *roff output.
This obviously would not be the end of the world, nor would it be a new
problem given that use of double spaces after periods in input text is now
largely no longer used. (Indeed, I switched to a single space after
periods in emails a year or so ago as an exercise in practicing my own
mental plasticity after noticing that few people younger than I use or
expected that spacing.) Pod::Man says the following about the general
problem:
CAVEATS
Sentence spacing
Pod::Man copies the input spacing verbatim to the output *roff document.
This means your output will be affected by how nroff generally handles
sentence spacing.
nroff dates from an era in which it was standard to use two spaces after
sentences, and will always add two spaces after a line-ending period (or
similar punctuation) when reflowing text. For example, the following
input:
=pod
One sentence.
Another sentence.
will result in two spaces after the period when the text is reflowed. If
you use two spaces after sentences anyway, this will be consistent,
although you will have to be careful to not end a line with an
abbreviation such as "e.g." or "Ms.". Output will also be consistent if
you use the *roff style guide (and XKCD 1285 <https://xkcd.com/1285/>)
recommendation of putting a line break after each sentence, although
that will consistently produce two spaces after each sentence, which may
not be what you want.
If you prefer one space after sentences (which is the more modern
style), you will unfortunately need to ensure that no line in the middle
of a paragraph ends in a period or similar sentence-ending paragraph.
Otherwise, nroff will add a two spaces after that sentence when
reflowing, and your output document will have inconsistent spacing.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
