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%20Component >> >>s >> >>/ >> >>http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e11 >> >>2 >> >>69 >> >>5 >> >>1a2 >> >>d98-7ffe.html >> >>http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e11 >> >>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
