Show or find all hyperlinks as the Navigator does not work

English
,
#1

Version: 7.6.0.3 (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)

#2

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.

#3

updated, thank you

1 Like
#4

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.
.
Bitmaps:
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 .w3.org/1999/xhtml” - spaces added for better understanding).

Version: 7.5.5.2 (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
#5

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

#8

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.

#10

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.)

#11

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.

#6

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)

#7

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)

#9

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.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.