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: Always Steps to Reproduce: 1. Open attached document (test.sxw) 2. Open menu Format-Numbering/Bullets dialog, Bullets tab 3. Actual Results: No bulltes displayed in document or in dialog. Expected Results: Display bullets in document and different bullets type in dialog Additional info:
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. ***
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.