Re: CTM - e (tx) and f (ty) divided by 1000

2002-07-29 Thread Keiron Liddle

On Sat, 2002-07-27 at 01:40, Kevin O'Neill wrote:
> Ok, so the millipoints conversion is specific to the xsl:fo to pdf
> conversion, the fo tree being in millipoints (correct me if I'm wrong).

All lengths are in millipoints from the properties, fo tree to area
tree.
The renderers usually work in points (I think all of them that draw to
an output do). So they need to divide by 1000.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: CTM - e (tx) and f (ty) divided by 1000

2002-07-26 Thread Kevin O'Neill



> > My quick solution was to add a method toPDFArray() that does what the
> > current toArray() does and update toArray() not to do the division and
> > updated the call in startVParea().
> 
> The toArray() method gets the proper value in terms of points so it is
> not really pdf specific. The values we normally use for the area tree
> are in millipoints.
> Maybe we could return an AffineTransform with the point values, and the
> toArray can return the stored values, ie. without dividing by 1000.

Ok, so the millipoints conversion is specific to the xsl:fo to pdf
conversion, the fo tree being in millipoints (correct me if I'm wrong).

I tried using affine transforms, but my transformations where horribly
sheared.

> > I think a better solution would be to create a helper class in
> > org.apache.fop.render.pdf that does the toPDF functions and remove the
> > knowledge of the pdf rendering requirements from org.apache.fop.area.CTM
> > If this seems like to right way to go I'll create some patches for this.
> 
> Yes, the pdf specific code should probably be somewhere pdf specific.

I'll create a couple of patches :)

-k.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]