Bug 37980 - When using FOP with -noedit fo:basic-links get broken
Summary: When using FOP with -noedit fo:basic-links get broken
Status: CLOSED DUPLICATE of bug 31039
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: pdf (show other bugs)
Version: trunk
Hardware: Other All
: P2 major
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-20 17:47 UTC by Adam Strzelecki
Modified: 2012-04-01 13:55 UTC (History)
0 users



Attachments
Run this sample with -noedit option (1.28 KB, text/xml)
2005-12-20 17:48 UTC, Adam Strzelecki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Strzelecki 2005-12-20 17:47:37 UTC
Ehh.. sorry... another bug submission from me.

Use attached file with:
fop -noedit link-bug.fo link-bug.pdf

The link in PDF should point to http://maps.google.com/ but points to some garbage.
When there's no -noedit option everything is fine.
Comment 1 Adam Strzelecki 2005-12-20 17:48:53 UTC
Created attachment 17247 [details]
Run this sample with -noedit option

This is buggy behavior example.
Comment 2 Jeremias Maerki 2005-12-20 19:31:30 UTC
Confirmed. The "uri" string in PDFUri doesn't get encrypted. But wrapping "uri"
in a call to encodeText() won't be enough in this case because PDFUri is used as
a direct object. And for PDF encryption an object and generation number are
needed and these are only available on indirect objects. So, PDFUri would have
to get the parent's info but PDFObject does not currently provide access to the
parent object. Note that there are other potential candidates for the same kind
of processing (PDFGoToRemote, for example). Just an analysis from me this time. :-)
Comment 3 J.Pietschmann 2008-03-19 12:24:46 UTC

*** This bug has been marked as a duplicate of bug 31039 ***
Comment 4 Glenn Adams 2012-04-01 13:55:23 UTC
batch transition to closed remaining pre-FOP1.0 resolved bugs