I have ÷ in .txt file in my android. When this division symbol is shown on android device, I see "�"
To make it worse, my laptop doesn't have division sign on keyboard. I used the above sign from wikipedia.
Any guess how can I resolve this.
You should use the Unicode value for any symbols such as the division symbol you have here.
Try the Unicode U00F7.
When using it within a String format like "\u00F7".
The problem is most likely a font issue, or possibly a unicode encoding issue. The character you pasted is unicode codepoint 0xF7: if the font being used to display your text file does not have a specific glyph for this codepoint, then it will render it using some reserved glyph like the question mark diamond you show. The solution in this case would be to install and use a font which includes an appropriate glyph for this codepoint. For instance, if it is displayed correctly in your web browser, then find out what font your browser is using, and try that. Of course, whether or not you can change the font used to display your text file depends on the application (at least I think: I don't think Android fixes the font across all apps).
Alternatively, it could be an encoding problem. For instance, if you're saving your text file in Latin-1 encoding, then this character will be stored in a single byte with value 0xF7. If the app that you're viewing the file with is assuming it's UTF-8, for instance, then this byte will be interpreted as the first of a multi-byte character, or it may even be invalid. If this is the case, you just need to make sure the encoding you use to save the file is the same as the one being used to display the file. Again, this would be application specific.
Related
In android #font-face do not work for UTF character.(Webpage hosted in web control using cordova)
The code works on chrome browser both on android as well as desktop.
It do not apply the changes in the application.
Observed that if there are no UTF characters then font styling was applied. Also observed that only the lines that has got UTF it is not applied with the web font style.
It was an indication that the path provided in font-face was correct.
Tried changing the UTF character to the encoded hex value and it did not help.
The Problem
In Android 4.3 the character " ്ര "details about this issue and work around is given here
I require this for Android app developed using cordova(phonegap) and hence rooting and installing is not an option.
I tried to do web view with embedded font (#font-face) and strangely, it is not working for web view in android, but works perfectly in browser of the same device.
The Solution
Got a hint from this stack over flow and this was pointing to this Solution, and thank you for that
Basically We need to get an ASCII based font and convert the unicode to mapping ASCII.
The solution provided was using JAVA and always a chance of missing some characters. Another problem that i faced using this solution was, if there is a mix of English and Malayalam character then the solution give undesirable results.
So I created this jquery plugin
Basically It does the following.
Identify the longest possible Malayalam character sequence and wrap them using tag with configurable class name.This process separate English and non English groups.
Each grouped Malayalam character sequence then converted to ASCII using a configurable mapping w.r.t the font.
The problem of Mix of English and Malayalam is solved, problem of missing some character is fixed, and also #font-face is working. I was able to create 2 fonts mapping.
So far the solution is working for me.
I feel some level of optimization can be done.
This question already has answers here:
Is there a "glyph not found" character?
(8 answers)
Closed 7 years ago.
On Android, I want to be able to detect if the font used can display a certain character or not, but as I understand it this is not possible with conventional means as indicated by Check if custom font can display character
To detect this I'm writing the character I want to check to a bitmap and then I write another character that I know is missing to another bitmap and compare the content of the bitmaps. If they are equal the character is missing.
The question is, is there any unicode character whose glyph is (more or less) guaranteed to be missing on fonts typically used on Android phones?
The Unicode replacement character sounds promising when reading about it on Wikipedia:
It is used to indicate problems when a system is not able to render a
stream of data to a correct symbol. It is most commonly seen when a
font does not contain a character, but is also seen when the data is
invalid and does not match any character
However after doing a bit of testing I see that this character is not used to represent missing glyphs on either my Windows 7 computer or the Android phone I've tested with (Motorola Atrix).
There isn't any designated Unicode value for the glyph that is used to render glyphs that are missing in the font used. In the actual font, glyph id 0 should always be the .notdef glyph which is used for all characters that are missing a glyph. However it is not possible this information from the fonts on Android, so it's not possible to use the .notdef glyph directly.
In Unicode there are many reserved/unassigned code points and my limited testing indicate that these code points are rendered using the .notdef glyph. So by using U+0978, which is a reserved code point in the middle of the Devanagari block, I can detect if some other valid, known character exists in the font I want to test.
This is not a future proof solution since new glyphs may be added to reserved code points by the Unicode Consortium in the future. But for my needs it's good enough since what I want to do is a temporary thing that is not relevant any more in the near future.
Update:
The solution to look at U+0978 did not work long. That character was added in the Unicode 7.0 release in June 2014. Another option is to use a glyph that exists in unicode but that is very unlikely to be used in a normal font.
U+124AB in the Early Dynastic Cuneiform block is probably something that doesn't exist in many fonts at all.
I just got my app strings translated to italian but having issues in displaying them on android device.
For example, one of the word is "velocità", on the device the last character à is shown as junk character.
Any pointers on how can I resolve it. The above word is present in the raw-it folder in a .txt file.
I assume you have the txt file not encoded as utf-8. Right click on the file in Eclipse and then properties. Set it to UTF-8. (You might need to copy the text into it again to make the characters appear ok).
UTF8 encoding supports foreign language characters. Try using UTF8 encoding. if that doesnt work then the problemmight be because of the font used.Good Luck.
I am maintaining an Android app that people use to display strings in various exotic languages like Tibetan or old Greek. Because Android devices come with very few fonts, users can put font files on the SD card, and the app will use them.
QUESTION: Given a string, how can I automatically decide which font file is the most appropriate, so that this string appears without characters being replaced with squares/boxes?
Notes:
Each string is in one language.
Strings are displayed in a WebView.
Custom fonts work, the only problem is deciding which font file to use.
Instead of a single font, it could provide a list of fonts that are acceptable for that string.
Unnecessary context, for the curious: I am trying to develop this feature:
http://code.google.com/p/ankidroid/issues/detail?id=779
UPDATE: I ended up creating the Antisquare Open Source library based on Mostafa's idea.
It has a getSuitableFonts method which is blazingly fast.
Android by itself does not provide enough for such a task. Loading and rendering fonts in Android happens in Skia, which is written in C. Skia detects if a character can't be found in a font and falls back to another font for such characters (not the whole string). That's how Japanese, Hebrew, or Arabic text is shown in Android and that's exactly why these scripts don't have bold face! (Their font is selected through fallback and fallback only selects one font file.)
Unfortunately, this mechanism is not provided in APIs and you have to build similar thing on your own. It seems complicated, but is easier than it looks. All you have to do is:
Prepare lists of characters available in each font file.
For every string find the font that has more characters of the string.
Getting list of characters in each font
You don't have to do this on-the-fly in your Android app. You can prepare the list of characters in each font and put these lists in your app. I say that because this is way easier with tools that may not be available in Android. I would do that through Python scripting in a font app (most serious font tools have awesome Python scripting environments), but these apps are expensive and are for serious type designers. Since you're an Android developer, I recommend using sfntly, a library in Java and C++. Doing what you need (getting a list of Unicode characters available in a font file) is easy with sfntly. This sample works with CMap tables (tables that hold character to glyph mapping) and should be a good starting point for you.
Now the interesting part is that snftly is in Java and you may be able to include that in your Android app and do everything automatically. That's awesome by I recommend you start by getting familiar with snftly.
Selecting the font
After the previous part you'll have a list of Unicode character for every font, and based on these lists selecting the font file that provides most characters of every string is trivial.
PREAMBLE: since API 17 (Android 4.2), there's a method TextView.setTextLocale() that explicitly solves this problem for TextViews and derived classes. Assign a Japanese locale (Locale.JAPAN), and Unihan characters will look Japanese.
I have an application on Android that displays Japanese text in WebViews and TextViews. There are some Chinese characters (kanji) that look, by convention, differently in China and in Japan, but share the same Unicode codepoint. Normally, the browser would rely upon the lang tag to choose the correct glyph. On Android, they all default to their Chinese shapes, and I want Japanese shapes.
The problem is well explained in this article. This article also serves as a perfect illustration of the problem - when watched on Android (up to 2.2), the characters in the "Examples of language-dependent characters" all look the same, and Chinese.
Using the lang="ja" attribute does not help. Switching the whole system locale to Japanese does not help either.
I'm wondering about Android phones that are sold in Japan. Do characters like 直, 今, 化 look Chinese-style on those, too? I'm assuming not.
So the questions are: are there official localized images of Android out there? Can I get one to run on the emulator? Is the DroidSansFallback font still the only CJK-enabled font on those? And if it is, is it the same as on the vanilla USA Android?
I'm kind of hoping that the Japanese glyphs are hidden somewhere deep in the font (Unicode private area or something). If so, I could leverage them...
EDIT: located DroidSansJapanese.ttf, installed it on the emulator by copying into /system/fonts, restarted. It made no difference on the look of the Unihan article. Even the hint area of the Japanese text input (which should know better) displays as if Chinese.
How do I know the typeface name of the DroidSansJapanese.ttf? I have a feeling it's still Droid Sans, same as in the built-in DroidSansFallback font. But if they contain the same typeface, what governs which one should take precedence? One would think - system locale, but apparently not. Fonts in Android are installed just by copying, right?
There are fonts with full Japanese support. I've heard some people talking about DroidSansJapanese.tff and TakaoPGothic.
Found a somewhat cludgey solution.
The DroidSansJapanese.ttf font exists and is available for download, for example, here. I downloaded it, renamed it to DroidSansJapanese.mp3 to avoid the 1MB compressed asset limit, and placed it under assets/web. I then introduced the following CSS statement:
#font-face
{
font-family: "DroidJP";
src:url('DroidSansJapanese.mp3')
}
Then I added 'DroidJP' to the font-family of every relevant CSS style. The way I load my HTML, the assets/web folder is already designated as the base for loading linked content.
Upon careful examination, I found several places in the app where Japanese was in TextViews. For those, I've loaded the typeface like this:
Typeface s_JFont =
Typeface.createFromAsset(Ctxt.getAssets(), "web/DroidSansJapanese.mp3");
and called setTypeface() on every relevant TextView. Now for PROFIT!
This expanded my APK by about 1 MB. There was an alternative way, where I'd store the font in the assets in compressed form - that'd save me about 500 KB of APK size, but then I'd have to expand it to phone memory on the first run, worry about data folder path, and lose compatibility with Android 1.5.
Some credit is due: here and here. Does not work on Android 2.1 (the WebViews, not the TextViews) - that's a known bug.
Now, the question remains - how do I identify devices where the default font already contains the Japanese shapes?
EDIT re: the mp3 hack. I've implemented the chunked solution at first, but then decided to go with font in the assets. The chunked approach has one upside - smaller APK size - and the following downsides:
Consumes more phone memory - you end up storing both compressed font in assets and uncompressed in the data directory
Is incompatible with Android 1.5 on the TextView side - the method Typeface.createFromFile() was introduced in API level 4
Complicates HTML generation - the CSS with the #font-face declaration needs to be parametrised, since the data path is a variable
Slows down the first app startup - you spend time combining the chunks
Storing the font as a compressed asset is not an option either - the font then doesn't show up in WebView, and you can clearly see in LogCat the message about "Data exceeds UNCOMPRESS_DATA_MAX".
Using the following in your onCreate/OnCreateView:
AssetManager am = getContext().getApplicationContext().getAssets();
mDroidSansJapaneseTypeface = Typeface.createFromAsset(am, String.format(Locale.JAPAN, "fonts/%s", "DroidSansJapanese.ttf")); //I put the font file in the assets/fonts/ folder
And then for your textviews:
myTextView.setTypeface(mDroidSansJapaneseTypeface);
myTextView.setTextLocale(Locale.JAPAN);
Be aware that not 100% of all fonts will be displayed in Android. I haven't seen too many problems for Japanese characters, but other CJK characters may appear as blank boxes, no matter what ttf file you use.