Re: [PATCH] posix.py: ffix: Correctly format URIs

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

 



At 2021-01-21T21:14:26+0100, Jakub Wilk wrote:
> > After seeing Branden's answer to Michael (Escaping hyphens), I've
> > seen groff_char(7), and I found that my tty correctly supports
> > U+2039 and U+203A.  I clearly see the symbols I would expect:
> > something quite similar to plain <>, but a bit more obtuse.
> > 
> > In the XFCE terminal, I also see something quite expected: a
> > slightly smaller version of <>.
> > 
> > But both show me very different characters for .UR/.UE.  tty
> > displays a diamond, and XFCE term displays (a weird version of)
> > round parentheses.
> > 
> > So... does it mean there's a bug in .UR/.UE?
> 
> Or a bug in Branden. ;-)
> 
> Contrary to what he wrote, and what I parroted, .UR/.UE use U+27E8 and
> U+27E9 as delimiters.

Mea culpa.  I don't know where I got U+2039 and U+203A.  It wasn't from
checking groff_char(7), which correctly documents the special character
escapes.  (Which softens the blow--I'd rather be wrong on a mailing list
thread than in a man page.)

U+2039 and U+203A are "single {left,right}-pointing angle quotation
mark" per Unicode.  Their groff special character escapes are \[fo] and
\[fc], respectively.  (I don't know the mnemonic that inspired the
"f" in the name.)

U+27E8 and U+27E9 are "mathematical {left,right} angle bracket" per
Unicode.  Their groff special character escapes are \[la] and \[ra],
respectively.  I _assume_, without having interviewed Werner Lemberg or
Eric Raymond on the subject, that angle brackets were chosen for .UR/.UE
(and .MT/.ME) in continuity with existing practice elsewhere.

If your terminals' font coverage refuses to support U+27E[89]
reasonably, you can remap the characters.  This is good fodder for
man.local[1], recently discussed here in another thread.

.if '\*[.T]'utf8' \{\
.  char \[la] \[Fo]
.  char \[ra] \[Fc]
.\}

...or you can just put < and > in place of \[Fo] and \[Fc] if you
prefer.

(The conditional checks the output driver being used for rendering.  It
keeps the glyphs from being remapped for PostScript of PDF output, for
instance.)

It may happen that you want to alter the character mappings only for
some terminal types, perhaps because some terminal emulator uses fonts
with a meager glyph repertoire.  Here's an example of how to do a string
comparison against an environment variable.

.if '\*[.T]'utf8'
.  if '\V[TERM]'linux' \{\
.    char \[la] \[Fo]
.    char \[ra] \[Fc]
.\}

In any event, if any font designed for use with terminal emulators
claims Unicode coverage and lacks glyphs for any of the special
character escapes in groff_char(7), I would regard that as a bug in the
font that should be reported to its maintainers.  The list of groff
special escapes has been stable for several years and is not expected to
change[2]; if I recall correctly, the previous groff maintainer Werner
Lemberg felt it should be frozen.

Regards,
Branden

[1] available at /etc/groff/man.local on Debian-based systems
[2] This does not mean that macro packages cannot extend the list, and
    in fact there is a pending contribution from Dorai Sitaram called
    rfc1345.tmac which adds all the digraphs from Vim (which are in turn
    based on RFC 1345) to the repertoire, and should be a nice
    convenience for users familiar with those.  I plan to merge it prior
    to the release of groff 1.23.0.  Authors of man pages intended for
    broad portability, however, should not source this macro file.  It
    remains to be seen what other implementations like Heirloom Doctools
    troff and mandoc do about it.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux