Font Change within Hyperlink String Results in Two Links

[A_B_C]

Hi,

there is another slight oddity with hyperlinks. Have a look at my video. String (a) is typeset in Arial throughout, while in string (b) the bullet character is typeset in Arial Black, this being the only difference. So there is a font change within the string the hyperlink is assigned to.

• Now, when you assign a hyperlink to (a), only one link will be created.
• When you assign a hyperlink to (b), you will get two of them.

I don’t know why that happens or if there is a technical reason for it, but it feels like a bug. By the way, you will get two hyperlinks with any change to the base font. Even assigning another style, such as italic, will result in the creation of two links. 

Thank you for having a look, Alex 

 

Hyperlink-Font-Change.afpub

[A_B_C]

And the same happens when you do a search and replace that affects the character style of some part of an existing hyperlink string.

Search-Replace.afpub

Search-Replace.pdf

[Old Bruce]

This is so the various elements you have changed will remain as working hyperlinks. You have two separate working hyperlinks. Are you wanting to have the bullet not be part of the link?

[A_B_C]

No, I don’t want to have separate hyperlinks. Changes in font styles within a string should never result in multiplying hyperlinks, working or not. Hyperlinks in PDF documents are technically independent of text strings (according to my understanding of the PDF specification), hence they should be, a fortiori, independent of the styling of text strings. I cannot imagine that someone would have a new link created by simply changing the styling of a part of the string the link is assigned to. In practice, that makes no sense and bloats the document structure.

Please have a look at my further explanations here:

https://forum.affinity.serif.com/index.php?/topic/86132-“show-hyperlinks”-missing/&tab=comments#comment-456281

Thank you. 

 

[Old Bruce]

I am more concerned that they work, and well at that. We can change the styling and we can add to or subtract from the link's length and they still work. I like the way it works now. As to bloat... I have no concern regarding the possible multiplication of some short text strings in a document which may be filled with graphics and long text.

[A_B_C]

Oh no, Old Bruce! It’s not the question whether they work or not, but a question of document maintenance!

Suppose you add an URL hyperlink to a PDF that points to a website. Then this URL may … and usually will … change from time to time. But then, to keep your document up to date, you will not only have to change the hyperlink in your PDF once, but possibly multiple times!

That would be so odd, I just doesn’t make sense … 

[fde101]

I still don't like the fact that if I have two hyperlinks in the document pointing to the same place they wind up with two entries in the hyperlinks panel.

I can live with it, but I really don't want to.

I do wish this would behave more like it does in QuarkXPress.

[A_B_C]

In my opinion, hyperlink, cross-references, table-of-contents, footnotes, and endnotes management are fields where Affinity Publisher would have a chance to shine and set itself apart from the other desktop publishing apps. According to my experience, all of the existing solutions are cumbersome in certain respects. Complex documents are most often an issue. 

At the moment, hyperlink management in Publisher feels just like an initial step. As soon as you add more than, say, fifty hyperlinks to a document, pointing to targets of different type, things start to get convoluted, not only due to the bugs (hyperlink labels not updating, generation of multiple entries, links that are attached to nothing), but also due to the fact that so many natural and useful options are missing. You cannot discern the link type (URL, anchor, page, …) from the Hyperlinks Panel, cannot edit the label as well as the link directly in a single panel, cannot reorder or group entries in the Hyperlinks Panel to create a logical structure that suits your document, cannot highlight links on your spreads, cannot edit link placement and string length in a text, etc. etc.

In short, there is a lot of room for improvement … and smart solutions. 

[Patrick Connor]

It may be an improvement to reamalgamate the multiple hyperlinks created by changing character attributes, but PDF limitations cannot drive the design of the app and other export options that include hyperlinks (HTML) would not want this. So I'm sure this is by design, and could be improved for PDF.

[fde101]

4 hours ago, A_B_C said:

