RE: Rendering the em dash on the terminal

[Jeff Conrad]

> From: groff-bounces+jeff_conrad=msn.com@gnu.org <groff-
> bounces+jeff_conrad=msn.com@gnu.org> On Behalf Of Peter Schaffter
> Sent: Tuesday, 27 August, 2024 6:08 PM
> To: groff@gnu.org
> 
> When I read text at the terminal, I expect to see correctly
> formatted typewritten copy such as would have satisfied
> Mr. Stevenson, my typing teacher in 1970.

Well, I (sorta) learned typing a few years before that; I can’t
remember my teacher’s name, and were he still with us, he
certainly would not remember mine.  And I used a slide rule in
college, graduating just as the HP-35 was released (sigh).  I’ve
not had a yearning to use a slide rule or a typewriter (both of
which I still have).

> The introduction of Unicode characters like em-dashes, check
> marks, or even bullets draws attention to those characters,
> distracting from the text.  Monospaced copy is not intended to
> reproduce typeset copy; it is intended to convey typographic
> _intent_ unambiguously.

But doesn’t using what’s going to appear in the final copy convey
the intent even more unambiguously?  In addition to saving an
editor some work.  And how does one convey intent for non-ASCII
characters?  In the old days, this was done on paper by hand
drawing the characters or diddling ASCII characters with a
pencil.

This is the way it was done for decades because there wasn’t
really an alternative for most people.  But would we have chosen
this if today’s alternatives had been available?  And how many
people under 40 even know what a typewriter is?  It’s not even
easy to find examples of the traditional guidance unless one
knows where to look (one place is the Chicago Manual of Style,
which still includes an image of a hand-marked document; this is
the only place I can find in the manual that mentions the two-
hyphen convention for an em dash).  And since the 14th ed. (1993)
most of their manuscript examples have shown proportional fonts.

> Where dashes are concerned, the rules were/are:

>   - Em-dashes are represented by two hyphens with no space either
>     side--visually easy to understand.

Spacing (or lack thereof) seems more a matter of style than
device configuration.  In most North American publishing, em
dashes are unspaced, though newspapers usually space them.  BrE
(save——at least officially——OUP) usually prefers spaced en dashes
to em dashes, and it often prefers spaced en dashes——like what
you have below——in general, even in typeset copy.

>   - En-dashes are represented by a single hyphen surrounded by
>     spaces (e.g. 2 - 3 minutes).  In typeset copy, there should be
>     no space around the en-dash, however in typewritten copy, the
>     notion of "range" is oddly enhanced by the spaces around the
>     hyphen.  Again, I find this visually easy to grasp.

But many sources (e.g., Chicago) call for the hyphen to be closed
up in the manuscript.

>   - All dashes longer than one em are represented by four hyphens.
>     The expectation is that if the copy is to be typeset, the length
>     of the typeset dash will be determined by the style guide being
>     followed.  Whether the typeset copy uses Mr. P——— or Mr. P————,
>     Mr. P---- is perfectly clear.

Nice enough if one has an editor to do this.

>     Ditto the use of long dashes in bibliographies (which
>     probably shouldn't be in a terminal document?).

Depends on what a “terminal document” is; I’m guessing most of us
think “man page,” where I agree a long dash would be uncommon
(though I have it in a few of mine).

>   - All enumerators for lists (other than letters or digits) are
>     represented by a single hyphen followed by a space, q.v.
> 
> <opinion>
> Given the clarity and former prevalence of these conventions,
> I can't see any reason why documents intended for the terminal
> shouldn't observe them.
> </opinion>

I must confess I sometimes feel the same way, though I wonder
why.  But can’t a user who prefers it this way just use ‘Tascii’
rather than ‘Tutf8’?

Jeff Conrad

HandMarkedManuscriptCMOS18.pdf
Description: Adobe PDF document