News:

Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration



Url & links

Previous topic - Next topic

a.l.e

After a long process, I think that I have a breakthrough with the markdown importer.

And once I can import my manuals, I will probably also want to create Epubs out of it...

And then I think it's time for Scribus to have (real) hyperlnks!

Can anybody find a good UI/interaction for the links?

GarryP

I'll start the ball rolling by suggesting this...

Add a sub-menu to the context-sensitive (right-click) menu called "Hyperlink". Add three items to this sub-menu as "Add...", "Change...", and "Remove".

To add a hyperlink:
* Select the text;
* Right-click the selected text;
* Select "Hyperlink -> Add...".

A simple modal dialog can then pop up (possibly using the Qt WebEngine Widget) where the user can browse to the required page - or manually enter a URL - and then they OK the dialog which then closes.

To change a hyperlink:
* Select text with hyperlink (or right-click on hyperlinked text);
* Select "Hyperlink -> Change...".

The same dialog as before would pop up and the user can change the URL.

To remove a hyperlink:
* Select text with hyperlink (or right-click on hyperlinked text);
* Select "Hyperlink -> Remove".

The hyperlink would just be removed. No need to get confirmation; if you remove it by mistake just press Undo.

It's not particularly sophisticated but it does the job and is easy to understand for most people.

An alternative would be to allow the user to build up a "dictionary" of URLs for the document which can be picked from as required. This would be useful for people who need to do changes en masse but might be going a bit too far for the average user.

One issue that springs to mind is how the user can be shown that a hyperlink is allocated to a piece of text. In other words, what (if any) formatting could be automatically applied to the text without messing up the user formatting? I don't think Scribus should change the text formatting so would putting a box round the text be reasonable? (The preview mode would also need to change/remove whatever automatic formatting is applied to show the real formatting.)

utnik

hi ale

i have some additions to garry's suggestions.

Quote from: GarryP on March 20, 2017, 10:43:35 AMA simple modal dialog can then pop up (possibly using the Qt WebEngine Widget) where the user can browse to the required page - or manually enter a URL - and then they OK the dialog which then closes.

this dialog could differentiate between:

       
  • web
  • email
  • a file
  • an anchor point in the actual file
QuoteOne issue that springs to mind is how the user can be shown that a hyperlink is allocated to a piece of text. In other words, what (if any) formatting could be automatically applied to the text without messing up the user formatting? I don't think Scribus should change the text formatting so would putting a box round the text be reasonable? (The preview mode would also need to change/remove whatever automatic formatting is applied to show the real formatting.)

