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