Bug 115236 - Don't strip out "." from hyperlink file://./subdirectory/file.xyz when exporting to SVG
Summary: Don't strip out "." from hyperlink file://./subdirectory/file.xyz when export...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Hyperlink
  Show dependency treegraph
 
Reported: 2018-01-26 02:46 UTC by UbunLibOffImp
Modified: 2023-06-15 09:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Confirmed that in 6.0.1.1 LO makes a mess of hyperlinks when a *.ODP is exported to *.SVG. (147.01 KB, application/vnd.oasis.opendocument.presentation)
2018-02-26 22:25 UTC, UbunLibOffImp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description UbunLibOffImp 2018-01-26 02:46:52 UTC
Description:
Environment = Ubuntu 16.04 & Firefox 58 & LibreOffice Impress Version: 5.3.7.2 & 5.1.X.X

There are many interrelated problems pertaining to the way LibreOffice Impress handles the export of URL(URI) links.

a] Impress will completely ignore/remove a relative link when a *.odp is exported to type *.svg
(example [a] = Insert > Link type > Internet > Web > URL: "./subdirectory/file.xyz")
(result  [a] = when the *.svg is opened in above listed web browser, no hyperlink(s) will exist)
 
b] Impress should never convert the characters "file://" to "smb://" when a *.odp is exported to type *.svg
(example [b] = Insert > Link type > INTERNET > Web > URL: "file://./subdirectory/file.xyz")
(result  [b] = when the *.svg is opened in above listed web browser, hyperlink becomes "smb://./subdirectory/file.svg" and is dead)

c] Impress should never strip out "." character when used as the first character in a relative link in a *.odp that is exported to type *.svg
(example [c] = Insert > Link type > DOCUMENT > DOCUMENT PATH: "file://./subdirectory/file.xyz")
(result  [c] = when the *.svg is opened in above listed web browser, hyperlink becomes "file:///subdirectory/file.svg" and is dead since it is not resolved correctly)

- The use of the file protocol (file://) was an attempt to workaround the fact that Impress cannot correctly embed relative links when exporting a *.svg
- Usage of the file:// protocol was a futile effort to try to get a relative URL within the *.svg to resolve correctly such that the *.svg can be used without absolute links
- Piles of unnecessary JavaScript had to be added to every web link in order to parse the location URL of the *.svg and then generate a URL for the hyperlink resource
- Please carefully review the concept of baseURL as it pertains to a *.svg created by Impress that has local filesystem links
- It is difficult to report more errors since the above listed items are so fundamental that additional items can't be dealt with until basic functionality is established.

Steps to Reproduce:
a] Impress will completely ignore/remove a relative link when a *.odp is exported to type *.svg
(example [a] = Insert > Link type > Internet > Web > URL: "./subdirectory/file.xyz")
(result  [a] = when the *.svg is opened in above listed web browser, no hyperlink(s) will exist)
 
b] Impress should never convert the characters "file://" to "smb://" when a *.odp is exported to type *.svg
(example [b] = Insert > Link type > INTERNET > Web > URL: "file://./subdirectory/file.xyz")
(result  [b] = when the *.svg is opened in above listed web browser, hyperlink becomes "smb://./subdirectory/file.svg" and is dead)

c] Impress should never strip out "." character when used as the first character in a relative link in a *.odp that is exported to type *.svg
(example [c] = Insert > Link type > DOCUMENT > DOCUMENT PATH: "file://./subdirectory/file.xyz")
(result  [c] = when the *.svg is opened in above listed web browser, hyperlink becomes "file:///subdirectory/file.svg" and is dead since it is not resolved correctly)

Actual Results:  
a] Impress will completely ignore/remove a relative link when a *.odp is exported to type *.svg
(example [a] = Insert > Link type > Internet > Web > URL: "./subdirectory/file.xyz")
(result  [a] = when the *.svg is opened in above listed web browser, no hyperlink(s) will exist)
 
