Does J2ME/MIDP handle BiDi & character joining when displaying Arabic(etc) Unicode?

[alexkerr]

I'm writing a J2ME app to display unicode text for non-Latin scripts, especially ones that are written right to left (like Hebrew) and also where multiple characters get combined to form one character using character shaping/joining rules (e.g. Arabic, various Indian/Asian languages etc).

Firstly, I'm assuming that a phone sold somewhere will have the correct fonts to support text displayed in that font (e.g. Arabic fonts if sold in an Arabic country, Hebrew fonts if sold in Israel, Farsi font if sold in Iran, Simplified Chinese font for China etc.). Is this an OK assumption? (I know it's not absolute but would it be generally the case - and for non-Nokia phones too?)

Second, and my main question, if I've got a Unicode string (encoded in UTF-8) e.g. in Arabic and I just want to display it on screen using standard J2ME method Graphics.drawString(), will the J2ME implementation on the phone handle the BiDirectional (BiDi) algorithm and character shaping for Arabic? (or whatever other languages/fonts are built into the phone).

Surely I don't have to implement my own BiDi algorithm and character shaping rules....or do I?

(Note I have searched quite extensively on this subject on the Forum before asking, so if I have missed a reply that answers my query, I'd be happy to be directed to it!).

Many thanks,
Alex

[petrib]

Firstly, I'm assuming that a phone sold somewhere will have the correct fonts to support text displayed in that font (e.g. Arabic fonts if sold in an Arabic country, Hebrew fonts if sold in Israel, Farsi font if sold in Iran, Simplified Chinese font for China etc.). Is this an OK assumption?

Usually it is a correct assumption at least as far as Nokia is concerned.