bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58500] default value for second parameter to .ss should follow mod


From: Dave
Subject: [bug #58500] default value for second parameter to .ss should follow modern typographic convention
Date: Sat, 5 Sep 2020 14:00:53 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #7, bug #58500 (project groff):

Topic of the day: Macro economics

The suggestion that we point users to a macro package (say, -modern_sentences)
to achieve typography that (absent evidence otherwise) has been the industry
standard for over 70 years, to me, misses the point of software defaults.

Defaults should not be arbitrary.  They should be carefully considered to be
the thing that it makes the most sense to do if the user doesn't explicitly
ask for something different.  And, as they'll be what gets used when the most
novice user of the system writes the most minimal source document and
processes it with the most unadorned command line, they should be the best
choice for the widest range of situations.

They very specifically should not require the novice user to notice the
section in the documentation stating "If you want post-1940 typographic
results, you must use the -modern_sentences flag."  The groff manual is
carefully designed to be nonlinear, so there's no place to put this guidance
"up front" where beginning users are certain to see it.  We don't even know if
beginning users will start with our documentation at all, rather than some web
tutorial or by modifying existing examples found in the wild.  Groff should do
the right thing in all these circumstances.

By analogy, consider a compiler for a new programming language you're
designing.  Users might complain if the canonically simplest program, "Hello
world," displayed that text in blinking red letters.  "But no," you say, "it
is so simple -- you merely give the compiler the -noblink flag, and the
message displays normally."  Something near 100% of your users will wonder why
they need to specify an additional flag to get the compiler to do the thing
they invariably want it to do.

Similarly, while groff can certainly document "You must use the
'odern_sentences' macro package to conform to the last 70 years of typographic
practice," why not just do that by default, and make the rare users who want
something else be the ones responsible for passing a, perhaps,
-historical_sentences flag?  (Except of course it needs to start with an m. 
-medieval_sentences?  -moldy_sentences?)

Groff's default of ".ss 12 12" is, by any sane metric, arbitrary.  It does not
follow historical typesetting practice of using 1/3 em as a word space and 1
em as a sentence space (that would be ".ss 16 32").  It does not follow TeX's
practice of using 1/4 em as a word space and 1/3 em as a sentence space (".ss
12 4").  It does not follow modern everywhere-but-TeX typesetting practice of
using 1/4 em as both word space and sentence space (".ss 12 0").  It instead
follows the example of its *roff predecessors, whose use of ".ss 12 12" (not
even expressible as such in historical implementation, where .ss took only one
parameter) looks to be the very definition of arbitrary, as it was not the
what professional typesetters did at the time of *roff's original writing nor
in the era of wider spacing before that.  *roff is truly out on its own in
this regard.

A macro-package setting would be the right answer were this a matter where AP
style differed from Chicago style differed from GPO style.  But it's pointless
to require a macro package for a setting that's the same across all modern
style guides.  Modern practice being in universal agreement tells us this
setting ought to be more universal than that.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58500>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]