Apache OpenOffice (AOO) Bugzilla – Issue 56629
PDF convert tool - relative links to files from file system are converted as URLs not
Last modified: 2009-07-20 14:53:17 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'). E.g.: 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.
ssa->pl: please have a look if this can be supported.
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.
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 :(
*** Issue 61484 has been marked as a duplicate of this issue. ***
*** Issue 56629 has been confirmed by votes. ***
CC to myself.
This is NOT only possible with Acrobat!!! I do something much more complicated by programme using pdfbox (www.pdfbox.org). 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...
Created attachment 37977 [details] A tree of linked PDF files
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 developers). 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 ?
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 bug.
beppec56: 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? ;)
-> fcodyc: The Java app lurks here: http://www.acca-esse.it/pp/gc/en/oopdfbuild.html, but I'm no longer maintaining it. Besides I had to tweak it a little to work with OOo 2.0.x.
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.
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).
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.
I'm going to attach a patch that can be thought as a 'draft' implementation of the issue. For further discussion.
Created attachment 47000 [details] patch for a first 'draft' implementation
Starting, target.
@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.
Created attachment 48546 [details] working docu as described above.
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: http://www.acca-esse.it/en/ooohs/start-here.html please read carefully the web page before installing it, it's still a development version...
I forgot, report here on the issue what you think, observation, etc...
Created attachment 49066 [details] short document, explaining how to use the test application in desc22 above
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.
Created attachment 49266 [details] draft of PDF Export addedum
Created attachment 49267 [details] a very skeletal test bed
Created attachment 49368 [details] Version of attachment of desc21 above, embedded picture. Sorry for the wrong posting
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.
Created attachment 49408 [details] New addendum version for PDF hyperlinks.
Created attachment 49497 [details] Version of PDFExportDialog.odt specification addendum the CWS beppec56pdflinks is based on
assign to beppec56
fixed in CWS beppec56pdflinks
-> jw, please verify in CWS beppec56pdflinks, specification addendum in desc31 above.
seen good in beppec56pdflinks set to verified
Hi All, Thanks to report your votes to another issue, this one is closed and fixed!!!
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. Ferry
->ftoth. 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).
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. Ferry
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 => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues