[ 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:27 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. EDIT3 - Oops! Overlooked that this is shared code between the PDF and PostScript renderers... More thinking required. 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? 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. > [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)