swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Swftools-common] libpoppeler


From: Matthias Kramm
Subject: Re: Re: [Swftools-common] libpoppeler
Date: Fri, 9 Oct 2009 17:15:14 -0700
User-agent: Mutt/1.5.19 (2009-01-05)

On Fri, Oct 09, 2009 at 11:58:34PM +0200, Andreas Haufler <address@hidden> 
wrote:
> This class is exactly what its name says ;-). It takes a "flashtype"
> (embedded?) font and computes the fontalignzones for it.

Ah, part of Flex. I see.

> I decompiled it and had a look at it.
> Computing those zones seems not too easy to me :-\

I don't know what it does to compute zones (well, it's probably
a lot of polygon code and polygon stuff always looks difficult
if you don't know the "big picture"), but I very much doubt 
that it really encodes the align zones values it computes as 
IEEE Float16 like the specification claims. 
My current version of swfdump can decode those values, and they're
just pure random when treated as Float16.

> (as long as the characters Z z l L are embedded in the font
> !?!?).

Yes, I saw that part in the (open source) Flex source code. 
I wonder whether this is just a kludge in Flex itself (don't
bother to generate align zones for fonts which don't have these
characters) or whether it's also a test that's performed in
Flash.

> However, I didn't manage to generate correct swfs as result. I
> don't think it's a player bug, since several test swfs fail, even with
> just DefineFont3 tags w/o DefineFontAlignZones.

That would indicate that the problem is indeed in the shape encoding
of the font.

> I think the
> coordinates are somehow the problem. I always tought the EM-square
> would by 1024 by 1024 in flash, so I expected the glymph coordinates
> to be within this range...not true, at least not when using the
> TagDecoder of flex (which is OSS by the way...). Also the TagEncoder
> normally checks the bitlength required by the coordinates and should
> throw an exception if values are too large.

Well, that's just Flex code checking on itself. If Flex has a bug
with coordinate encoding somewhere, chances are that the same bug is
in the test code, causing it to think everything is valid.
Try to run "swfdump -F" on the file. Maybe that'll point out some
problem.

> For my other font problem: No I didn't try the git version of
> swftools, since I "develop"/test under ubuntu local (x86) and the
> production server is debian (lenny  I quess) x64. So I'd need to
> install all tools there first...

Ok, I see. You might want to install a local git repository- it 
seemed to me you use a modified version of swftools.

Matthias





reply via email to

[Prev in Thread] Current Thread [Next in Thread]