Re: Doc: NR - Doc CSS colour support (issue 551270043 by address@hidden)

[lemzwerg]

> > There should always a comma after 'i.e.', as far as I know.

> Nope.  It's grammatical dogma (in the same vein as not
> starting sentences with the words 'And' or 'Because).
> I think commas after these abbreviations look ugly.

I'm not a native speaker, but I think exactly the opposite, given that
'i.e.' means 'that is' and 'e.g.' means 'for example'.

> > This is especially important for the PDFs since by default
> > `texinfo.tex` doesn't use frenchspacing, thus inserting a
> larger horizontal space after a full stop.

> So?  If it were that bad why are we using two spaces after
> a full point then?

I'm talking about the printed *output*.  Having two spaces in the
*input* files is a convention to better support editors like Emacs who
use those spaces to recognize sentence endings, allowing quick
sentence-wise navigation.

> Which has nothing to do with grammar and would mean this would have to
be made
> policy (which it isn't) and fixed throughout the entire doc.

By default, texinfo follows the convention of inserting more horizontal
space after a full stop in the printed output (both info and PDF).
Having this additional space looks extremely ugly if it is not the end
of a sentence (like in abbreviations 'e.g.' or 'i.e.').  We have three
possibilities to fix this.

(1) Insert a comma after such abbreviations.  This is what I would do,
and I already tried to handle that in a uniform way in a few previous
commits (at least for the NR).  BTW, you might check whether the
majority cases in the docs are either 'e.g.,' or 'e.g.'.
(2) Insert `@:` after a full stop that doesn't end a sentence.
(3) Insert the command `@frenchspacing on` in the preamble to disable
this American typography feature.

We *must* do one of the three solutions.  Otherwise we get really ugly
output in the info and PDF formats.

https://codereview.appspot.com/551270043/