[Issue 113586] Unable to get correct version of OpenSymbol

nmailhot at openoffice.org nmailhot at openoffice.org
Tue Aug 3 06:29:51 UTC 2010

To comment on the following update, log in, then open the issue:

------- Additional comments from nmailhot at openoffice.org Tue Aug  3 06:29:49 +0000 2010 -------
> If that is what is happening wouldn't it be proper handling if the font was
> moved away from share/fonts/truetype to establish a link to the new location in
> that directory as well?

It seems I need to expand.

Fedora (and where Fedora leads, others tend to follow) is moving *away* from
font-selection-by-filename as fast as a gigantic package repository like ours can.

The reason is simple: most applications that embed fonts do not maintain them,
application authors just download random fonts on the net and dump them in their
trees, do not review them, do not update them. So we had dozens of copies of
Vera in the repository way after everyone had been supposed to move to DejaVu,
several Arial copies when they violate our licensing guidelines, various old
buggy font versions that had long been fixed in the font package dedicated to
this font, etc (and all those problem font files consumed quite a lot of space btw)

Therefore, our new target is:
1. apps do not select fonts by filename
2. apps are forbidden to include font files in their application package, they
have to use existing font packages or split their fonts in new packages if no
one else provides them
3. font selection *must* go through fontconfig
4. fonts exist somewhere in fontconfig space, their exact location is not fixed
and can change without notice
5. sometimes fonts are not actually present but faked by fontconfig font
aliasing (typically, DejaVu declares itself as Vera if the Vera package is not
6. the application package *must* require the font packages it needs so the
fontconfig selections it needs succeeds
7. and lately we've started adding magic font provides to font packages such as
font(dejavusans) so other packages do not need to know the exact name of the
font package, just the font provide they require

Longer term we may start tweaking font names in the fontconfig layer like
Microsoft does in WPF to fix hopelessly named fonts/styles. Anything that
accesses font files directly will break in this scheme

Now, I realise the main justification for the change does not apply to
OpenSymbol, since OO.o actually maintains the font it embeds, and our opensymbol
font package is generated from the OO.o srpm, so there's no coordination problem
between the application packager and the font packager

However, common packaging guidelines must target the common case first. And the
common case is we want font embedding to stop. So font symlinking, while done
when an app is too dumb to got through fontconfig, is not encouraged, and breaks
regularly when files are moved within fontconfig directories (because fontconfig
apps do not care about it, and other apps are supposed to be fixed anyway, so
why add constrains to font packagers).

Also, who knows, now that opensymbol uses standard unicode points, we may decide
to replace it with some other nicer unicode math font in the future, and alias
this font to opensymbol to hide the change from OO.o.

Therefore, I strongly recommends OO.o makes sure its symbol font is named in
such a way it can safely select it via fontconfig only on Linux systems, that no
attempt to do resolution by filename is added, and that dependencies are used to
make sure the font package is present when OO.o needs it.

See also the official Fedora font packaging guidelines and in particular the
fontpackages templates. 

You'll find out individual font packagers are not even allowed to specify the
location of font files, it's all taken care of by an opaque macro they have no
control of but are required to use (and when this macro changes, every font in
the distro may be relocated on rebuild)

Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.

More information about the fonts-bugs mailing list