I think supporting SVG natively is the best option going foward. It should be possible to utilize something like AS3SVGRenderer to support SVG rendering in Royale. [1]
Thoughts? Thanks, Om [1] https://github.com/lucaslorentz/AS3SVGRenderer On Mon, Feb 26, 2018 at 10:10 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > IMO, this deserves its own thread. > > I think there are several choices. I've not ever really analyzed and > compared SVG to SWF, but one possibility is to write an SVG Interpreter in > ActionScript that translates SVG into flash.display.Graphic calls. Of > course, that sounds like a really big project, which it probably is, but > with PAYG and DAYG (do as you go) it seems like it might be the true final > answer because then ActionScript that you write to manipulate the SVG at > runtime can work. More on this later. > > I think the only choice that currently works is to embed the SVG in a SWF > with the Flex compiler. I don't see support for SVG transcoding in the > Royale compiler, but I could have missed it. > > Another option is to try to transform SVG back to FXG. I think Om wrote a > transform from FXG to SVG. > > Then there are options that transform SVG to PNG or other non-vector image > formats. > > It would be easier on the runtime to have the compiler do the > transformation, but I'm tempted to have the ActionScript code do it > because then the asset that is deployed and loaded is the same SVG. You > don't have to copy an SVG file for JS and an FXG or SWF or some other file > for Flash. > > I mentioned in another thread that for SWF, we first want to get the > bounding boxes right, then worry about the pixels. That's because, until > customers really demand it, it may not matter how good the SWF output is > as long as it can be used to test your business logic. You may never > deploy the SWF version, but it should save you time in catching errors in > your code but I know I would want the UI to layout close enough to the JS > version that I don't have to go and tweak a lot of the UI after I'm done > testing on Flash/AIR. > > So, with PAYG/DAYG, the initial implementation of an SVG interpreter would > just draw a filled rectangle of the size specified in the SVG. Then over > time as needed we would add beads for each SVG tag. > > Anyway, those are my thoughts on it. Definitely want to hear from Om and > anyone else who has spent more time around this topic. > > HTH, > -Alex > > On 2/26/18, 1:45 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi Alex, > > > >many thanks, just test and this is working fine! :) > > > >One more thing to think about now that we get to this point. In order for > >SWF and JS versions to share the same assets...should we move swf to the > >same folder than "assets"?...or maybe put assets (and maybe CSS) directly > >on "target" folder? So any output could grab a the same assets folder (or > >in other words, to avoid copying 2, 3 or more versions of the same files) > > > >I'm thinking in make JS and SWF version and try to match both, but for > >this > >I need to know how I can load the SVG from Flash. Right now is referenced > >in CSS, but don't know if SWF version can handle as well SVGs in CSS. If > >is > >possible that would be great since will make the creation of themes more > >easy > > > >Thanks > > > >Ca > > > > > > > > > >2018-02-26 19:36 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > > > >> OK, I just pushed a change for this in vivid-ui-set branch. It seemed > >>to > >> work for me. > >> > >> HTH, > >> -Alex > >> > >> -- > >> Carlos Rovira > >> > >>https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me% > >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C74ac42b84dbb4bcd7b8508 > >>d57d624f87%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C63655278355713391 > >>7&sdata=FNLpJCEUmENigzmOpOexcH446lX%2BDhGag1%2FmrjcP3V0%3D&reserved=0 > >> > >> > >> > >
