One other wrinkle is a lot of the .swfs have _multiple frames_ for
things like mouseover states. I don't think the JSFL I sent you handles
this. We'll need to come up with a convention for frame numbers in the
filenames. I'd suggest appending 0001, 0002 ... to the end of the
filename, before the extension.
Right now, the resource compiler will take a folder in place of a
resource name and compile its contents into a multiframe resource, e.g.:
<resource name="tabrsrc" src="animation/"/>
For an example, see lps/includes/lfc/test/animation.lzx. We might want
to put the sequentially-numbered images in a sensibly named folder.
This introduces some complexity, because the resource compiler will need
to look for directories as well as individual files when deciding to
prefer a png over a swf. Directories _could_ be named after the .swf
for consistency, e.g. 'animation.swf.png/'.
I propose we put this whole multiframe generation issue off until we get
single frame resources working...
-Max
Phillip Apley wrote:
> My intention is that the designers would just save a file with a different
> extension (.png), as Max suggests. Only the automated png generator would
> place files in the special subdirectory. We trust designers to make a better
> version than the automatically generated file. They might want to extract
> the automatically generated file from the special subdirectory as a starting
> point for their hand edited version, but they would put the result next to
> the .swf it is related to. I think all the automatically generated files
> would be reproduced as part of the build process and so keeping versions
> that had been tweaked by hand in the 'normal' place makes sense.
>
> Of course none of this deals with naming conventions for the likely
> possibility that a swf will be replaced by a group of pngs and some special
> logic to stretch and place them. We'll leave this aside for now.
>
>
> on 7/31/06 4:20 PM, Max Carlson at [EMAIL PROTECTED] wrote:
>
>> Phillip G. Apley wrote:
>>> I am writing some scripts which can be integrated into the build process
>>> and will generate .png files for each .swf file in the system as a first
>>> step towards rasterizing components for use in DHTML. I want to be able
>>> to keep track of which .png files were created manually and are
>>> therefore not to be replaced by the automated png generator. I had some
>>> baroque thoughts about managing a database pf pathnames. Then I thought
>>> to put the generated .png files in a special (automatically generated)
>>> subdirectory of the directory in which the swf appears
>>> (legals/.../autopng). The compiler would look for a hand-generated or
>>> approved .png in the same directory as the swf. Then, if there is none,
>>> the compiler would look for a png in the autopng subdirectory. Max
>>> suggested it might be better to name the files resourcename.swf.png to
>>> show they were autogenerated, and avoid creating unnecessary
>>> subdirectories, but to me it seems that parsing and tracking the double
>>> file type is more complicated than just putting the autogenerated files
>>> in a separate subdirectory. Thoughts?
>> The main reason I suggest avoiding a separate subdirectory is for ease
>> of use for LZX developers and the designers working with them. I think
>> most designers would prefer to save a file with a different extension,
>> rather than have to create a new directory. Using extensions may be
>> more work for us and the compiler, but I think it's ultimately nicer to use.
>>
>> -Max
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev