You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Tony Morris <to...@jtiger.org> on 2005/10/22 11:12:21 UTC
RTF output
Using the following fo file:
<?xml version="1.0" encoding="utf-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master
master-name="content"
page-height="29.7cm"
page-width="21cm">
<fo:region-body/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="content">
<fo:flow flow-name="xsl-region-body">
<fo:block>
<fo:external-graphic src="images/JavaCrtfd_Prg.gif"/>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
I attempt to generate RTF using the Ant task:
<fop format="application/rtf" fofile="in.fo" outfile="out.rtf" force="true"/>
I receive the following error:
[fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue
[fop] SEVERE: getValue() called on AUTO length
[fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue
[fop] SEVERE: getValue() called on AUTO length
Can anyone provide any pointers to what might be the issue?
--
Tony Morris
http://www.tmorris.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: RTF output
Posted by Peter Herweg <ph...@web.de>.
There's the intention to use the wrapper classes, which are already used by
rest of FOP.
Jeremias made a similiar suggestion on 4th Oct.
I will see, if i can invest some time on that task this week-end.
Kind regards,
Peter Herweg
-----Ursprungliche Nachricht-----
Von: fop-dev-return-28447-pherweg=web.de@xmlgraphics.apache.org
[mailto:fop-dev-return-28447-pherweg=web.de@xmlgraphics.apache.org]Im
Auftrag von Andreas L Delmelle
Gesendet: Dienstag, 25. Oktober 2005 21:10
An: fop-users@xmlgraphics.apache.org
Cc: fop-dev@xmlgraphics.apache.org
Betreff: Re: RTF output
On Oct 25, 2005, at 00:20, Tony Morris wrote:
> I don't have my test case with me, since I am at work at the moment.
> Otherwise, what I recall is setting the size of an external-graphic
> to the
> exact number of pixels (I think if I didn't, the RTF renderer
> wasn't happy),
> the image appeared scaled down, but if I set the image size to say,
> 10x the
> number of pixels, it would not appear 10x bigger than the scaled
> down image,
> but about the size I would expect normally. Granted, I was using MS
> Word
> 2003 for verification, which may well be the culprit.
(cc'ing fop-dev, since the message contains pointers on the causes of
this problem, and may help someone devise a solution for it)
Well, we shouldn't be blaming M$ for everything --however tempting it
may be ;-)
All I can say is that the other renderers all use the same set of
image library wrappers. The RTF renderer currently is the only
exception (support for external-graphics was reintroduced for RTF
about a month ago).
AFAICT, in the long run, it's the intention of switching to the same
set of wrappers for the RTF renderer. Doing so could mean that your
problem disappears, I'm not sure. What is more than certain is that
the current code in the RTF lib is not 100% correct, and even seems
to make the same mistake in interpretation of the related properties
(height/width) that FOP 0.20.5 made, namely interpreting the value of
these properties as the dimensions of the image itself instead of
taking them to be the dimensions of the image's surrounding box.
Looking at the related code in the RTF library, it seems the 'height'
and 'width' of the external-graphic are interpreted as 'desired
height' and 'desired width', which is wrong if neither content-height
nor content-width were specified as 'scale-to-fit'. One can define an
external-graphic with height="10cm" and still have the content take
up only 3cm.
Roughly, it seems line 952 in the RTFHandler:
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
is too simplistic, and should at least become something like:
if (eg.getWidth().getEnum() != Constants.EN_AUTO) {
if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) {
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
} ...
...
}
So, only if width is not specified as "auto" *and* content-width is
specified as "scale-to-fit" (or is of length equal to the non-auto
width) does the external-graphic's width become the desired width for
the image.
If, for instance, width="auto" *and* content-width="auto", the
following could be used (instrinsic width of the image):
newGraphic.setWidth("100%");
I don't think it's all that difficult to tweak the RTFHandler into
handling these properties correctly, but then again, the question can
be asked whether it's all worth it. If the RTF renderer is going to
switch to the default image lib wrappers anyway, this effort would
perhaps be completely in vain.
Anyone?
Cheers,
Andreas
AW: RTF output
Posted by Peter Herweg <ph...@web.de>.
There's the intention to use the wrapper classes, which are already used by
rest of FOP.
Jeremias made a similiar suggestion on 4th Oct.
I will see, if i can invest some time on that task this week-end.
Kind regards,
Peter Herweg
-----Ursprungliche Nachricht-----
Von: fop-dev-return-28447-pherweg=web.de@xmlgraphics.apache.org
[mailto:fop-dev-return-28447-pherweg=web.de@xmlgraphics.apache.org]Im
Auftrag von Andreas L Delmelle
Gesendet: Dienstag, 25. Oktober 2005 21:10
An: fop-users@xmlgraphics.apache.org
Cc: fop-dev@xmlgraphics.apache.org
Betreff: Re: RTF output
On Oct 25, 2005, at 00:20, Tony Morris wrote:
> I don't have my test case with me, since I am at work at the moment.
> Otherwise, what I recall is setting the size of an external-graphic
> to the
> exact number of pixels (I think if I didn't, the RTF renderer
> wasn't happy),
> the image appeared scaled down, but if I set the image size to say,
> 10x the
> number of pixels, it would not appear 10x bigger than the scaled
> down image,
> but about the size I would expect normally. Granted, I was using MS
> Word
> 2003 for verification, which may well be the culprit.
(cc'ing fop-dev, since the message contains pointers on the causes of
this problem, and may help someone devise a solution for it)
Well, we shouldn't be blaming M$ for everything --however tempting it
may be ;-)
All I can say is that the other renderers all use the same set of
image library wrappers. The RTF renderer currently is the only
exception (support for external-graphics was reintroduced for RTF
about a month ago).
AFAICT, in the long run, it's the intention of switching to the same
set of wrappers for the RTF renderer. Doing so could mean that your
problem disappears, I'm not sure. What is more than certain is that
the current code in the RTF lib is not 100% correct, and even seems
to make the same mistake in interpretation of the related properties
(height/width) that FOP 0.20.5 made, namely interpreting the value of
these properties as the dimensions of the image itself instead of
taking them to be the dimensions of the image's surrounding box.
Looking at the related code in the RTF library, it seems the 'height'
and 'width' of the external-graphic are interpreted as 'desired
height' and 'desired width', which is wrong if neither content-height
nor content-width were specified as 'scale-to-fit'. One can define an
external-graphic with height="10cm" and still have the content take
up only 3cm.
Roughly, it seems line 952 in the RTFHandler:
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
is too simplistic, and should at least become something like:
if (eg.getWidth().getEnum() != Constants.EN_AUTO) {
if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) {
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
} ...
...
}
So, only if width is not specified as "auto" *and* content-width is
specified as "scale-to-fit" (or is of length equal to the non-auto
width) does the external-graphic's width become the desired width for
the image.
If, for instance, width="auto" *and* content-width="auto", the
following could be used (instrinsic width of the image):
newGraphic.setWidth("100%");
I don't think it's all that difficult to tweak the RTFHandler into
handling these properties correctly, but then again, the question can
be asked whether it's all worth it. If the RTF renderer is going to
switch to the default image lib wrappers anyway, this effort would
perhaps be completely in vain.
Anyone?
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Oct 25, 2005, at 00:20, Tony Morris wrote:
> I don't have my test case with me, since I am at work at the moment.
> Otherwise, what I recall is setting the size of an external-graphic
> to the
> exact number of pixels (I think if I didn't, the RTF renderer
> wasn't happy),
> the image appeared scaled down, but if I set the image size to say,
> 10x the
> number of pixels, it would not appear 10x bigger than the scaled
> down image,
> but about the size I would expect normally. Granted, I was using MS
> Word
> 2003 for verification, which may well be the culprit.
(cc'ing fop-dev, since the message contains pointers on the causes of
this problem, and may help someone devise a solution for it)
Well, we shouldn't be blaming M$ for everything --however tempting it
may be ;-)
All I can say is that the other renderers all use the same set of
image library wrappers. The RTF renderer currently is the only
exception (support for external-graphics was reintroduced for RTF
about a month ago).
AFAICT, in the long run, it's the intention of switching to the same
set of wrappers for the RTF renderer. Doing so could mean that your
problem disappears, I'm not sure. What is more than certain is that
the current code in the RTF lib is not 100% correct, and even seems
to make the same mistake in interpretation of the related properties
(height/width) that FOP 0.20.5 made, namely interpreting the value of
these properties as the dimensions of the image itself instead of
taking them to be the dimensions of the image's surrounding box.
Looking at the related code in the RTF library, it seems the 'height'
and 'width' of the external-graphic are interpreted as 'desired
height' and 'desired width', which is wrong if neither content-height
nor content-width were specified as 'scale-to-fit'. One can define an
external-graphic with height="10cm" and still have the content take
up only 3cm.
Roughly, it seems line 952 in the RTFHandler:
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
is too simplistic, and should at least become something like:
if (eg.getWidth().getEnum() != Constants.EN_AUTO) {
if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) {
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
} ...
...
}
So, only if width is not specified as "auto" *and* content-width is
specified as "scale-to-fit" (or is of length equal to the non-auto
width) does the external-graphic's width become the desired width for
the image.
If, for instance, width="auto" *and* content-width="auto", the
following could be used (instrinsic width of the image):
newGraphic.setWidth("100%");
I don't think it's all that difficult to tweak the RTFHandler into
handling these properties correctly, but then again, the question can
be asked whether it's all worth it. If the RTF renderer is going to
switch to the default image lib wrappers anyway, this effort would
perhaps be completely in vain.
Anyone?
Cheers,
Andreas
Re: RTF output
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Oct 25, 2005, at 00:20, Tony Morris wrote:
> I don't have my test case with me, since I am at work at the moment.
> Otherwise, what I recall is setting the size of an external-graphic
> to the
> exact number of pixels (I think if I didn't, the RTF renderer
> wasn't happy),
> the image appeared scaled down, but if I set the image size to say,
> 10x the
> number of pixels, it would not appear 10x bigger than the scaled
> down image,
> but about the size I would expect normally. Granted, I was using MS
> Word
> 2003 for verification, which may well be the culprit.
(cc'ing fop-dev, since the message contains pointers on the causes of
this problem, and may help someone devise a solution for it)
Well, we shouldn't be blaming M$ for everything --however tempting it
may be ;-)
All I can say is that the other renderers all use the same set of
image library wrappers. The RTF renderer currently is the only
exception (support for external-graphics was reintroduced for RTF
about a month ago).
AFAICT, in the long run, it's the intention of switching to the same
set of wrappers for the RTF renderer. Doing so could mean that your
problem disappears, I'm not sure. What is more than certain is that
the current code in the RTF lib is not 100% correct, and even seems
to make the same mistake in interpretation of the related properties
(height/width) that FOP 0.20.5 made, namely interpreting the value of
these properties as the dimensions of the image itself instead of
taking them to be the dimensions of the image's surrounding box.
Looking at the related code in the RTF library, it seems the 'height'
and 'width' of the external-graphic are interpreted as 'desired
height' and 'desired width', which is wrong if neither content-height
nor content-width were specified as 'scale-to-fit'. One can define an
external-graphic with height="10cm" and still have the content take
up only 3cm.
Roughly, it seems line 952 in the RTFHandler:
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
is too simplistic, and should at least become something like:
if (eg.getWidth().getEnum() != Constants.EN_AUTO) {
if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) {
newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt");
} ...
...
}
So, only if width is not specified as "auto" *and* content-width is
specified as "scale-to-fit" (or is of length equal to the non-auto
width) does the external-graphic's width become the desired width for
the image.
If, for instance, width="auto" *and* content-width="auto", the
following could be used (instrinsic width of the image):
newGraphic.setWidth("100%");
I don't think it's all that difficult to tweak the RTFHandler into
handling these properties correctly, but then again, the question can
be asked whether it's all worth it. If the RTF renderer is going to
switch to the default image lib wrappers anyway, this effort would
perhaps be completely in vain.
Anyone?
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Tony Morris <to...@jtiger.org>.
> Tony Morris escribió:
>
>> Thanks, by explicitly setting a width and height, the problem
>> disappeared - it only occurred for the RTF renderer (though I only
>> tried the PDF one as well). The sizes themselves seem to be a tad
>> obscure though.
Tony, can you be a bit more precise as to what you mean by this last
sentence? All I know is that, in FOP Trunk, with 'height' and 'width'
you only specify the dimension of the area. Use them in combination
with 'content-height' and 'content-width' to get appropriate results.
I don't have my test case with me, since I am at work at the moment.
Otherwise, what I recall is setting the size of an external-graphic to the
exact number of pixels (I think if I didn't, the RTF renderer wasn't happy),
the image appeared scaled down, but if I set the image size to say, 10x the
number of pixels, it would not appear 10x bigger than the scaled down image,
but about the size I would expect normally. Granted, I was using MS Word
2003 for verification, which may well be the culprit.
I will get more exact details when I go home.
Tony Morris
Software Engineer
IBM Software Group, Tivoli Software
Gold Coast, Australia (GMT +10)
Sun Certified Programmer for the Java 2 Platform 1.4
Sun Certified Programmer for the Java 2 Platform 5.0
Sun Certified Developer for the Java 2 Platform
"I am an engineer. If I fail to accept what others accept, I earn their
opprobrium."
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Oct 22, 2005, at 15:01, Glen Mazza wrote:
> I wonder if setting the margins on the fo:region-body (instead of
> the fo:external-graphic) would also have solved this. The example
> you gave had an empty <fo:region-body/> without dimensions, but
> you may have been just abbreviating the sample by removing those
> dimensions.
I doubt it, since many of our own layout-engine testcases have
similar, minimal page-masters. If this were a problem, it would have
surfaced much sooner...
In the meantime, I've pinpointed the culprits. Seems it's the two
calls one lines 952 and 955 in RTFHandler. These should first check
whether the respective property has an enum value of "auto" instead
of assuming that an explicit dimension will always be available, but
what exactly should happen in case either value is "auto", I'm not
sure about that. I'd say the values of content-height and content-
width should also be checked, and subsequently, the total bpd/ipd of
the area containing the graphic can be inferred from its original
size (?)
> Tony Morris escribió:
>
>> Thanks, by explicitly setting a width and height, the problem
>> disappeared - it only occurred for the RTF renderer (though I only
>> tried the PDF one as well). The sizes themselves seem to be a tad
>> obscure though.
Tony, can you be a bit more precise as to what you mean by this last
sentence? All I know is that, in FOP Trunk, with 'height' and 'width'
you only specify the dimension of the area. Use them in combination
with 'content-height' and 'content-width' to get appropriate results.
HTH!
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Glen Mazza <gm...@apache.org>.
I wonder if setting the margins on the fo:region-body (instead of the
fo:external-graphic) would also have solved this. The example you gave
had an empty <fo:region-body/> without dimensions, but you may have
been just abbreviating the sample by removing those dimensions.
Glen
Tony Morris escribió:
> Thanks, by explicitly setting a width and height, the problem
> disappeared - it only occurred for the RTF renderer (though I only tried
> the PDF one as well). The sizes themselves seem to be a tad obscure though.
>
> At 07:32 PM 22/10/2005, Andreas L Delmelle wrote:
>
>> On Oct 22, 2005, at 11:12, Tony Morris wrote:
>>
>> Hi,
>>
>>> I attempt to generate RTF using the Ant task:
>>> <fop format="application/rtf" fofile="in.fo" outfile="out.rtf"
>>> force="true"/>
>>>
>>> I receive the following error:
>>> [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
>>> getValue
>>> [fop] SEVERE: getValue() called on AUTO length
>>> [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
>>> getValue
>>> [fop] SEVERE: getValue() called on AUTO length
>>>
>>> Can anyone provide any pointers to what might be the issue?
>>
>>
>> I'm not absolutely sure, but most likely, this message is caused by
>> the default values of height/content-height/content-width... on
>> fo:external-graphic. All these properties default to a value of
>> "auto" and somewhere the property is being queried for its value
>> without checking first whether it has an enum value.
>>
>> Have you tried different output targets? Same problem? If not, the
>> cause of this would be somewhere in the RTFRenderer.
>> To remove these errors, I guess you could try specifying explicit
>> values for height/content-height etc. It's not ideal, but should
>> suffice as a workaround until we manage to track down the unchecked
>> call to getValue().
>>
>>
>> Greetz,
>>
>> Andreas
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>
> --
> Tony Morris
> http://www.tmorris.net/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Tony Morris <to...@jtiger.org>.
Thanks, by explicitly setting a width and height, the problem
disappeared - it only occurred for the RTF renderer (though I only
tried the PDF one as well). The sizes themselves seem to be a tad
obscure though.
At 07:32 PM 22/10/2005, Andreas L Delmelle wrote:
>On Oct 22, 2005, at 11:12, Tony Morris wrote:
>
>Hi,
>
>>I attempt to generate RTF using the Ant task:
>><fop format="application/rtf" fofile="in.fo" outfile="out.rtf"
>>force="true"/>
>>
>>I receive the following error:
>>[fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
>>getValue
>>[fop] SEVERE: getValue() called on AUTO length
>>[fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
>>getValue
>>[fop] SEVERE: getValue() called on AUTO length
>>
>>Can anyone provide any pointers to what might be the issue?
>
>I'm not absolutely sure, but most likely, this message is caused by
>the default values of height/content-height/content-width... on
>fo:external-graphic. All these properties default to a value of
>"auto" and somewhere the property is being queried for its value
>without checking first whether it has an enum value.
>
>Have you tried different output targets? Same problem? If not, the
>cause of this would be somewhere in the RTFRenderer.
>To remove these errors, I guess you could try specifying explicit
>values for height/content-height etc. It's not ideal, but should
>suffice as a workaround until we manage to track down the unchecked
>call to getValue().
>
>
>Greetz,
>
>Andreas
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
--
Tony Morris
http://www.tmorris.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: RTF output
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Oct 22, 2005, at 11:12, Tony Morris wrote:
Hi,
> I attempt to generate RTF using the Ant task:
> <fop format="application/rtf" fofile="in.fo" outfile="out.rtf"
> force="true"/>
>
> I receive the following error:
> [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
> getValue
> [fop] SEVERE: getValue() called on AUTO length
> [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength
> getValue
> [fop] SEVERE: getValue() called on AUTO length
>
> Can anyone provide any pointers to what might be the issue?
I'm not absolutely sure, but most likely, this message is caused by
the default values of height/content-height/content-width... on
fo:external-graphic. All these properties default to a value of
"auto" and somewhere the property is being queried for its value
without checking first whether it has an enum value.
Have you tried different output targets? Same problem? If not, the
cause of this would be somewhere in the RTFRenderer.
To remove these errors, I guess you could try specifying explicit
values for height/content-height etc. It's not ideal, but should
suffice as a workaround until we manage to track down the unchecked
call to getValue().
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org