DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #16 from Glenn Adams gad...@apache.org 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #15 from Glenn Adams gl...@skynav.com 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Glenn Adams gl...@skynav.com 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Jason Edwards jason.edwa...@biftechnologies.com 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #14 from James Kauczka jkauc...@chubb.com 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Marc Haesen marc.hae...@oneaccess-net.com changed: What|Removed |Added CC||marc.hae...@oneaccess- ||net.com --- Comment #12 from Marc Haesen marc.hae...@oneaccess-net.com 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Attachment #22969|0 |1 is obsolete|| --- Comment #10 from Andreas L. Delmelle adelme...@apache.org 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
https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Attachment #23053|0 |1 is obsolete|| --- Comment #11 from Andreas L. Delmelle adelme...@apache.org 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
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.
snip /
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
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
Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped
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 snip / 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
DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped
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.
DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped
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
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
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
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 snip / 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.
Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped
On 30 Nov 2008, at 23:12, [EMAIL PROTECTED] wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 snip / 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
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.
