groff
[Top][All Lists]
Advanced

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

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


From: B 9
Subject: Re: Groff macro to make .UR and .UE links clickable in PDF?
Date: Fri, 10 Jul 2020 19:45:11 -0700
User-agent: s-nail v14.9.11

Ingo Schwarze <schwarze@usta.de> wrote:

> Yes, i do strongly object.

You make good points, Ingo. Let me see if I can answer your concerns.


> I think it is very bad practice to omit the protocol from an URI.
> For one thing, it results in invalid URI syntax.

I am only talking about the display. When hovering over the link the
full URL would be shown. And, of course, the underlying link address
would include "https://"; as that is necessary for it to even work.

Also, I am not suggesting changing the URL in a way that would break
the link. In particular, to address the concern someone else had, I
don't think groff should ever remove a "www." hostname.

For hardcopy, typing what is printed would still go to the same page.
For ASCII output, cut-and-paste into a browser also still works.


> On top of that, the fact that this week, the web is a monoculture of
> https:// neither means that other protocols don't exist nor that
> other protocols cannot become used.

Like you, I would prefer if writing, especially printed, would be
valid decades from now. If someday all URLs begin with ACK!THBBFT!://,
the default presumption may change and it would take a historian to
know to try https:// instead. So, why doesn't that convince publishers
of today to always leave in the protocol? I think the answer is that
most URLs are ephemeral and aren't expected to be around ten years
from now.


> Oh wait, i think i have occasionally seen URIs like rsync:// and
> git:// and imaps:// even amid the prevalent monoculture.

Existing protocols, like man://, mailto:, and gopher:// are not a
problem as I'm not talking about eliding all protocols, just the ones
that web browsers default to when a protocol isn't specified.


> Besides, the distinction between http:// and https:// can
> occasionally be meaningful.

Yes, and an author would surely specify the link text on those
occasions instead of letting groff come up with a good default. It is
simply a matter of specifying both the URL (the underlying link) and
the link text (which is what is to be displayed).

    .URL  https://foo.bar.com/fred/juki/  https://foo.bar.com/fred/juki/


> And finally, the omission of the protocol can - depending on the
> context - cause confusion because it removes an obvious indicator
> that the thing printed is a URI in the first place, an indicator
> that the document author may have relied on.

I also wondered whether people might get confused, particularly if a
document tells them to go to an unusual domain like "jit.si". However,
the WWW package (or, at least, my version), does distinguish URLs from
plain text by color (PDF) or underlining (nroff). For documents
processed with groff -c, italics are used.


> I hate the malpractice of omitting the protocol even in browser
> software (e.g. in the address bar and in similar places).  It treats
> the users as stupid animals who cannot understand proper URI syntax.
> It is insulting.

I'm sorry, but I don't see the same problems you do, Ingo. But, even
if I am wrong — as I often am — is solving those problems in groff's
domain as a typesetting program? Shouldn't groff follow common
conventions in the industry?


> You propose to break the rendering of existing documents for
> absolutely no benefit:  authors who want to join the malpractice
> of omitting the protocol are already perfectly free to do so by
> writing:
> 
>       .URL foo.bar.com/fred/juki

Actually, no. The first argument is the URL and so it must be
specified with the protocol in order for the link to function.
You might be correct if you said that they could do this:

    .URL  https://foo.bar.com/fred/juki/  foo.bar.com/fred/juki/

However, since shortening a URL as much as possible may be a common
case in publishing, it is worth considering whether it should be the
default. Personally, it'd save me time as an author if groff did the
work for me instead of me having to shorten each URL by hand. Unlike
some of the people on this list, though, I am no expert on publishing
standards. That is why I am asking what everyone thinks.

As for breaking existing documents... that's one of the things I was
hoping people would be able to show me. Are there actually any
existing documents where the author's intent requires the protocol be
shown *and* they didn't specify exactly what they wanted displayed
using a second argument?


> Consequently, we have to assume that those who provided syntactically
> correct URIs in their documents did so...  on purpose.

I think my biggest mistake was giving the impression that I was
suggesting changing what an author has requested be printed. That is
not the case. My question was only about what default makes the most
sense if the author omits the link text and leaves it up to groff to
"do the right thing" with a bare URL.

Some publishers are making URLs shorter by removing the protocol and,
personally, I find it more readable. If that is the typical desire of
authors and publishers, then perhaps it should also be what is most
simple and convenient in groff.

I hope I addressed all of your concerns, Ingo.

What do other people think? How often do you want URLs to display as
www.website.tld and how often, https://www.website.tld? My bias is
strongly towards the former, but I'm asking out of ignorance, not
because I want a specific answer.

—b9

P.S. I just realized that T. Kurt Bond may have thought that Steve was
     talking about lopping off the "www". I believe what Steve was
     saying was,

         https://www.website.tld  →  www.website.tld 

     not

         www.website.tld  →  website.tld 

P.P.S. Nate: Good tip. I think MANWIDTH=66 may be even more readable.
       I wish 'groff -mandoc -Tpdf' used two columns (whenever it
       wouldn't cause bad hyphenation or interword spacing.)




____

Addendum: "+1 (212) PEnnsylvania Six-Five Thousand!"
          Hmmm.... somehow not as catchy. ;-)




reply via email to

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