TL->HDU: This problem needs to be solved between you and IS. I regard this a
sure show stopper for OOo 3.3.

Any thought on this?

When building DEBs or RPMs the package manager should know that the installed ttf-opensymbol does 
not meet the requirements. Adding a dependency on a proper version of the ttf-opensymbol package and 
maybe providing it separately could help to solve this. Things could get more complicated though if there 
were more versions of OpenSymbol installed, e.g. in the user's home font directory.

IS -> HDU: I do not think that dependencies are a good solution. How about Mac
and Windows? And which dependency do we want to use for which Unix platform? The
opensymbol font is in one package with all other fonts. A missed dependency
leads to the situation that no font will be installed with OOo.
And as we discussed this morning, there is no necessity for such an inconvenient
and insufficient dependency. My favorite solution is, that the font gets a new
name. If the different versions of this font are not compatible because of big
changes in this font, it should get a new name. So we avoid any version
conflict. Your suggestion was, that you evaluate not only font name but also
font version. If you prefer this, then this seems also to be valid. Finally we
could also hard code, that this one font is always used from
share/fonts/truetype. This seems to be a very stable and simple solution. 
So there are much better ways, then using dependencies between packages. This is
also not a valid solution for all our OS.
 

> Finally we could also hard code, that this one font is always used from
> share/fonts/truetype

This won't fly under Linux. Distributions explicitely move opensymbol in a
standard place instead of having it lost deep inside the OO.o tree
http://koji.fedoraproject.org/koji/rpminfo?rpmID=2100031

Also, under Linux (still) fontconfig will always use the most recent version of
any given font (as in: font metadata), regardless of where it is installed 

Though it's a good idea to rename the font if it has changed so much old
documents referencing the previous version will break if fed the new one

And dependencies are the right way to handle this under Linux

To avoid misunderstandings: The font itself is compatible! Meaning that all
characters in the old font are still present in the new font. Thus an old office
with Math using the old private use area code points will still work.

But a OOo 3.3 Math with new and correct code points in use (internally and for
import/export) can not properly work with the old font where usually no symbol
was present at the correct code points.


Just to list here as well what we previously considered as possible solutions
without yet choosing one from:

1) Have new name for the new font. Easiest but maybe ugliest solution since we
just fixed problems with the font and it is still compatible with old versions
of the font.

2) The font found in the installation should *always* be used. This will also
solve the issue for sure, but the font may not have been installed system wide
and thus other applications may still use the old version. Whatever implications
that might have. It could also be considered to use this approach for the
OpenSymbol font only in order to not miss new versions of other fonts 
that come with the OOo installation.

3) when vcl is determining the path of the font to use it may also retrieve the 
version of that font. If the version within the OOo installation is newer that
one should be used. Since we are probably the only provider for updates of the 
OpenSymbol font I see no real advantage over using solution 2) here though if
only the OpenSymbol font is in question.

All in all my favorite solution would be 2) since 3) seems to be unnecessarily
complicated and 1) somewhat crude. But since I'm no expert on the matter and
neither do manage distributions probably someone else might be able to shed more
light on this.

tl->nmailhot:
> This won't fly under Linux. Distributions explicitely move opensymbol in a
> standard place instead of having it lost deep inside the OO.o tree
> http://koji.fedoraproject.org/koji/rpminfo?rpmID=2100031

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?
Thus the font would be installed system wide but can be locally retrieved from
share/fonts/truetype as well. 

@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)

tl->nmailhot: I see now. Thanks for the detailed explanation.

Thanks for the excellent summary of the consensus regarding font packaging.

> 6. the application package *must* require the font packages it needs so the fontconfig selections it
> needs succeeds [...] and that dependencies are used to make sure the font package is present when
> OO.o needs it.

Yup, so this is obviously a task for a package specialist. Reassigning accordingly.

tl->hdu: Are you sure abot that this is a task for the package specialist? I
agree that it should behave as listed, but I also think that will NOT solve the
problem completely. 
After all packages are not available in tar balls (which are also a common means
of distributing OOo). And what about the other OS aside from Linux?
Can we guarantee that there will be no problem as well?

