Issue 98211 - Hyperlink to local file in filesystem generate a wrong relative path
Summary: Hyperlink to local file in filesystem generate a wrong relative path
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 3.0
Hardware: Unknown Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-01-19 02:30 UTC by linda_octa
Modified: 2017-05-20 10:45 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Test file (84.34 KB, application/x-compressed)
2009-01-19 02:31 UTC, linda_octa
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description linda_octa 2009-01-19 02:30:34 UTC
When a hyperlink pointing to local file in the filesystem, OO generate a wrong
relative path.

The link in testing.odt is pointing to the file 1.gif in the same directory.
However the content.xml shows:
<text:p text:style-name="p">
<text:a xlink:type="simple" xlink:href="../1.gif">link to file 1.gif</text:a>

Although the exported pdf and html links pointing to the correct 1.gif file,
shouldn't be the xlink:href contain the value of "1.gif" instead of "../1.gif"?
Comment 1 linda_octa 2009-01-19 02:31:13 UTC
Created attachment 59467 [details]
Test file
Comment 2 gkaragoulis 2009-01-28 17:00:01 UTC
I also have problems with this.  I try to make a link to a local folder but it
overwrites the <A HREF="file://///blah/blah"> with <A HREF="">.

This even happens if I open a file with these types of links and save them using
open office writer.  All the links become broken.  Please fix!
Comment 3 eric.savary 2009-02-16 15:24:25 UTC
@MBA: please have a look
Comment 4 fredhan 2009-11-12 16:24:49 UTC
I agree with all the above observations: the system (OO 3.1.1, running under
Windows Vista) is unable to handle relative URLs – and this is, for me, a major
problem (sufficient to rule out the use of Open Office).

It seems that this bug, or a closely related one, has been present in OO since,
at least, version 2.2. Its roots seem to lie in a muddled and unclear
specification of the functionality that is desired, and in the accretion of
layers of bolted-on fixes that have attempted to address one or other aspect of
the problem. To identify just three of these:

1.It is curious the way that the means to specify whether a link is to be
interpreted in relative or absolute terms (within an original OO document, or
within its pdf or its html derivitives) is specified in a remote Options box.
Since, in general, one will be using both relative and absolute links in and
between a set of documents, it would seem much more natural that the choice of
relative or absolute be specified at the same time as each link is specified.
(Given this separation, it is not clear at what stage the absolute/relative
status is bound to the link: suppose one creates a link and then, at a later
stage, changes the absolute/relative status in the Option box, will this affect
the link -- or will it only affect links created in the future? And is it
intended that the link created in OO works in the same way in both pdf and HTML
derivitives of the OO document, or are these independent choices?).

2. Another feature I find surprising is that Tools => Options => Load/Save =>
General leads to an option box which presents, as *independent* choices: "Save
URLs relative to file system" and "Save URLs relative to internet". Surely these
should be mutually exclusive choices? (And what, in fact, is "Save URLs relative
to the internet" intended to mean?)

3. And yet another curious aspect is that there appear to be two independent
ways of specifying a hyperlink: either to click the hyperlink button on the main
toolbar (which drops down a box giving a set of options) or alternatively, to
follow Format => Character => Hyperlink, which leads to an apparently unrelated
mechanism for inserting a hyperlink. Is one a simplified version of the other,
or do the two mechanisms perform distinct roles?

The actual task (to be able to generate both relative and absolute URLs) is an
almost trivially simple one, and does not need anything like such an elaborate
set of mechanisms as are presently in place. The best solution would be to begin
by writing a clear, simple specification of how relative and absolute URLs
should be handled (both in OO documents, and in any pdf and html derivitive
documents),  stripping out the existing mechanism (including the various options
scattered around the place) in its entirety, and replacing it with a simple,
clean implementation.

Comment 5 Mathias_Bauer 2009-11-12 20:11:59 UTC
Michael, please comment.
Comment 6 michael.brauer 2009-11-13 13:11:25 UTC
The original issue that was reported is that relative hyperlinks that reference
a local file are wrong. Actually, they are not wrong. They are correct. How
relative URIs behave is defined in the ODF specification. One may look at
section 2.7 in
or 17.5 of

Essentially, relative URIs are resolved as like they would if the ODF document
would not be a zip file, but a folder with the name of the zip file. Which
means, that an URI "./styles.xml" contained in the file "content.xml" which is
in the root of the zip file references the file "styles.xml" in the root of the
zip file. To reference a file outside the zip file, one has to add "../".

Regarding the comment from gkaragoulis: "file://///blah/blah" seems not be a
valid URI to me. That may be the reason why it is removed.

Regarding the comments from fredhan:

1) Documents in OOo always contain absolute URIs only. Relative URIs contained
in a document that is loaded are made absolute while the document is loaded as
defined by the ODF specification (or the HTML specification in case of HTML
documents). The absolute URIs can be turned into relative ones while the
document is stored. This is controlled by the two options mention in 2).

