Re: fop-0.90.alpha1: SVG graphic outside bounds of table cell when using PDF
Ryan, you should work with a viewBox attribute on the svg root element. Otherwise, the simple numbers for widths are interpreted as pixels at 72dpi which causes the SVG to appear with a fixed width. Furthermore, it is a good idea to specify the size of the SVG itself as a length (pt, for example). A very simple example: svg width=11pt height=11pt viewBox=0 0 20 20 g style=fill:red; stroke:#00 rect x=0 y=0 width=15 height=15/ rect x=5 y=5 width=15 height=15/ /g /svg Furthermore, if you want the SVG to be fit into the box you define using instream-foreign-object you should specify content-width=scale-to-fit. Otherwise the SVG is simply matched into the upper left corner of the i-f-o's box at the default size. I hope that helps. On 21.12.2005 22:31:02 Ryan Gustafson wrote: Hello, I'm using fop-0.90.alpha1. The following is a sample XSL-FO document which when converted to PDF results in the SVG graphic on the last row of the table being outside the bounds of the table cells. Notice the other identical graphics which correctly render inside the bounds of the table cells. Feel free to contact me for further details if needed. I can provide the PDF being generated if requested. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fop-0.90.alpha1: SVG graphic outside bounds of table cell when using PDF
Jeremias, Thank you, I don't know why those things would actually make a difference, but they do. The following works as a great checkbox, and it positions properly (it's not way off on the left margin of the page in neverneverland): fo:instream-foreign-object width=1em height=1em content-width=scale-to-fit svg:svg xmlns:svg=http://www.w3.org/2000/svg; width=1em height=1em viewBox=0 0 22 22 svg:g style=fill:none; stroke:black; stroke-width:2 svg:rect x=0 y=2 fill=black width=20 height=20 stroke-width=1/ svg:rect x=2 y=0 fill=white width=20 height=20 stroke-width=1/ /svg:g /svg:svg /fo:instream-foreign-object I'm evaluating FOP as an approach for generating paper versions of our online forms, and the fop-0.90.alpha1 release has been working great for me so far. Keep up the good work, and I'll be sure to report any issues I encounter. Thanks, Ryan Jeremias Maerki [EMAIL PROTECTED] 12/21/05 3:53 PM Ryan, you should work with a viewBox attribute on the svg root element. Otherwise, the simple numbers for widths are interpreted as pixels at 72dpi which causes the SVG to appear with a fixed width. Furthermore, it is a good idea to specify the size of the SVG itself as a length (pt, for example). A very simple example: svg width=11pt height=11pt viewBox=0 0 20 20 g style=fill:red; stroke:#00 rect x=0 y=0 width=15 height=15/ rect x=5 y=5 width=15 height=15/ /g /svg Furthermore, if you want the SVG to be fit into the box you define using instream-foreign-object you should specify content-width=scale-to-fit. Otherwise the SVG is simply matched into the upper left corner of the i-f-o's box at the default size. I hope that helps. On 21.12.2005 22:31:02 Ryan Gustafson wrote: Hello, I'm using fop-0.90.alpha1. The following is a sample XSL-FO document which when converted to PDF results in the SVG graphic on the last row of the table being outside the bounds of the table cells. Notice the other identical graphics which correctly render inside the bounds of the table cells. Feel free to contact me for further details if needed. I can provide the PDF being generated if requested. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fop-0.90.alpha1: SVG graphic outside bounds of table cell when using PDF
Ryan, the viewBox attribute changes the meaning of coordinates without a length unit (pt, mm etc.). If no viewBox is specified the length unit is interpreted as pixels with the resolution in use by the user agent (user agent here = FOP with 72 dpi). Together with explicit length units on width and height attributes you create a well defined SVG image with an explicitely defined size. Otherwise, the SVG image does not have an explicit intrinsic size, only an implicit one which can vary between user agents (viewer software). On 21.12.2005 23:49:07 Ryan Gustafson wrote: Jeremias, Thank you, I don't know why those things would actually make a difference, but they do. The following works as a great checkbox, and it positions properly (it's not way off on the left margin of the page in neverneverland): fo:instream-foreign-object width=1em height=1em content-width=scale-to-fit svg:svg xmlns:svg=http://www.w3.org/2000/svg; width=1em height=1em viewBox=0 0 22 22 svg:g style=fill:none; stroke:black; stroke-width:2 svg:rect x=0 y=2 fill=black width=20 height=20 stroke-width=1/ svg:rect x=2 y=0 fill=white width=20 height=20 stroke-width=1/ /svg:g /svg:svg /fo:instream-foreign-object I'm evaluating FOP as an approach for generating paper versions of our online forms, and the fop-0.90.alpha1 release has been working great for me so far. Keep up the good work, and I'll be sure to report any issues I encounter. Thanks, Ryan Jeremias Maerki [EMAIL PROTECTED] 12/21/05 3:53 PM Ryan, you should work with a viewBox attribute on the svg root element. Otherwise, the simple numbers for widths are interpreted as pixels at 72dpi which causes the SVG to appear with a fixed width. Furthermore, it is a good idea to specify the size of the SVG itself as a length (pt, for example). A very simple example: svg width=11pt height=11pt viewBox=0 0 20 20 g style=fill:red; stroke:#00 rect x=0 y=0 width=15 height=15/ rect x=5 y=5 width=15 height=15/ /g /svg Furthermore, if you want the SVG to be fit into the box you define using instream-foreign-object you should specify content-width=scale-to-fit. Otherwise the SVG is simply matched into the upper left corner of the i-f-o's box at the default size. I hope that helps. On 21.12.2005 22:31:02 Ryan Gustafson wrote: Hello, I'm using fop-0.90.alpha1. The following is a sample XSL-FO document which when converted to PDF results in the SVG graphic on the last row of the table being outside the bounds of the table cells. Notice the other identical graphics which correctly render inside the bounds of the table cells. Feel free to contact me for further details if needed. I can provide the PDF being generated if requested. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
