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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]