Please look at files at URL. At Batik viewer they look fine. But once PDF is generated using FOP dimensions of those files get crazy. Those files are clipped (sample1) or stretched by fop (sample2, sample3). This is serious bug which makes SVG embedding kind of unusable.
Created attachment 17204 [details] Buggy behaviour on SVG of FOP 0.90 TRUNK Those are samplefiles that shows buggy FOP behaviour.
Created attachment 17205 [details] Result using the most recent revision Are you using the binary distribution, or did you check out the source and build yourself? The two last pictures don't seem to get stretched when I run this FO through FOP (revision 356327). Take a look at the sample in attach (don't mind the #'s for the missing glyphs). Is this more like it?
Okay I know what did the trick... I took default config file shipped with FOP TRUNK that has the setting of: <resolution>72</resolution> This setting produced that bug... please try run FOP with this setting in config.. you will see some SVG images will go stretched. This should be fixed.. or this setting should be commented out in sample config.
Can I also kindly ask for explanation why the 1st file is cropped on PDF ?? I generated it using Inkscape, and both Inkscape and Batik viewer are showing this file complete. But FOP is cropping the file. Seems like some DPI, units conversion problem.. resulting that image dimensions are too small comparing to real ones.
[in reply to comment #3] So I did. I still can't reproduce the stretching effect... Maybe it's caused by the fact that I'm on Mac (Apple JVM 1.4.2)? Can anyone else running Windows XP confirm the stretching behavior? [in reply to comment #4] I haven't fully sorted out why the clipping happens. I'm not an SVG expert, so may take some time before I can explain this, but as soon as I find something I'll get back to you.
(In reply to comment #5) > [in reply to comment #3] > So I did. I still can't reproduce the stretching effect... Maybe it's caused by the fact that I'm on Mac (Apple > JVM 1.4.2)? Can anyone else running Windows XP confirm the stretching behavior? No, no stretching here with FOP Trunk. I'll try again tomorrow with fresh energy. > [in reply to comment #4] > I haven't fully sorted out why the clipping happens. I'm not an SVG expert, so may take some time before I > can explain this, but as soon as I find something I'll get back to you. If I set the uaResolution to 96 in org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument() then the SVG doesn't get clipped. PDF normally uses 72dpi. That and the fact that the SVG doesn't use a viewBox is the reason that the sizes differ. As I learned from Thomas DeWeese, having an SVG without a viewBox asks for trouble. In this case here the viewBox should be: viewBox="0 0 400 350"
(In reply to comment #6) > No, no stretching here with FOP Trunk. I'll try again tomorrow with fresh energy. Please try also with <resolution>96</resolution> in FOP config. After that FOP gives me broken PDF at all.. with 72 images are stretched vertically. I have no idea maybe AbstractGraphics2D scale causing that or ... no clue ;) Tell me what is default resolution anyway if I don't set <resolution> in config ? > If I set the uaResolution to 96 in > org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument() then the SVG doesn't > get clipped. PDF normally uses 72dpi. That and the fact that the SVG doesn't use > a viewBox is the reason that the sizes differ. As I learned from Thomas DeWeese, > having an SVG without a viewBox asks for trouble. In this case here the viewBox > should be: viewBox="0 0 400 350" Or even smaller when looking at one set with viewBox="0 0 400 350" the page is too big comparing one visible on Inkscape. When I use Batik Squiggle it reports viewbox as "0 0 384 336" which is more like one in Inkscape... maybe we can use same method as it seems to be more acurate for SVG files without viewBox. It is also Inkscape fault coz there is no way to force it to generate viewBox. Have you been using Inkscape or you do SVG samples by hand ?
(In reply to comment #7) > (In reply to comment #6) > > No, no stretching here with FOP Trunk. I'll try again tomorrow with fresh energy. > Please try also with <resolution>96</resolution> in FOP config. After that FOP > gives me broken PDF at all.. with 72 images are stretched vertically. > I have no idea maybe AbstractGraphics2D scale causing that or ... no clue ;) > Tell me what is default resolution anyway if I don't set <resolution> in config ? I'm not through with this, but at least I have found and fixed a bug in FOUserAgent that read the resolution value as if it were a pixelToMillimeter value: http://svn.apache.org/viewcvs?rev=357063&view=rev The default value for the resolution is 72dpi. > > If I set the uaResolution to 96 in > > org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument() then the SVG doesn't > > get clipped. PDF normally uses 72dpi. That and the fact that the SVG doesn't use > > a viewBox is the reason that the sizes differ. As I learned from Thomas DeWeese, > > having an SVG without a viewBox asks for trouble. In this case here the viewBox > > should be: viewBox="0 0 400 350" > Or even smaller when looking at one set with viewBox="0 0 400 350" the page is > too big comparing one visible on Inkscape. When I use Batik Squiggle it reports > viewbox as "0 0 384 336" which is more like one in Inkscape... maybe we can use > same method as it seems to be more acurate for SVG files without viewBox. > It is also Inkscape fault coz there is no way to force it to generate viewBox. Squiggle, it turns out, uses a user agent that reports 96dpi. That's why the SVG image looks fine there. The same probably applies to the Adobe SVG Viewer and the SVG support in Firefox. Only FOP uses 72dpi mostly because of PDF and PostScript. I'm going to dig a little deeper here. At the very least, I want to know why the images doesn't look good when I set the resolution to 96dpi. > Have you been using Inkscape or you do SVG samples by hand ? I have Inkscape installed and produced a few simple test files with it, but always manipulating the produced SVG by hand afterwards. I also don't like Inkscape too much because of the many bugs. I hope that will soon improve. Most SVGs I create are by hand.
> > Have you been using Inkscape or you do SVG samples by hand ? > I have Inkscape installed and produced a few simple test files with it, but > always manipulating the produced SVG by hand afterwards. I also don't like > Inkscape too much because of the many bugs. I hope that will soon improve. > Most SVGs I create are by hand. Note on the side: if there's a way to derive the size of the viewBox from the other attributes and the target resolution, a possible workaround to avoid the 'manual' intervention may be to insert the SVG as a fo:instream-foreign-object, and add the viewBox attribute via XSLT (combination of: document() + xsl:copy + xsl:attribute + xsl:copy-of)... Just a suggestion. Should be doable, IIC.
(In reply to comment #9) > > > Have you been using Inkscape or you do SVG samples by hand ? > > > I have Inkscape installed and produced a few simple test files with it, but > > always manipulating the produced SVG by hand afterwards. I also don't like > > Inkscape too much because of the many bugs. I hope that will soon improve. > > Most SVGs I create are by hand. > > Note on the side: if there's a way to derive the size of the viewBox from the other attributes and the target > resolution, a possible workaround to avoid the 'manual' intervention may be to insert the SVG as a > fo:instream-foreign-object, and add the viewBox attribute via XSLT (combination of: document() + > xsl:copy + xsl:attribute + xsl:copy-of)... Just a suggestion. Should be doable, IIC. There's no way to derive the size of the viewBox. Otherwise, we would certainly implement it. But the idea of using a wrapper for establishing a viewBox and therefore indirectly correcting for a resolution that is differing from the default is a good one. However, I've just realized that we need two resolutions instead of one. One source resolution (for interpreting the pixel size in an SVG image or a bitmap with no resolution information) and a target resolution (for the effective resolution of an XSL-FO file rendered to a multi-page TIFF or for the resolution of filter effects generated as bitmaps by Batik). I'm currently implementing the necessary changes. The downside here is that the configuration format and the user agent's API would have to be changed in a backwards-incompatible way to have self-speaking names there. But given that we're still in "alpha" mode, that shouldn't be a problem.
Resolution parameter split into source and target resolution. For details, see commit message and updated documentation: http://svn.apache.org/viewcvs?rev=357081&view=rev For Adam, this means he has to set the source-resolution parameter in the config file to "96". Please retest with the latest sources and close the bug if everything's alright. It is on my machine.
Fixes for resolution settings are perfect now. I'm using by default 96dpi for source files and it does the job perfectly now. Thank you for your support. I think we can mark this bug FIXED.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed