I realised recently that the Android Browser doesn't have any of the fonts I have in my font stack as a Times Replacement with the help from http://www.codestyle.org/css/font-family/index.shtml.
"Times New Roman",Times,FreeSerif,"DejaVu Serif",serif
I'm not angry about it, because it looks nice. But I want to know what is the font's name so that I can include it into my font stack.
You don’t need to add a name, since the Android browser checks your current list, notices that none of the specific names matches, and uses serif, which is mapped to the browser’s serif font. Similarly for the Android sans-serif font (which is what your heading refers to...), use just the generic name sans-serif.
Oddly enough, the often-advertised name Droid Serif does not work. It is just yet another unrecognized name to the Android browser. See e.g. the question Using CSS font-family to select Droid fonts not working on Android (the question is more useful than the comments and answers).
The original Android font was "Droid" (Serif version is "Droid Serif"): http://en.wikipedia.org/wiki/Droid_(font)
The font in the newer devices is "Roboto", though I'm not sure if it has a serif version.
Related
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
In our application, we're using Roboto and Roboto Bold. However, in some versions of Android (seems to be 4.0 to 4.1) we have issues with text rendering when using the imported version of Roboto (i.e. using Typeface.createFromAsset()) that do not appear when simply using the built-in version of Roboto (i.e. Typeface.DEFAULT).
I know that Roboto and Roboto Bold were introduced in Android 4.0, but I can't seem to find anything that guarantees that these fonts are available regardless of manufacturer modification (e.g. Touchwiz, Sense). If they are guaranteed to exist, we can just use a version check to only use the custom import for devices lower than Android 4.0.
EDIT: With some experimentation, particularly with the Galaxy S3 that allows a user to change their font, this is what I've discovered:
Using Typeface.create(Typeface.SANS_SERIF, Typeface.NORMAL) will return that CUSTOM typeface, rather than the system default sans-serif font (i.e. Roboto)
Instead, use Typeface.create("sans-serif", Typeface.NORMAL) (or BOLD) and it will return Roboto regardless of the user's font customization. From the list below, you can actually use "helvetica", "tahoma", "verdana", or "arial" above instead of "sans-serif" with the same result.
I found a document called system_fonts.xml that seems to confirm that Roboto will be used for any reference to Typeface.SANS_SERIF in the SDK directory under:
platforms > android-14 > data > fonts
<!--
System Fonts
This file lists the font families that will be used by default for all supported glyphs.
Each entry consists of a family, various names that are supported by that family, and
up to four font files. The font files are listed in the order of the styles which they
support: regular, bold, italic and bold-italic. If less than four styles are listed, then
the styles with no associated font file will be supported by the other font files listed.
The first family is also the default font, which handles font request that have not specified
specific font names.
Any glyph that is not handled by the system fonts will cause a search of the fallback fonts.
The default fallback fonts are specified in the file /system/etc/fallback_fonts.xml, and there
is an optional file which may be supplied by vendors to specify other fallback fonts to use
in /vendor/etc/fallback_fonts.xml.
-->
<familyset>
<family>
<nameset>
<name>sans-serif</name>
<name>arial</name>
<name>helvetica</name>
<name>tahoma</name>
<name>verdana</name>
</nameset>
<fileset>
<file>Roboto-Regular.ttf</file>
<file>Roboto-Bold.ttf</file>
<file>Roboto-Italic.ttf</file>
<file>Roboto-BoldItalic.ttf</file>
</fileset>
</family>
Since the vendor fonts must be placed in fallback_fonts.xml and the system fonts will always be prioritized, and the first family listed is Roboto under the aliases of sans-serif, aria, helvetica, tahoma, or verdana, unless I find out otherwise I think it's safe to assume that Roboto will be the font returned for a call to Typeface.create(Typeface.SANS_SERIF, Typeface.NORMAL).
I'm still going to leave this open for now, hoping for a definitive answer, as I'm unsure whether an OEM is allowed to modify system_fonts.xml. If they are, then this isn't really helpful at all.
In Section 3.8.5 of the Android 4.0 Compatibility Documentation it says:
3.8.5. Themes Android provides "themes" as a mechanism for applications to apply styles across an entire Activity or application.
Android 3.0 introduced a new "Holo" or "holographic" theme as a set of
defined styles for application developers to use if they want to match
the Holo theme look and feel as defined by the Android SDK [Resources,
24]. Device implementations MUST NOT alter any of the Holo theme
attributes exposed to applications [Resources, 25]. Android 4.0
introduces a new "Device Default" theme as a set of defined styles for
application developers to use if they want to match the look and feel
of the device theme as defined by the device implementer. Device
implementations MAY modify the DeviceDefault theme attributes exposed
to applications [Resources, 25].
AFAIK, the Roboto font set is part of the holo theme, and therefore is required to be present on any Android 4.0 and above device that has been certified by Google (i.e. runs Google Play).
The same requirement is also present in the 4.1 and 4.2 documents
(Search for Holo in the PDFs to find the section quickly. There's only 4 mentions of it)
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 saw that on iPhone there is a truetype font called Apple Color Emoji. It contains the emoticons that exist on iPhones which can be used in any application.
I wonder:
How is this font displayed in multicolor?! Truetype fonts can only include black and white glyphs.
Can this font, or one like it, be used on Android phones?
Apple is using a proprietary extension to the OpenType standard. Basically, they just store pre-rasterized color PNGs in a proprietary extension "block" within the TTF file (reference, corroboration).
The only reason this works is because they also provide the full stack between that font extension and the screen (font rasterization, system graphics library, text rendering widgets). There's no standardized way to accomplish this across all platforms/libraries.
The font uses embedded PNGs and they are stored in a sbix table.
Apple Color Emoji cannot be used in Android, but a Google CBLC/CBDT formatted font can.
There are four methods for implementing color in Open Type fonts right now:
Apple's SBIX - Embedded PNGs
Google's CBLC+CBDT - Embedded PNGs
Microsoft's COLR+CPAL - Colored glyphs
Adobe/Mozilla/W3C's SVG+CPAL - SVG in OpenType
The complete list of OpenType tables.
You can disassemble/reassemble the font using ttx from FontTools(pypi, github) for more details.
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.