Underlined internal links when compiling to RTF?

For my printouts, I used to compile to PDF then print.
For technical reasons, I am no longer doing this, but rather compiling to RTF then print.

But I have this issue that I can’t seem to resolve:
When compiling to PDF, my internal links are underlined, and print as such. (I print in B&W, and therefor, without the blue font, that’s how I know a link is actually a link.)
Except that now that I am compiling to RTF, I just can’t get my internal links to compile with the underline. (They are not blue either, but that I don’t care.)
Is there a setting somewhere I would have missed ?

[EDIT] As this thread developed, I realize that I had the above statement wrong. It doesn’t work for PDF either. I just happened to notice the issue quite some time after changing my approach to compiling for a printout from PDF to RTF, and thought it worked for me back then. (I probably just got lucky as to my compile scope at the time. I wasn’t doing things quite as I do now.)

P.S. I can manually underline my links in the editor and that works, but I’d prefer not.
I can totally see myself forgetting about that extra step in the rush of things… Made worse by the fact that I have no visual cue until I compile.

I have this option checked in the compile panel:
I tried with and without : that made no difference.

The whole of my compile options


. . . . . . . . . .
These work (so I know the issue is not with the other app (LO) I use afterwards) :


Hello Vincent_Vincent. You might customize your RTF compile settings and confirm that the Compatibility options have the “Ensure hyperlinks are colored and underlined” setting is ticked.

If it is but you’re not seeing the hyperlinks colored and underlined when you view the output file on your PC, then we’ll look at some other settings.

1 Like

Hi Ruth :slight_smile: Thanks for hopping in.

I have the compatibility setting checked.

Let’s try this:

I’ve slapped together a project with two hyperlinks and compiled them to RTF using the default compile format.

If you compile this project on your PC, what results do you get?

I’m curious if just a simple project will work or if it’s also an issue.

testing [2023_01_19_16_08_25].zip (10.8 KB)

1 Like

I compiled once with the default compile format, and once with my own compile format.
Both compiles were successful.

But these are not internal links… (?)

I will add a document to that test project, internally link to it, and test again…

. . . . . .

This is compiled through the default compile format:



… A few seconds later >>
Oh wait… Hey!
It suddenly worked with my own compile format… ???
(Probably the compatibility setting, plus what follows)

I figured it out (partially? – perhaps totally) :
The link isn’t formatted as a link if the destination document is NOT part of the compile…
That’s an issue in my case. (I am compiling the printout of chapters one at a time, whenever and whichever I need. I am not gonna compile the whole draft each time, then look for the chapter’s pages numbers, so that I can print only that one chapter…)

If I can understand and agree with the logic of the above, I think the compiler should at least format a link as a link whether or not the destination document is included in compile with that option checked:
…but it does not.

I don’t compile with internal links like this often enough to know if that’s expected behavior or not.

I’m hoping wiser heads like @AmberV or @MimeticMouton might stop by and review this…

Meanwhile… thanks for your input.
Much appreciated. :wink:

Yes, I’ve discovered the same thing when testing output for Mastering Scrivener. I think it’s somewhere in the book. :slight_smile:

1 Like

Yeah, if there is nothing to link to, we remove the link. That is nearly always going to be a better result than a reader clicking on something and being presented with an error message like, “Unrecognised link protocol: scrivlnk://9EB75FB3-5A5E-4B65-9DC6-BC3C13DD303E”. Plus it allows for one to heavily link to research without fear of having to strip everything out by hand when they are done.

That said, I do see the logic in having an exclusion to that rule if the internal-link conversion checkbox is enabled. At that point we clearly aren’t distributing proofing copies or something, and the intention is for the output document to be within the same domain as the original project, thus making the invalid links valid.

I’ll write it up as a potential improvement.

1 Like

Thanks @AmberV and @RuthS

With the behavior confirmed, I have then dedicated a character attribute style to internal links which allows me to restore the underline comes printouts.

It might prove also useful to completely remove those links from the body text (not just the decoration), while preserving web links, some time in the future. (?)

It does the job and gives me a visual cue as to whether the style was applied or not, having set the highlight box for that character attribute style.

Meanwhile, thanks for noting it down as a potential improvement.

P.S. I am otherwise wondering if, for maximal convenience, there could be some automatic way to handle this, using a RegEx formula in the replacements tab of one’s compile format?
I know RegEx doesn’t impact stuff like whether text is underlined or not, but in this case perhaps just add a prefix and a suffix to the link (brackets or something) without having to systematically apply a style to those links in the editor? (Settings in the Document Title Links panel do nothing in this context.)
→ So, is the link still a link by the time it passes through the compile format’s replacements is to be considered too… not just whether RegEx could or not. (I can’t currently answer that question on my own.)

More even: I myself never really got into RegEx formulas, so if someone could help or provide the formula, it’d be much appreciated. Thx.

This is the kind of flexibility I get by using Markdown. :wink: Since the hyperlink in Scrivener can be completely internal, while links you want the reader to see use simple bracket markup like on the forum here, you can choose whether any link is internal-only, external-only or global, by whether there is a hyperlink, brackets around text, or brackets around a link.

But yes, I think you might have luck with your replacement idea, and I don’t think you would need to add the complexity of RegEx to do it. The way replacements should work is that if the string they replace is formatted, then the formatting carries through (not unlike selecting the range of text and typing). If however the replacement starts outside of the formatted range, then the formatting is “cleaned”. Hence, if you put your link in a bracket like so: “This is [the hyperlink] but the brackets are outside of it”, then the following would work:

Replace: [$@]
With: $@

Now the text ceases to be linked because the range of replacement starts with the unlinked bracket. In case you’ve never used it before, $@ is a capture wildcard, similar to how one would use parentheses to capture a string from a regular expression, and then later print it with $1.

So that would be your production Format, and for the proofing one, where all links are left in, you’d simply nuke all the brackets by themselves, leaving the link text alone. Obviously if you use brackets for legitimate purposes elsewhere, there is probably a better marker to use, but the point should be suitably illustrated.

link_replacement.zip (150.0 KB)

In the sample project, the green highlights are simply there to help find link locations (or lack thereof) in the output. Note that both the “Retain links” and “Strip links” formats remove the brackets—it’s how the brackets are used that matters.

It might prove also useful to completely remove those links from the body text (not just the decoration), while preserving web links, some time in the future. (?)

Ultimately I feel linking and cross-referencing—and how the two are conflated into a big tangle of settings—needs to be completely revisited in the future, as it has grown up to be a confusing system that forces choices that shouldn’t have to be made.

It reminds me of the mess that evolved during v2’s design, where there was the Formatting pane (Section Layouts now), and Preserve Formatting, and then a tangle of if-then-but-else checkboxes to try and effectively solve a problem for which there was already a good answer for: Styles. In this case the simpler answer is: Cross-References, not links with a dozen settings and happenstance naming collisions (only a Document Title Links eligible link if the text of the link precisely matches!).

1 Like

I have fiddled a bit with the [$@] replacement approach and will do a tad more later on, but so far I can’t get it to work.

I have the feeling that the reason it doesn’t work is that the text wasn’t ever really underlined, as it gets its underline from the link decoration.
So replacing [$@] with $@ removes the brackets, but doesn’t underline $@, as it wasn’t before.
(Or it is just me who did it wrong. Which is very possible.)

One way or the other, since this method involves adding brackets (or whatever other symbol) to the link, and the editor trying to make it part of the link (I have to also insert a space first, then remove it), might as well stick to using a character attribute style, which gives me a strong visual cue as to whether the operation was done or not.

Your input no less appreciated.

I’ve compiled your demo project using the “retain links” compile format embedded in it.
But compiling only the first document, it didn’t preserve the look of a link for the links to that second document…

I got the same result with the other compile format. “Strip links”.

. . . . . . . .
(Before someone asks) :wink:image

I’m not sure why you’re getting a different result with the same settings, so it must have something to do with how the output is being reviewed.

As for underlining text that isn’t a link anymore, yeah I can’t really help with that.

The underlining is pretty much the only thing I paid attention to.
What did I potentially miss ?

What if you compile only the first document ?
Don’t you get the same result as what I screenshotted ?

Oh, sure, but then we’re going over ground already covered above, about internal links to items not in the compile group being stripped out.

I don’t really know what’s going on with underlines. I can’t get that result and would need more data to reproduce it. Maybe the compile Format, since you mentioned at one point that seemed to make a difference.

Sorry, my bad. I thought that $@ was a solution you proposed as to get those links-no-more-links underlined.

Perhaps. But I lost track at this point.

Anyways, since there is no automatic solution to the underline, I’ll just go with a character attributes style. It works. And it is not that much trouble to implement in my workflow.
→ As a matter of fact, since right-clicking a link selects the whole of the link’s text, it is quite fast to do.
I’ll survive. :wink:

Thanks. :slight_smile:

1 Like

Yes, to clarify that was specifically to address the desire of being able to choose which links are for your own use vs cross-references or web links that are meant to be public:

It might prove also useful to completely remove those links from the body text (not just the decoration), while preserving web links, some time in the future. (?)

In other words this is one of those cases where there isn’t a checkbox for it, but you can build that capability from Scrivener’s general purpose feature set. As the whole bit about using regex came after that line, I just assumed you were looking for a way to do that.

All I was interested in was to have my links look like links so that they would print underlined.
This just came in as a bonus potential usage. Once I went for the character attributes style solution.

It’s all fine.

Otherwise yes, I now understand what the $@ was/is for.

And thanks again for your input. :slight_smile: