To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=113586
------- Additional comments from nmailhot@openoffice.org Tue Aug 3 06:29:49 +0000 2010 ------- @tl
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 installed) 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. http://fedoraproject.org/wiki/Packaging:FontsPolicy
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. http://qa.openoffice.org/issue_handling/project_issues.html#notification