Has anyone explored creating "cached" TLF? Rather than re-composing the text every time it's displayed, the composition could be cached as an image and that would be used rather than the live text. Of course, for this to work, something would have to set a flag to indicate that the text reeds to be "recached" when the content is changed.
On Mar 29, 2014, at 9:30 PM, Maurice Amsellem wrote: > Ok, managed to get the font embedded in the mobile app, but still does not > display correctly. > > So I leave it for now, until someone gets a genius idea... > > Maurice > > -----Message d'origine----- > De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] > Envoyé : samedi 29 mars 2014 18:57 > À : dev@flex.apache.org > Objet : RE: RTL support in mobile apps > > Is this the right way to do it ? > > http://help.adobe.com/en_US/flex/mobileapps/WS19f279b149e7481c6a9f451212b87fe7e87-8000.html > > Maurice > > -----Message d'origine----- > De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] > Envoyé : samedi 29 mars 2014 18:54 > À : dev@flex.apache.org > Objet : RE: RTL support in mobile apps > > Thanks Om, > > That's what I am trying now (embedding the font). > > Maurice > > -----Message d'origine----- > De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash > Muppirala Envoyé : samedi 29 mars 2014 18:50 À : dev@flex.apache.org Objet : > RE: RTL support in mobile apps > > Might be the font. Did you try embedding the font? > > Thanks, > Om > On Mar 29, 2014 6:43 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> > wrote: > >> Hi, I have completed RTL management on mobile skins. >> >> The idea was that all default mobile skins (based on >> StyleableTextField and ScrollableStageText) display correctly when >> using RTL text >> (Arabic/Hebrew) and layoutDirection set to RTL. >> So I changed StyleableTextField to correct it's matrix and textAlign >> and it works!! >> >> Well, almost :-( >> >> I tested it on ADL with default skins => OK: >> https://www.dropbox.com/s/ee61mpazlgyloof/ADL_RTL_OK.png >> >> However, when the same application run on Android or iOS device, the >> letter order is not inverted as it should be. >> https://www.dropbox.com/s/rfme0g60xxkne87/android_rtl_ko.png >> >> See for example the word in Arabic in the action bar title on both >> screenshots. >> >> I don't understand this difference. >> This is not "stage" iOS or Android component (such as StageText), >> which could have a different behavior on ALD and device. >> It's plain AIR rendering. >> So why is it OK on ADL , and KO on the device? >> Very frustrating... >> >> Could it be because of the font used , that wouldn't be the same on >> ALD >> (Windows) and device? >> Or is it an AIR "bug" because RTL is not supposed to work, although it >> does.. >> >> Maurice >> >> -----Message d'origine----- >> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >> Envoyé : lundi 24 mars 2014 22:36 >> À : dev@flex.apache.org >> Objet : RE: RTL support in mobile apps >> >>> I assume this was a release version and not a debug version? >> Damn, I fell in the trap again. Thanks for reminding me. >> I have re-done the tests with release packaging, almost same results: >> 21- 25 FPS for TextField >> 1 ~ 4 for spark Label. >> >> >>> Either way, I don't think TLF will get out to 25fps. >> Yes, 15 would have been fine. but 4 fps is really too bad. >> >>> I'd suggest doing a simple test to see if TextField really can do >>> RTL >> (text starting from the right edge) or just knows how to place >> characters in a string based on some positioning information. >> Yes, that was my intention. Crossing fingers that it works. >> >> Thanks >> >> Maurice >> >> -----Message d'origine----- >> De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 24 mars 2014 >> 21:56 À : dev@flex.apache.org Objet : Re: RTL support in mobile apps >> >> I assume this was a release version and not a debug version? >> >> Either way, I don't think TLF will get out to 25fps. I'd suggest >> doing a simple test to see if TextField really can do RTL (text >> starting from the right edge) or just knows how to place characters in >> a string based on some positioning information. >> >> -Alex >> >> On 3/24/14 1:46 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> >> wrote: >> >>> I just did a quick test to compare TLF and TextField on mobile. >>> Basically, replaced StyleableTextField cell renderer on MobileGrid by >>> spark Label-based renderer. >>> >>> Test results: >>> - iPad 3 (retina) >>> - "slow" iOS packaging , GPU rendering >>> - Mobile grid with 4 columns of text, and 200 rows >>> >>> StyleableTextField => 25 fps when scrolling Spark Label => 1 to 3 fps >>> when scrolling ( UI is very slow, almost frozen). >>> >>> So of course mobile grid displays a lot of text, including >>> multi-line, but that's where performance is needed, not on button and >>> titles, IMO. >>> I could also have used TextLine, but it does not support multi-line, >>> which TextField does, so it's not equivalent. >>> >>> So for me, spark Label is not good enough on mobile, even on recent >>> devices. >>> I will explore the other track (RTL using TextField). >>> >>> What do you think? >>> >>> Maurice >>> >>> -----Message d'origine----- >>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>> Envoyé : lundi 24 mars 2014 11:19 >>> À : dev@flex.apache.org >>> Objet : RE: RTL support in mobile apps >>> >>> Hi Carlos, >>> >>> 1) It's not proven yet that TLF is "fast enough" on mobile, >>> especially when there are lots of text to display, such as in lists of >>> datagrid. >>> Plus I have discovered that the "old" TextField is actually capable >>> to display RTL , but the Flex positioning is broken, so the text does >>> not appear (probably because it was not supposed to work that way). >>> So IMO, the question is still open, and I won't rush into replacing >>> TextField by TLF on mobile. >>> It would be probably much simpler to fix the layout. >>> >>>> Right now we need to deal in different ways with TextInput in mobile >>>> and browser and this defeat the "code once run everywhere". >>> What do you mean? From the SDK developer standpoint, or from the >>> end-user developer stand point ? >>> From the SDK standpoint, the difference is only on the skin, the 'host' >>> component is the same. >>> From the end-user developer, you must use TextInput in both cases, so >>> where's the difference ? >>> The behavior is different, but that's inherent to mobile vs desktop (eg. >>> you don't have softkeyboard or restricted keyboards on desktop). >>> >>> Please explain >>> >>> Maurice >>> -----Message d'origine----- >>> De : carlos.rov...@gmail.com [mailto:carlos.rov...@gmail.com] De la >>> part de Carlos Rovira Envoyé : lundi 24 mars 2014 10:54 À : >>> dev@flex.apache.org Objet : Re: RTL support in mobile apps >>> >>> Hi, >>> >>> if there are plans to introduce TLF on mobile TextInput this will >>> change my priorities about change the internals of MaskedTextInput >>> component and will only make it to preserve slot positions. >>> >>> IMO, if now TLF give us a good performance in mobile this days it >>> will be very useful to make it happen since this will be more aligned >>> to the Flex philosophy. Right now we need to deal in different ways >>> with TextInput in mobile and browser and this defeat the "code once >>> run >> everywhere". >>> >>> So +1 to TLF support on mobile is performance is good! :) >>> >>> Please let me know if that's are the plans. >>> >>> Thanks! >>> >>> Carlos >>> >>> >>> >>> >>> 2014-03-23 21:08 GMT+01:00 Maurice Amsellem >>> <maurice.amsel...@systar.com >>> : >>> >>>> Found a number of tickets on this topic: >>>> >>>> https://issues.apache.org/jira/browse/FLEX-26365 (closed as >>>> "later") >>>> https://issues.apache.org/jira/browse/FLEX-34145 (closed) >>>> https://issues.apache.org/jira/browse/FLEX-34181 (In progress) >>>> https://issues.apache.org/jira/browse/FLEX-33750 (open) >>>> https://issues.apache.org/jira/browse/FLEX-28107 (later) >>>> https://issues.apache.org/jira/browse/FLEX-28103 (later) >>>> https://issues.apache.org/jira/browse/FLEX-26169 (later) >>>> https://issues.apache.org/jira/browse/FLEX-24502 (later) >>>> >>>> Maurice >>>> >>>> >>>> -----Message d'origine----- >>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>> Envoyé : samedi 22 mars 2014 01:14 >>>> À : dev@flex.apache.org >>>> Objet : RE: RTL support in mobile apps >>>> >>>> Yes, that might me the answer: so I need to "cancel" the flipping >>>> like I did for StageText (and like is done in spark Label). >>>> I will try this tomorrow. >>>> >>>> Still does not explain why TextField accepts bidi text now ? >>>> >>>> Maurice >>>> >>>> -----Message d'origine----- >>>> De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 22 mars >>>> 2014 >>>> 01:09 À : dev@flex.apache.org Objet : Re: RTL support in mobile >>>> apps >>>> >>>> Again, I was not highly involved in this code, but IIRC, the >>>> TextLines are never flipped, so if you choose a flipped >>>> layoutDirection the TextLines are re-flipped. But if you start >>>> flipping TextFields without embedded text they go blank. >>>> >>>> Does that explain what you're seeing? >>>> >>>> -Alex >>>> >>>> On 3/21/14 5:00 PM, "Maurice Amsellem" >>>> <maurice.amsel...@systar.com> >>>> wrote: >>>> >>>>> Thanks Alex. That was also my understanding. >>>>> >>>>> Regarding TextInput / TextArea, there is no issue with regard to >>>>> RTL in using StageText ( embedded in StyleableStageText or >>>> ScrollableStageText) . >>>>> >>>>> Now something strange that gets me puzzled. >>>>> >>>>> I did some experiments with mobile components that use TextField >>>>> (actually StyleableTextField) and I managed to displayed >>>>> Arabic/Hebrew (list , titles and nav bar) >>>>> >>>>> https://www.dropbox.com/s/4e4untcp3f4jeb2/List_arabic_LTR.png >>>>> >>>>> But this works only if the surrounding View or the application >>>>> layoutDirection is set to "ltr". >>>>> And indeed, you notice that the text is RTL but the layout is >>>>> still >>>> LTR. >>>>> >>>>> Now, if I set layoutDirection to RTL either at the Application or >>>>> View , then everything disappears: >>>>> >>>>> https://www.dropbox.com/s/jzu1veecjm64m51/list_Arabic_RTL.png >>>>> >>>>> >>>>> I thought that layoutDirection = RTL was "merely" applying a >>>>> mirroring transform to the display. >>>>> >>>>> I am confused. >>>>> >>>>> Maurice >>>>> >>>>> -----Message d'origine----- >>>>> De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 22 mars >>>>> 2014 >>>>> 00:44 À : dev@flex.apache.org Objet : Re: RTL support in mobile >>>>> apps >>>>> >>>>> I wasn't on the mobile components team (I did some mobile work but >>>>> mostly worked on other SDK stuff), but fundamentally, if there's a >>>>> TextField involved, then there is no RTL support. You need >>>>> TextLines for RTL. You may be able to swap in the "desktop" skins >>>>> for TextInput/TextArea and pay the performance and memory hit to >>>>> get RTL text, but then I'm not sure how well StageText will work >>>>> with that, if at all. Essentially, the mobile team traded off RTL >>>>> support for better performance. Now, that was several years ago >>>>> and phones and tablets are faster, so it might be worth revisiting >>>>> that >> decision. >>>>> >>>>> -Alex >>>>> >>>>> On 3/21/14 3:41 PM, "Maurice Amsellem" >>>>> <maurice.amsel...@systar.com> >>>>> wrote: >>>>> >>>>>> Hi Team, >>>>>> >>>>>> Ori Segal has reported a problem in TextInput default skin with >>>>>> RTL (Hebrew, arabic) layout. >>>>>> I have fixed this problem. >>>>>> >>>>>> Now he has reported a problem in TextInput "prompt" text not >>>>>> being displayed in RTL. >>>>>> >>>>>> So I did a small test: set layoutDirection="rtl" to a sample >>>>>> mobile app (with buttons, mobilegrid, etc..) and almost every >>>>>> text >>>> disappeared. >>>>>> >>>>>> The only texts that seem to be displayed correctly are: >>>>>> - TextInput / TextArea with the default text (that is using >>>>>> native >>>>>> StageText) >>>>>> - spark Label, that is using TextLine (and the new FTE/TLF engine). >>>>>> Everything else, that uses the mobile-optimized >>>>>> StyleableTextField, will not display RTL (apparently because it's >>>>>> based on the old TextField engine). >>>>>> >>>>>> Reading the articles below, it seems clear enough that RTL is NOT >>>>>> supported on AIR mobile (with a few exceptions): >>>>>> >>>>>> http://sourceforge.net/adobe/flexsdk/wiki/Mobile%20Text%20Compone >>>>>> nt >>>>>> s >>>>>> / >>>>>> http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e >>>>>> 11 >>>>>> 2 >>>>>> 69 >>>>>> 5 >>>>>> 1a2 >>>>>> d98-7ffe.html >>>>>> http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e >>>>>> 11 >>>>>> 2 >>>>>> 69 >>>>>> 5 >>>>>> 1a2 >>>>>> d98-7ffd.html >>>>>> >>>>>> Alex, as you seem to have been involved in that, do you confirm? >>>>>> >>>>>> Something else: >>>>>> The first article says: >>>>>> " Primarily for performance reasons and support for native >>>>>> predictive text input and editing, mobile will use >>>>>> TextField-based text in all critical areas. This is expected to >>>>>> be a short-term solution until a performant version of FTE arrives on >>>>>> mobile." >>>>>> >>>>>> So has FTE been optimized for mobile since the article was >>>>>> written , for example in AIR 4.0? >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Maurice >>>>> >>>> >>>> >>> >>> >>> -- >>> Carlos Rovira >>> Director de Tecnología >>> M: +34 607 22 60 05 >>> F: +34 912 94 80 80 >>> http://www.codeoscopic.com >>> http://www.directwriter.es >>> http://www.avant2.es >> >>
