Hi Om, This is great to hear!
The fact that performance was acceptable in AIR was what I was hoping to find out. This is not a game or anything, so frame rates is not a major concern (for the most part…). I'm not surprised that HTML/JS/Webfonts did not work out well. Truth be told, the only solution outside Flash that I really see for faithful text rendering would be to create a whole text engine a la FTE in Javascript (rendered inside Canvas or something). Not a small project by a long shot… We will probably be going the AIR route for tablets, and this will probably be a viable solution for the medium term. However, the long term future of AIR is very uncertain (if for no other reason than supporting the plethora of tablet devices might become too difficult for Adobe). This being the case, I think it might be wise to really explore how text rendering might be handled outside Flash -- especially with all this talk of Flex targeting platforms outside Flash/AIR. I don't have a lot of extra time these days (I'm juggling two businesses and a couple of side projects in addition to my very busy family life…). I would be interested in contributing to a text-rendering project if someone else could spearhead it though. (Assuming a reasonable plan could be worked out…) In my search for javascript rendering, I came across this page some time back: http://www.bramstein.com/projects/typeset/ Harbs On Nov 21, 2012, at 10:19 PM, Om wrote: > Harbs, > > The Printui.com app looks very similar to the work I did for an internet > based publishing company for the better part of the last couple of years. > We had much more custom TLF handling code on the front end because the > backend InDesign scripts were not easily modifiable (for various reasons) > The approach we took worked great for web/desktop. > > And when it came time to look at a mobile/tablet app for the same, I was > able to take the same exact codebase and build tablet apps around it and > all the custom TLF code worked perfectly - to my huge surprise. Now, this > is just about rendering fidelity. > > When it came time to start editing TLF fields on Tablets, the way I handled > editing was to just treat it like a normal text field and invoked the > native keyboard, attached an event and updated the TLF based control. > > Of course Adobe documentation says to avoid TLF in mobile apps, but in the > context I was using it with, I dint see any major issues. One obvious > failpoint was when I tried to do a font selector using live fonts(TTF > converted to SWFs) inside of a list. This caused major performance issues > while scrolling. The way I fixed it was a big kludgy - I pre-created > bitmaps and just loaded them as images. In this context, there was no real > need for using live fonts. I dabbled with creating text fields off screen > and created bitmaps during runtime. This approach looks promising as well. > > > This kind of across the platform rendering fidelity is what the Flash > runtime excels in. We dabbled a bit with webfonts, JS, etc. but the > fidelity and performance was no where close to what we had seen with > FlashPlayer/AIR. > > Thanks, > Om > > On Wed, Nov 21, 2012 at 11:40 AM, Harbs <harbs.li...@gmail.com> wrote: > >> I'm probably not the standard Flex developer and my focus is very narrow >> at the moment. >> >> I agree with most of what's been said, but I have not seen my biggest >> concern for the future addressed: TLF. >> >> The lion share of my time is taken up right now by my w2p startup >> printui.com. Reliable rendering of text is critical to the application -- >> not just across browsers, but everything must match the rendering in >> InDesign which we use for both initial document creation and output >> rendering. For us TLF and FTE was a godsend, because we had: >> a) reliable rendering across browsers >> b) quality reproduction of advance typesetting including many OpenType >> features >> c) Built in support for international languages >> d) Rendering that was very close to InDesign's native text rendering that >> only required minor tweaks to get a 100% match. >> e) a framework (TLF) that allowed for easy translation between InDesign >> markup and our web app >> >> Right now, non-desktop support is not a major concern for us, and smart >> phones is not a concern at all because I really don't see editing documents >> on a smartphone. However, tablet support is something that keeps coming up >> and we've had countless discussions on which way to go. None of the options >> are really appealing. I'm leaning towards a port to AIR, but my two big >> concerns are performance and long term ubiquity. As Alex said, who knows >> how many devices Adobe can support before they just throw in the towel. I >> plan on doing some performance profiling to see if I can get the app >> performant enough for tablets. I'm not sure because there's a lot of TLF >> there… >> >> If there was a good way to go to HTML, I'd definitely like to explore that >> avenue, but consistent rendering of text on browsers without Flash just >> doesn't seem to exist. I've seen some experiments of writing a composer in >> JS, but not much more than simple experiments. I'm really struggling with >> how to handle the text rendering on tablets, and if anyone has something >> useful, I'd love to hear! >> >> Harbs >> >> On Nov 21, 2012, at 8:22 PM, Alex Harui wrote: >> >>> >>> >>> >>> On 11/21/12 8:53 AM, "Kevin Newman" <capta...@unfocus.com> wrote: >>> >>>> From what I see, the HTML5 everything push is ending - mostly because >>>> of performance issues on the native app side. >>> Here's my take: sometimes when you buy into the hype to early and the >>> technology isn't ready, you get burned, and then there is a move away. >> But >>> if you don't keep watching you may miss when it does become ready. I >> don't >>> know HTML5, but for sure, there is a lot of smart people working on it. >> It >>> may not be ready today, or even 3 years from now, but will get faster as >> the >>> hardware gets faster, and folks will eventually settle on Dart or some >> other >>> OO language to migrate to from JS. Could be 10 years from now, but I'm >>> pretty sure it will happen. >>> >>> Meanwhile, all of you on this list are in different circumstances, but I >> can >>> think of a three buckets: 1) You are employed by an enterprise that is >> going >>> to need desktops with keyboards for quite some time (although watch out >> for >>> keyboards to go away as natural language input gets better). The >>> availability of fast networks and the lower maintenance of zero-install, >>> browser-delivered apps is attractive, and you can control whether Flash >> is >>> used or not. >>> 2) You are an independent consultant that builds apps for companies. You >>> can't control whether Flash is used or not. >>> 3) You are building an app that just plain needs Flash (maybe premium >> video) >>> or requires a lot of input so you can assume folks will have keyboards. >>> >>> Flash on a desktop with a keyboard will be around for a very long time. >>> There are too many desktops with keyboards in companies who will complain >>> loudly if any of the companies involved (OS, browser, Adobe) screws that >> up. >>> >>> But some projections say that laptop sales in the home/consumer market is >>> doomed by tablets just like pocket cameras were doomed by smartphones. >> If >>> your target customer is not a business worker with a need for a keyboard, >>> you can assume they will soon be using a device that doesn't run Flash in >>> the browser. And, what isn't clear is how well AIR will run on that >> device, >>> if at all. There are so many devices it will be hard for AIR to keep >>> running well (in captive runtime of course) on all of them. >>> >>> This is why, even though Flash will be running in browsers on desktops >> with >>> keyboards "forever", more and more of the folks most of you are targeting >>> won't be using a browser/keyboard combination that is Flash capable. >>> >>> And, eventually, the network speeds and prices and device speeds will >> reach >>> the point where zero-install browser-delivered apps on those devices >> become >>> the predominant paradigm again. >>> >>> For sure, there are plenty of reasons to keep maintaining the current >> code >>> base, and I will invest time there. But I see it as my mandate to try to >>> shape a next generation of Flex that is designed to be ported to other >>> platforms. By going to JS, we get the most coverage for the least >> amount of >>> work, but we have to give up fidelity and performance. Over time, with >>> enough resources, we may be able to target other platforms natively, but >>> that will take a lot of time and effort. >>> >>> I am starting a re-write that prioritizes different things than the >> current >>> code base. It won't use things that are hard to port like weak >> references >>> and Dictionary so you may have to do more work managing memory. It will >>> have other deficiencies and trade-offs and will never match exactly what >> you >>> have today. But it should still feel a lot like current Flex. By >> starting >>> now and trying to get to critical mass over the next year or two, the >> goal >>> is to have a softer landing for those who have a lot invested in AS3 and >> the >>> current code. >>> >>> Those of you who are Haxe fans should definitely start your own rewrite. >> We >>> can't just keep talking about it in email. We won't know how it will >> truly >>> be to move to Haxe until there is something to actually play with. We >> don't >>> have to decide as a community which language to use for a re-write >> without >>> actually trying a couple of different angles. For me, I will stay on AS3 >>> unless I get strong signals that there is no value to any of our current >>> Flex developers by staying on it. >>> >>> -- >>> Alex Harui >>> Flex SDK Team >>> Adobe Systems, Inc. >>> http://blogs.adobe.com/aharui >>> >> >>
