Feature request: hyperlinks to external files

[harryhoffner]

I often need to establish a hyperlink inside a document to either an Internet web site/page or to another document on my hard drive. This can be done in MS Word, but not in Mellel. The hyperlink to the Internet page can also be done in Nisus. I would love to have this capability in Mellel.

Thanks.

[Nick Sloan]

I second this. It is a feature I have been hoping to see in Mellel for a very long time.

[rpcameron]

I suppose it depends on how you wish it to be expressed. But, how should links be handled? Should a certain stream of text be able to be selected to a link? If so, what determines the link? Protocol? Address? Extra parameters?

Word does this because it tries to do everything. Nisus does this because TextEdit does this because Word promotes this, and therefore RTF does, too. But if you want links to files, how are those to be addressed? If you do it by standards and protocols, then it needs links to the file:// protocol. But if you do that, what are the links in relation to? The file? The root filesystem? Relative to the original file? What do you use to determine the root?

As long as it is not the standard response of the program to create a link upon seeing a string with "://", then this can be acceptable. However, perhaps a true "stream" element (somewhere between character and paragraph) will help further this desire for hyperlinks?

[harryhoffner]

I'm not sure if the "you" in the question refers to me, or if it just means "one". I certainly do not need to concern myself with how the Redlers handle these complicated issues. As an end user I am concerned only with the availability of a desired feature and its proper functioning. I have no vested interest in either praising or bad-mouthing Word, Nisus, or any other competing program. I know that in those programs their feature works, because I have used them satisfactorily. If the Redlers wish to use a different method to accomplish the desired end, that's fine with me. I just want this feature as soon as they are able to implement it. I am glad to see that at least one other user has seconded the motion.

[kjmatthews]

@harryhoffner, I think you've misunderstood rpcameron's point. As a user who is "concerned only with the availability of a desired feature and its proper functioning," it is most assuredly in your best interest to weigh in as specifically as possible regarding what that desired feature and its proper functioning entail.

I also concur with rpcameron that I have no wish to see Mellel automagically recognize and mark up things that look like links by default. If this feature were implemented, I would prefer that the user be required to intervene to make text look and act like a link, rather than requiring user intervention to revert it back to simple text.

[rpcameron]

I apologize if my previous post was a bit misleading or obtuse. Yes, the "you" referenced is "the user", not any particular individual. And although you may not care how it works, the way in which it is implemented will affect workflows. Perhaps a couple of examples might help:

1. Relative v. Absolute File Paths (and how they're resolved). When you link to a file, how Mellel references those files may change your workflow if you use the feature. Relative paths would mean "images/example1.png" and "notes/example2.mellel" are referenced in your main document. They are looking for a file called "example1.png" in a directory called "images", and that directory named "images" is in the same location/directory as your main document; a second referenced Mellel file named "example2.mellel" is in the "notes" directory which is in the same location/directory as your main document. Now, what happens if you move your main document? With relative file paths, if you do not move both the "images" and "notes" directories to the same new location where you moved your main document, then you will no longer have access to "example1.png" and "example2.mellel".

A similar problem would occur if you use absolute file paths. If you want to link in "~/Documents/images/example1.png" and "~/Documents/notes/example2.mellel", you can do that, and you would not notice any difference from relative file paths. This might be nicer, too, because your "images" and "notes" directories do not have to be the same place in relation to your main document. However, if you ever move, rename, replace or delete the referenced files, then your link will be useless.

What happens if you want to send your main document to someone else to take a look at, but they only download the main document, then what do you do? They do not have a copy of your linked files, and the purpose of linked files is lost. Or if they download only the main file, but they have files named "example1.png" and "example2.mellel" in the locations where the main document is going to look? The links would work, but would reference the incorrect document.

2. Network Locations. Network locations are represented by a well-defined format know as a URI scheme. This is probably the most common method of linking items externally. However, this type of linking requires network access, and not all viewers of your document may have the necessary access.

3. Styles. How are these links to be indicated? Are they going to have a specific character style applied to them? It seems it would be necessary to introduce an intermediary style between the character and paragraph levels to handle these "stream" type of objects. (This "stream" entity would have further uses such as defining streams of text as one language or another, which is another often asked for feature.) Also, how would the the interface indicate that there are external links? Would the Microsoft model be adopted where all external links are bold-faced and underlined blue text? What about the consistency with the rest of the document?

4. Import/Export. How would sharing documents in other formats work? This is especially important for exporting documents. For linked files, would RTF export resort to RTFD or resolve the links and insert the files in place? How about Word export? Word supports linked files, but Mellel's Word export is actually RTF with a ".doc" extension. What effect does this have on that? Perhaps most important would be PDF. Mellel's current PDF export is quite limited. TOC export is not supported, and bookmarks are not preserved. How would external links be handled in PDF?

I'm not trying to be a spoil-sport, but these are real issues that can affect your workflow and how you handle/manage your documents. While one may not care about how the features are implemented, only that they "just work", how they work is important, too. If your desire is for just having a clickable link to some external resource, what happens when you want to share your document with someone else? If the person you've shared your document with sees an external link and tries to click it, but nothing happens because there were issues between implementations, then this would directly affect you. (True, this would not be the case if everyone was using Mellel, but in a real-world situation, how often does everyone you exchange documents with use Mellel?)

Hopefully these points can help everyone involved be more specific about what is desired, so that if/when it is implemented, it will work in the expected manner. There's nothing worse than hearing a new feature has been added, only to find out that while it sounds exactly like what you want, it really is quite different from what you were expecting.

[Nick Sloan]

I am sorry that it has taken me a while to respond to R P Cameron’s detailed explanation of the options here. I visit this forum rather randomly.

Speaking for myself, what I am looking for with links to external files in Mellel is simply the ability to extend the reach of Mellel by having separate but local documents (and online resources) readily referenced and openable from within specific Mellel documents, without having to hunt them down in Finder.

For instance: say I am writing an account of a dispute, and need to reference various related documents and folders without wanting to incorporate them all into one unwieldy document. I might choose to place links in footnotes, or in the main text, such that clicking them would open the external document or folder.

I would like the links to be editable within Mellel, so that however they are in the first instance set up, the reference in the text is not limited to the file name and certainly not the URL, but I would prefer to set or change the name manually. Likwise I would not expect (or want) Mellel automatically to style the text of the reference, again preferring to apply my own preferred style manually if I want to differentiate the reference from the surrounding text.

A link to an external ref should however be indicated by the cursor changing to a hand. It would also be helpful if the filename and/or URL were available as tooltips on hover, or via a contextual menu when control-clicking on references. Finally, it should be possible to search for such references.

While links to external files are implemented in different ways in Word, Nisus and Scrivener, the closest to my ideal (that I know of) would be Voodoo Pad, where items can simply be dragged onto a page to become clickable links; whether or not (and how) they are styled in the text being subject to preference. The only thing you cannot do in Voodoo Pad (there is always something) is to rename the link.

No doubt the interface for creating links in Mellel would be rethought from scratch. I would much rather use drag and drop for local files than have to browse to them or insert file system URLs manually, but anything that did the business would be welcome.

So, to answer the points in the post above (just speaking for myself here):
1) Absolute paths (accepting the limitations, and in particular that any links to local items will be useless in shared documents; that does not concern me, since I am only interested in links for personal use.)
2) Not an issue for me, though with online URLs the limitation would be assumed.
3) Ideally I’d like a preference for whether or not links are by default differentiated, for instance by underlining, but in any case manual over-rides should be possible.
4) Again, import and export is not for me an issue—and it would greatly simplify the implementation of the feature if Mellel-created links were simply ignored in exports to RTF etc, at least as far as links to local files are concerned; URLs to web pages (easily distinguished) could presumably be maintained and translated into whatever form is supported in RTF/DOC? I don’t know how this would work for PDF.

[harryhoffner]

Thanks, Nick. I think your preferences are mine as well. And thanks to others for their input as well.