Issue 56629 - PDF convert tool - relative links to files from file system are converted as URLs not
Summary: PDF convert tool - relative links to files from file system are converted as ...
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOO 2.0 Beta2
Hardware: All All
: P3 Trivial with 39 votes (vote)
Target Milestone: OOo 2.4
Assignee: jack.warchold
QA Contact: issues@gsl
: 61484 (view as issue list)
Depends on:
Reported: 2005-10-25 16:46 UTC by kruczka
Modified: 2009-07-20 14:53 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

A tree of linked PDF files (479.35 KB, application/x-compressed)
2006-07-24 08:15 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
patch for a first 'draft' implementation (49.80 KB, patch)
2007-07-23 16:18 UTC, Giuseppe Castagno (aka beppec56)
no flags Details | Diff
working docu as described above. (70.73 KB, application/vnd.oasis.opendocument.text)
2007-09-27 12:50 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
short document, explaining how to use the test application in desc22 above (34.36 KB, application/vnd.oasis.opendocument.text)
2007-10-22 13:17 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
draft of PDF Export addedum (92.37 KB, application/vnd.oasis.opendocument.text)
2007-10-30 10:48 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
a very skeletal test bed (2.19 MB, application/x-compressed)
2007-10-30 10:50 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
Version of attachment of desc21 above, embedded picture. Sorry for the wrong posting (335.29 KB, application/vnd.oasis.opendocument.text)
2007-11-01 23:07 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
New addendum version for PDF hyperlinks. (94.49 KB, text/plain)
2007-11-04 16:35 UTC, Giuseppe Castagno (aka beppec56)
no flags Details
Version of PDFExportDialog.odt specification addendum the CWS beppec56pdflinks is based on (102.82 KB, application/vnd.oasis.opendocument.text)
2007-11-07 13:59 UTC, Giuseppe Castagno (aka beppec56)
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kruczka 2005-10-25 16:46:07 UTC
Dear Developer,
there is one issue concerning PDF export. During conversation from odt Writer
file to pdf format hyperlinks that point on file are converted as www links not
'open file' links (Acrobat chooses action 'Link to a document using a World Wide
Web URL' instead of 'Click the Select File button to chose a file to open,
including other applications'). 

I use relative links features for saving the files. 
When in odt file there is a link to the file './example/example.txt' this link
is converted as www link: 'file:///absolute_path/example/example.txt' and
Acrobat (I have 5.0 version)  tries to open it in web browser as URL and of
course it failes. 
Such link should, I suppose };), be converted as 'open file' link and the path
should be 'example/example.txt'. Then while clicking on such a link in pdf
document Acrobat would try to open nedit, notepad or whatever is assigned to txt
file and show the file in opened aplication.

When this bug was found:
I have lots of files in odt format, they contain many links to differnt files
(txt, jpg etc.). I need to convert them to pdfs, than copy the pdfs and all
linked files (txt, jpg etc) to cd's. Unfortunately it is not possible to open
links from pdfs, so such cd's are useless.
Comment 1 stephan_schaefer 2005-10-25 17:10:52 UTC
ssa->pl: please have a look if this can be supported.
Comment 2 philipp.lohmann 2005-10-25 17:34:50 UTC
This is basically two issues:

1: you want to handle links to files on your machine not as URL but as a Launch
action (as these are called in the PDF spec, basically the same should happen as
if you clicked unto the file on your desktop).

2: you want relative URL's not to be resolved to absolute, possibly only in case
of above launch action.

regarding 1: the PDF file written would loose portability; such an action would
only work on Windows if you wrote the PDF file on Windows or on Unix if you
wrote the PDF file on Unix. This basically destroys one of the main advantages
of PDF, namely the portability.

regarding 2: relative URLs would mean that the PDF file created only works on
the machine it was created on or on one with identical subdirectory structure.
This could e.g. be achieved by zipping the PDF together with the files pointed to.

Both things can certainly be done.
Comment 3 kruczka 2005-10-26 10:24:05 UTC
Sorry for 2 issues in 1 subject, but 2nd issue is a result of 1st, so for me it
looked as 1 issue };)

Regarding 1: That is exactly my problem - portability of PDF's.

