Comments 12
А рассматривался вариант использовать формат woff2? Конечно, если ограничиться только им не было бы таких значительных улучшений, но кажется, что первое с чего можно начать это более компактный формат данных.
А что в этом woff2?
Woff был по сути контейнером для того же ttf, сжатым deflate. Условно Font.ttf.zip
В woff2 поменяли метод сжатия на brotli, выиграв по размеру около 30%
Переход с ttf на woff вообще никакого выигрыша не даст, т.к. сам пакет приложения apk уже zip архив с тем же самым deflate
Я только уточнить этот момент
"вообще никакого выигрыша не даст "
APK как zip-архив существует только в магазине и при закачке.
При установке он разворачивается на диске
https://developer.android.com/studio/debug/apk-analyzer#view_file_and_size_information
Размер диска у пользователя не безграничен - поэтому влияние все же есть.
Да, я имел ввиду размер в магазине. Ну и сжатый woff нужно распаковывать перед использованием (при каждом запуске?), что тоже не совсем бесплатно.
APK как zip-архив существует только в магазине и при закачке.
При установке он разворачивается на диске
developer.android.com/studio/debug/apk-analyzer#view_file_and_size_information
Я думал, что всё необходимое mmap'ится из .apk напрямую, и zipalign сделали как раз для того, чтобы это работало.
Честно говоря, не рассматривался. Когда добрались до шрифтов, подавляющее большинство было TTF, ещё пару штук OTF. Поэтому естественным образом решили пойти и стандартизировать уже присутствующие на проектах решения и сделать их лучше. Пока что получившийся вариант нас устраивает и по качеству, и по размеру. А задач по улучшению сборки ресурсов всегда много и даже не уверен, что появится время поглядеть на woff2. Но будем иметь в виду куда можно ещё покопать.
Скажите, Вы рассматривали возможность использования вариативных шрифтов, ради получения большого(нужного) количества глифов?
Используя главное свойство вариативного шрифта, можно получить градиент вариаций глифов из одного файла со шрифтам.
Не рассматривали. Насколько понял, он будет весить больше, чем обычный ttf, так как содержит в себе несколько вариаций символов. А внутри игры мы уже точно знаем какие символы и какие начертания нам нужны, поэтому можем составить себе минимальный набор.Ну и другой вопрос - это дизайнеры. Технология относительно новая и все ли студии уже работают с ним не ясно.
Кстати, интересный вопрос. А как вы решаете тогда проблему с вводом пользовательских данных (имён, например) или их у вас нигде нет? Мы-то, конечно, знаем, какие иероглифы у нас в текстах есть, но пользователь-то ввести может что угодно.
Имена у нас, конечно, есть. Здесь есть пару хитростей:
Текстовый документ common.txt, в котором часто используемые символы. Их может не быть в текстах, но они могут быть в именах.
Есть fallback на системный шрифт: если нет символа в собранном шрифте, то он берётся из системного. Выглядеть этот символ будет немного не так, как все остальные, но жалоб на это не было.
Спасибо! А символы для CJK берёте из частотного словаря? Это же довольно нетривиальная тема.
Файл с часто использьуемыми символами не менялся уже наверное лет пять. Возможно при его составлении использовался частотный словарь, но тут точно не подскажу. В дебри именно составления словарей подобного рода не залезали, а сделали fallback в системный шрифт. Это решение проще в реализации с одной стороны, а с другой - итоговый шрифт не будет распухать.
Шрифты в играх: как из 191 Мб сделать 12 Мб