Re: [PATCH] nextup.3: minor improvements

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

 



Hi John,

At 2024-08-09T15:53:30+1000, John Gardner wrote:
> Hi Vincent,

Not to horn in, but I think I'm better situated to venture opinions or
background on implementation decisions taken in groff than Vincent is.

> So ideally, the fallback for "±0" should be "+0 or -0", which is
> > much more readable and less ambiguous than "+-0" or "+/-0".
> 
> For approximating ± in ASCII, is there some reason \z_+0 hasn't been
> considered?

You anticipated the answer.

> I'm asking earnestly, as I'm primed to assume overstriking hacks have
> already been ruled out (pun intended) as a fallback.

\z _is_ an overstriking hack.

From groff's Texinfo manual (slightly altered):

 -- Escape sequence: \o'abc...'
     Overstrike the glyphs of characters A, B, C, ...; the glyphs are
     centered, written, and the drawing position advanced by the widest
     of the glyphs.

 -- Escape sequence: \zc
     Format the character C with zero width; that is, without advancing
     the drawing position.  Use '\z' to overstrike glyphs aligned to
     their left edges, in contrast to '\o''s centering.

All of the terminal output devices groff supports lack overstriking
support.

Resolving <https://savannah.gnu.org/bugs/?63583> (waiting on me) is a
prerequisite to doing anything about that.

We would also need a new "DESC" file keyword to declare overstriking
support in output devices, and a way to query this parameter from the
GNU troff language.[1]  (This would also be useful for Tektronix 4014
support.)

The enthusiastic aficionados of the Western Electric/Teletype
Corporation Model 37, including (it would seem) many less(1) users,
could then run wild with TERM=tty37.

tty37|model 37 teletype,
        OTbs, hc, os, xon,
        bel=^G, cr=\r, cub1=^H, cud1=\n, cuu1=\E7, hd=\E9, hu=\E8,
        ind=\n,

I'm open to correction by Vincent or anyone else.  :)

Regards,
Branden

[1] Straw man:

    A.  A new keyword "overstrike" or "has-overstriking" would be
        recognized by libdriver and/or libgroff.  (In practice, only
        grotty(1) would need to bother checking for it; any driver for a
        typesetter can assume that overstriking is possible.)

    B.  A new conditional expression operator, "T", would take a
        delimited argument naming an output device capability.

So you might have something like this:

.ie T'has-overstriking' .fchar \[+-] \o'_+'
.el                     .fchar \[+-] +/\-

The feature window for groff 1.24 is closing (maybe in a month?), though
I still want to get #63583 landed before freezing the formatter, even
though it's strictly just an output driver change, on the off chance
that I _have_ to change something in the formatter to support it, and
because Lennart Jablonka has demonstrated the patience of a saint (as
have Deri James and TANAKA Takuji_).

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