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 Andreas L Delmelle <a_...@pandora.be> on 2005/10/25 21:09:35 UTC
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
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