Hi Rasmus,
The issue you describe is actually two different issues.
For the first image, you are talking about linking a digital object via web URI. In this case, the
documentation (see step 5) and
previous posts in this forum are clear that there are some requirements for making these links work. Specifically:
- They must be web-accessible without any barriers to access (no logins, firewalls, VPNs, etc)
- They must be HTTP or HTTPS links (FTP links won't work)
- They must end in the file extension of the digital object. You can't link to a landing page, unfortunately
Without a URL that ends in a file extension, AtoM has no way of knowing what on the page you are trying to grab, and it therefore can't generate the derivatives. For this reason, using a shortlink service won't help, because the shortened link still will not end in the file extension.
If you are able to right-click on your image link and get a "View image" option in your browser, this will generally give you a URI right to the object that should work (assuming the other criteria are met as well). Otherwise, some repository applications will let you customize how permalinks are formed - it may be possible to change the behavior to get the kind of link you need?
If not, there is a sort of hacky option you can try. You can sort of work around this by treating the object upload just as a hyperlink that will take the user to the view page, and manually uploading your own thumbnail and reference display copy, as well as changing the media type if needed, by going to the Digital object metadata edit page . See:
Unfortunately, however, there's no way to bulk upload derivatives to AtoM, so that would be a rather time consuming approach if you have a lot of objects. Additionally, changing the media type (which will probably default to "other" when AtoM can't access the master digital object via the link you provide) can, in some cases, cause issues - for example, if you change it to video, AtoM will try to load the media player, so users won't be able to click through on your link. It can work okay if you set the type to text or image, however.
I'm also not sure how we could improve this in AtoM without a massive overhaul - ultimately, AtoM needs some way to figure out what on the page you are trying to link as the master digital object, and pointing directly to the object via a URL that leads to the file extension is the easiest way of doing so.
With the second link: this does seem to be a limitation of AtoM's current regular expressions (or regex - the patterns used to identify and automatically convert hyperlinks into something clickable) - it looks like parentheses are not currently part of the regex, and this is where the link is breaking. I have filed an issue for this here:
However, since there are several workarounds (see below), I've marked this as low priority for now. If you consider this a priority for your institution and might be interested in sponsoring a fix, please feel free to contact me off-list.
Some possible workarounds:
Have you tried creating a link with Markdown? One of the reasons we moved from our previous custom linking syntax to Markdown was the the third-party library we use for markdown support (called Parsedown) is much better overall at managing links than anything we could create in-house. If you are willing to provide target text as a hyperlink using markdown, rather than a raw link, I suspect it might work better.
Otherwise, for this second case, yes I think that using a link shortener would serve you well as a workaround.
Another option you could try: using percent encoding for the parentheses. I believe that %28 is used for the opening parenthesis, and %29 for the closing, as per this:
I can't tell if it is working as expected because your original link doesn't work for me (I suspect because I am not logged in), and just redirects me to the Libris homepage - but I did test that adding your link as follows in an AtoM edit page allowed the whole URL to render as a hyperlink: