Bug 69996 - Bullets don't show in oowriter
Bullets don't show in oowriter
Product: Red Hat Public Beta
Classification: Retired
Component: freetype (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
: 71574 72865 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-07-28 07:32 EDT by Pavel
Modified: 2008-05-01 11:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-15 15:27:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test document (5.07 KB, application/octet-stream)
2002-07-28 07:34 EDT, Pavel
no flags Details

  None (edit)
Description Pavel 2002-07-28 07:32:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020726

Description of problem:
I have a document created with OpenOffice 1.0.1 for Windows. When I open this
document on Linux (openoffice 1.0.0-7), bullets inside document are not
displayed. In Bullets tab of Format-Numbering/Bullets dialog all bullets are empty.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open attached document (test.sxw)
2. Open menu Format-Numbering/Bullets dialog, Bullets tab

Actual Results:  No bulltes displayed in document or in dialog.

Expected Results:  Display bullets in document and different bullets type in dialog

Additional info:
Comment 1 Pavel 2002-07-28 07:34:18 EDT
Created attachment 67384 [details]
Test document
Comment 2 Jakub Jelinek 2002-07-29 14:19:52 EDT
There are problems with /usr/lib/openoffice/share/fonts/truetype/*.ttf
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?
Comment 3 Bernhard Rosenkraenzer 2002-08-05 11:27:47 EDT
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.
Comment 4 Jakub Jelinek 2002-08-05 11:35:00 EDT
Have you tried to generate afm file for the OpenSymbol font?
Comment 5 Mike MacCana 2002-08-21 01:05:37 EDT
*** Bug 71574 has been marked as a duplicate of this bug. ***
Comment 6 Mike MacCana 2002-08-21 01:05:57 EDT
*** Bug 71574 has been marked as a duplicate of this bug. ***
Comment 7 Jakub Jelinek 2002-08-21 09:47:32 EDT
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...
Comment 8 Jakub Jelinek 2002-08-21 10:32:24 EDT
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);
Comment 9 Bernhard Rosenkraenzer 2002-08-21 10:41:01 EDT
Seems to be a freetype bug then - adding freetype maintainer
Comment 10 Jakub Jelinek 2002-08-21 11:30:00 EDT
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...
Comment 11 Owen Taylor 2002-08-21 11:41:44 EDT
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:


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.
Comment 12 Jakub Jelinek 2002-08-21 14:58:46 EDT
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
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...
Comment 13 Mike A. Harris 2002-09-01 02:28:36 EDT
*** Bug 72865 has been marked as a duplicate of this bug. ***
Comment 14 david d zuhn 2002-10-15 15:27:48 EDT
This is working for me just fine now under 8.0 (final).  I suggest it be closed

Note You need to log in before you can comment on or make changes to this bug.