[
https://issues.apache.org/jira/browse/FOP-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043435#comment-15043435
]
Andreas L. Delmelle edited comment on FOP-2549 at 12/6/15 10:25 PM:
--------------------------------------------------------------------
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
EDIT2 - To answer my own question: Yes, absolutely! :) Currently,
{{o.a.fop.pdf.PDFFunction}} somehow has to import functionality from the
{{o.a.fop.render.gradient}} classes, in order to construct a Type 3 Stitching
function, which seems wrong on so many levels... :( Seems like a perfect
opportunity to improve the code here.
was (Author: adelmelle):
Also not an expert here, but at any rate, from what I can tell, the problem
seems to be deeper, and this would be a quick-fix in that it merely 'fakes' an
extra interval, where there should not really be any. Additionally, whether
that value of 0.999 (= 99.9%) suffices, may depend on other factors, like the
output resolution (I think) ? If the precision is increased, you may eventually
end up with a percentage that is low enough so that it does not produce a
noticeable difference on any currently available printer/output medium.
So, if I interpret correctly, an SVG gradient is translated into a PDF Type 3
Stitching Function. A gradient having 3 stops with respective offsets of 0, 0.5
and 1, could be translated into a function with Domain [0.0, 1.0] and a Bounds
array of 1 element [0.5].
The first subdomain would then run from 0 (inclusive) to 0.5 (exclusive), the
second subdomain from 0.5 (inclusive) to 1 (*inclusive*).
It may be the case that something is just going wrong with the processing of
the last subdomain, for which the PDF spec clearly states that it is the only
interval that is supposed to be fully closed, on both the left and the right.
All other subdomains are half-open, closed on the left but open on the right.
EDIT - Still looking closer at this, but it just caught my eye -- and I think
this is a bit strange -- that the {{Function}} class lives _outside_ of the
o.a.fop.pdf or o.a.fop.render.pdf packages... Is that not a class that is very
specific to PDF output, and potentially lends itself to other uses than just
gradients/shadings?
> [PATCH] SVGs with radial gradiant causes PDF display error
> ----------------------------------------------------------
>
> Key: FOP-2549
> URL: https://issues.apache.org/jira/browse/FOP-2549
> Project: FOP
> Issue Type: Bug
> Components: image/svg
> Reporter: Matthias Reischenbacher
> Attachments: fop-2549-test-case.pdf, fop-2549-test-case.svg,
> fop-2549-test-case_wrong.pdf, fop-2549.patch
>
>
> A radial gradiant isn't processed correctly by FOP. E.g. the following
> gradiant:
> <radialGradient
> cx="51159.898"
> cy="57300"
> r="5279.6602"
> fx="51159.898"
> fy="57300"
> id="id0"
> gradientUnits="userSpaceOnUse">
> <stop
> id="stop28"
> style="stop-color:#fefefe;stop-opacity:1"
> offset="0" />
> <stop
> id="stop30"
> style="stop-color:#cdcece;stop-opacity:1"
> offset="0.58823502" />
> <stop
> id="stop32"
> style="stop-color:#9d9e9e;stop-opacity:1"
> offset="1" />
> <stop
> id="stop34"
> style="stop-color:#9d9e9e;stop-opacity:1"
> offset="1" />
> </radialGradient>
> is only outputted with one "Bound" entry in the PDF color function (instead
> of two).
> When opening the PDF with Adobe Acrobat the SVG is only partially displayed
> and an error message pops up after clicking on the image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
