Pango/Cairo/Fontconfig: корректная работа отката/связывания шрифтов Unicode в Windows

Недавно пользователь Windows сообщил нам, что японские символы (и другие символы Юникода) в нашем приложении не отображаются должным образом в Windows. Вместо этого он получает коробки с номерами.

Мы используем Pango, Fontconfig/freetype и визуализацию с помощью Cairo. В Unix (то есть и в Linux, и в macOS) работает отлично. Однако под Windows мы просто не можем заставить его работать.

Я предполагаю, что это связано с тем, как резервное копирование / связывание шрифтов работает в Windows, но я понятия не имею, с чего начать, чтобы заставить эту работу работать правильно.


windows fonts internationalization unicode pango
person Gregorio Litenstein    schedule 12.07.2017    source источник
comment
Из того, что я читал, прямоугольники представляют собой коды юникода для отсутствующих глифов. Таким образом, становится более очевидным, что проблема связана со шрифтами. Чего я не понимаю, так это того, как (или если это возможно) заставить Windows вести себя так же, как Unix в этом отношении: т. Е. Отсутствующие глифы? использовать другой шрифт. Я даже пытался вручную добавить MS Gothic и пару других в ключ FontLink в regedit, но ничего не изменилось.   -  person Gregorio Litenstein    schedule 13.07.2017

Ответы (2)


arrow_upward
2
arrow_downward

Оказывается, проблема проще, чем ожидалось, но нигде не очень хорошо документирована. Fontconfig нужны свои файлы конфигурации (fonts.conf и вторичные конфигурации, находящиеся в conf.d). В Linux это никогда не проблема, потому что большинство (если не все) дистрибутивов используют fontconfig по умолчанию, поэтому даже если кто-то ошибается, все равно остается системная конфигурация, к которой можно вернуться.

Напротив, Windows обычно не использует fontconfig, поэтому, если разработчики не отправят набор файлов конфигурации fontconfig, он в лучшем случае загрузит указанные шрифты, но не сможет делать что-либо еще (например, откат шрифта).

Решение этой проблемы состоит в том, чтобы отправить папку «шрифты», содержащую по крайней мере fonts.conf, а также любые соответствующие определения из conf.d, обычно папка должна находиться в той же папке, что и библиотека fontconfig. (и если это не сработает, вы можете установить для FONTCONFIG_PATH значение «.»)

Наконец, если вы на самом деле не вносили какие-либо специальные изменения в конфигурацию, вы можете просто скопировать файлы конфигурации по умолчанию из /etc/ для отправки вместе с вашим приложением.

person Gregorio Litenstein    schedule 31.08.2017

arrow_upward
2
arrow_downward

Системы Linux построены на основе fontconfig и замены шрифтов, поэтому шрифты, доступные в Linux, хорошо работают в этом сценарии.

Очень часто можно встретить в других системах шрифты, которые делают глупые вещи, такие как сопоставление всех глифов, которые дизайнер шрифта еще не нарисовал, с символом-заполнителем (обычно квадратным). Когда fontconfig встречает такой шрифт, он не заменяет отсутствующие глифы материалом из других шрифтов, поскольку шрифт уже объявляет что-то для отображения для этих кодовых точек.

Другим распространенным случаем является то, что нелатинские шрифты содержат быстрые и грязные латинские глифы, поэтому программное обеспечение, которое не может заменить шрифты, по-прежнему отображает ошибки на английском языке. Они требуют определенных правил в fontconfig, чтобы продвигать полезную часть шрифта, а не заполняющую.

person nim    schedule 28.09.2017
comment
В моем конкретном случае я видел квадраты с кодом utf8 для этого конкретного символа. В конце концов, чтобы исправить это, я включил файлы конфигурации в свой выпуск и использовал _putenv_s() для правильной установки FONTCONFIG_PATH при работе в Windows. - person Gregorio Litenstein; 28.09.2017