swftools-common
[Top][All Lists]
Advanced

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

Re: [Swftools-common] buggy pdf2sw conversion?


From: Ricardo Pedroso
Subject: Re: [Swftools-common] buggy pdf2sw conversion?
Date: Sat, 12 Feb 2011 23:39:32 +0000

On Sat, Feb 12, 2011 at 10:54 PM, Chris <address@hidden> wrote:
> On Sat, 12 Feb 2011 21:51:27 +0000
> Ricardo Pedroso <address@hidden> wrote:
>
>> > going back to previous frames, because there is (one or more frames)
>>> less to read. And this isn't the case.
>>
>> No. As I understand when you go back the flashplayer need to read all the > 
>> frames starting from frame 1 until the one to be displayed.
>
> You read the Format specification page too then?  There's more.. ;o)
>

Didn't read that part, I just read parts of it when I need some info.
But the quote you post makes sense and explains what is happennig.


>> Do the conversion of the pdf with:
>>
>> pdf2swf -O1 file.pdf
>>
>> or  -O2 or -O3
>
> Yes, I've been meaning to ask.. What exactly do those three parameters do
> Ric?  Not documented.

They are shortcuts to:
O1) -s poly2bitmap
O2) -s poly2bitmap -s bitmapfonts
O3) -s poly2bitmap -s bitmapfonts -s ignoredraworder

For example when using -O2 we can reduce the number of "assets" for each frame.
Each frame will have only one bitmap to display or at worst will
additionally have some buttons for the links

You can try to convert with -O1 and with no parameters into different files
than compare the output of swfdump of each one.

Compare for example the frame 18 (the one with a bunch of guns, skulks -
could not be more appropriated - just kills some flashplayer's performance :) )

With no parametes there are a bunch of tags just after SHOWFRAME 17
until the SHOWFRAME 18.

With -O1 you only have:
[01c]         2 REMOVEOBJECT2 removes object from depth 0001
[014]     29929 DEFINEBITSLOSSLESS defines id 0093 image 841x595 (8 bpp)
[002]        41 DEFINESHAPE defines id 0094
[01a]         5 PLACEOBJECT2 places id 0094 at depth 0001
[001]         0 SHOWFRAME 18 (00:01:07,894)

The later is lighter to the player.

And when we go backward the player needs to begins on frame1
and process all tags until it reaches the desired frame to be able to give you
a correct display.

Note that this is just my conclusion after a little research that was triggered
by the quote you post from the swf specification.
So take it with a little of salt. I may be wrong.... but I guess I'm not ;)


Ricardo



reply via email to

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