Hi all,
I agree wit Thorsten here. I'm also not thinking about a generic SMIL
engine in Flash. We can do much preprocessing before export. The first
thing would be to flatten the SMIL tree so we only have a list of
effects to work on in flash.
Augustus, I think we are not that far away from our ideas on how to
implement this. I know that looking on SMIL for the first time can seem
very complicated. But the beauty really is the possibility to compose
very complex looking effects by overlaying a small set of simple
effects.
What effects do we have in SMIL?
Transition effects (Blinds, Wipes, etc.)
Transformation effects (Moving, Rotating, Scaling)
Property Effects (Changing fill colors, fonts, e.t.c)
Motion Paths
Thats it! So I think instead of implementing the aprox 114 legacy
effects from OOo 1.x all individually, lets just implement the few
SMIL effects properly.
I agree, if we do not get a action script guru to sign up for this
then having this scripted can be a problem. But as I said, we can
do as much preprocessing during export as we like. So for a first
step the actionscript would not need to be that complex. For file
size it *would* be preferable if much of the action :) is going on
in script but it is not *needed*.
Anyway, I also agree with Thorsten that who ever codes this decides.
The above is only my personal suggestions on the topic.
Regards,
Christian
Thorsten Behrens wrote:
Augustus Saunders <[EMAIL PROTECTED]> writes:
There are 2 sides to this: 1) what is the "most optimal" solution, and
2) what is the "most realistic" solution? The most optimal solution
involves creating an entire SMIL processing engine in ActionScript.
[...]
So we come around to the "realistic" solution. The realistic solution
is to expand upon the work already done and push it as far as it
goes.
Hi Augustus,
well - your effort estimates appear reasonable, but from experience I
can tell that the hacked-up solution will accumulate at least as much
time poured into it over the years, as if we'd do it right up-front.
At any rate, he who codes decides, so this is all my two cents worth
of counsel. But maybe there's something inbetween full-blown,
independently developed SMIL engine, and coincidental effect
generation (yeah, that's what I call it - just import a PPT
presentation, and see that Impress UI really has no clue either, about
what specific effects are in there): the basic SMIL animations are
few, and very simple in nature. Triggering them is event-based (either
time, or other effects start/end, or user interaction). So, whipping
up such a simplified engine should be possible in your two weeks
time frame, and getting that broken-down SMIL is certainly possible
with the existing c++ smil processing.
My rough guess is that we can get to about 90% compatibility without
substantial structural changes.
As I said, I doubt that with arbitrary PPT input. But certainly true
for Impress 2.x generated input.
Cheers,
-- Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