b] Impress should never convert the characters "file://" to "smb://" when a *.odp is exported to type *.svg
(example [b] = Insert > Link type > INTERNET > Web > URL: "file://./subdirectory/file.xyz")
(result  [b] = when the *.svg is opened in above listed web browser, hyperlink becomes "smb://./subdirectory/file.svg" and is dead)

c] Impress should never strip out "." character when used as the first character in a relative link in a *.odp that is exported to type *.svg
(example [c] = Insert > Link type > DOCUMENT > DOCUMENT PATH: "file://./subdirectory/file.xyz")
(result  [c] = when the *.svg is opened in above listed web browser, hyperlink becomes "file:///subdirectory/file.svg" and is dead since it is not resolved correctly)

Expected Results:
When a user exports a LibreOffice Impress document to the file format SVG, the user expects that hyperlinks associated with the text and imagery will actually function when the SVG file is opened in a web browser such as FireFox.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Note: LibreOffice Documentation is not accurate. There are two checkboxes that are not referenced in the Help citation. The Help files do not address the reality of the UI.

Choose Tools - Options - Load/Save - General and specify in the Save URLs relative to ??? FIELD ??? if LibreOffice creates relative or absolute hyperlinks. Relative linking is only possible when the document you are working on and the link destination are on the same drive.


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Buovjaga 2018-02-15 20:09:13 UTC
The issue a] is reported as bug 103454.

Before I continue, could you please test the other bugs with 6.0? An easy way on Linux is appimage: https://www.libreoffice.org/download/appimage
Comment 2 UbunLibOffImp 2018-02-26 22:25:14 UTC
Created attachment 140168 [details]
Confirmed that in 6.0.1.1 LO makes a mess of hyperlinks when a *.ODP is exported to *.SVG.

See attached *.ODP created using AppImage Fresh 6.0.1.1
Comment 3 Buovjaga 2018-02-27 18:05:20 UTC
I could not reproduce b]. I do reproduce c], so let's change summary.

Perhaps b] is specific to Ubuntu. Anyway, each issue should have its own report, so do open a new one for it. Same for this, using Documentation as the component: "Note: LibreOffice Documentation is not accurate. There are two checkboxes that are not referenced in the Help citation. The Help files do not address the reality of the UI."

Arch Linux 64-bit
Version: 6.0.1.1
Build ID: 6.0.1-1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 0b49701fa5c22abba6b9b4a60ddd2720973dd858
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on February 27th 2018
Comment 4 QA Administrators 2019-02-28 03:51:41 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2021-02-28 04:00:17 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2023-03-01 03:21:54 UTC Comment hidden (obsolete)
Comment 7 Stephan Bergmann 2023-06-15 09:24:58 UTC
(In reply to UbunLibOffImp from comment #0)
> c] Impress should never strip out "." character when used as the first
> character in a relative link in a *.odp that is exported to type *.svg
> (example [c] = Insert > Link type > DOCUMENT > DOCUMENT PATH:
> "file://./subdirectory/file.xyz")
> (result  [c] = when the *.svg is opened in above listed web browser,
> hyperlink becomes "file:///subdirectory/file.svg" and is dead since it is
> not resolved correctly)

(<file://./subdirectory/file.xyz> is not a relative URL.  It is an absolute file URL whose authority component is a host denoting the registered name "."; whatever that is supposed to mean semantically.)

I cannot reproduce this claim of LO stripping out ".":  The resulting svg file contains the exact text "file://./subdirectory/file.xyz" eight times.  It does not contain "subdirectory" in any other place (i.e., it does not also contain the text "file:///subdirectory/file.xyz" or something similar), which could indicate that LO does garble the specified <file://./subdirectory/file.xyz> URL when exporting to svg.

(When I open that svg file in Firefox, following the link makes it indeed try to open <file:///subdirectory/file.xyz>, dropping the "." host.  But that appears to be an issue of Firefox.  In its inspector window, one still sees

> <a xlink:href="file://./subdirectory/file.xyz">file://./subdirectory/file.x</a>

as the source of the link.)