[NTG-context] colors for links

[NTG-context] colors for links

[Pablo Rodriguez]

Hi Hans,

I have the following source, which tries to resemble three kinds of links:

    \setupinteraction[state=start, style=, focus=standard]

    \def\inone#1{%
      \start\setupinteraction[color=darkgreen]%
      \enabledirectives[references.border=darkgreen]%
      \goto{#1}[url(#1)]\stop}
    \def\intwo#1{%
      \start\setupinteraction[color=darkred]%
      \enabledirectives[references.border=darkred]%
      \goto{#1}[url(#1)]\stop}
    \def\inthree#1{%
      \start\setupinteraction[color=darkblue]%
      \enabledirectives[references.border=darkblue]%
      \goto{#1}[url(#1)]\stop}

    \starttext
    \startTEXpage[offset=1dk, align=middle]
    \inone{one}\blank
    \intwo{two}\blank
    \inthree{three}\blank
    \stopTEXpage
    \chapter[one]{First chapter}
    \chapter[two]{Second chapter}
    \chapter[three]{Second chapter}
    \stoptext

I see that the directive for link borders only allows one color for
links per document.

In my real-world documents, I need to make three different border links:
for destinations inside the document (/GoTo), for destinations in other
documents (/GoToR or /GoToE) and for external destinations (/URI).

With the current document I write now, I have over a hundred links in
twenty pages. Being able to visually distinguish each link helps
interaction with the document (reading or even writing it).

Would it be possible that \setupinteraction could have a bordercolor
key, such as the color one?

Many thanks for your help,

Pablo
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: colors for links

[Hans Hagen via ntg-context]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

On 10/12/2023 3:14 PM, Pablo Rodriguez wrote:
> Hi Hans,
> 
> I have the following source, which tries to resemble three kinds of links:
> 
>      \setupinteraction[state=start, style=, focus=standard]
> 
>      \def\inone#1{%
>        \start\setupinteraction[color=darkgreen]%
>        \enabledirectives[references.border=darkgreen]%
>        \goto{#1}[url(#1)]\stop}
>      \def\intwo#1{%
>        \start\setupinteraction[color=darkred]%
>        \enabledirectives[references.border=darkred]%
>        \goto{#1}[url(#1)]\stop}
>      \def\inthree#1{%
>        \start\setupinteraction[color=darkblue]%
>        \enabledirectives[references.border=darkblue]%
>        \goto{#1}[url(#1)]\stop}
> 
>      \starttext
>      \startTEXpage[offset=1dk, align=middle]
>      \inone{one}\blank
>      \intwo{two}\blank
>      \inthree{three}\blank
>      \stopTEXpage
>      \chapter[one]{First chapter}
>      \chapter[two]{Second chapter}
>      \chapter[three]{Second chapter}
>      \stoptext
> 
> I see that the directive for link borders only allows one color for
> links per document.
> 
> In my real-world documents, I need to make three different border links:
> for destinations inside the document (/GoTo), for destinations in other
> documents (/GoToR or /GoToE) and for external destinations (/URI).
> 
> With the current document I write now, I have over a hundred links in
> twenty pages. Being able to visually distinguish each link helps
> interaction with the document (reading or even writing it).
> 
> Would it be possible that \setupinteraction could have a bordercolor
> key, such as the color one?
All is possible but not all should be done, especially not features that 
mostly serve a few viewers (like acrobat) and don't really relate to 
typesetting.

That said, we can add some styling. First of all, you can use a bit of 
abstraction

\defineinteraction[one]  [color=darkgreen,style=\underbar]
\defineinteraction[two]  [color=darkred,  style=\underbar]
\defineinteraction[three][color=darkblue, style=\underbar]

\def\inone#1{%
   \start\setinteraction[one]%
   \goto{#1}[url(#1)]\stop}
\def\intwo#1{%
   \start\setinteraction[two]%
   \goto{#1}[url(#1)]\stop}
\def\inthree#1{%
   \start\setinteraction[three]%
   \goto{#1}[url(#1)]\stop}

which already might help you. To make it easier I'll add \namedgoto do 
that one can say:

\def\inone  #1{\namedgoto[#1]{#1}[url(#1)]}
\def\intwo  #1{\namedgoto[#1]{#1}[url(#1)]}
\def\inthree#1{\namedgoto[#1]{#1}[url(#1)]}

I'll also add \outline and \outlined

\defineinteraction[one]  [color=darkgreen,style=\outlined]%
\defineinteraction[two]  [color=darkred,  style=\outline]%
\defineinteraction[three][color=darkblue, style=\outlined]%

which of course you then will wikify ...

I attached an example but there is no upload (will happen when the build 
is running again because I can't make osx bins here).

hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------

[-- Attachment #2: oeps.pdf --]
[-- Type: application/pdf, Size: 8350 bytes --]

[-- Attachment #3: Type: text/plain, Size: 511 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: colors for links

[Pablo Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]

On 10/14/23 14:19, Hans Hagen via ntg-context wrote:
> On 10/12/2023 3:14 PM, Pablo Rodriguez wrote:
>> […]
>> I see that the directive for link borders only allows one color for
>> links per document.

Many thanks for your reply, Hans.

I apologize for my poor explanation of the issue.

Wanting to give a minimal sample, I didn’t add my full interaction setup:

  \setupinteraction
    [state=start,
     style=,
     color=,
     contrastcolor=,
     display=new,
     focus=standard]
  \enabledirectives
    [references.border=darkgreen]

I wanted to be able to setup the interactive link color only, not to add
any color to the link text. This would be similar to the following object:

  <<
    /Type /Annot
    /A 3 0 R
    /Border 1 0 R
    /C [ 0 .6 0 ]
    /F 4
    /Subtype /Link
    /Rect [ 11.148045 64.22294 29.080798 78.65044 ]
  >>

The "references.border" directive sets all /C keys in /Link objects to
one single color in the same document.

I may edit a single file by hand (such as in the attachment), but I
won’t be able to do that in a larger PDF source.

Drawing something in the document (avoiding the interactive link border)
is not the solution here.

>> Would it be possible that \setupinteraction could have a bordercolor
>> key, such as the color one?
>
> All is possible but not all should be done, especially not features that
> mostly serve a few viewers (like acrobat) and don't really relate to
> typesetting.

Interaction is key in cases such as the one described, because this kind
of interaction avoids two things (or a twofold situation):

* Link borders won’t be printed in paper and they’ll be displayed on screen.

* This kind of interactivity avoids having to provide recipients with
two versions of pretty much the same document (screen and print version).

Having to deal with more than one version of almost any documents tends
to cause confussion to most people and it eventually leads to errors.

Sorry, but I have to keep resulting PDF documents as simple as possible.
For their recipients, but this also helps me.

Of course, one clear objection to my approach is that PDFium (the PDF
viewer in Chrome/Edge) doesn’t display annotation borders.

There are a handful of PDF features that PDFium doesn’t support
(attachments and electronic signatures, to name other two).

In that case, many people understand that PDF (the format itself) is
“PDF according to Google” (or “PDF according to Microsoft”, since PDF is
opened with Edge by default since Win7).

I experience this at work every single day and I’m tired to tell people
“please, use Acrobat to display PDF documents and make it your default
PDF viewer” (otherwise, it is impossible to know whether a PDF document
is electronically signed or not [among other features]).

Your workaround works best when you have only one medium to handle the
document (only displayed on screen). Since it also avoids annotations,
it will work with all (or almost all) PDF viewers. Even if a document
doesn’t need to be printed now, it doesn’t mean it won’t be needed to
print it in the future (so this might give issues in the long run).

On the general issue here [PDF features only implemented by Acrobat and
few viewers], it is a fact Acrobat is only one PDF viewer. But it can be
considered the «de facto» standard implementation of the format.

I know Acrobat contains errors (deviations from the specification), but
this is not very relevant now (since not even Adobe claims that Acrobat
implementation of the PDF spec is fully conformant with the it).

For example, MuPDF, SumatraPDF and Chrome/Edge don’t care about
/EmbeddedFiles or annotation borders.

MuPDF may access to the embedded file only to save its contents from
/FileAttachment. Again, it has to be saved first, to be opened and
displayed then. No matter whether the file is actually a PDF document.

SumatraPDF follows the same path, but it doesn’t seem to enable saving
attachments in its latest stable release.

I know there is no way to have it all. But at least in the case of
attachments, I think it is clear that (what to some viewers seeems to
be) new functionality has to be implemented.

As for the users, sorry to disagree with you, Hans, we need a decent
viewer (and I’m not an Acrobat user at home). I mean, a viewer that
implements the required features (by the document creator or their
recipients).

That being said, if different annotation border colors (/C value in
/Annot) is not an option in ConTeXt, a single annotation border color
will be a “must have”.

> That said, we can add some styling. First of all, you can use a bit of
> abstraction

Many thanks for your help again.

I’m afraid for the reasons explained above, this cannot be my way.

> […]
> which already might help you. To make it easier I'll add \namedgoto do
> that one can say:
> […]
> I'll also add \outline and \outlined
> […]
> which of course you then will wikify ...

Of course, I’ll wikify this new feature in ConTeXt.

As it might help other users, I‘m happy to help.

I’ll have to wait until I test \namedgoto myself, because I don’t get
how \namedgoto may differ from \goto.

> I attached an example but there is no upload (will happen when the build
> is running again because I can't make osx bins here).

So all new releases will be held untill the build farm is running again,
won’t they?

Many thanks for your help again,

Pablo

[-- Attachment #2: new_oeps.pdf --]
[-- Type: application/pdf, Size: 11115 bytes --]

[-- Attachment #3: Type: text/plain, Size: 511 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: colors for links

[Hans Hagen via ntg-context]

On 10/14/2023 7:55 PM, Pablo Rodriguez wrote:
> On 10/14/23 14:19, Hans Hagen via ntg-context wrote:
>> On 10/12/2023 3:14 PM, Pablo Rodriguez wrote:
>>> […]
>>> I see that the directive for link borders only allows one color for
>>> links per document.
> 
> Many thanks for your reply, Hans.
> 
> I apologize for my poor explanation of the issue.
> 
> Wanting to give a minimal sample, I didn’t add my full interaction setup:
> 
>    \setupinteraction
>      [state=start,
>       style=,
>       color=,
>       contrastcolor=,
>       display=new,
>       focus=standard]
>    \enabledirectives
>      [references.border=darkgreen]
> 
> I wanted to be able to setup the interactive link color only, not to add
> any color to the link text. This would be similar to the following object:
> 
>    <<
>      /Type /Annot
>      /A 3 0 R
>      /Border 1 0 R
>      /C [ 0 .6 0 ]
>      /F 4
>      /Subtype /Link
>      /Rect [ 11.148045 64.22294 29.080798 78.65044 ]
>    >>
> 
> The "references.border" directive sets all /C keys in /Link objects to
> one single color in the same document.

indeed, because these objects get creates when apage is shipped out and 
we don't let additional color (or style for tham matter) information 
travel with the link info

> I may edit a single file by hand (such as in the attachment), but I
> won’t be able to do that in a larger PDF source.
 >
> Drawing something in the document (avoiding the interactive link border)
> is not the solution here.

you mentioned that you use it for checking so then rendered different 
whatever styling is reasonable; once you render a final version the 
single color will do

>>> Would it be possible that \setupinteraction could have a bordercolor
>>> key, such as the color one?
>>
>> All is possible but not all should be done, especially not features that
>> mostly serve a few viewers (like acrobat) and don't really relate to
>> typesetting.
> 
> Interaction is key in cases such as the one described, because this kind
> of interaction avoids two things (or a twofold situation):
> 
> * Link borders won’t be printed in paper and they’ll be displayed on screen.
> 
> * This kind of interactivity avoids having to provide recipients with
> two versions of pretty much the same document (screen and print version).

it's one of the nice things about tex that one can easily generate two 
versions; for screen i'd even make a landscape instead of portrait 
version and maybe for phones yet another

> Having to deal with more than one version of almost any documents tends
> to cause confussion to most people and it eventually leads to errors.
> 
> Sorry, but I have to keep resulting PDF documents as simple as possible.
> For their recipients, but this also helps me.

but one color will do then in the final document ... multiple for 
different links / targets is also confusing

> Of course, one clear objection to my approach is that PDFium (the PDF
> viewer in Chrome/Edge) doesn’t display annotation borders.

indeed

> There are a handful of PDF features that PDFium doesn’t support
> (attachments and electronic signatures, to name other two).

indeed ... and after decades of pdf that tells a story ... maybe no one 
using or programming open source viewers care much about it and when 
different viewers also behave different we end up with endless 
adaptation and patching which is no fun either

> In that case, many people understand that PDF (the format itself) is
> “PDF according to Google” (or “PDF according to Microsoft”, since PDF is
> opened with Edge by default since Win7).

hard to say what is default ... esp when bugs become/became features ...

> I experience this at work every single day and I’m tired to tell people
> “please, use Acrobat to display PDF documents and make it your default
> PDF viewer” (otherwise, it is impossible to know whether a PDF document
> is electronically signed or not [among other features]).

i admit that i never nbother about signed documents; the last time i got 
some link to an adobe server telling me that i had to sign something i 
just removed the mail (who knows what they do with your data)

> Your workaround works best when you have only one medium to handle the
> document (only displayed on screen). Since it also avoids annotations,
> it will work with all (or almost all) PDF viewers. Even if a document
> doesn’t need to be printed now, it doesn’t mean it won’t be needed to
> print it in the future (so this might give issues in the long run).

yes but you wanted it for checking, so then a 'temporary' rendering as 
mentioned can work ok; it can even be more visible if you use think borders

> On the general issue here [PDF features only implemented by Acrobat and
> few viewers], it is a fact Acrobat is only one PDF viewer. But it can be
> considered the «de facto» standard implementation of the format.

with the user interface becoming more horrible every i try to avoid the 
reader (sumatra works just fine)

(viewers in broswers or mail agents can also be weird: currently my 
thunderbird shows white text on black pages, if at all)

> I know Acrobat contains errors (deviations from the specification), but
> this is not very relevant now (since not even Adobe claims that Acrobat
> implementation of the PDF spec is fully conformant with the it).

i suppose that the feautures added for some specific customer (or 
application) are not really concidered part of the standard; as with any 
standard: only the things everyone understands and can test are real; 
basically pdf is an application format that happened to be widely used 
and therefore survived

> For example, MuPDF, SumatraPDF and Chrome/Edge don’t care about
> /EmbeddedFiles or annotation borders.

probably because embedding was kind of fuzzy (described) from the start 
with evolving implementations and wrt borders: they just look ugly in 
documents so i tend to ignore these (plenty of other stuff to read)

> MuPDF may access to the embedded file only to save its contents from
> /FileAttachment. Again, it has to be saved first, to be opened and
> displayed then. No matter whether the file is actually a PDF document.

that actually might be more reliable (also memory wise unless one caches 
on disk) than making the viewer more complex by adding all king of options

> SumatraPDF follows the same path, but it doesn’t seem to enable saving
> attachments in its latest stable release.

hm, i admit that i didn't even knew it supports it; for me support of 
layers and basic javascript is a threshold for considereing a viewer 
more mature

> I know there is no way to have it all. But at least in the case of
> attachments, I think it is clear that (what to some viewers seeems to
> be) new functionality has to be implemented.
> 
> As for the users, sorry to disagree with you, Hans, we need a decent
> viewer (and I’m not an Acrobat user at home). I mean, a viewer that
> implements the required features (by the document creator or their
> recipients).

as said: there has been plenty of time to add trivial things like 
showing borders to viewers but it's not considered essential; personally 
i never assume such application specific features to be long term stable 
and therefore avoid them

> That being said, if different annotation border colors (/C value in
> /Annot) is not an option in ConTeXt, a single annotation border color
> will be a “must have”.

but that works afaik (we probably can have different border colors per 
annotation type without much extra code / overhead (if i ever need it in 
a project that pays the bills i might consider some plugin)

>> That said, we can add some styling. First of all, you can use a bit of
>> abstraction
> 
> Many thanks for your help again.
> 
> I’m afraid for the reasons explained above, this cannot be my way.
> 
>> […]
>> which already might help you. To make it easier I'll add \namedgoto do
>> that one can say:
>> […]
>> I'll also add \outline and \outlined
>> […]
>> which of course you then will wikify ...
> 
> Of course, I’ll wikify this new feature in ConTeXt.
> 
> As it might help other users, I‘m happy to help.
> 
> I’ll have to wait until I test \namedgoto myself, because I don’t get
> how \namedgoto may differ from \goto.

it obeys an interaction instance (so text color and such)

>> I attached an example but there is no upload (will happen when the build
>> is running again because I can't make osx bins here).
> 
> So all new releases will be held untill the build farm is running again,
> won’t they?

indeed. which is no real problem because i rewrote some mechanisms to be 
a bit more lmtx-ish (internally):

- effects, like extend, squeeze, weight, slant and combinations 
including local control
- italic correction (math already lost it, text is now somewhat cleaner) 
with neglectable overhead
- even better (and closer rto normal) compact font mode (which was 
actually the reason for the other changes)

this means: sometimes smaller pdf files, slightly better backend 
performance because we default now to previously experimental code 
paths, sometimes less font loading, a bit faster startup time (in 
compact mode)

but as it needs testing i'd not upload it before a few power testers 
give the green light

Hans

> Many thanks for your help again,
Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________