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

Reply via email to