groff
[Top][All Lists]
Advanced

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

RE: Rendering the em dash on the terminal


From: Jeff Conrad
Subject: RE: Rendering the em dash on the terminal
Date: Wed, 28 Aug 2024 15:42:52 -0700

> From: groff-bounces+jeff_conrad=msn.com@gnu.org <groff-
> bounces+jeff_conrad=msn.com@gnu.org> On Behalf Of Tadziu Hoffmann
> Sent: Wednesday, 28 August, 2024 9:59 AM
> To: groff@gnu.org

Regionalism
===========
> I suspect conventions might be strongly regionally
> dependent.

For sure.  And political.  And personal.  And confrontational.
Some years ago, English Wikipedia had a _two-month_ discussion on
using the en dash; in the end, a couple of folks with an agenda
managed to persuade the participants--most of whom would not
previously have recognized an en dash had it bitten them--to do
it their way.  My only regret is that I was foolish enough to
participate, when I could have done something useful like
organizing my sock drawer.

> > - Em-dashes are represented by two hyphens with no space
> >   either side--visually easy to understand.
> >
> > - En-dashes are represented by a single hyphen
> >   surrounded by spaces (e.g. 2 - 3 minutes).
> 
> I believe this should be reversed -- 2 hyphens with spaces
> for an em-dash, and 2 hyphens without spaces for an en-dash
> (e.g., 2--3 minutes).  This not only follows typeset conventions
> more closely, but it also indicates the intent to the typesetter
> much better.

All depends on your region ... and sometimes more.  New Hart's
Rules--which admits that OUP may be an outlier in BrE--calls for
closed-up em and en dashes (but calls them "rules").

> In addition, it corresponds to European practice,
> where it is customary to use an en-dash surrounded by spaces
> instead of the em-dash without spaces used in the US.

The EC style indeed calls for this.

TeX
===
> TeX's convention is also good and unambiguous, and I've
> seen that being used in documentation as well:
>   * one hyphen for hyphen or minus (depending on context)
>   * two hyphens for an en-dash
>   * three hyphens for an em-dash

Hard to dispute the lack of ambiguity.  But few people outside
the TeX community would recognize.  And I always use "@minus{}"
in Texinfo because it properly aligns horizontally and vertically
with a plus.  Regrettably, I use an en dash for a minus on my
CP1252 device because Microsoft declined to include a true minus
(U+2212) in their "ANSI" character set.

Lists
=====
> > - All enumerators for lists (other than letters or digits) are
> >   represented by a single hyphen followed by a space
> 
> Anything nicely symmetric works well, and allows visually
> distinguishing between different list levels in addition
> to list indentation.  (In earlier times when documents
> such as manual pages were often printed on lineprinters
> capable of overstriking, I've seen o-plus used.)

With the nroff tables I had years ago, the plus was the last
character, so on a terminal we got

  +  Item

Not so good ... we changed the sequence when we could (when ASCII
nterm files replaced compiled term files) so that the 'o' was
last,

  o  Item

(better) and eventually just went with and asterisk, which seemed a
better approximation to a bullet.

  *  Item

YMMV ...

With typeset material, an em dash has seemed a bit long and an en
dash a bit short; a ¾-em dash (which I could swear one version of
troff had; we faked it) seemed just right.  But it doesn't seem
to officially exist.  When I have a choice, I usually use the
horizontal bar (U+2015).

Agree that it's important to visually distinguish list levels.
Major fail for MS Word and most CSS defaults.

To '--' or '--'
===============
But I'm not sure all of this has much to do with Dave's original
question: should 'Tutf8' use '--' or '--' for an em dash?  Though
I'm a bit of a traditionalist (or just old), I'm increasingly
leaning toward Branden's approach.  Seems to me that using
'Tascii' should work for those who prefer the more traditional
approach.




reply via email to

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