[devel] I: Font policy 2.0 discussion

[Igor Vlasenko]

Уважаемые коллеги,
хочу начать обсуждение поправок к font policy.

1) с недавним появлением в fontconfig filetrigger'а 
наконец устарели %post/un скрипты с вызовом fc-cache, 
а также макросы %post_fonts/%postun_fonts 

соответственно, по факту надо поправить rpm-build-fonts
и текст полиси.

2) Установка шрифтов под core X font subsystem.

У нас, как и в большинстве других дистрибутивов,
есть 2 подсистемы шрифтов: новая, Fontconfig, 
и старая, core X font subsystem, которая объявлена
legacy and broken by design.

для установки шрифта в core X font subsystem нужен fonts.dir
и симлинк в /etc/X11/fontpath.d.
Большинство приложений сейчас использует Fontconfig,
включая новый emacs. core X font subsystem нужна для совместимости
со старыми приложениями, в т. ч. Qt1/Qt2 и gtk1.

Сейчас в Сизифе все наши шрифты недискриминантно устанавливаются сразу
под обе подсистемы, в отличие от, например, SuSE и Fedora.

Там принято устанавливать под core X font subsystem только
растровые и избранное множество проверенных векторных шрифтов, 
так называемые Core Fonts, мотивируя это тем, что 

а) немногим старым приложениям нужны только экранные шрифты. 
Все, кому нужно что-то большее, уже переехали на Fontconfig.

б) установка в core X font subsystem большого числа ненужных
художественных otf/ttf шрифтов эквивалентна DoS атаке на X сервер
через его протухший устаревший плохо поддерживаемый модуль.

Предлагаю и нам принять такое полиси и перестать устанавливать
новые otf/ttf шрифты в core X font subsystem по умолчанию,
оставив там только имеющиеся шрифты. 

Если пойти дальше, может быть, и часть имеющихся тоже перевести 
в Fontconfig-only шрифты (выбросив fonts.dir и симлинк 
в /etc/X11/fontpath.d).


Ресурсы:

http://old-en.opensuse.org/Packaging/Fonts_Policy#Core_fonts
http://fedoraproject.org/wiki/Packaging:FontsPolicy#Core_fonts
Core fonts

Once upon a time every Linux GUI application used the so-called Core fonts server-side X11 backend[7]. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (fontconfig). Nowadays almost no modern Linux GUI application uses the Core fonts backend. Few (if any) people are willing to fix its remaining bugs.

Therefore, unless your font has previously been registered in Core fonts, and the problems triggered by this font hopefully fixed, you SHOULD NOT declare it there. This is especially true of fonts in modern (TTF or OTF) formats.

The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to fontconfig like everyone else a long time ago.



http://markmail.org/message/4nwmisamzgkoklnp

fonts.dir and fonts.scale are used by the old X11 "core" font backend.

http://fedoraproject.org/wiki/Packaging:FontsPolicy#Core_fonts

It's been deprecated in favour of client-side font management (fontconfig) for about 7 years (replacing the X11 core font backend with fontconfig could probably be considered the first step that lead to modern modularized xorg). Nowadays almost nothing important uses the X11 core font backend in Fedora (even emacs finally switched and emacs is not exactly an agile project)

That being said many proprietary or niche software packages still use the old system because they either do not care a lot about i18n, or about Linux, or want code that works the same way on antique 'classic' Unix systems (less-antique Unix systems use fontconfig just as Linux as every single major GUI package requires it nowadays).

If you want to expose your fonts in the core font system you'll need to include fonts.* and symlink the directory you deploy your fonts in to /etc/X11/fontpath.d/ (note that software that still uses the old font system is likely to go bang if you feed it a modern font).

Fedora-side, we're not encouraging people to register new fonts in the core font system. We're keeping just enough old core fonts to make old apps happy (and don't install them by default anymore, so people who depend on them have to request them explicitely, and not continue to ignore the software landscape has changed) 

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.