Regarding 2: Yes, I want relative URL's not to be resolved to absolute in case
of launch action.

There is only one solution for these problems right now (if someone is not
familiar with programming): changing manually every link in PDF from 'www link'
to 'open file' and setting the targeted file for the link once again :( And of
course full version of Acrobat is needed to do this :(

Comment 4 lohmaier 2006-02-02 21:20:55 UTC
*** Issue 61484 has been marked as a duplicate of this issue. ***
Comment 5 palves 2006-03-31 10:21:35 UTC
*** Issue 56629 has been confirmed by votes. ***
Comment 6 Giuseppe Castagno (aka beppec56) 2006-07-15 10:39:07 UTC
CC to myself.
Comment 7 antonovich 2006-07-21 16:46:29 UTC
This is NOT only possible with Acrobat!!! I do something much more complicated
by programme using pdfbox ( I agree that it is annoying however.
I also don't see how it is not portable (relative links) - I am almost certain
windows will handle *nix/http style relative urls properly. After all, it
handles proper file urls, which are not the same as windows urls...
Comment 8 Giuseppe Castagno (aka beppec56) 2006-07-24 08:15:08 UTC
Created attachment 37977 [details]
A tree of linked PDF files
Comment 9 Giuseppe Castagno (aka beppec56) 2006-07-24 08:15:35 UTC
The file I attached is a zip archive of a working directory tree of linked
documents: PDF, jpg and txt.
I prepared the PDF files in it using a hacked Java application to convert the
native ODT documents, using OOo.
The native ODT document are inside the tree as well.

To check it, expand it in a directory of your choice, then start the navigation
with: tree-test/start-here-main-doc.pdf.

The links are relative and should work on both Windows and GNU/Linux and they
where added using the standard "Insert Hyperlink" command of OOo.
They are all converted as "Remote Go-To Actions" (PDF v 1.4, 8.5.3, fo the

Some of them are direct link to bookmarks, e.g. the bookmarks in OOo are
translated as "Named Destinations" in PDF files (see PDF 1.4 ref, 8.2.1), so
they can be used as target for the action. This last one was not requested in
the issue but I had this capability available and left it there.

Even though I added links to JPEG and TXT files, it seems that the best way to
link this files is to convert them to PDF, even though I didn't do this here.

In GNU/Linux, Acrobat Reader uses Firefox to open them, in Windows I didn't have
the same results, may be because I don't have a clear set-up there.

It seems that this tree layout works well under Acrobat Reader only. Other
readers don't seem to resolve the links as relative, or don't resolve the "jump
to beginning of PDF document", the same as the "Initial view" action added
recently in OOo 2.0.3.

You can try yourself with the attached archive.

Can somebody test the attached zip archive and confirm this is the feature asked
for ?
Comment 10 bob_treder 2006-10-17 11:42:38 UTC
The discussion here revolves around OO Writer files but the problem is the 
same for Impress files. I expect it will be the same for all OO files 
converted to pdf. I desperately need the relative paths I set in Impress 
preserved as the reporter describes when converting to pdf. I am developing 
course materials and without relative paths there must be a fixed installation 
point! :(!!  Although this is listed as an Enhancement, I consider it a bug 
because the pdf converter is not maintaining link settings created in OO. 
Overriding work done in OO without an option to prevent is dysfunctional, a 
Comment 11 fcodyc 2006-10-24 22:02:30 UTC

That's great.  That's exactly the output I'd expect (but am not getting) from
OpenOffice.  Any chance you could post the Java code you used to create those
samples?  ;)  
Comment 12 Giuseppe Castagno (aka beppec56) 2006-10-25 15:12:24 UTC
-> fcodyc: The Java app lurks here:, but I'm no longer maintaining it.
Besides I had to tweak it a little to work with OOo 2.0.x.
Comment 13 bob_treder 2006-10-30 11:16:59 UTC
I just tested creating a pdf from my Impress files against the new development 
version of beppec56. It works great! Relative links (at least in Impress) are 
preserved in that version. I hope this will make it into the next release. 
Comment 14 sibbi77 2007-02-22 13:52:25 UTC
using OOo version 2.1 (linux), neither Impress nor Writer is able to export
relative links in pdf-files. Writer converts relative links to absolute ones as
soon as it saves the file in the native .odt format.
Links are always web links even, if the scheme is file:// and is entered using
the hyper link dialog for document links (in contrast to internet links).
Comment 15 skyblue2 2007-06-13 17:51:41 UTC
I think it might be helpful to restate this issue in a way more likely to result
in solving the problem users are confronting.  It appears what users are looking
for is OOo functionality for creating pdf hyperlinks and bookmarks/named
destinations equivalent to the hyperlink and target creation capabilities of a
simple HTML editor.  That is:  1) provide an author the option of designating
hyperlinks as either relative or absolute when exporting a .od? document to
.pdf, and 2)  provide the ability to create pdf target documents that contain
named destinations (targets/bookmarks), which open the pdf to the named
destination when a hyperlink to them is clicked.

Enabling relative hyperlinks would allow creation of a hyperlinked pdf
presentation comprised of one or many documents, that could be moved to a CDROM
or uploaded to a web site with little change to hyperlinks.  In other words, it
would enable building truly portable pdf presentations.  Hyperlinks in one pdf
document on a CD could take the reader to a specific location (bookmark/named
destination) in another pdf document on a CD.  OOo currently cannot produce pdfs
like this.  It seems no other pdf creation program can either.  However, it
appears from his example-tree documents that beppec56 found a way to get a
previous version of OOo to do this (that is, prior to 2.2).

This could change the way people communicate with CDs and the Internet by
substituting pdf pages for HTML.  Here are some advantages:  

1)  Avoids HTML's problem of an author not knowing how a page will be displayed
by different monitors or browsers. 

2)  Allows an extensive pdf presentation to be created with relative hyperlinks
on a desktop computer, then burned on CD for distribution, or uploaded to a web
server, with few if any hyperlink changes required.  It might even end up
competing with HTML for building web sites (as pdf compression improves and
broadband expands).  

3)  Allows easier creation of a hyperlinked slide presentation, as opposed to
creating it using standard HTML (especially if pages need to be removed or added
as a large presentation is developed).

I see on the Internet that people have been looking for this pdf capability
since at least 2001.  It looks like beppec56 knows how to get OOo to do it.  My
vote is to include this functionality in future OOo releases. 
Comment 16 Giuseppe Castagno (aka beppec56) 2007-07-23 16:17:40 UTC
I'm going to attach a patch that can be thought as a 'draft' implementation of
the issue.
For further discussion.
Comment 17 Giuseppe Castagno (aka beppec56) 2007-07-23 16:18:59 UTC
Created attachment 47000 [details]
patch for a first 'draft' implementation
Comment 18 Giuseppe Castagno (aka beppec56) 2007-08-09 16:14:07 UTC
Starting, target.
Comment 19 Giuseppe Castagno (aka beppec56) 2007-09-27 12:48:49 UTC
@mmp, @pl:
I'm going to attach what is a working document (I mean it's a track I'm
following) of the resolution to this issue I'm proposing (and some other issues
I think, see the docu).
It's not a specification enhancement, but a document I use and update while
implementing the code to test the whole thing.

My idea it to derive a specification enhancement from it.

Let me know what you (both) think.
Comment 20 Giuseppe Castagno (aka beppec56) 2007-09-27 12:50:39 UTC
Created attachment 48546 [details]
working docu as described above.
Comment 21 Giuseppe Castagno (aka beppec56) 2007-10-22 11:34:54 UTC
For anyone interested, I built a Windows version of OOo, 2.2.1 based (I still
haven't a 2.3.x tree in Windows, sorry) which contains my proposal solution to
this issue, basically the beppec56pdflinks CWS.

You can download it from here:

please read carefully the web page before installing it, it's still a
development version...
Comment 22 Giuseppe Castagno (aka beppec56) 2007-10-22 11:35:54 UTC
I forgot, report here on the issue what you think, observation, etc...
Comment 23 Giuseppe Castagno (aka beppec56) 2007-10-22 13:17:59 UTC
Created attachment 49066 [details]
short document, explaining how to use the test application in desc22 above
Comment 24 Giuseppe Castagno (aka beppec56) 2007-10-30 10:47:27 UTC
I'm going to attach two files: the first is the draft of the specification for
this feature, to be added to the current PDF Export specification document, the
second contains the documents I used to test while writing the draft.

Comments are greatly appreciated.
Comment 25 Giuseppe Castagno (aka beppec56) 2007-10-30 10:48:28 UTC
Created attachment 49266 [details]
draft of PDF Export addedum
Comment 26 Giuseppe Castagno (aka beppec56) 2007-10-30 10:50:43 UTC
Created attachment 49267 [details]
a very skeletal test bed
Comment 27 Giuseppe Castagno (aka beppec56) 2007-11-01 23:07:36 UTC
Created attachment 49368 [details]
Version of attachment of desc21 above, embedded picture. Sorry for the wrong posting
Comment 28 Giuseppe Castagno (aka beppec56) 2007-11-04 16:33:20 UTC
Due to interoperability needed with PDF/A-1 (issue 59651) I changed the PDF
specification addendum attached on desc26 above.
In it I changed some wording not meant for the spec: the English spellchecker
changed some example Italian words in something else that has nothing to do with
the spec, I' sorry for that.

Attaching the new spec addendum version.
Comment 29 Giuseppe Castagno (aka beppec56) 2007-11-04 16:35:51 UTC
Created attachment 49408 [details]
New addendum version for PDF hyperlinks.
Comment 30 Giuseppe Castagno (aka beppec56) 2007-11-07 13:59:43 UTC
Created attachment 49497 [details]
Version of PDFExportDialog.odt specification addendum the CWS beppec56pdflinks is based on
Comment 31 philipp.lohmann 2007-11-07 15:20:37 UTC
assign to beppec56
Comment 32 philipp.lohmann 2007-11-07 15:21:48 UTC
fixed in CWS beppec56pdflinks
Comment 33 Giuseppe Castagno (aka beppec56) 2007-11-07 16:04:55 UTC
-> jw, please verify in CWS beppec56pdflinks, specification addendum in desc31
Comment 34 jack.warchold 2007-11-13 15:44:01 UTC
seen good in beppec56pdflinks

set to verified
Comment 35 hagar_de_lest 2008-04-04 20:59:30 UTC
Hi All,

Thanks to report your votes to another issue, this one is closed and fixed!!!
Comment 36 ftoth 2008-04-05 22:25:21 UTC
This new feature in 2.4 seems to be a little broken. I propose to reopen it.

Here is my case: import a html document with relative url's to pdf's into Writer.
When viewing the link in Writer the link shows as an absolute path, but this
path is built from the path of the current writer document.

As a result can be:
Linux: file:///path/file.pdf
Linux: smb:///path/file.pdf
Windows: file:///c:\path\file.pdf

Depending on how the folder is mounted/connected to.

Now exporting the pdf:
-on the Windows machine
-relative path checked
- open with PDF reader checked
a pdf file is created with a link with a relative path using remote goto actions
with file:///./file.pdf.

Opening the file in Acrobat on Windows and clicking the link gives an error that
the file does not exist.
Opening on Linux as an embedded pdf (in Acrobat 8) in konqueror opens the link fine.
Opening on Linux directly in Acrobat 8 and clicking the link also gives and error.

I have not checked exporting the pdf from the Linux version (waiting for 2.4.0
to go into testing on Debian). But from the documentation I get that smb:
(kioslave in KDE) is not supported yet.

Comment 37 Giuseppe Castagno (aka beppec56) 2008-04-06 08:14:40 UTC
It would be better to open a new issue, narrowed down to your problem.
Don't forget to attach test documents in order to be able to reproduce the behavior.

Assign it to component gsl, subcomponent code.

Remember that currently this feature works for 'file://' protocol only (e.g. no
'smb://' or others).
Comment 38 ftoth 2008-04-07 14:54:13 UTC
I'm sorry! I need to correct the bug report above (Sat Apr 5 21:25:21 +0000 2008).

Please disregard all of that.

I have now traced down the problem to the following:
- relative path checked
- open with PDF reader checked
- path contains *spaces*.

The spaces are converted to %20, this is correct for URI but incorrect for
remote goto actions (generated because of "open with PDF reader"). This can
easily be reproduced.

Comment 39 thorsten.ziehm 2009-07-20 14:53:17 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>