I think I’m going to spend a few weeks prototyping in FlexJS to get a feel for it before making a final decision.
I’d really like to make it work. I’d love to get a normal JS text engine. It seems to me there’s enough people who have an interest in this space that it should be possible to get a joint effort going. Of course there’s the basic question as to whether it should be done using DOM, SVG or Canvas. If there’s a common interface, maybe all three are options depending on the use case, and they could be hot-swapable. As far as porting TLF goes, yeah. It’s a beast. It’s a temperamental beast. I broke things a little too easily when I was working on the table support. Most of the core architecture is pretty sound. There’s a few things I’d definitely want to change (besides trying to make it more lightweight). I really do not like the way FTE and in turn TLF handles paragraph terminators. All the fancy footwork getting those virtual terminators in place, etc. I’d probably make certain things more modular rather than have a single ITextLayoutFormat for every conceivable format in existence. There’s probably a bunch of other things as well. Despite that, starting by porting it as-is like you say might make sense, but we’re getting ahead of ourselves here… ;-) I might ask for help getting up to speed in FlexJS. Stay tuned… ;-) Harbs On Nov 3, 2014, at 7:48 AM, Alex Harui <aha...@adobe.com> wrote: > It is conceivable that the FlexJS compilers will be 1.0 ready by end of > 2015. I think we’ll have a decent set of widgets by then as well. The > big ticket items for 2015 is virtual lists/datagrids/tree. And then > there’s a text layout package. > > Now FlexJS doesn’t just compile its own set of widgets. The idea is that > ActionScript and MXML are great ways to assemble any framework into an > app. If you can wrap a JS UI framework with AS APIs and emulate the JS > framework in AS, then you can build your app in FlexJS and the output will > use the JS UI framework with as little overhead as possible. We’ve tried > it with bits of Jquery, CreateJS, and Cordova already. > > So, if there is a JS text layout engine you can use and approximate it in > AS, then you can use FlexJS to assemble the application and, in theory, > save time by having a better language and tool chain that will catch > errors sooner. > > Now, I would love to see you, Judah, Piotr take on porting TLF to FlexJS, > but I’m definitely biased. In theory, if you abstract the instantiation > of the text widget and the measurement of it, you can just cross-compile > the whole thing and use different text widgets in JS. I would argue that > TLF is a beast and may be more than one would want to run in JS, but at > least we have it. > > FWIW, I don’t spend too much time on studying other alternatives because > MXML and AS is Flex and my only goal is to see how well we can make it > work on JS. > > And here’s a selling point: If you go with some other JS framework and > tool chain and run into trouble, you have to bug them to help you. If you > go with FlexJS, you can fix it yourself or if you need help, I promise to > help you. > > -Alex > > On 11/2/14, 10:02 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> The sooner the better… ;-) >> >> Realistically, we’re looking to “beginning of 2015” for basic WYSIWYG. >> Your guess is as good as mine what that will actually mean. I don’t >> imagine we’re going to approach feature parity before the end of 2015. >> But hopefully at the end of next year we’ll at least be close. >> >> Harbs >> >> On Nov 2, 2014, at 4:03 PM, Alex Harui <aha...@adobe.com> wrote: >> >>> What kind of timeframes are you talking about? When does the first >>> production version on HTML5 have to be ready? >>> >>> -Alex >>> >>> On 11/2/14, 1:51 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> A bit of background: >>>> Our Flash/Flex based web app at printui.com is pretty much feature >>>> complete. The last major features on my list to implement was table >>>> support and page editing support which is more or less done. The next >>>> “big project” is getting support for non-Flash platforms. While it’s >>>> very >>>> tempting to port the app to AIR, our average client needs a web app >>>> rather than a native one. >>>> >>>> So, in the coming months, I’m looking to start work on porting the app >>>> to >>>> HTML. We already have basic HTML functionality implemented using >>>> Angular.js, but it’s a simple forms-based approach. We’re looking to >>>> do a >>>> full WYSIWYG HTML app. I need to decide on what framework we’re going >>>> to >>>> use. Angular has its advantages, but I’m not looking forward to doing a >>>> complex app in pure JS and Angular. >>> >> >
