Японские персонажи похожи на китайцев на Android

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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

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

Некоторые кредиты должны быть: здесь и здесь. Не работает на Android 2.1 (WebViews, а не TextViews), что известная ошибка.

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

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

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

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