Bug 59839 - PDF: PDF export with relative links
Summary: PDF: PDF export with relative links
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.0.0.2 rc
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: possibleRegression
Depends on:
Blocks:
 
Reported: 2013-01-25 09:15 UTC by dany franck
Modified: 2015-12-15 10:53 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
The link is in the first line (22.75 KB, application/vnd.oasis.opendocument.text)
2013-02-04 10:02 UTC, dany franck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dany franck 2013-01-25 09:15:13 UTC
Problem description: 

A relative link in the pdf produced by writer has the form
file:///directory path/./filename
which was not recognized by most readers
Before versions had the form
fille:///directory path/filename.



              
Operating System: Windows 7
Version: 4.0.0.2 rc
Last worked in: 3.6.4.3 release
Comment 1 Michael Stahl (allotropia) 2013-01-25 13:53:56 UTC
"." path segments are perfectly valid in relative URIs
according to the relevant IETF RFC (though i don't know what "URI"
means in the PDF format).

see RFC3986 section "5.2.4.  Remove Dot Segments".

which PDF consumers have problems with URIs containing "." path segments?

however when trying this out on Linux i can't reproduce any difference
between 4.0.0.2 and 3.6.4.3; please provide more detail how
to reproduce such URIs, e.g. where exactly do the document
and the link target need to be relative to each other.
Comment 2 dany franck 2013-01-28 07:14:01 UTC
>which PDF consumers have problems with URIs containing "." path segments?

We are using Foxit Reader under windows and it could be a bug of the reader.

>however when trying this out on Linux i can't reproduce any difference
>between 4.0.0.2 and 3.6.4.3; please provide more detail how
>to reproduce such URIs, e.g. where exactly do the document
>and the link target need to be relative to each other.

I reported a bug because we never had this problem with 3.6.4 under windows. This problem was introduced with version 4. 
Typical use is developping documentation on a drive and using it on an other. The LibreOffice links of type "file:///..." are not recognised by a lot of free pdf-reader under Windows. Foxit was an exception, until version 4.
Comment 3 Michael Stahl (allotropia) 2013-02-03 18:53:49 UTC
dany, your comment does not contain a better description how to
reproduce the problem.

can you perhaps attach an ODF file, which will, when exported to PDF,
contain such problematic URIs?
Comment 4 dany franck 2013-02-04 10:02:39 UTC
Created attachment 74165 [details]
The link is in the first line

This is a file with a relative link
Comment 5 Robinson Tryon (qubit) 2013-10-16 04:31:01 UTC
Test document provided, so changing status: NEEDINFO -> UNCONFIRMED
Comment 6 Robinson Tryon (qubit) 2013-10-16 04:31:38 UTC
Changing 'regression' -> 'PossibleRegression' until we can get independent confirmation of a regression.
Comment 7 Dennis Roczek 2013-10-20 14:27:20 UTC
Which link? The navigator doesn't say that there is a link in that odt, nor can I find any link in the exported (x)html nor in the exported PDF.
Comment 8 dany franck 2013-10-21 12:54:17 UTC
Yes, the link was suppressed by saving the document. Probably because the file was not found (tested with 4.0.5).
For me, a relative link has the form: ./essai.pdf
Such a link helps in moving a batch of files globally without having to change the links. 
It seems all the links that LO can produce are absolute links: file:///drive/repertory/file.
Thanks for trying to help, but I think there are other and more problematic bugs waiting for your expertise, so I propose to close the bug.
Comment 9 Joel Madero 2014-06-20 23:40:00 UTC
Back to NEEDINFO - we need a functional document attached. Once attached mark as UNCONFIRMED. Thanks
Comment 10 QA Administrators 2015-01-10 18:06:36 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

Message generated on: 10/01/2015
Comment 11 Robinson Tryon (qubit) 2015-01-10 22:47:00 UTC
(In reply to Joel Madero from comment #9)
> Back to NEEDINFO - we need a functional document attached. Once attached
> mark as UNCONFIRMED. Thanks

Yes, but:

(In reply to dany franck from comment #8)
> ...
> Thanks for trying to help, but I think there are other and more problematic
> bugs waiting for your expertise, so I propose to close the bug.

That's fine. We have a number of open bugs that we're punting on anyhow, but without a demo document we can't repro, so:
Status -> RESOLVED WORKSFORME

(If anyone wants to provide a demo document showing the problem, we can open this bug again)
Comment 12 Robinson Tryon (qubit) 2015-12-15 10:53:41 UTC
Migrating Whiteboard tags to Keywords: (possibleRegression)
[NinjaEdit]