Re: Batik support for WMF files without an APM header

[Hervé Girod <he...@club-internet.fr>]

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: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org