You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Kevin O'Neill <ke...@rocketred.com.au> on 2002/07/26 01:28:23 UTC
CTM - e (tx) and f (ty) divided by 1000
I've been having a look at org.apache.fop.area.CTM and I notice that the
toArray() method modifies the e and f elements of the matrix by dividing
them by 1000 before returning them in the array. This seems to be there
to support one function
org.apache.fop.render.pdf.PDFRenderer.startVParea() where it is used to
create an AffineTransform for the current state.
As I'm using the CTM class to generate PDF files outside of xslf:fo and
I don't want e and f to be divided by 1000.
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().
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.
-k
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: CTM - e (tx) and f (ty) divided by 1000
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: CTM - e (tx) and f (ty) divided by 1000
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
<snip/>
> > 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: CTM - e (tx) and f (ty) divided by 1000
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Fri, 2002-07-26 at 01:28, Kevin O'Neill wrote:
> I've been having a look at org.apache.fop.area.CTM and I notice that the
> toArray() method modifies the e and f elements of the matrix by dividing
> them by 1000 before returning them in the array. This seems to be there
> to support one function
> org.apache.fop.render.pdf.PDFRenderer.startVParea() where it is used to
> create an AffineTransform for the current state.
>
> As I'm using the CTM class to generate PDF files outside of xslf:fo and
> I don't want e and f to be divided by 1000.
>
> 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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org