groff
[Top][All Lists]
Advanced

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

Re: Is it possible to detect `grotty -i` at runtime?


From: G. Branden Robinson
Subject: Re: Is it possible to detect `grotty -i` at runtime?
Date: Thu, 21 Jul 2022 20:09:03 -0500

Hi John,

At 2022-07-22T07:29:48+1000, John Gardner wrote:
> I'm looking for a way to harden my .UL
> <https://github.com/Alhadis/Mono/blob/25765171fbf676b623a4bcbf3d9f93384ef83040/ono.tmac#L171-L233>
> (underline) macro against grotty(1) v1.23's new -i switch,

This command-line option is not forthcoming.  It was introduced in groff
1.18 (July 2002).[1]  So it's a 20 year-old feature.

What groff 1.23 does do is add a `-P` option to nroff so that arbitrary
options can be passed to the postprocessor via that command.[2]

> which causes italicised text to be rendered with actual italics (in
> TTYs that support SGR 3, at least). My intended workaround involves
> something like
> 
> \l'\w,\$1,u\(ul'\h'-\w,\$1,u'\$1
> 
> or some similarly atrocious hack. Unfortunately, there doesn't appear
> to be any predefined register to report the status of grotty(1)'s -i
> and -r switches (both of which change how italic fonts are rendered in
> the terminal).
> 
> Can anybody confirm that what I'm seeking to do is even possible?

As I understand *roff architecture, this is indeed impossible.

`-i` is a _postprocessor_ option here.  Recall the basic *roff pipeline.

preprocessor | troff | postprocessor

The most your macro can know about postprocessor-specific information is
what was given as the -T argument to troff, what's in the corresponding
`DESC` file (only if a mechanism for exposing that information via the
roff language has been implemented), and, in groff, what the
postprocessor-specific macro file (like tty.tmac) chooses to declare.

Further, the pipeline can always be broken up such that a "grout" file
(the output of the troff command itself) is stored and then processed
with a different output driver (this is how gxditview works) or with
different options to the intended output driver.

What are you trying to do?  Avoid underlining text that the output
device is already underlining itself?

Regards,
Branden

[1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n1694
    https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n2083
[2] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n77

Attachment: signature.asc
Description: PGP signature


reply via email to

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