I want to use #font-face to import a chinese font into my site. But as we all know chinese fonts are always large.
Since i will only use no more than ten chinese characters one time, i wonder how can i extract several characters from a chinese font?
Tks~
You can use the FontSquirrel web tools to do this: http://www.fontsquirrel.com/fontface/generator
Expert
Subsetting: Custom Subsetting
Single characters
Other than online uploading solutions, there are also offline editors like Fontforge that can do the same task.
For instance you can look at this guide for Fontforge which do the same task.
The main reason why this could be preferrable over online solutions are that, other than more customizable subsettings, there are also no file size restrictions in doing the extraction process locally. It is rather common for Chinese fonts especially for those with large collection of glyphs.
Related
Is there any fontconfig-like way to search system font files on Android?
My game UI library provides a ttf font rendering. Someone just specify at least "human-readable" name, italic flag and font weight. The only way I found is just hardcode paths to system fonts in code, but it does not reliable and can't consider weight and italic parameters.
Maybe there is a file, which I can parse and get system font names from it?
On Linux I use fontconfig, I can use it on Android too, but I don't want to have completely useless megabytes in APK.
You can now query Google Fonts API, with the latest Support Library. It's not exactly what you're looking for, but maybe you'd like to consider this approach.
I have a small problem regarding the EmojiCompat library which was introduced some weeks ago.
There is a group of people (including me) who don't quite like the new Emoji style, Google has introduced with Oreo.
As I like the good old blob emojis, I recently started updating this emoji font.
Now my problem:
The Android developer page shows that there are two ways of using EmojiCompat.
The first one is using downloadable fonts and the second one is using this bundled emoji font which is based on loading font assets.
I already have a working implementation of EmojiCompatConfig which allows me to load any font I have in my assets-folder and it works with the font provided in the bundled configuration but not with my own font.
The section "Library-Components" [I don't have enough/any reputation, so I can't provide a link to this section...] says the original Noto-Emoji font (which my font is actually based on) is modified in some way (i.e. moving the emojis into another area and adding some "Extra emoji metadata" which isn't really specified anywhere in the documentation).
I already tried to look for some differences using the ttx tool provided by fonttools.
It looks like these modifications are the only ones made.
The modified version differs in both the meta-table not present in the default noto font and in the actual positions the emoji glyphs have - probably because they movede the emojis to the private area.
Does anyone know how to recreate these modifications so I am able to use my own emoji font instead of that new one?
I already tried to search for this issue but I didn't find anything that could help me.
There has already been another post regarding whether or not it would be possible to use the iOS emojis using the downloadable font approach but I don't think these questions are the same...
The script to modify an existing CBDT/CBLC emoji font can be found here: https://android.googlesource.com/platform/external/noto-fonts/+/android-8.0.0_r17/emoji-compat/createfont.py
The "unicode path" that needs to be passed to the script should point to this data: https://android.googlesource.com/platform/external/unicode/+/android-8.0.0_r17
I have looked within Stack Overflow and online elsewhere but can't find an answer to this:
If I use an external font/typeface (a pretty mainstream one like Helvetica Neue Condensed) rather one of the three default Android ones (sans, serif, monospace), would/could this cause problems on how other languages (Chinese, Russian, Arabic etc) are displayed?
Are there any other problems that could be caused in using an external font that I should be aware of?
From the lack of articles and forum questions on the web, I am guessing that using external fonts is discouraged. Is this the case?
This depends upon whether that font supports these languages or not. You can check this from the source you are getting that font file.
There will be no problems caused, apart from the limitations of the font. Like some fonts(e.g. Boycott and CharlemagneStd-Bold fonts) supports only Capital letters and changes the small ones into caps automatically.Also Some fonts can not render special characters or characters used in languages like Espaniol (spanish).
Its not discouraged at all, thing is this approach is used only in the apps where you need to get more fancy and display the things in different way.Like in games, promotional app for celebrities like PrinceRoyce in Android(available in Amazon Android Market only).In all, you can use the external fonts but you need to make sure whether it will render your texts in all the languages your app will be used.
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.