I've found another TMemo rendering oddity that I wonder if anyone had come across before, or could help with?
I've found another TMemo rendering oddity that I wonder if anyone had come across before, or could help with?
I've had a user report of a bug where Arabic characters aren't showing in a TMemo set to ControlType = "styled". Before it's mentioned, I know that Firemonkey doesn't support R-to-L rendering and I'm not looking for that (yet), plus for other reasons, I need to use the Styled memo rather than the Platform one so that's unfortunately not an option either.
A quick way to reproduce is of you put a few Arabic characters into a TMemo at design time and run it on iOS it renders them as spaces. It renders fine on Android and Windows but not iOS.
I've been debugging and tracked it down to a display issue when rendering the glyph for the characters within FMX.FontGlyphs.iOS.pas. The internal data structures store the correct character to be rendered but its as if the glyph bitmaps for late unicode characters (1333 in this case) aren't correct.
I wonder if anyone had experience in this area? TIOSFontGlyphManager.DoGetGlyph() feels like the problematic method but I can't see anything wrong in their code and the debugger becomes almost useless at this level.
Thanks
I've had a user report of a bug where Arabic characters aren't showing in a TMemo set to ControlType = "styled". Before it's mentioned, I know that Firemonkey doesn't support R-to-L rendering and I'm not looking for that (yet), plus for other reasons, I need to use the Styled memo rather than the Platform one so that's unfortunately not an option either.
A quick way to reproduce is of you put a few Arabic characters into a TMemo at design time and run it on iOS it renders them as spaces. It renders fine on Android and Windows but not iOS.
I've been debugging and tracked it down to a display issue when rendering the glyph for the characters within FMX.FontGlyphs.iOS.pas. The internal data structures store the correct character to be rendered but its as if the glyph bitmaps for late unicode characters (1333 in this case) aren't correct.
I wonder if anyone had experience in this area? TIOSFontGlyphManager.DoGetGlyph() feels like the problematic method but I can't see anything wrong in their code and the debugger becomes almost useless at this level.
Thanks
Douglas Rudd that’s a good point but it seems ok on Windows and Android so I would hope it contains them on iOS. I’ll check
ReplyDeleteOn second look, the Arabic does show up if you set ControlType to Platform, so the Arabic characters must be in the font. Why do you need Styled? Because of a colored background? It may be easier to figure out how to color the background in custom code.
ReplyDeleteDouglas Rudd when you choose Platform for ControlType on iOS it creates as UITextView rather than rendering it directly using Firemonkey so is totally different and hard to compare.
ReplyDeleteI can’t remember why we had to use styled rather than platform (I’d need to look back through the logs) but think it was a stability issue when embedded in frames that are embedded on page control tabs in certain situations.
Either way, it looks like a bug in the TMemo styled control which is why I wondered if anyone else had come across and fixed this? Unfortunately FMXRTL isn’t an option either as I’m using Berlin and they only support iOS for Tokyo!