Японские персонажи, похожие на китайские на 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 установлены только путем копирования, не так ли?

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

Нашел несколько 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 . Для них я загрузил шрифт следующим образом:

 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».

Intereting Posts