DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959

Glenn Adams  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #16 from Glenn Adams  2012-04-11 06:17:10 UTC ---
change status from ASSIGNED to NEW for consistency

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959

Glenn Adams  changed:

   What|Removed |Added

   Priority|P2  |P3

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959

--- Comment #15 from Glenn Adams  2012-04-07 01:41:29 UTC ---
resetting P2 open bugs to P3 pending further review

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959

Jason Edwards  changed:

   What|Removed |Added

 CC||jason.edwards@biftechnologi
   ||es.com

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959

--- Comment #14 from James Kauczka  2011-04-29 15:12:20 UTC 
---
What is the current status of this bug / patch?
Any thoughts on applying Peter's code from comment 3?
I'm still running 0.95 and I haven't found any mention of this being looked at
or fixed in 1.0. I'm thinking if I do try Peter's suggestion I should at least
move to 1.0 beforehand. I just hate putting a self-code patch in and then worry
that any new release might contain a modification that would break is. 
Duck

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #13 from Andreas L. Delmelle   2009-02-22 
13:04:28 PST ---
(In reply to comment #12)

Apologies for the rather late response...

> 
> I had the same problem and I tried this patch. It solved the link to an
> external web-site problem but a lot of internal links were not working 
> anymore.

Anything particular about the internal links? I assume that by 'a lot of' you
mean 'not all'. I just tried a small sample, and could not reproduce this
immediately (latest FOP Trunk with the patch applied). Can you provide a small
sample document, perhaps?

> I have also tried the patch suggested in Comment #3, and this seems to solve
> the external link problem without breaking the internal links.

That is expected, since Peter's quick fix only touches the code related to
external links (PDF URI Actions). The attached patch proposal is a refactoring
of all PDF Actions, including internal links, bookmarks etc.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959


Marc Haesen  changed:

   What|Removed |Added

 CC||marc.hae...@oneaccess-
   ||net.com




--- Comment #12 from Marc Haesen   2009-02-12 
09:02:59 PST ---
(In reply to comment #11)
> Created an attachment (id=23054)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23054) [details]
> another update
> Same as the previous, only with the addition of creating only one URI action
> for each distinct URI. Those are referenced by the links through their PDF
> object number. A benefit for cases where separate links with the same URI 
> occur
> in a lot of places in the document. 
> Only small thing to add is support for the isMap entry.

I had the same problem and I tried this patch. It solved the link to an
external web-site problem but a lot of internal links were not working anymore.

I have also tried the patch suggested in Comment #3, and this seems to solve
the external link problem without breaking the internal links.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959


Andreas L. Delmelle  changed:

   What|Removed |Added

  Attachment #23053|0   |1
is obsolete||




--- Comment #11 from Andreas L. Delmelle   2008-12-28 
13:24:27 PST ---
Created an attachment (id=23054)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23054)
another update

Same as the previous, only with the addition of creating only one URI action
for each distinct URI. Those are referenced by the links through their PDF
object number. A benefit for cases where separate links with the same URI occur
in a lot of places in the document. 
Only small thing to add is support for the isMap entry.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959


Andreas L. Delmelle  changed:

   What|Removed |Added

  Attachment #22969|0   |1
is obsolete||




--- Comment #10 from Andreas L. Delmelle   2008-12-28 
04:32:38 PST ---
Created an attachment (id=23053)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23053)
updated patch


Basically the same as Jeremias' patch-proposal, but with additional
hashCode/equals pairs for some other types that are used as values in the
dictionaries but are not PDFDictionary subclasses themselves (PDFName,
PDFNumber, PDFReference, PDFArray...) .

Still not sure if I got them all. PDFArray can contain any type of Object it
seems, so it could well be that I'm still missing some...


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #9 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-12-03 
13:39:11 PST ---
(In reply to comment #8)
> Created an attachment (id=22969)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22969) [details]
> Proposed way to approach this problem.

Nice! Some time ago, when considering the extension to allow injecting custom
PDF dictionaries into the output, I already felt a PDFString object to be
absent. 


> I assume Andreas could combine this with his changes. 

Yes, seems to be no problem.

> Anyway, a second pair of eyes would be
> good here. Let me know I should commit the changes.
> 
> A more critical part could be the equals() methods that I removed from many
> classes I converted. I added an equals()/hashcode() pair to PDFDictionary to
> compensate but I'm not sure if any of this is needed and if it still works as
> before.
> 

Seems more than OK at the very first glance. Certainly beneficial that the
equals()/hashCode() pair is centralized in PDFDictionary. 

For a code-compression competition, maybe equals could be:

