groff
[Top][All Lists]
Advanced

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

Re: Zero Width Space


From: Peter Schaffter
Subject: Re: Zero Width Space
Date: Mon, 6 Jun 2022 14:25:46 -0400
User-agent: Mutt/1.9.4 (2018-02-28)

Following this thread, I've been reminded of this classic.  An
old man speaks to his grandson:

 "When I was young, I looked across the lake and saw a mountain.
  As I grew up, I looked across the lake and saw so much more than
  a mountain.  Now I am old; when I look across the lake, I
  see a mountain."

I've carried the original cstr54 definition of \& in my head since
my first exposure to *roff: a non-printing, zero width character
(NPZWC).  I had never seen it defined as a "zero-width space" until
I had a look at my version of the info manual (1.22.4), where it
is defined as both a zero-width space ("Requests" section) and a
zero-width character ("Escapes" section).

I propose a radical solution to the problem of defining \&: return
to the cstr54 definition, which reliably applies to all scenarios
where \& is needed and, for users, provides an easily-grasped
conceptual framework to understand how and why it works.

*Preventing control character interpretation.
  \&.
Groff doesn't interpret the period as a control character because it
isn't the first character on the input line.

Any other character would accomplish the same thing (preventing
interpretation) but it would appear in the output.  NPZWC to the
rescue.  From the point of view of the user, it behaves identically
to a character except it prints nothing.

*Inhibiting inter-sentence spacing
  ...end.\&  Start...
Groff doesn't interpret the period as end-of-sentence punctuation
because there's a character between it and the following spaces.

Any other character would accomplish the same thing (preventing
interpretation of inter-sentence spacing) but it would appear in the
output.  NPZWC to the rescue.  From the point of view of the user,
it behaves identically to an intervening character except it prints
nothing.

*Inhibiting kerning
  T\&oronto
"T" and "o" are not kerned because there's an intervening character.

Any other character would accomplish the same thing (preventing the
kerning of T and o) but it would appear in the output.  NPZWC to the
rescue.  From the point of view of the user, it behaves identically
to a character except it prints nothing (and isn't in the kerning
tables).

*Character translation
  .tr #\&

If you translate # to \&, # retains its use as an input character,
except it prints nothing.

I hope the repetitiveness makes my point: Any place \& is used, it
behaves identically to a character.  Furthermore, conceptualising
it as a character makes it easy to grasp why it has the effect
it does.  I posit that "zero-width, non-printing character" is
accurate (behaves like a character, has zero width and doesn't
print), is easy to conceptualise, and applies to and helps explain
all scenarios where \& is used.

That said, if we must find a convenient, shorter alternative, "null
character" seems the best choice, though were I to document it, I
would probably say, "\& is a null character, i.e. a non-printing,
zero-width character."

-- 
Peter Schaffter
https://www.schaffter.ca



reply via email to

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