On 14.12.2007 14:18:36 Adrian Cumiskey wrote: > Jeremias, > > Jeremias Maerki wrote: > > Adrian, > > > > I wanted to plug in the new image package into the AFPRenderer in the > > branch and found out that I cannot even render the simplest of SVGs > > (like [1]) after the addition of the Graphics2D implementation here. The > > image is painted but much too small and in the wrong place. > > The example [1] you provide is very small (only 16pt in width and height). I > have tested the > Graphics2D implementation with a number of complicated SVG examples (tax > return forms, fractal > patterns etc). All my tests were done AFP-Lookup Professional, AFP Explorer > and IBM's AFP Workbench > Viewer (which is essentially the same app as the IE plugin), as I've found > all of these products to > be lacking in some way so I use all of them for the purposes of software > testing. When I'm happy > with how the software is interpreting the AFP byte codes I do a hard copy > test by sending it to a > queue on IBM's Infoprint Manager where it is serviced by an IBM Infoprint > 1585. Could I ask you how > you are testing your AFP output and what the context is of referencing the > svg file in your fo?
I only have the IE plugin. No AFP hardware to test with. snif. Basically, it was just a: <fo:block> <fo:external-graphic src="test/resources/images/img-w-size.svg"/> </fo:block> No special configuration (i.e. the defaults). Really the simplest of possible cases and it came out wrong. > > Furthermore, I noticed that there are NullPointerExceptions as soon as a > > user calls AFPGraphics2D.create() because the parent values are not > > copied from the parent Graphics2D in the copy constructor. > > This is an oversight in my testing, I tested its use only through > AFPSVGHandler (which is the > standard way it is handled). I will fix the copy constructor. > > Adrian. Jeremias Maerki
