I just found that the following red marked unicodes can not be shown on Android EditText
Anyboday has met similar issue? And how can I resolve this issue?
Edit again:
I attached another picture to shown the unicode and the corresponding result in Android
If you find that you are trying to use characters that are not in the standard android font then you might consider using a custom font like DejaVuSans.ttf (I use this one for Maths symbols). You display the character by entering its unicode symbol in the format \u...
Start searching for ttf files ... I think it is likely that you will find one that contains the characters you require.
Be aware that this will probably increase the size of your app by 1MB (based on DejaVuSans.ttf).
Information on how to use a custom font can be found here (you don't have to use a sub directory but you should put the file under assets):
Android - Using Custom Font
Related
I am developing an application in Android. I want to show Hindi text for EditText, Buttons, textview, webview
and also I need to get data from json parsing and store in Sqlite.
i have checked many sollutions but the following issues arise
Normal words in hindi can be rendered properly like सरल
the problem arises in words like नित्य
also words like प्र
My questions are
1) which ttf file should i use
2) which min sdk should i target
3) will the sqlite database support unicode
4) how to display data in webview it gets all messed up
is there a simple solution than using
TextView t = (TextView ) findViewById(R.id.hindi);
Typeface face=Typeface.createFromAsset(getAssets(),
"fonts/hindi.ttf");
t.setTypeface(face);
t.setText("Hindi font");
everywhere for textview like setting up a common file to call in res folder like we call strings.xml
I found these ttf available on this link
Android Fonts TTF
try give it a go :)
For the second question the minSdk looks like to be API14 from what I read on this link
Android 4.0 APIs
I know, I am bit late here but this is a known bug for android. You may like to see this thread
my problem is that I can't put '\u221c' unicode on button in Android app. '\u221a' is OK and works, but 221b and 221c doesn't. Also, when I want that button to put text '\u221c' in EditText it puts \u221a. I dont know why it works that way and how to fix this. Please help
This appears to be simply a font problem. U+221A SQUARE ROOT “√” is a much more common character in fonts than U+221B CUBE ROOT “∛” and U+221C FOURTH ROOT “∜”. You may need to find a font that contains them and bundle it into the application, or use other notations.
You can, in particular, use fractional powers instead of roots. That’s even the preferred way, according to the standard ISO 80000-2. So instead of ∜a, you would use “a” followed by “1/4” in superscript style, if that’s possible in the application.
I'm designing an Android app that is to support 10 different languages/localities using Android Studio. The problem is that if I perfect the layout file for English it won't look right for other languages. For instance, some of the text might be truncated/cut off in another language because it is too long for the TextView, even if it is fine in English.
Is it possible to have language-based differences in font sizes in the layout (xml) file?
You should be able to create a layout-es folder to override the layout for the Spanish language etc. I have used it myself for drawables so I can't see why it wouldn't work for layouts too.
#darnmason's solution is correct -- locale-aware layout files do work, and to make it work, just duplicate the resource file in a layout folder with -xx, where xx is the language code. See the "639‑1" heading in this table for the language code.
So, for \res\layout\MainScreen.xml in French, the new file becomes \res\layout-fr\MainScreen.xml.
Despite Android Studio complaining that string resources should be localized into a (separate) resource file, it sometimes makes sense to use a duplicated locale-specific layout file; one such example is in the case referred to by the OP.
In general, try to do localization of text in a strings resource file. Sometimes, however, the translated text in one language would make the UI ugly in another language (compare length of "Nom d'utilisateur" with "用戶名", and the field sizes that result). In such cases, duplicate the layout file, as described above, as more than just the text (dimensions, perhaps fonts) is being localized.
The downside of using an additional layout file per language is that each time something changes (e.g. adding a button), multiple layout files need to be updated with all changes, rather than just adding the control to one layout file, and adding all translations to a separate strings resources file.
I am working on an application that will work on Android WebView. I enabled the selection and copy for this view. In some devices that support Arabic, When I paste the copied text from WebView in any EditText view, It shows me the reserve text. but In some cases it shows me the correct form.
Could any one please help me to show in correct form in all devices ? :-/
I have red all threads that depend on supporting Arabic and Farsi Text, but I can not reach my purpose.
Thanks in advance :)
You can pass your copied text to FarsiLibrary. It will analyses your text letters and justify them according to their possible 4 states (Initial, Middle, End, Isolated) :
Initial like 'ن' in 'نازک'
Middle like 'ن' in 'هنر'
End like 'ن' in 'وطن'
Isolated like 'ن' in 'ایران'
Android has Added support for RTL in Native widgets(i.e TextView , EditText) . so if u run the app onward 4.2 u will get RTL feature automatically ,
http://android-developers.blogspot.com.es/2013/03/native-rtl-support-in-android-42.html
You can create different versions of the layouts for different API versions.
As you can read here: http://developer.android.com/guide/topics/resources/providing-resources.html you can have say the normal folder (/res/layout/) with the layout for old devices and then another one for the ones that support it: /res/layout-11/
The layout inside layout-v11 will only be applied on devices with android 3.0 and over.
The screenshot below displays my problem.
The first EditText shows a hint in Arabic which is shifted upwards, now the second EditText is just for reference which shows the English version completely fine. Same goes for the Button.
I have declared the string in strings.xml like this:
<string name="ar_login">دخول</string>
This is how I set the EditText's hint:
UserName.setTypeface(ArabicFont);
String hint = getString(R.string.ar_HintUserName);
....
UserName.setHint(hint);
UPDATE:
I used this, but of no use:
UserName.setGravity(Gravity.CENTER_VERTICAL);
But with this, Text moved a little down; but i guess its not generic:
UserName.setPadding(0,15,0,0);
With Padding, English words move to downwards.
UPDATE 2:
Originally arabic texts are separated; means they are shown letter by letter. So to join them, i was using this Arabic Reshaper. To Download Code, Check this link
Now when i reshape the arabic text and then set on TextView or as EditText's Hint, it got shifted upwords but without reshaping it is fine.
So i guess, whether i have to change the reshape class OR make my textview to not split the word. But dont know where to go?
I am still unable to find out why Android splits the arabic words into separate letters anyhow in my second edit I am providing a link which uses a class to rejoin the separated letters and form a word again.
In the reshape function, it was mistakenly appending \n at the end, just removing it solves the problem.
I am sure its problem with the font file which you are using.!
[Sorry I am not allowed to upload the screen shot as my reputations are lower :(]
For the layout, I was setting text in xml, and typeface in code. And I'm not setting any attributes like padding/gravity. But it was working fine for me.
So, I can assure you that using font file whose style matches your requirement will solve your problem.
Just to help you out with, but 'm not sure I got font file from DroidSansFallback.ttf
Just a guess :) ...,
What if the size of the Arabic font is lower? [If this is the case, then Gravity.CENTER_VERTICAL should have worked for you :( ]
May be this is the style of that font file. How about trying a different font file for Arabic text ?