Request for Question Clarification by
webadept-ga
on
28 Dec 2003 05:43 PST
Hi again? glad you wrote back, this question interests me as I'm doing
a great deal of work lately in this area on a few other projects. I'm
not sure what level of programming knowledge you are at, so if I
appear to be "talking below you" please understand that it is not
meant to mean anything except in the area of "clarity".
Okay, you said
-------
Purpose -- Instant creation of intelligent buttons, tabs, menu items,
and animated shapes for insertion and floating in new and existing
pages.
Buttons would also be inserted inside of swf files.
Can you recommend a way to implement 100% success during the editing /
conversion process?
Also, do you know of a way to insert this SVG parser into my flash
code? If I can get the actionscript affects and svg parsing, that
would be a nice first step:
------
If this is our final goal, then we are going about it in the wrong
fashion. I can do this, but it would not be to your project's benefit.
First, the library and functions, once completed, for each button, or
even the smallest graphic, would be included in the final file, adding
a huge overhead to these.
Second, created this way, each button and graphic, if it was possible
to save it in this manner, would have to "create" itself every time it
was loaded.
Third, ? it is not possible to save it this way, since ActionScript
cannot 'save' files. We could work around this, by creating a text
file of sometype, xml or something to load variables and tell the
basic flash component created for you to load the right SVG file for
conversion, but this just adds another level of overhead to the SWF,
and, more processing time.
Four, our button would not be "smart" as we could not save the desired
functionality in this manner, again, SWF can not change itself and
recompile. There is no work around for this, as SWF will not read an
external text actionscript library and use it. FLA's will do this in
the development stage, but once compiled, it will no longer be able to
do this. The file read would simply be added text.
Five: doing it this way, even if all the problems could be worked out,
limits our output files in size, shape and complexity.
And last but certainly not least in the problems of this approach is
fonts. Adding the right fonts to the "prototype" file would be messy
indeed, and a absolute monster in the size problem. Literally, even a
modest list of fonts added for the user to apply to their button,
would add almost two megs to the final SWF file, for every button or
graphic, whether the font is used or not.
I've done this, and the action script needed to import the SVG file
would be several times larger than the SVG file itself. What we would
have at the end is a very slow, very large, very clumsy SWF button. It
is a great pastime in the "gosh.. can I do this?" area, but that is
all it is.
What we want to do, if this is our goal, is this:
1. Create an SVG file in a known and controlled format, with fonts and
size and colors.
2. Get the desired "smart" action from the user (what ever it is, in
ActionScript language, the user wants the button to do, this could be
a set library with changeable variables).
3. Parse, the SVG file, and set the actionscript for the SWF outside
4. Create, import only the fonts we are really going to use, if any,
compile and save the SWF file for use on a website or, importing into
another SWF file created in a similar manner, or through the Flash
interface.
What we have now is a SWF file which does the desired actions, and has
only what is required to do it's job complied inside. Thus it is as
small, and fast as possible. Also, changing the Look, or Action of the
"smart" button or graphic is simple as well, creating a new file. You
would have now a method of creating libraries of swf's, or changing
the color scheme of existing swf's used on a website, simply by
changing a few hex codes and recompiling.
To do this we can use PHP, or Perl, or Python. I know and have a great
deal of experience with the PHP or Perl methods. We can also do this
in a Visual C++, but I personally would want to start with the Perl
method for a prototype, because the time is much less, and you could
work out any bugs or problems with the steps involved, before
committing the time required for the C++ version.
Our development overhead, is top heavy in the "drawing interface"
There is a reason the very talented people at ActionScript-Toolbox,
only did "one" graphic at a time on their demo there, with no color
changes or really anything else. It's a lot of work for a demo. Much
more than say, 8 or 10 hours.
What is a bit "ironic" is, the fastest method of developing an
interface to draw and design with, would be a Flash program, like is
seen on the http://www.eddiecat.us site. There is also a interface at
source forge I've been watching for some time now with a great deal of
interest.
http://drawswf.sourceforge.net/
It is in Java, but it does create and save SWF images, and uses SVG
files as it's 'save' file. It will also give you an idea of the size
and complexity required of a drawing interface to do this type of
work. *Side comment : of course the Warning, given by the Java
WebStart interface when it loads will scare the pants off any
potential user of this program as well. J (This Program is requesting
Unlimited Access to your Computer?) Ha! But it is a great work in
progress, and an example of some very talented people.
You said :
I would be satisfied to do this, and wonder if you can create an
action-script that can create an SWF movie that will parse any SVG
file that is equal or less than its size?
The "any" part is a bit scary there, as I'm very sure given enough
time I can do this, I can't do it under the existing budget, or time
frame. I can, parse and create SWF's from simple SVG's, and add to
those SWF's a few examples of dynamic ActionScript "smart" commands
with dynamic font loading. This I could do under the time frame (the
budget is a bit tight).
The drawing interface gives us the advantage (a huge advantage) of
controlling the type and style of SVG created. With this control in
place, we can be certain of several things, which we can be certain of
in no other fashion really. Again, almost every program I've looked at
which creates SVG files, does so in it's own little way, and a great
deal of them are not compatible with each other. So if a user
approached this tool I created with an SVG file they made in Corel or
Adobe, it is almost certain to not work correctly. It's a shame really
that the "S" in SVG is for "Scalable" rather than "Standard" but there
you have it.
The tools and technology however is definitely available and, really,
it is only a matter of putting them together in the proper rows. We
can create from SVG an SWF file, with button or movie clips, or
graphics. We can put movie clips inside movie clips, so the
limitations on "what" we can create on the fly is really unlimited. We
can add fonts dynamically, and even images in PNG, JPG or BMP format,
and alter ActionScript commands to these movie clips to load other
webpages, respond to javascripts, or talk to them on the webpage. And
we can set the final SWF file to load a set of directions externally
from an XML file or other text file for things like changing prices
and displayed help text, so that the owner of the website only needs
to change a text file to alter values in the SWF file. All of this,
and much more is possible. More than possible, it is being done, in
one form or another, by me, and several others out there on the
Internet. You idea here is simply another way of putting these
together, which is currently (as far as I know) not being done.
I took a little break here from this rather long and growing response.
I apologize for being so long winded, but as I said, this question and
questions like it are of growing interest to me. I've been playing
around with the newest version of DrawSWF (the java program I
mentioned above), and they have come a very long way. The interface is
still a bit clumsy, but they are certainly moving in the right
direction. What is really interesting me right now, and what drew me
away, is the SVG output they create. It is clean, set, and from what I
can see, more or less, predictable. I mean this in a programic sense.
The font list comes from the user's installed fonts, so this isn't
really good enough for what you are trying to do, but ?
And they have a function to load images into the SVG, which again,
isn't great, because we have no control over where this image is, on a
website but?
Other than those two things, the SVG is clean and "simple" ? I'm very
tempted to suggest I could create an SWF from this tool's output, with
"functionality" . The functionality of course is the only thing they
are missing (besides the fonts and graphics) to being a completed idea
of what you are looking for.
Well.. I think this is long enough and brought up way more than enough
things for you to think about, and get back to me on. Check out the
DrawSWF program, you can download the jar file to your computer and
run it there (if you have Java installed of course), and go over what
I suggested about the "way" you want to do this to meet your goal. The
DrawSWF project shows this very well, and if you check the sizes of
the SVG files, vrs the sizes of the exported SWF files, it shows it
even more. Add those two together and you get basically the size of
what a file from your orginianl concept would create (minus all the
nessesary fonts of course).Let me know the outcome at very least, as I
am very interested in what the question poses.
Thanks,
webadept-ga
