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

Reply via email to