Show or find all hyperlinks as the Navigator does not work

Version: (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-CA (en_CA); UI: en-GB
Calc: threaded

Hello, I meet a unnatural Text Document .odt(converted from Microsoft Office 2021) which has hyperlinks to web in body texts. And links work. And in Navigator it shows 0 Hyperlinks. And in Accessibility Check there are suggestions for them.

So, may I know what is the method to definitely detect all hyperlinks? Thanks!

Sample file
Untitled 1.odt (9.6 KB)

Please upload the .odp file here. At least a smaller version of it (delete the unrelevant pages).
Then we will able test it with older versions of the LO, and we will able to examine those hyperlinks.

updated, thank you

1 Like

Use the Swiss Knife for LO Writer: AltSearch.oxt
Text (Asian type and Latin type):
AltSearch.oxt: You can find hyperlinked texts with the included hyperlink; if you set \o in the replace line the found text is replaced by the URL of the link.
Only Latin Textformat:
Hyperlinks are found in the Navigator.
Hyperlinked bitmaps seem to be objects without being recognized as such.

To find every link you could extract the content.xml and search for xlink:type=“simple” xlink:href, which is followed by the user added links’ URLs.
If you search for “http.*?”(regular expressions) every link is found but the built-in links as well (e.g. “http: // www” - spaces added for better understanding).

Version: (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Ubuntu package version: 4:7.5.5~rc2-0ubuntu0.20.04.1~lo2
Calc: threaded

1 Like

If you find that LibreOffice is not working as expected then you should report a bug, How to Report Bugs in LibreOffice - The Document Foundation Wiki

Sorry to participate late in the discussion.

I experimented a bit on the provided sample file. I dumped it as .fodt to have easy access to the XML encoding.

I don’t know if the problem comes from an error during the conversion process, but it seems the Navigator is very picky about its items. An XML element qualifies as a Navigator-hyperlink if either text:style-name= or text:visited-style-name= is equal to Internet_20_link or Visited_20_Internet_20_Link. Both of which are the built-in expected character styles for links.

Since user can choose some other style for links, the correct detection criterion is probably <text:a or, in case it is also used for cross-references <text:a xlink:href=.

When character styles are modified for one of the built-in styles, hyperlinks are listed again in the Navigator.

Yes. Interesting.
I personally didn’t investigate much, but looked for a workaround.
Anyway I still think there must be a bug, and if qualifying as a hyperlink depends on the CharacterStyle, this would be part of that bug.
… …
The successful workaround I supplied, however, doesn’t change the style.
On the other hand it triggers an automatism setting hard attributes: the color to #000080 (=128: medium blue) and underscore to single.
On the third hand :wink: the link is still accepted for the navigator if I revert these changes and this persist over save/reload.
Without putting it on a fourth hand, I would state that there is an inacceptable inconsistency if a TextPortion can be a working hyperlink neither being emphasized correctly nor being shown in the navigator.

… …
Well, the implementation of hyperlinks based on a character property in Writer is a mystery to me, anyway. Probably there are ends which are incompatible with compatibility?
Not so well, I’m not the right one to report the respective bug. (More than 30 open.)

I think you’re right. Detection of an hyperling should be base on <text:a …>. I didn’t investigate to see if <text:a …> is used in other contexts than hyperlinks. It likely is because this a long used tag (HTML <a>) to jump to other parts of a page or to other pages. So, the decision criterion is probably more subtle than just <text:a> but the Navigator can surely do it.

The problem is most likely created by an error during the conversion and related to the “complex” script.
For a probably intended solutiuon by user code see the returned example which now conatains a few lines of Basic code.
To do the trick for lots of links probably contained in subordinate text objects, some more parsing is needed.
disask95176makeHiddenLinksNavigatable.odt (10.8 KB)

Since the questioner found the time to check my answer, I also took the time to complete the code as needed if the contents of TextTable objects and of TextFrame objects shall also be treated. See attachment.

A bug report (as @EarnestAl suggested) should also be a good idea. If one is (was?) filed, a link to it should be given in this thread.
(Sorry. I chose a too large image for the “negative demonstration” concerning hyperlinks assigned to graphical objects.)

disask95176makeHiddenLinksNavigatableZ).odt (582.5 KB)

Yes, I have read your codes, thank you. However, I can’t submit a bug report on my own now. Everyone is welcome to do this.