Apache OpenOffice (AOO) Bugzilla – Issue 6815
MS PowerPoint default Times bullets come out as question marks
Last modified: 2008-05-17 23:44:17 UTC
When I try to open any MS Powerpoint file which uses the default times font. The bullet character is a question mark. This has to be a duplicate bug. So perhaps this bug should be: "Why is this not in the FAQ?" This has to be a top ten issue for new users. This should be at the top of the FAQ for the Presentation
Set to new.
Reassigned to Christian.
The Times unicode for this character is "0x2022" It prints on paper just fine, it just shows up as "?" on the screen.
It seems to be a function of the font size as well, it works (I get a real bullet) at 20pt font but question mark at 24pt font.
I had a number of different users report this to me. It seems that all the documents people open have question marks instead of bullets. I opened a number of them and I see the same thing. This also happens with Verdana pt. size 18 and 24. Is it possible to bump this up on the priority list since it is fairly annoying to see presentations with question marks.
I'm seeing the same thing. It happens when importing from PPT into OpenOffice and when exporting to PPT. The root cause seems to be font family used for the bullet. I imported a PPT file into OpenOffice, and got question marks (0x2022) for the bullets. The XML source had: <text:list-style style:name="L4"> <text:list-level-style-bullet text:level="1" text:bullet-char="\342\200\242"> <style:properties text:min-label-width="1.058cm" fo:font-family="'Times New +Roman'" style:font-family-generic="roman" style:font-pitch="variable" +fo:color="#003399" fo:font-size="83%"/> </text:list-level-style-bullet> I changed the 3rd line to: <style:properties text:min-label-width="1.058cm" +fo:font-family="'OpenSymbol'" style:font-family-generic="roman" +style:font-pitch="variable" fo:color="#003399" fo:font-size="83%"/> which fixed all of the L4 style bullets. So the short answer is that 0x2022 (in this specific case) is the right value, but it is using the wrong font family. You can bet it's the same thing when exporting to PPT.
I can reproduce the bug.
I think the reason for not displaying default bullets is that the corresponding font is not installed. To improve our capabilities we will work on two solutions: In the short term, default bullets will be mapped to the corresponding OpenSymbol character which should always be available. I plan to fix this for OO 1.0.3 The second improvement will be an improved Glyph fallback. There is already somebody working on this, but it is not clear when this feature will be finished.
Though the OpenSymbol font in 1.0.1 and later has both W32 unicode and MAC 1.0 CMAP tables, FT only recognizes the MAC table. Since a lot of characters require full unicode access instead of 8bit, these characters are not displayed. OpenSymbol's cousin StarSymbol works fine everywhere while OpenSymbol currently only works in Win32. Need to investigate the FT<->OpenSymbol troubles...
Looks like http://lists.debian.org/debian-openoffice/2002/debian-openoffice-200208/msg00039.html Originally we thought this problem would only happen with our recent unix builds, but the problem also seems to cause trouble on older W32 platforms. What is more important is, that it also happens on newer W32 platforms when e.g. a PDF printer driver tries to embed OpenSymbol. HDU->IH: Though I originally thought using only the FT patches would be sufficent, with the recent reports on OpenSymbol causing trouble on W32 too I got convinced that only changing the font itself can help. The Fontographer tool seems to be the root of the problem here. As suggested in the link above PfaEdit can solve the problem.
IH: I will try to fix the CMAP tables with PfaEdit.
us->hi: I'll take over.
us->ih: sorry, but I assume the font is still somehow buggy. + A *.ppt document still shows rectangles + the Numbering/Bullets dialog shows rectangles + and an Impress document with OpenSymbol bullets also shows squares instead. I'll point you to the bugdocs, give me a call.
*** Issue 9757 has been marked as a duplicate of this issue. ***
us: additional comment: fontview.exe on winXP also *only* displays squares for the new 'OpenSymbol'.
us->ih: unfortunately the brand new version is worse than the original one (at least on WinXP). The first tab page in Format-Numbering/Bullets does not display the small round bullet in its upper left. And when selecting -this-not-displayed bullet, obviously nothing is displayed (at least in Impress, Writer still displays a bullet). BTW. the original description (bullets in PPT documents not displayed on Linux) is still true.
IH: Creating a new OpenSymbol font with PfaEdit did not fix the problem - so I do not know what to do at this moment. The other fonttools (Fontographer and Fontlab) write much more buggier fonts so PfaEdit was our last hope so far. A closer look at the CMAP tables did not give us a clue where the problem is. Has someone out there some other font edit tools to try? Unfortunately we do not have some of the tools that the professional font vendors use :-(
us->ih: as this effort did not succeed, I shouldn't be the owner any longer. Feel free to retarget or set to duplicate. You should have enough tasks regarding this topic.
HDU: Looks like only the hardcore method of binary patching can help here. Ugh...
Hi, If someone has a Mac with Classic installed, try out TrueEdit. You have to convert the font to a resource-based font (its a fairly complex process, but I've done it and can attach the font file if needed, in .sit.hqx format). Then, after editing, you have to convert back to a regular .ttf file, but if the Mac in question has our OOo Final Beta for Mac OS X installed, we've installed Fondu already and you can simply run Fondu on the font, and it will spit out the .ttf. http://developer.apple.com/fonts/Tools/agreed.html#Editors If someone wants to tell me exactly what the problem is, I could take a stab at fixing it. Dan
Hi, Looking at the Apple font documentation for the 'cmap' table, it appears that the font itself _is_ correct, and that the error lies with FreeType. The MS and Unicode tables both map to the same actual data in the fonts 'cmap' table, so what affects one affects the other. Hence, they are both type 4 tables. If I understand the email to the debian list correctly, and Warner Lemberg's reply, he is saying that the last glyph in the cmap table should map to the 'unknown' glyph, or ID 0. However, the tables in OpenSymbol, the last glyph 0xFFFF maps to 4096 (0x1000), which is incorrect. I have tried to change the value to 0 with TrueEdit on my Mac, but TrueEdit returns an error when I attempt to change the value of any of the mappings. I also tried to use DumpCMAP and FuseCMAP, but it seems that the last mapping of 0xFFFF is added as part of the program and is not under the control of the user. "To use these arrays, it is necessary to search for the first endCode that is greater than or equal to the character code to be mapped. If the corresponding startCode is less than or equal to the character code, then use the corresponding idDelta and idRangeOffset to map the character code to the glyph index. Otherwise, the missing character glyph is returned. To ensure that the search will terminate, the final endCode value must be 0xFFFF. This segment need not contain any valid mappings. It can simply map the single character code 0xFFFF to the missing character glyph, glyph 0." So Fontographer is incorrect in creating a cmap table that ends with the 0xFFFF mapping to 0x1000, but I'm not sure how to fix it other than editing the data by hand. This would be a time consuming task, considering the complexity of the cmap table 4 format, but could be done. Dan
Make the first sentence of my last post that the font is _in_correct, and that FreeType is _correct_. Sorry. The rest of it stands :) Dan
Looking at two other fonts on my machine that have the 'cmap' tables in question (ie MS type 4, and Unicode 2.0 type 4) both show that the last mapping is 0xFFFF mapped to glyph ID 0. So these are correct, and OpenSymbol is NOT. If Freetype is indeed dropping these 'cmap' tables (of which OOo only understands the MS table, and with patches that I've added for Mac OS X also the Unicode 2.0 table), then we have a problem. Dan
Created attachment 5234 [details] Corrected (?) TrueType file to test
Can someone test the attached TrueType font? Looking through the font's 'cmap' table with a hex editor, I think the following is the problem. There is an extra byte at offset 0x07A6 from the start of the file. This lies inside the idDelta[] array of the MS/Unicode 'cmap' table for the font. However, this last entry should be 0x0118 (segCount * 2). This extra byte was causing the entry to be 0x0001 which was perhaps causing the Freetype problems. Thus, the character->glyph mapping algorithm would find the wrong place in the glyphIndexArray[] for entry 0xFFFF, instead of what it should be. This extra byte was probably causing other errors too. So removing the 0x00 at location 0x07A6, making the 2 bytes at that location be 0x0118 rather than 0x0001 as it was, corrects the cmap issue. Please let me know if the attached font fixed the problem, or helps in any way. Dan
Because I was using Resourcerer on opensymbol converted to a resource-based font so I could use TrueEdit, the offsets listed here are a bit mixed up. Its actually two extra bytes, 0x0001, located at offset 0x0173b7 and 0x0173b8 in opens___.ttf. 0173b0: 00 00 00 00 00 00 <00 01> 01 18 01 1E 01 20 01 2E 0173c0: 01 36 01 36 01 36 01 36 01 38 01 38 01 3A 01 3C Dan
Argh. Offsets 0x0173b6 and 0x0173b7, as shown above in the hex data. Dan
Hmm, I messed something up. Ignore most of this, but the issue with the last glyph mapping to something other than 0 is still the problem it looks like. Just my method of fixing it, and hence the attached file are wrong. I'll have to go over the tables and the glyph mapping algorithm for table format 4 again. dAn
IH->Dan: please try to fix this if you could.
IH: Did the font that you forwarded to me that you edited with pfaedit not work correctly? I opened it in TrueEdit and it did seem to have the correct 0xFFFF glyph mapping to unknown glyph (0). Is there still a problem with your corrected font? dan
Can someone attach a document, either Writer or Impress, that is known _BAD_? One other thing with this font is that somehow, for the Mac OS X port, none of the glyphs actually show up on screen. They are displayed in the Font popup, but when you type in OpenSymbol, no glyphs show up. I need to put my debug code back into Freetype to find out whether FT actually recognizes the font or not, and if it doesn't, then why. I have a local build of FT 2.14-pre that I've been using on the OS X side for other work. Thanks, Dan
With IH's correct OpenSymbol, and FT 2.1.3-pre, I get succes on loading. -------------------------------------------------------------------- gcach_ftyp.cxx:::: Attempt to FT_New_Face() font file /ooo-install/share/fonts/truetype/opens___.ttf, face 0 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 Success Freetype returned family_name of OpenSymbol Freetype returned style_name of Medium Freetype returned 3 charmaps gcach_ftyp.cxx:::: File /ooo-install/share/fonts/truetype/opens___.ttf done With the old, "bad" font I get success as well, but the style_name is different: ------------------------------------------------------------------- gcach_ftyp.cxx:::: Attempt to FT_New_Face() font file /ooo-install/share/fonts/truetype/opens___.ttf, face 0 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 ftobjs.c: clazz->init_face() returned error 2 Success Freetype returned family_name of OpenSymbol Freetype returned style_name of Regular Freetype returned 3 charmaps gcach_ftyp.cxx:::: File /ooo-install/share/fonts/truetype/opens___.ttf done Dan
retarget to 1.0.4
utomo> mh: Can you retarget ths, as 1.0.4 is not planned, how about 1.1.1 ? Thanks ------- Additional Comments From Martin Hollmichel 2003-04-14 22:44 PDT ------- retarget to 1.0.4
Problem seems to be solved in 1.1.0; I tried both Linux (SuSE 8.2) and Windows 98 SE. Thanks! Jogchum Reitsma
Clsoing as fixed then.
The Issue you raised has been marked as 'Resolved' and not updated within the last 1 year+. I am therefore setting this issue to 'Verified' as the first step towards Closing it. If you feel this is incorrect, please re-open the issue and add any comments. Many thanks, Andrew Cleaning-up and Closing old Issues ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
As per previous posting: Verified -> Closed. A Closed Issue is a Happy Issue (TM). Regards, Andrew