Re: Groff macro to make .UR and .UE links clickable in PDF?

2020-07-17 Thread Steve Izma
On Fri, Jul 17, 2020 at 12:32:54PM -0700, Michael Pirkola wrote: > Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? > > While I agree that a shorter line length is more readable, I > frequently exit a manpage, maximise the terminal window, then > reopen it when my goal is to qu

Re: Groff macro to make .UR and .UE links clickable in PDF?

2020-07-17 Thread Steffen Nurpmeso
Michael Pirkola wrote in <20200717123254.3aff0148@walrus>: |On Sat, 11 Jul 2020 09:28:45 +0100 |Colin Watson wrote: | |> On Fri, Jul 10, 2020 at 11:26:46AM -0400, Steve Izma wrote: |>> I think it's an abomination that a man page extends it's line |>> length to fit the width of the terminal;

Re: Groff macro to make .UR and .UE links clickable in PDF?

2020-07-17 Thread Michael Pirkola
On Sat, 11 Jul 2020 09:28:45 +0100 Colin Watson wrote: > On Fri, Jul 10, 2020 at 11:26:46AM -0400, Steve Izma wrote: > > I think it's an abomination that a man page extends it's line > > length to fit the width of the terminal; built into the macros > > should be a 65- or 70 character maximum wid

Re: translating defined glyphs: docs vs reality

2020-07-17 Thread Tadziu Hoffmann
> And I can surround the target of this .char definition > with \m escapes and it still works fine. So something > else seems to be going on here. You are right -- it's not that simple. For example, the following also works: .char a \m[red]a\m[] .char b \m[blue]b\m[] .tr abba ab and

Re: translating defined glyphs: docs vs reality

2020-07-17 Thread G. Branden Robinson
Hi Dave and Tadziu, At 2020-07-17T10:58:40+0200, Tadziu Hoffmann wrote: > > > .char \[red-c] \m[red]c\m[] > > .char \[slashed-o] \[/o] > > red-c is \[red-c]; slashed-o is \[slashed-o] > > .br > > .tr c\[red-c]o\[slashed-o] > > bock > > > > Of these two new glyphs defined with .char, .tr only > >

Re: translating defined glyphs: docs vs reality

2020-07-17 Thread Dave Kemper
On 7/17/20, Tadziu Hoffmann wrote: > It may be because you're defining c in terms of itself, > so you get a (non-terminating) recursive mapping. Hmm, curious, because it doesn't seem to hold in the general case. These definitions ought to have the same problem: .char a dab .tr ba bag But this o

Re: translating defined glyphs: docs vs reality

2020-07-17 Thread Tadziu Hoffmann
> .char \[red-c] \m[red]c\m[] > .char \[slashed-o] \[/o] > red-c is \[red-c]; slashed-o is \[slashed-o] > .br > .tr c\[red-c]o\[slashed-o] > bock > > Of these two new glyphs defined with .char, .tr only > recognizes \[slashed-o]. The other generates the warning > "7: warning: can't find special

translating defined glyphs: docs vs reality

2020-07-17 Thread Dave Kemper
In the section about .char, groff's info manual says: "A glyph defined by [this request] can be used just like a normal glyph provided by the output device. In particular, other characters can be translated to it with the 'tr' or 'trin' requests..." This statement is reiterated in the section