Hi,
Sorry for the delay... I found that the WMFHeaderProperty class seems to
hint the "good" dimension for the file, although it turns out it ends
not all right after creating the svg file, so the problem must be in the
WMFTranscoder class. I will look at it today and tomorrow.
However, it seems that there is now a regression in the transcoder code,
because some elements are not where they ought to be, even in the case
where THERE IS a APM in the WMF file. I will just file a bug for that too.
@for batik dev: It seems to me that the problem with the scaling in the
case of the lack of APM is not a difficult one (as it is OK when looking
at dimension in WMFHeaderProperty), but there is a nasty bug somewhere
for ALL WMF files that should be fixed before 1.7... I wil lokk at it
today and tomrrow (my PC is OK now ;-))
Herve
Trejkaz wrote:
I found another issue, META_EXTTEXTOUT isn't using the sign and
scaling. Easy to fix, but then I realised something... this sign and
scaling code should probably be in the painter rather than in the
parser... and if it were in the painter, I suspect that affine
transforms would do all the work for us too.
Using units instead of pixels when I take measurements makes 1.7beta1
behave the same as current trunk. Now I'm just trying to figure out
why the scaling is so different between the two. The new version
seems to scale too much. I wonder if this is *also* related to the
scaling logic being done in two places.
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