bugs (hyperlink labels not updating

I rather doubt that is a bug, though there may be some room for improvement there.

 

4 hours ago, Patrick Connor said:

an improvement to reamalgamate the multiple hyperlinks created by changing character attributes

It's not just that.  If I have a document with multiple links to the same place, and the target changes, in QuarkXPress these are *ONE* entry such that I can update all of the links in the document at once.  In Publisher, I would need to search through the entire list of hyperlinks to update it in multiple places.

[Patrick Connor]

2 hours ago, fde101 said:

In Publisher, I would need to search through the entire list of hyperlinks to update it in multiple places

Early days. I think that this will need improving as well.

[A_B_C]

10 hours ago, Patrick Connor said:

It may be an improvement to reamalgamate the multiple hyperlinks created by changing character attributes, but PDF limitations cannot drive the design of the app and other export options that include hyperlinks (HTML) would not want this.

Patrick, I am not sure whether I understand what you mean with that. 

It’s nice to hear that you are planning HTML export, but even then, I do not really get your argument. We are obviously discussing two different issues in this thread,

• the first one being the fact that Publisher duplicates entries in the hyperlinks panel whenever a change in text style occurs within the string the link is assigned to,
• the second one being an improvement suggestion by @fde101.

I cannot speak for @fde101, but regarding my initial posts, I don’t see how my remarks concerning the first issue would conflict with the future addition of export options, in particular with the addition of HTML export. As you know, it is perfectly possible to enclose text in <a> tags, even if different parts of that text have different style attributes. There is no need to split HTML links when a style change occurs. Am I wrong here?

Furthermore, exporting is always a matter of translation into a target format. I don’t understand why a suggestion for improving the usability of the application (such as the suggestion to avoid a completely useless and cumbersome multiplication of entries in the Hyperlink Panel when a style change occurs) will create translation issues that cannot be solved by an appropriately written exporter. When you take a look, for instance, back at Indesign CS 5.5, you can see that the issue I initially described in this thread didn’t show up there at all. Honestly, I cannot consider the current behaviour anything but a bug. 

Please expand a little on your comment! 

Alex

 

[A_B_C]

6 hours ago, fde101 said:

I rather doubt that is a bug, though there may be some room for improvement there.

Too late, it is already logged as an issue (afb-2179) … 

https://forum.affinity.serif.com/index.php?/topic/86053-hyperlink-labels-do-not-update-automatically/

 

[fde101]

30 minutes ago, A_B_C said:

Too late, it is already logged as an issue

Just because something is logged as an issue doesn't mean that it is a bug.

[Patrick Connor]

39 minutes ago, A_B_C said:

Please expand a little on your comment

I am not saying that we are planning HTML export. HTML was just an example of an export that would support hyperlinks (like RTF).

Thinking about this, the whole link can probably export as one in PDF without affecting the underlying data format

[A_B_C]

Sure. Isn’t it true that links are added to PDFs as hyperlink annotations, according to the PDF specification?

https://forum.affinity.serif.com/index.php?/topic/86132-"show-hyperlinks"-missing/&amp;tab=comments#comment-456281

I am not a file format expert nor a programmer, but as far as my understanding goes, I believe it should indeed be possible to export the entire link as one. 

[Jon P]

Thanks for reporting this, I've logged the fact two links get created if you apply a hyperlink to text containing different styles/formatting.

[garrettm30]

Thank you @A_B_C for reporting this bug and for explaining why it matters, especially in regard to updating links. I see a real potential for user error to go undetected in the case of updated links. In most cases, the user intended there to be one link, and he may not be aware, when updating the link target, that there are actually two links. If this problem were actually fixed, then there is still no reason the user could not explicitly have two links to the same place in a consecutive string if that is what he wanted (for some reason I can't imagine).

To illustrate in terms of simple HTML:

Example: Here is a good link.

<!-- One link -->
Here is <a href='serif.com'><em>good</em> link</a>.

<!-- Two links, current Affinity style -->
Here is <em><a href='serif.com'>good</a></em> <a href='serif.com'>link</a>.

Both should be possible, depending on user intent, but I would think that the first would be what people are naturally expecting. Incidentally, when I entered the example string, the forum software chose to implement the first solution on this page.

-------

This discussion gave me the offshoot idea that it would be nice to find/replace in URLs. Imagine that a company reorganized its website language scheme from "www.domain.com/lang/" to "lang.domain.com". A find/replace of URLs could fix all such instances in document right away. Does anyone think that is worth a feature request?

[fde101]

35 minutes ago, garrettm30 said:

Does anyone think that is worth a feature request?

Absolutely.

[A_B_C]

Great explanation, @garrettm30! Thank you … 

I would second your suggestion regarding find/replace for URLs. Maybe it would make sense, however, to add this option to the Hyperlinks Panel, not to merge it into the current Find/Replace Panel. For since we have to discern between

• links (the strings between the tags <a>…</a> in HTML)

and 

• link target strings (the strings between the quotes of the href="…" attribute in HTML),

we will also have to discern between

• doing a find/replace on links

and

• doing a find/replace on link target strings.

Hence, it would feel natural for me to add the find/replace option you have in mind to the Hyperlinks Panel rather than to merge it as a new option into the current Find/Replace Panel, as the latter one operates directly on stories in a document. Furthermore, I think it would be necessary then that the Hyperlink Panel would not only show a list of the links in a document, but also a list of the corresponding link target strings. Maybe in columns, side by side.

More generally spoken, I would believe that hyperlinks, cross-references, etc. should be manageable through an interface similar to the current Resource Manager. As soon as you add more than a couple of links to a document, the current panel-based or “studio”-based approach results in an overcrowded interface that is hard to survey.

Alex 

[fde101]

4 hours ago, A_B_C said:

Maybe it would make sense, however, to add this option to the Hyperlinks Panel, not to merge it into the current Find/Replace Panel

Agreed

[Patrick Connor]

We believe the issue ("Text with different formatting/styles applied creates multiple hyperlinks") has been fixed in the latest Affinity Publisher beta and should not occur in the initial release of Affinity Publisher next week.

[A_B_C]

Thank you, Patrick. It is indeed fixed. So much better.