2) The one option controls whether file URIs should be turned into relative ones
if a document is stored in the local file system. The other one controls whether
FTP and HTTP URIs should be turned into relative ones if a file is stored using

3) OOo provided two alternative ways to add hyperlinks. Why should that be an
issue. Where are also multiple ways how to format a piece of text let's say in bold.

Summary: There is no defect, but the handling of relative URI may be changed.
That would be an enhancement of feature.

Comment 7 fredhan 2009-11-18 17:55:05 UTC
Thanks for the response. But it does not answer any of the substantive points
made by the contributors:

"How relative URIs behave is defined in the ODF specification...  Essentially,
relative URIs are resolved ... as they would be if th ODF document would be ...
a folder with the name of the zip file".

The way that OO documents are internally represented (viz, as a zip of a
subdirectory of a collection of component files) is an implementation detail: as
such, it should be totally invisible to a user. If the present OASIS spec
suggests that an end user needs to write relative references wrt this hidden
subdirectory, then this aspect of it is in need of urgent revision. (It is as if
page numbers had to be expressed in hexadecimal simply because, internally, they
are represented in binary!).

"... To reference a file outside of a zip file, one has to add "../"."

In common with one of the contributors (and with others in the OO User Forums),
I have found that  any attempt to specify a relative URL, result either in the
generation of an HREF link (as visible in the content.xml file) that is null, or
that treats the given target filename as the hostname in a URL. For example,
specifying the target as  foo.html  (or as ./foo.html or as ../foo.html) 
results in either an HREF of "" (ie, null) or of "http://foo.html"  (a hostname
with a null pathname). Worse than that, however, it sometimes displays it (as a
tooltip, when hovered over) as a null and then, when the .odt file is saved and
then reopened, it displays it in the other form.  Although (thanks to the
explanation you offered about the purpose of the "Save URLs relative to"
options), I have managed to generate relative URLs with the "file" access
scheme, I have not managed (despite exhaustive experimentation) to do so with
the "http" scheme.

"Documents in OOo  always contain absolute URIs only."

It looks as if it is this decision that is at the root of the problem. (As an
aside: it is incomprehensible how this decision was arrived at: unless relative
links can be expressed, a collection of documents is forever rooted to its
original file location.) The consequences of this decision have given rise to a
quite unnecessary explosion of complexity and attendant implementation bugs. 

"OOo provides two alternative ways to add hyperlinks. Why should this be an issue?"

One approach (via Format)  offers the possibility of associated events and
macros, and a choice of link styles; the other (via the Hyperlink tool) offers a
much richer set of link schemes. The relation between these two mechanisms is
far from obvious to the casual user (maybe they generate different kinds of

"Summary: There is no defect"

Sorry, I disagree: there are defects with both the underlying conceptual scheme
for relative links and with its implementation. These problems  appear to have
been around for a long time (eg, see Issue 56629 from 2005).

My own summary:  Overall, OpenOffice is superb in concept and well implemented
in practice. But, in failing (in both specification and implementation) to
handle relative links between documents, it excludes itself from other than
single-document tasks. 

I repeat my original plea (that a clear simple specification should be written
for the handling of relative and absolute URLs,  that the existing mechanism
should be stripped out in its entirety, and that it be replaced with a simple,
clean implementation).
Comment 8 michael.brauer 2009-11-23 08:29:22 UTC
First of all, we strictly have to differ between a document loaded into OOo
where hyperlinks are accessed by the UI, and hyperlinks stored in ODF.

The initial issue said that hyperlinks are stored wrong in ODF. I explained why
this is not the case, of cause, by referring to ODF.

End users of cause do not have to know that. They insert links to resources.
These resources have URIs. These URIs are absolute, but they may be stored
relative. Storing them relative requires a so called base URI, which allows to
make the URI absolute again.

In a new document which has not been stored, there is no such base URI. And even
if a document has been stored, it may be stored somewhere else the next time.
This would change the meaning of any relative URI. That's exactly the reason why
OOo uses absolute URIs internally. If you have loaded a document and save it
somewhere else, you probably don't want that embedded hyperlinks reference other
files. So, one could see it this way: If you insert a hyperlink, you do not
insert a URI, but a link to that resource. The URI is just an implementation detail.

Of cause, there are experts like you which would prefer to insert just URIs,
including relative URIs. But relative URIs have all the problems I mention
above, because they are valid only in stored document (but not in a document in
memory which could be stored at an arbitrary place next time), and because they
depend on the definitions of the file format that is stored.

So, I still would say there is no issue.
Comment 9 Marcus 2017-05-20 10:45:37 UTC
Reset the assignee to the default "".