public boolean equals(Object o) {
  return this == o
|| (o != null
  && this.getClass() == o.getClass()
  && (this.entries == ((PDFDictionary)o).entries
  || (this.entries != null 
  && this.entries.equals(((PDFDictionary)o).entries;
}

... but this is more a personal favorite. I'm not sure whether such logical
short-circuits actually have any benefit after compilation. I just find them to
be clear and concise code-wise... :-)

One thing that could lead to issues, would be when a PDFDictionary can contain
PDFObjects that fall back on the default Object.equals(). Not sure if this is a
serious issue, but if so, fixing that for the object types in question
shouldn't be too difficult. Quickly redeclaring equals() abstract in PDFObject
revealed some 19 types that don't provide an override (hence equals() will only
return true in case of identity). 
A few of those will be taken care of by your patch. For the others, we should
probably first determine if changing them too would make sense (if they can be
used in dictionaries)
One type that concerned me, for example, is PDFName, which could act as key in
the dictionary. Then I noticed that this is implemented with Java Strings,
rather than PDFName objects, so nothing to worry about there. If a PDFName
would be used as a value, however, I think we could end up with two
dictionaries that have equal-yet-non-identical entries, so entries.equals()
would return false because one of the value pairs are of a type that invokes
Object.equals().


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[Andreas Delmelle]

On 01 Dec 2008, at 09:48, Jeremias Maerki wrote:

Hi Jeremias,


I think it should be safe to make them private. If there's a reason to
make the protected we'll hear about it soon.


OK, done (see r722613)

Thanks for the pointers in the Bugzilla report. That would of course  
be the most comprehensive fix for the issue. Haven't looked at the  
patch yet. Will follow-up via Bugzilla once I have.



Cheers

Andreas

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #8 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-12-01 02:24:21 
PST ---
Created an attachment (id=22969)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22969)
Proposed way to approach this problem.

I've attached a patch that shows how I would approach the problem. I've done
some testing but not enough to simply commit the changes. For example, I
haven't checked FileSpecs which I changed, too, as they are also using "string"
objects (they would have the same problem when encrypted). I assume Andreas
could combine this with his changes. Anyway, a second pair of eyes would be
good here. Let me know I should commit the changes.

A more critical part could be the equals() methods that I removed from many
classes I converted. I added an equals()/hashcode() pair to PDFDictionary to
compensate but I'm not sure if any of this is needed and if it still works as
before.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #7 from Peter Coppens <[EMAIL PROTECTED]>  2008-12-01 01:28:52 PST 
---
I kind of already wondered whether there would not be other cases where this
issue would be present (which seems to come from 'forgetting' to invoke an
encoding/encryption method before writing out the PDF). I guess that is
confirmed now and obviously architectural improvements where it is just no
longer possible to create this bug are to be preferred compared to an adhoc
fix. That is why I said (..I doubt it's the most optimal approach...).

But for now I am all set (having a local fix on 0.95) and I guess the next
release will have the issue fixed (in a better way).

Thanks for moving this forward (and helping me out).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #6 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-12-01 01:05:13 
PST ---
I'm sorry that I'm a little late here but I fear the approach you both have
taken is probably not the best one. Some background: When I write the
PDF-in-PDF extension I needed generic PDF structures (arrays, dictionaries
etc.) to I could easily transform the PDFBox model into something that can be
processed by FOP's PDF library. That's when I introduced PDFArray,
PDFDictionary & Co. The thing is: I've only converted some of the existing PDF
classes to use the generic structures, yet. Now, fixing the encryption problem
only for this special case seems like a bad idea. You may remember we had a
similar problem with the PDF outlines (fo:bookmark) in the past. So we're
essentially fixing the same bug in different places. A better idea would be to
convert the existing PDF classes to use the generic structures when they need
to be touched.

Yesterday, I've had some train time (a rare resource lately) and I've converted
all the classes related to Actions to use PDFDictionary. That reduces the
number of lines of code quite a bit and made the code more readable. I have one
remaining problem before my changes are in a state to be committed: I noticed
(a little late) that there are two different string types: strings and text
strings. String objects are currently treated as if they are "text strings",
i.e. allow Unicode. But "strings" (as used by the "URI" dict entry) cannot use
Unicode. So I probably have to introduce a "PDFString" class that simply
carries a "string" object and handles the encoding (especially in the
encryption case) correctly.

BTW, Andreas, the reuse of URI actions may not always be a good idea since the
URI alone may not uniquely identify a URI action. There's also a dictionary
entry "IsMap" which offers additional functionality. I'm also not entirely sure
if this should be a functionality PDFDocument has to offer. This can easily be
done outside the PDF library. I'm not saying this is wrong but I wonder if we
don't bloat the whole PDF library too much with stuff like this. OTOH, even in
PDF 1.7 the URI action doesn't support more than the "URI" and "IsMap" entries,
so if your look-up method includes both the parameters, it should be safe.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[Jeremias Maerki]

I think it should be safe to make them private. If there's a reason to
make the protected we'll hear about it soon.

On 30.11.2008 23:22:49 Andreas Delmelle wrote:
> On 30 Nov 2008, at 23:12, [EMAIL PROTECTED] wrote:
> 
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=41959
> > 
> >
> > I'll try to post a patch shortly, but it seems I've made a rather  
> > large number
> > of other unrelated changes (mostly minor cleanups) to the code,  
> > which would
> > only confuse people...
> 
> Regarding those 'cleanups', I noticed that all of the object lists in  
> PDFDocument currently are protected. Does this have a reason? I  
> changed most of the protected instance variables to private, since  
> they didn't reveal any dependencies within FOP (= all necessary access  
> goes via the public accessors).
> 
> Are there implementors I should be aware of here?
> 
> 
> Andreas




Jeremias Maerki

Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[Andreas Delmelle]

On 30 Nov 2008, at 23:12, [EMAIL PROTECTED] wrote:


https://issues.apache.org/bugzilla/show_bug.cgi?id=41959


I'll try to post a patch shortly, but it seems I've made a rather  
large number
of other unrelated changes (mostly minor cleanups) to the code,  
which would

only confuse people...


Regarding those 'cleanups', I noticed that all of the object lists in  
PDFDocument currently are protected. Does this have a reason? I  
changed most of the protected instance variables to private, since  
they didn't reveal any dependencies within FOP (= all necessary access  
goes via the public accessors).