a warning for unmarked hyperlinks might be useful. (but i'm not sure, what's best here...)

       
  • scribus could support something like automatically applied styles (i.e. a character style called 'hyperlink' which will be applied automatically as long as the user doesn't prevent it in some way.)
  • the preflight verifier could check for unmarked hyperlinks.
(both of them are difficult with other active areas than text...)
to test a link (go to the target) the user has to press a modifier key (i.e. ,ctrl') while clicking the active area.
as the active area can be any selection of characters and/or other objects, there are some special situations:
when i try to apply a hyperlink to a selection

       
  • which is part of the active area of another hyperlink
  • which contains the active area of another hyperlink
  • which intersects the active area of another hyperlink
...scribus should at least warn me – and, if possible, provide the following options:

       
  • cancel the action
  • delete the existing link while adding the new one on the actual selection
  • adding the new link wihle keeping the existing one by excluding the smaller active area from the bigger one. (doesn't work with intersecting areas...)
i know that i just opened a big bottle – so it might be better to skip some of my suggestions instead of making an eternal story out of it...

utnik

GarryP

#3
Some nice suggestions from utnik there.

For differentiation between link types (web, email, etc.), I would say that a tabbed dialog would be a reasonable first implementation. One tab for a web URL, one to add an email address (automatically adding the mailto), one to reference a external file, and one to link to something in the current document. I don't think it needs to be anything more complicated than that but I'd be interested in hearing about better ways of doing it.

One other thing that does come to mind is PDF Annotations. These are already a way of linking external/internal resources to certain types of Scribus objects. Would PDF Annotations be kept alongside hyperlinks or would they "merge" into one single thing? I don't know enough about the PDF specification to say how they work. It would be nice if there was just one dialog that the user could use, either for both things or modified to be used for each. It would be even better if the user didn't really need to know about PDF Annotations and just called all of these things "links" and didn't have to worry about any differences. Not "What sort of annotation/hyperlink do I need to use?" but more like "There, I just added a link, easy".

utnik: Could you explain what you mean by "unmarked" hyperlinks please? Do you mean URLs in the text that are not formatted as links, or hyperlinks that have no destination, or something else? (Just so I know if we are talking about the same thing.)

I'm not sure if I like the idea of using automatically applied styles for hyperlinks. Unless Scribus creates the styles on the fly - creating a character style from the formatting of the text and keeping it updated - it would have to apply a default style which will probably not be formatted the same as the rest of the text. The user would then have to go in and change the style formatting to match the text.

And then if there's a hyperlink in two bits of text that have different formatting, what happens then? If there's one hyperlink style then it's not going to match at least one of the bits of text a hyperlink is in. Or if you create multiple styles - one for each different formatting - then you could end up with lots of styles, some of which might be useless as the user has changed the formatting of the text. And then, if the user changes the formatting of the text that the hyperlink is in, how does Scribus then change the style to match? It would be a nightmare. And that's if the user is used to using styles. If they don't know how to use styles then all bets are off.

Linking the way hyperlinks are shown to the user by using styles would, in my opinion, be a very tricky thing to get right and whatever is done might be very confusing to the user (and not just beginners). That's why I suggested putting a box around the text instead. Something simple like in my attached screenshot would be fine. Scribus already knows how to draw a box round the text - that's how you know which text is selected - so it shouldn't be too difficult to reuse the code that calculates where to draw the hyperlink box.

As for intersections of hyperlinked text, I would say that it might be easier for Scribus to just override anything that already exists.

By way of example, say you've got some text "Hello to all Scribus users" and you add a hyperlink to "Scribus" the link would be (linked text shown in bold) "Hello to all Scribus users". Then if you selected "all Scribus" and gave it a link then the link would be "Hello to all Scribus users" linking to the new resource. If you then selected "l Scri" and gave it a link the link would now be "Hello to all Scribus users" linking to the new resource. Then if you created a link on "to all Sc" you would now have a link like "Hello to all Scribus users". Essentially if the selected text is part of - or intersects with - text that has a hyperlink then the new hyperlink overrides the existing link. I've tried to illustrate it better in my other screenshot. (Edit: I've mistakenly omitted the first instance but I think it's still clear enough.)

It's a bit simplistic and might not cover every possible need but it's easy to understand. Much easier than having embedded or overlapping links.

If I've misunderstood any of what has been said then please tell me.

[attachment deleted by admin]

CGood

Just a couple of immediate responses: I like what I'm reading here. I hope and assume it pertains only to Scribus output as a pdf on screen - not as Scribus generating a web page output. I have no interest in the latter.

I don't believe links should usually depend upon a visual change in the pointer upon pointer hover to be recognized. They should usually look distinct. Immediate visual differentiation and recognition makes life easier. A default link character style has appeal - as long as the link character style can be modified and made appropriate to the user's needs.

But then I have just opened the doors to making this a more involved project. But as long as I'm writing, should a link be created, in a perfect world it should have a style applied. But in this real world a character style could be manually applied and thus one could control all links with character styles.

utnik

hi garry

Quote from: GarryP on March 20, 2017, 02:27:15 PMCould you explain what you mean by "unmarked" hyperlinks please? Do you mean URLs in the text that are not formatted as links...

yes!

QuoteI'm not sure if I like the idea of using automatically applied styles for hyperlinks. Unless Scribus creates the styles on the fly - creating a character style from the formatting of the text and keeping it updated - it would have to apply a default style which will probably not be formatted the same as the rest of the text. The user would then have to go in and change the style formatting to match the text.

as i wrote before, i'm not sure, what's best here.
maybe an automatically applied 'standard link style' (might be marked by something like an underline) – and the 'preflight verifier' would check by default if a link is still formatted by this 'standard link style'...

QuoteAs for intersections of hyperlinked text, I would say that it might be easier for Scribus to just override anything that already exists.

i'm fine with that, as everything else might be a big deal to implement properly – but i see reasons to have hyperlink areas as part of previously defined ones. (i.e. if the source is a map and you have a link on 'asia', and now you need another one on 'nepal', i would prefere to keep the rest of the first link working...)

utnik

GarryP

CGood:

As far as I'm concerned, my comments only pertain to the output that Scribus can currently produce from the latest stable version. I'm only interested in PDF output here.

I agree that just changing the pointer isn't enough to mark a hyperlink. If the author didn't remember where they had created links - or they are getting the document from someone else - they would have to mouse over all of the text to find the links. Links should have some kind of persistent - on-screen, but not in preview mode - visual marking to show the user where they are.

utnik:

Thanks for clarifying that. There's probably still the issue of URLs that are in the text itself - I.e. "Go to www.scribus.net for the latest news" - but that might be taking things a bit too far at the moment.

Both:

As I said previously, I would advise against using automatic styles to mark hyperlinks. Doing so would create one of two situations:
1. A single "standard" hyperlink style that was applied to all hyperlinks. This would mean that all hyperlinks were formatted in the same way which would spoil any text that wasn't formatted in the same way as the style. Since hyperlinks can be anywhere in any piece of text - formatted by either styles or not - forcing them to all have the same formatting would not be a good way to go.
2. Multiple hyperlink styles. This would be horrible for both the developer and the user. The developer would have to make sure that Scribus updated the styles on-the-fly to conform to any formatting the user applied to the text and the user would have multiple styles to manage. Again, not a good situation.

This is why I suggested that the "look" of the hyperlinks would not be connected with any formatting that the user could apply. Personally I don't really have a problem with how hyperlinks look, as long as they are visually distinct from other formatting. This could be (see attached examples):
* a box (like I've suggested but I'm thinking that this is a bit too "in your face" now);
* a squiggle under the text (a simple underline may confuse the user if their text is already underlined or they might confuse a link for an underline and try and remove it);
* a little icon next to the text;
* a mixture of two of the above;
* or something else entirely.

As long as it's clear what a hyperlink looks like and it can't be confused with user formatting then that's fine by me.

To the clear: I have no problem with the user creating styles to manually format links but I think it would be a mistake for Scribus to be creating and applying them automatically.

utnik (again):

I think the preflight verifier could be used to highlight:
* hyperlinks that are not manually formatted differently - by either a user style or other formatting - from the rest of the text - e.g. there's a link there but no way for the reader to know about it;
* hyperlinks that have no valid target, e.g. a link was created to a text frame that no longer exists.

I'm not sure what you mean by having "hyperlink areas as part of previously defined ones". I can't remember seeing such an embedded link anywhere, either on the web or in a document. Do you have an example? As I understand it, it would be confusing to the user unless there was a way to show that there were multiple links active in the same bit of text. If absolutely necessary the user could define three links, the outer two to one target and the inner one to another. As you said, I don't think this is a big issue though.

[attachment deleted by admin]