Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Hyperlink to local file in filesystem generate a wrong relative path|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||dager.rel, issues, michael.brauer|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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> </text:p> 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 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 http://www.oasis-open.org/committees/download.php/35090/OpenDocument-v1.2-part3-cd1.odt or 17.5 of http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.odt 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 HTTP/FTP. 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 link??). "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.