Also as I understood IS yesterday our single existing font package unfortunately
does not provide version info so far :-( , and splitting out OpenSymbol is also
no option since that would be an incompatible change in the package manager
which is not allowed for minor versions. Therefore it is impossible to introduce
a correct working dependency to the OpenSymbol font right now. Thus it looks
like the packaging side of the problem can only be addressed for OOo 4.0. 
TL->IS: Please correct me if I understood something wrong.

But as already said above having tar ball distributions in mind will already
make a pure packet based solution inappropriate.

@tl: Regarding *.tar.gz distributions of OOo the answer is simple: if you use tarballs you do not get the 
benefits of package management such as getting your requirements resolved automatically. For exactly 
this reason official OOo releases are only distributed as *deb or *rpm and not as *tgz.

Another noteworthy aspect of this question is whether and how the problem shows itself on other 
platforms: on WIN, OSX, SOLS etc. the problem is usually not seen because these platforms there a 
conflicting version of the OpenSymbol font is rare and it will stay this way unless the platform providers 
start to push OpenSymbol in their maintenance updates. And even then it would not be a problem unless 
they pushed an obsoleted version.

Platforms such as WIN do not even allow to register an app-specific font as temporary if the font has a 
system-wide equivalent. So the installer must make sure that if there is a system-wide OpenSymbol 
installed then that file needs to be updated in the installation process.

@tl

As I wrote before fontconfig will always serve apps the font files with the
highest version (as in, version field in truetype metadata). Thus, on a
fontconfig platform, the worst that can happen is someone installed a newer
opensymbol system-wide, and the tar install uses it instead of its local one.

Therefore, as long as OO.o selects fonts through fontconfig, keeps compat in
OpenSymbol, and increments the font version when it changes, there will be no
problems. (and if compat is not kept the font should be renamed)

But if fontconfig always uses the highest version of a font, we will have no
problem, if we install the fonts in our builds into the directory
share/fonts/truetype inside the application. If there is an older version in the
system font directory, it will not be used. 
On the other hand every distro repackages our packages, and includes the fonts
only into the system font dir. Then this problem also does not occur. 
So do we have a problem of fontconfig here?

*** Issue 113564 has been marked as a duplicate of this issue. ***

> So the installer must make sure that if there is a system-wide OpenSymbol  installed then that file
> needs to be updated in the installation process.

FWIW I extended this comment in issue 113700 to be more generic (not OpenSymbol-specific):
The installer must make sure that there are no competing files for the same font face: If a font face is 
installed system-wide then the OOo installer must overwrite it with the newer version.

Why do you think, that the installer should do all this? Do you know that we
offer installations with non root privileges? And also installations of simple
tar.gz files. Why do you want to add this complexity into the installation, if
it is not necessary? The correct fonts for each of our OOo builds are always
available in share/fonts/truetype. Did you check, if fontconfig works correctly?

> Why do you think, that the installer should do all this?

Because the installer is responsible for instalingl stuff on the system in such a way that the package 
dependencies are fulfilled and conflicts are avoided.

> Do you know that we offer installations with non root privileges?
> And also installations of simple tar.gz files.

And this works because as long as there are no conflicting packages there is no conflict.

> Why do you want to add this complexity into the installation, if it is not necessary?

It only becomes necessary if there are conflicting system-wide packages on the system.

> The correct fonts for each of our OOo builds are always available in share/fonts/truetype.

An app can guide the system to do what it wants ("here is the file, please use it") but one cannot fight 
the system ("use this file even when the system insists on using its own file"). Kernel/Root/Admin tend 
to win...

> Did you check, if fontconfig works correctly?

The fontconfig magic regarding versions works when the conflicting files are in the same directory.

*** Issue 113918 has been marked as a duplicate of this issue. ***

Setting target 3.4

@is

does this mean that the current issue won't be fixed in OOo 3.3?
I still see it on the 3.3 blockers list

Oh, this task is on the blocker list? I do not see a solution in 3.3 time frame.
Therefore I set the target to 3.4.

*** Issue 115620 has been marked as a duplicate of this issue. ***

Adding work-arounds listed in another issue here:

To work around this problem there are 3 possible ways:

1) If the installation was done with root privileges everything should be fine.
That is the system wide font should have been updated properly.

2) remove the system wide installed font manually (and from all other places the
system might look for the font), then install the new font system wide manually.
The new font can be found within the OOo installation (named opens___.ttf). For
windows the directory to look into is 'Basis\share\fonts\truetype'

3) Remove all OpenSymbol fonts from the installation but NOT the one from with
the OOo installation. In that case OOo should make use of the font version found
in the installation and that will (always) be the correct version.
However this solution will be a bad idea if you want to print, because in that
case the printer will not find the OpenSymbol font. On the other hand, since now
the correct Unicode points get used by Math, you will probably still have luck
as long as some other installed font provides the characters in question.

*** Issue 116280 has been marked as a duplicate of this issue. ***

Setting target 3.x

*** Issue 116647 has been marked as a duplicate of this issue. ***

*** Issue 117594 has been marked as a duplicate of this issue. ***