Re: [groff] improve a few terminal renderings of special characters

[Ingo Schwarze]

Hi Ralph,

Ralph Corderoy wrote on Wed, Aug 22, 2018 at 11:11:39AM +0100:
> Ingo Schwarze wrote:
>> Ralph Corderoy wrote:
>>> Ingo Schwarze wrote:

>>>> +.tty-char \[HE] <heart>

>>> In the context of playing cards, single capital letters are used is
>>> king of clubs, `4D' is four of diamonds.  If listing a hand using
>>> `\(CL', etc., it should be approximated using single letters, not
>>> the noisy `<club>', over and over.

>> I used that suggestion in the commit; it seems you are right, these
>> symbols are quite unlikely to be used when the context is unclear.

> Seeing your `<heart>' got me thinking.  If there's expansions
> for U+2661 `white heart suit', or U+2665 `black heart suit', etc.,
> then they're `H'.

As a matter of fact, groff_char(7) does mention:

  \[u2661]   uni2661      u2661     white heart suit
  \[u2662]   uni2662      u2662     white diamond suit

It's very odd that they are mentioned, though: they are the only
two characters mentioned in this page that do not have a native
roff(7) character escape sequence.  It semms illogical to mention
them: the page already explains that *any* Unicode character can
be requested with \[uXXXX], and these two don't strike me as the
most important Unicode characters ever.  There is no need to
duplicate information from the Unicode standard in this manual
page unless we also have some roff-specific information to provide.
Should these two characters be removed from the manual page?
They were added by wl@ in the monster commit 48615a444 on 2003-02-23,
but the commit message doesn't mention why.

Besides, they do not have an ASCII representation, and i really
wouldn't see see the point in adding one, given that they don't
even have a groff character name - and it's good that they don't
have a name, IMHO.

> An emoji heart would be `<heart>', but there doesn't seem to be a
> simple plain obvious heart emoji, but dozens.  :-)

And those certainly do not deserve assignment of groff character
names, either.

>>> Because it's a recent invention and someone just copied the ISO
>>> 4127.  Given Pound, `$', and Yen, are in ASCII `L', `$', and `Y', I
>>> think `E' should be the approximation.  That's the rendering for
>>> epsilon, which is the inspiration for the Euro symbol;  a nod to the
>>> Greeks, the `cradle of Europe'.  (The two horizontal lines reinforce
>>> the `stability' of the currency, apparently.)  And again, `E' gives
>>> a conformant single column when mixing currencies.  I seen it used
>>> for this reason elsewhere.

>> Not sure about that one.  I wouldn't understand 'E' to mean "Euro",
>> and i guess that many other continental Europeans wouldn't either.

> No, I agree, they wouldn't.  But few will see it?  ASCII and ISO 8859-1
> readers?  ISO 8859-15 has a Euro sign as 0xa4.  Is -15 becoming more
> common, replacing -1?  https://en.wikipedia.org/wiki/ISO/IEC_8859-15

No, ISO 8859 is dying out, all variants of it.  UTF-8 is becoming
more common.  So basically, ASCII users would see it.

> `\z-E' or `\z=E' seems to give a reasonable approximation here and it
> does follow tty-char.tmac's
> 
>     These definitions are chosen so that, as far as possible, they:
>     ...
>     - represent the character's graphical shape (not its meaning)

That text is no longer in tty-char.tmac.  Instead, that file has
been saying now, for some time:

.\" These definitions are chosen so that, as far as possible, they:
.\" - work with all of -Tascii, -Tlatin1, -Tutf8, and -Tcp1047.
.\" - work on devices that display only the last overstruck character
.\"   as well as on devices that support overstriking
.\" - help understanding the character's meaning, only aiming to imitate
.\"   a particular graphical shape when that doesn't hinder understanding

> I suspect context would help make the meaning more clear, and the single
> column valuable.

Maybe, but i don't see a pressing reason for change here.  EUR is
widely used and clear, and groff and mandoc both do it like that.

>> Anyway, changing this wasn't part of the proposed patch in the first
>> place.  :-)

> No, you're quite right.
> 
> I wonder if John Gardner's HTML-canvas renderer could lay down text in a
> dark grey that's additive to what's already there, thus over-striking
> would have an effect, e.g. `\z~o' as well as bold.  For plus points,
> every glyph placed could have a slight random `jitter' applied to both
> its coordinates so bold was also thicker, except around the edges.
> Half-line motions would be nice too, John.  ;-)

Right, and i want ponies.  And cute little unicorns!  ;-)

Yours,
  Ingo