Bug 69996

Created attachment 67384 [details]
Test document

There are problems with /usr/lib/openoffice/share/fonts/truetype/*.ttf
font.
First of all I thought it is just because this directory is not registered
with xfs, but when I add it to its fontpath, I still cannot see any of its
letters. Bero, any ideas?

OO font handling is buggy - some other TT fonts (Arioso, Helmet, etc.) are 
displayed as white-on-white, as well. 
 
This might be because OpenOffice requires *.afm files for every fonts. We 
might want to copy the afm generation code from kfontinstaller.

Have you tried to generate afm file for the OpenSymbol font?

*** Bug 71574 has been marked as a duplicate of this bug. ***

*** Bug 71574 has been marked as a duplicate of this bug. ***

I don't think this has anything to do with .afm files, OOo doesn't even try to
look for it.
So far I have found that this is because
FT_Select_Charmap (OpenSymbol_FT_Face, ft_encoding_unicode)
returns FT_Err_Invalid_Argument error.
I've looked at the font using showttf
and I see
Encoding (cmap) table (at 93380)
platform=0 specific=0 offset=924 Unicode Default
???
platform=1 specific=0 offset=28 Mac Roman
platform=3 specific=1 offset=924 MS Unicode
 Format=4 len=1970 Language=0
Windows unicode, 140 segments
and e.g. the default Bullet character U2022 is there too.

Will need to read freetype a little bit more closely...

Distilled testcase is:
/* -I/usr/include/freetype2 -lfreetype */
#include <stdlib.h>
#include <stdio.h>
#include "freetype/freetype.h"
#include "freetype/ftglyph.h"
#include "freetype/ftoutln.h"
#include "freetype/tttables.h"
#include "freetype/tttags.h"
#include "freetype/ttnameid.h"

int main (void)
{
  FT_Library aLibFT;
  FT_Face aFaceFT = NULL;
  int i, ok = 0;

  if (FT_Init_FreeType (&aLibFT))
    abort ();
  if (FT_New_Face (aLibFT, "/usr/lib/openoffice/share/fonts/truetype/opens___.ttf", 0, &aFaceFT))
    abort ();
  for (i = 0; i < aFaceFT->num_charmaps; i++)
    {
      printf ("%08x\n", aFaceFT->charmaps[i]->encoding);
      if (aFaceFT->charmaps[i]->encoding == ft_encoding_unicode)
        ok = 1;
    }
  if (! ok)
    abort ();
  exit (0);
}

Seems to be a freetype bug then - adding freetype maintainer

The culprit seems to be segment 139 in the unicode cmap (showttf output):
  Segment=138 unicode-start=e0db end=e0dd range-offset=830 delta=0 glyph-start=410 end=412
  Segment=139 unicode-start=ffff end=ffff range-offset=65535 delta=1 End
It fails to validate this cmap because range-offset p + 0xffff obviously
doesn't fall into a valid area. From showttf output it looks like range-offsets
0 and 0xffff are special, not just 0 as freetype assumes. Checking...

This is a known case where FreeType-2.1.x is strict in its
validation and a considerable number of fonts are broken.

See thread from:

 http://www.freetype.org/pipermail/devel/2002-August/003843.html

We may be able to put in a patch to our freetype RPM to
work around such broken fonts; depending on what the license
is on the fonts, we could also fix them by decompiling and
recompiling with fonttools, but that would, at best be a bit
of a pain.

Well, the font is LGPL/SISSL as the rest of OOo, so I guess I'll modify it in
place (it is not hard in fact, because the undefined character glyph is
present in the font (glyph 0) and thus simply changing:
Segment=139 unicode-start=ffff end=ffff range-offset=65535 delta=1 End
into:
Segment=139 unicode-start=ffff end=ffff range-offset=0 delta=1 glyph-start=65536
(ie. replacing 0xffff with 0 in the range offset and updating cmap csum
and "head"'s checksumAdj is enough, just tested that)).
But it would be good to have a freetype patch in too...

*** Bug 72865 has been marked as a duplicate of this bug. ***

This is working for me just fine now under 8.0 (final).  I suggest it be closed
out.