incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Web to Print solutions
Date Wed, 21 Nov 2012 20:19:22 GMT
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.lists@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" <CaptainN@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
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message