Omnioutliner OPML transfer to Scrivener 2.0 loses hyperlinks

Scrivener Scrivener for macOS
1

I did an Omnioutliner OPML export then imported the OPML file into Scrivener 2.0.

I lose the hyperlinks. URLs just come across as text. Is there a way around this?

Or is their an easy way to quickly edit URL text to become hyperlinks inside Scrivener?

Thanks.

2

In some cases you can select and right click on the hyperlink text; if Scrivener recognizes it as a hyperlink, you’ll get a choice at the top of the context menu to “Make Link”.

3

Thanks MM, this works for simple URLs like www.yahoo.com but not for those with embedded %20’s etc. Any solution for more typical complex URLs?

4

Alas, none off the top of my head. You could make a shortcut for “Add Link…” then do what you’re doing but instead of right clicking when you select the hyperlink, copy it, pull up the “Add Link” dialogue and paste it there, and then hit “okay.” Doing it all with the keyboard will make it faster. If you have any addresses that start https instead of http, you’ll have to make sure that you switch from the default “web” to “no prefix” or they won’t come out right; regular http:// prefixes won’t get doubled even if you leave it on “web”, so you’re fine there.

5

I asked about this also here: [img]https://forum.literatureandlatte.com/t/url-handling-for-imported-documents/11501/1]

No reply from the Scrivener team as yet.

6

OPML is a plain text format, and so does not store information as links. Scrivener does not try to parse imported plain text files for links or any other possible formatting - trying to determine what might be intended as a link is more tricky than it may at first sound (especially when you consider custom links that are not generally well-known, such as sente://….).

7

Keith - That doesn’t make sense to me since the text entry system does parse them fine when I type them into Scrivener. I’m not a software developer (anymore) so can’t easily understand why the import can’t use the same logic… Oh well.

8

The parsing code is handled by internal Apple code and I’m no expert. Parsing every file on import is a different matter - not impossible, but non-trivial, and not on the roadmap at the moment, sorry. I don’t rule it out for the future though. (You’ll notice that likewise, if you create a plain text file in TextEdit and type a link, it will get detected, but when you save and re-open the file, it will not parse the link and it will be plain text.)

9

Here’s an idea for that future implementation as to how to identify what are hyperlinks on an import:
Caveat: I am not a Cocoa or OS X programmer, except for a little Applescript so I likely don’t know what I’m talking about! :slight_smile:

The URIs that are in use by OS X for any given user are stored in com.apple.LaunchServices.plist – Perhaps those URI strings could be loaded into a list that could be searched for (followed by the standard :// suffix), using regex perhaps, to form links. So any LaunchServices identified URIs followed by :// along with all subsequent non-blank text would be encompassed in the link? Just a thought, as I really know nothing about Cocoa and OS X programming except for a little AppleScript.

Here’s what the plist file looks like for one type:

<?xml version="1.0" encoding="UTF-8"?> LSHandlerRoleAll com.apple.quicktimeplayer LSHandlerURLScheme quicktime
10

OK, looking into this a little more, it appears the // is only for those schemes that include a naming authority. Since hyperlinks that are directed not at authorities but at resources do not include the // the format would be to look for text matching the LSHandlerURLScheme followed by : followed by the path so in the case of Sente URIs you’d be looking for something like sente:/my+library…

It appears that a slash is not required to begin the path component, so something like quicktime: might be a valid URI that would launch quicktime but not direct it at a particular movie? If you create a link in TextEdit as quicktime: it does launch Quicktime. Thus any text where there was a handler scheme followed by the colon character would infer a link, so typing “These are the features of Quicktime: (a)…” would create a link for the Quicktime: text, which would likely be undesirable.

Nevertheless, I think it’s unlikely someone would type a colon followed by characters other than a space in the normal use of English, so I think it might be safe to infer “quicktime:followedbyanytext” would be a link whereas “quicktime: followedbyanytext” would not.

The standard Mac OS text processing engine only recognizes :// as an indicator of a link, which is itself insufficient.

Details in the spec: ietf.org/rfc/rfc3986.txt Look at section 3, also section 3.3 for the path part.

11

Unless they are writing the time - 21:59 - or quoting Objective-C code:

[self setHasChanges:YES];

Or - looking up the use of the colon on Wikipedia - quoting the Bible (“John III:14–16”), or writing in Finnish or Swedish where colons can appear inside words, or writing certain phonetics…

Sorry, there are too many cases where many users may need to have a colon with no space after it. Thanks for taking the time to think about it though and offer suggestions.

All the best,
Keith

12

No problem. I used to work for a company whose management mantra (for better or worse) was “bring solutions, not problems,” and so I tend to work that way now. :slight_smile: