Японские символы, похожие на китайские на Android

Question

PREAMBLE: с API 17 (Android 4.2) существует метод TextView.setTextLocale(), который явно решает эту проблему для TextViews и производных классов. Назначьте японский язык (Locale.JAPAN), а персонажи Unihan будут выглядеть японскими.

---

У меня есть приложение на Android, которое отображает японский текст в WebViews и TextViews. Есть несколько китайских иероглифов (кандзи), которые, по соглашению, выглядят по-разному в Китае и Японии, но имеют один и тот же код Unicode. Обычно браузер полагается на тег lang, чтобы выбрать правильный глиф. На Android все они по умолчанию по-китайски настроены, и мне нужны японские формы.

Проблема хорошо объясняется в this article. Эта статья также служит прекрасной иллюстрацией проблемы - при просмотре на Android (до 2.2) символы в «Примеры символов, зависящих от языка» выглядят одинаково, а китайцы.

Использование атрибута lang="ja" не помогает. Переключение всей языковой системы на японский язык тоже не помогает.

Мне интересно, какие телефоны Android продаются в Японии. Такие персонажи, как 直, 今, 化 выглядят в китайском стиле тоже? Я предполагаю, что нет.

Итак, вопросы: есть ли официальные локализованные изображения Android там? Могу ли я запустить его на эмулятор? Является ли шрифт DroidSansFallback по-прежнему единственным шрифтом с поддержкой CJK? И если это так, это то же самое, что и на Android-телефоне Vanilla?

Я как бы надеюсь, что японские глифы скрыты где-то глубоко в шрифте (частная область Юникод или что-то еще). Если это так, я мог бы использовать их ...

EDIT: расположенный DroidSansJapanese.ttf, установленный на эмуляторе путем копирования в/system/fonts, перезапущен. Это не повлияло на внешний вид статьи Unihan. Даже область подсказок японского ввода текста (который должен знать лучше) отображается как китайский.

Как узнать название шрифта DroidSansJapanese.ttf? Я чувствую, что это все еще Droid Sans, так же, как и во встроенном шрифте DroidSansFallback. Но если они содержат один и тот же шрифт, что определяет, какой из них должен иметь приоритет? Можно было бы подумать - системный язык, но, видимо, нет. Шрифты в Android установлены только путем копирования, не так ли?

Answer 1

Есть шрифты с полной поддержкой Японии. Я слышал, как некоторые люди говорили о DroidSansJapanese.tff и TakaoPGothic.

Answer 2

Обнаружено несколько cludgey решение.

DroidSansJapanese.ttf шрифт существует и доступен для скачивания, например, here. Я загрузил его, переименовал его в DroidSansJapanese.mp3, чтобы избежать ограничения на сжатые активы 1 МБ и разместил его под assets/web. Затем я представил следующий CSS заявление:

@font-face 
{ 
font-family: "DroidJP"; 
src:url('DroidSansJapanese.mp3') 
} 

Затем я добавил «DroidJP» к font-family каждому соответствующему стилю CSS. Как я загружаю свой HTML, папка assets/web уже обозначена как база для загрузки связанного контента.

После тщательного изучения, я нашел несколько мест в приложении, где японцы были в TextView.Для тех, я загрузил шрифт, как это:

Typeface s_JFont = 
    Typeface.createFromAsset(Ctxt.getAssets(), "web/DroidSansJapanese.mp3"); 

и называется setTypeface() на каждом соответствующем TextView. Теперь для PROFIT!

Это расширило мой APK примерно на 1 МБ. Был альтернативный способ, где я бы сохранил шрифт в активах в сжатой форме - это бы сэкономило бы около 500 КБ размера APK, но тогда мне пришлось бы его расширять до памяти телефона при первом запуске, беспокоиться о пути к папке с данными и потерять совместимость с Android 1.5.

Некоторое количество кредитов должно быть получено: here и here. Не работает на Android 2.1 (WebViews, а не TextViews) - это known bug.

Теперь остается вопрос - как определить устройства, в которых шрифт по умолчанию уже содержит японские фигуры?

EDIT re: mp3 hack. Сначала я реализовал пакетное решение, но потом решил использовать шрифт в активах. Фрагментированное подход имеет один вверх - меньший размер APK - и следующие недостатки:

• потребляет больше памяти телефона - вы в конечном итоге хранение как сжатый шрифта в активах и несжатого в каталоге данных
• несовместимы с Android 1.5 на стороне TextView - метод Typeface.createFromFile() был введен в уровне API 4
• усложняет HTML поколение - CSS с декларацией @ шрифт лица должно быть параметрировано, так как канал передачи данных является переменной
• Замедляет первое приложение startup - вы проводите время, объединяя куски

Сохранение шрифта в качестве сжатого актива также не является вариантом - шрифт не отображается в WebView, и вы можете четко видеть в LogCat сообщение о «Data превышает UNCOMPRESS_DATA_MAX».