Are there implementors I should be aware of here?


Andreas

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #5 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-11-30 
14:12:01 PST ---

I started playing with it myself, and I had the idea of registering the URI as
a separate object, to be referenced by the links.

Not sure, but it seems a cleaner and more comprehensive approach for cases
where an identical URI is referenced by many links. 
OTOH, it could have drawbacks, in case a large number of different URIs is
referenced by only one link at a time (?)

Changes made in a nutshell:

1. PDFDocument 
  -> added List of uris + accompanying findUriAction() method
2. PDFFactory 
  -> added getUriAction() method, which depends on 1. 
  -> changed getExternalAction() accordingly: replace instantiations to go
through getUriAction()
3. PDFUri 
  -> change getAction() implementation to return the PDF object reference (like
PDFGoTo does)
  -> change toPDFString() to contain the code contained in Peter's suggested
PDFObject.encodeText2()

I'll try to post a patch shortly, but it seems I've made a rather large number
of other unrelated changes (mostly minor cleanups) to the code, which would
only confuse people...


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #4 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-11-30 
03:47:49 PST ---

Adding my response to Peter's suggestions here too:

---
> Here are the changes I did
>
> 1. PDFLink#toPDFString
> Added
>
>  this.action.setParent(this);
>
> (would be better to do this when creating the PDFUri object )

Or maybe, we should do this in PDFLink#setAction() ?

That seems to be the point where the PDFAction (PDFUri) is associated with the
PDFLink.

I already checked whether this had unwanted side-effects when the same URI is
used in multiple links, but that does not seem to be the case. The parent link
is only used to get to the ancestor document, which is obviously the same for
all links.

> 2. PDFUri#getAction
> 
> 3. Added PDFObject#encodeText2

I'm wondering to what extent this new, separate method could be merged with the
original encodeText(), maybe by changing the signature, and adding a second
parameter to distinguish this case from the one covered by the original method.
---


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Comment #3 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-11-30 
03:44:59 PST ---

Recently reported again on fop-users@ by Peter Coppens, who made progress
towards a fix:

---
I have something that seems to be working, but I am not sure it is always
correct and I doubt it's the most optimal approach.

Here are the changes I did

1. PDFLink#toPDFString
Added

   this.action.setParent(this);

(would be better to do this when creating the PDFUri object )

2. PDFUri#getAction

   public String getAction() {
   return "<< /URI (" + uri + ")\n/S /URI >>";

   }


-->

   public String getAction() {
 String uriString=new String(this.encodeText2(uri));

 return "<< /URI " + uriString + "\n /S /URI >>";

   }


3. Added PDFObject#encodeText2


   protected byte[] encodeText2(String text)  {
   if (getDocumentSafely().isEncryptionActive()) {
   final byte[] buf = PDFText.encode(text);
   byte[] enc = getDocument().getEncryption().encrypt(buf, this);
   return PDFText.toHex(enc,true).getBytes();

} else {
   return encode(PDFText.escapeText(text, false));

}

   }


Perhaps this can be used as something to start from for a patch for bug
41959 ?

Thanks,

Peter
---


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959


Andreas L. Delmelle <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 OS/Version|Windows XP  |All
   Platform|PC  |All
Version|0.93|1.0dev




--- Comment #2 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-11-29 
05:37:02 PST ---
Still present in FOP Trunk


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41959] - External links are broken if pdf is encryped

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41959





--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 12:15 ---

Confirmed. Running examples/fo/basic/newlinktest.fo even crashed my Adobe 
Reader just now... :/

No immediate idea on the cause or fix, though.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.