[
https://issues.apache.org/jira/browse/FOP-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Custer updated FOP-3251:
-----------------------------
Description:
I recently discovered that Apache FOP can overwrite the "url" value encoded in
basic links.
Example:
If there are 2 basic links in a file, and the first has a value with the
characters "0P" and the second link has the characters "11", then the second
link that should have been "11" will render as "OP". I believe that this
happening due to some hashing techniques to cut down on processing when trying
to determine if various URIs are identical.
I have attached both an XSL-FO file and its PDF result as rendered by Apache
FOP 2.10. I've also included a screenshot showing how a hover of a link that
has been overwritten (in that case, where the "OX" provided value is
overwritten by the "19" from a previous link).
I've only tested 2 versions so far (2.10 and 2.7), though, so I don't know how
far back the issue spans.
I should also say that though the examples in this file are contrived to show
where the clashes occur, the reason I stumbled across this bug is because I
have a set of PDF files that I need to create that have a large number of links
with 6-digit hash values as part of their path, and Apache FOP is rendering
many of those as indistinguishable duplicate values. If this is indeed an
optimization issue for base URIs, and if this feature can be turned off with a
configuration, just let me know, as that type of fix would more suffice for my
use case.
was:
I recently discovered that Apache FOP can overwrite the "url" value encoded in
basic links.
Example:
If there are 2 basic links in a file, and the first has a value with the
characters "0P" and the second link has the characters "11", then the second
link that should have been "11" will render as "OP". I believe that this
happening due to some hashing techniques to cut down on processing when trying
to determine if various URIs are identical.
I have attached both an XSL-FO file and its PDF result as rendered by Apache
FOP 2.10. I've also included a screenshot showing how a hover of a link that
has been overwritten (in that case, where the "OX" provided value is
overwritten by the "19" from a previous link).
I've only tested 2 versions so far (2.10 and 2.7), though, so I don't know how
far back the issue spans.
I should also say that though the examples in this file are contrived to show
where the clashes occur, the reason I stumbled across this bug is because I
have a set of PDF files that I need to create that have a large number of links
with 6-digit hash values as part of their path, and Apache FOP is rendering
many of those as indistinguishable duplicate values. If this is indeed an
optimization issue for base URIs, and if this feature can be turned off with a
configuration, just let me know, as that type of fix would more suffice for my
use case.
> Basic-link external destination URL are overwritten with previous values in
> an FO input stream
> ----------------------------------------------------------------------------------------------
>
> Key: FOP-3251
> URL: https://issues.apache.org/jira/browse/FOP-3251
> Project: FOP
> Issue Type: Bug
> Affects Versions: 2.10
> Reporter: Mark Custer
> Priority: Major
> Labels: link
> Attachments: Hover_showing_19_overriding_OX_in_basic_link.png,
> test-links.fo, test-links.pdf
>
>
> I recently discovered that Apache FOP can overwrite the "url" value encoded
> in basic links.
> Example:
> If there are 2 basic links in a file, and the first has a value with the
> characters "0P" and the second link has the characters "11", then the second
> link that should have been "11" will render as "OP". I believe that this
> happening due to some hashing techniques to cut down on processing when
> trying to determine if various URIs are identical.
> I have attached both an XSL-FO file and its PDF result as rendered by Apache
> FOP 2.10. I've also included a screenshot showing how a hover of a link that
> has been overwritten (in that case, where the "OX" provided value is
> overwritten by the "19" from a previous link).
> I've only tested 2 versions so far (2.10 and 2.7), though, so I don't know
> how far back the issue spans.
> I should also say that though the examples in this file are contrived to show
> where the clashes occur, the reason I stumbled across this bug is because I
> have a set of PDF files that I need to create that have a large number of
> links with 6-digit hash values as part of their path, and Apache FOP is
> rendering many of those as indistinguishable duplicate values. If this is
> indeed an optimization issue for base URIs, and if this feature can be turned
> off with a configuration, just let me know, as that type of fix would more
> suffice for my use case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
