Description of problem: The font 'Symbol' is not rendered correctly on screen in OpenOffice 1.1.0. Version-Release number of selected component (if applicable): openoffice.org-1.1.0-6 fontconfig-2.2.1-6.1 XFree86-xfs-4.3.0-42 How reproducible: Always Steps to Reproduce: 1. Start OpenOffice.org 1.1.0 Writer 2a. Add some text, then Insert->Special Character->Font->Symbol and insert e.g. some greek glyphs. Insert more text with regular fonts around the 'Symbol' characters. OR 2b. Open an existing document that contains characters in the 'Symbol' font. Actual results: 'Symbol' characters are displayed on top of adjacent characters in other fonts or not at all. Sometimes the font 'Symbol' is invisible in the fonts menu (there is a blank line instead). Expected results: Correct rendering of 'Symbol'. Additional info: 'Symbol' works properly when using OpenOffice.org 1.1.0 installed from the OOo distribution package on Red Hat 9, both on screen and in print. On Fedora Core 1, 'Symbol' is not rendered right in either the RPM-packaged OOo or OOo 1.1.0 installed using the OOo installer, so the problem appears to be in the font handling of FC1.
For me it is rendered on screen correctly but gives blank print output.
I have two FC1 systems. One is a fresh install and one is an upgrade from a fully up2date RHL9. The fresh install exhibits the behavior indicated above, that is the Standard Symbol and OpenSymbol fonts are invisible in OO.o. The upgrade system works perfectly. Both symbol fonts are visible in the font list and both produce visible text in the document.
I understand that Ximian's patched version of OOo that includes Xft support is being packaged for Fedora. Are those packages available for testing? Can someone check whether 'Standard Symbols' and 'Open Symbol' work on that version?
Colin Charles pointed out on fedora-list, that this problem is in the OOo issuezilla, issue no 16337. See http://www.openoffice.org/issues/show_bug.cgi?id=16337 Symbol fonts fail also on Mac OOo and on Linux/Fedora with the Ximian patches applied. It seems like 'why _does_ it work on (at least some of the time) RH9' is a better question than 'why does it not work on Fedora'.
Created attachment 97681 [details] Snip from /var/log/cups/error_log with debug2 level Snippet from the /var/log/cups/error_log with debug level set to 2. Things that I find interesting... 1) line 38, inconsistant and suspicious..: D [14/Feb/2004:22:32:36 -0800] [Job 87] --> This document is DSC-conforming! D [14/Feb/2004:22:32:36 -0800] [Job 87] Job claims to be DSC-conforming, but "%%BeginProlog" was missing before first line with another "%%Begin..." comment (is this a TeX/LaTeX/dvips-generated PostScript file?). Assuming start of "Prolog" here. Don't know if this is important, looked suspicious to me.... 2) ghostscript quits working on line 94, with this error: Error: /invalidfont in -dict-
Created attachment 97682 [details] Snip from /var/log/cups/error_log with debug2 level System: FC1, fully patched through Synaptic package manager. The symbol font appears somewhat garbled in OpenOffice, but does not print at all. Within OpenOffice, you cannot select "Symbol"..rather can select "OpenSymbol" and "Standard symbol" When printing from OpenOffice, no characters appear, only dots. AcrobatReader 5 complains that it cannot find the "Symbol" font, and cannot print (although it does display correctly). Ghostscript indicates error in /var/log/cups/error_log that "Symbol-Identity-H" type font has invalid dictionary. Discussed problem on "www.linuxprinting.org" site, verified that "Symbol" was in ghostscript's path by creating symbolic link from /usr/share/fonts/default/ghostscript to /usr/share/cups/fonts/Symbol and modified cupsd.conf to include the ghostscript font path. All failed to resolve problem. Snippet from the /var/log/cups/error_log with debug level set to 2. Things that I find interesting... 1) line 38, inconsistant and suspicious..: D [14/Feb/2004:22:32:36 -0800] [Job 87] --> This document is DSC-conforming! D [14/Feb/2004:22:32:36 -0800] [Job 87] Job claims to be DSC-conforming, but "%%BeginProlog" was missing before first line with another "%%Begin..." comment (is this a TeX/LaTeX/dvips-generated PostScript file?). Assuming start of "Prolog" here. Don't know if this is important, looked suspicious to me.... 2) ghostscript quits working on line 94, with this error: Error: /invalidfont in -dict- This is the killer, as ghostscript dies here...
Can you try with latest OOo 1.1.0 (-28 at this time)?
I tried to install this on my FC1 system that is up2date with the distribution upgrades, but not with rawhide. Too many dependencies on packages in rawhide for me to risk ruining my production system. My FC2 Test 1 system was hosed last week by trying to keep up with rawhide. I tried a new install and update, but could not get the several hundred updates to complete. Maybe someone with a testing system that works can try this. Sorry
With 1.1.0-28, OpenSymbol symbols work fine. However Standard Symbol L symbols, while rendering correctly on-screen, do not appear at all in the print output.
*** Bug 120455 has been marked as a duplicate of this bug. ***
So the question on my mind is: why isn't OOo embedding this special font?
What additional information can I supply? The symbol font issue is also present when opening/printing from Acrobat Reader. Please let me know what I can supply to assist in the debug. DD
With openoffice.org-1.1.1-4 OpenSymbol and Standard Symbol L seem to work, and the printable issue as in comment #9 seems to work (at least when doing a page preview). Seems to me as fixed in CURRENTRELEASE - does anyone else still have this problem when using Fedora Core 2's OOo?
I agree that it all works fine now, including output on the printer.
I'm still broke.... I've upgraded from RH9 to FC1 to FC2 with all the latest updates. Acrobat still looking for symbol font, can't print any electronic component datasheets with standard electrical symbols. I have installed and the msttcore font package from sourceforge, could that be the cause? Anyone above using the msttcore fonts?
Using RPM-packaged openoffice.org-1.1.1-4 on FC2 is a bit better, but only a bit. Typing in Standard Symbols L works on screen, i.e. 'a' inserts and alpha and so on. This font is invisible in an exported PDF (font not found by Acroread?). Interestingly, Standard Symbols L characters inserted using Insert/Special Character _do_ appear correctly in PDFs displayed with Acroread. The kerning problem with Standard symbols (Symbols overlapping adjacent characters set in other fonts) seems fixed. OpenSymbol is visible in the drop-down menu and the font works both at editing and in PDF output if the characters are inserted with the Special Character dialog. Typing OpenSymbol gives empty rectangles as before.
Created attachment 106323 [details] patch to plausibly fix 1. That OpenSymbol doesn't work outside of using the "Special Character" dialog is a red-herring. That font doesn't have glyphs at most of the normal locations like 'A' etc. But it has a few, so you should see e.g. "+" "-" and "&" work in OpenSymbol from the keyboard. 2. On-screen display of Symbol and Standard Symbols L are ok 3. Printing to ps seems ok 4. Print to PDF of "insert->special characters" apparently always works, but... 5. I certainly see that Print to PDF of typed from keyboard Symbol works, but that "Standard Symbols L" doesn't. The patch attached makes it work and seems a plausible solution.
Upstream as http://qa.openoffice.org/issues/show_bug.cgi?id=36901
Incorporating into 1.1.2-13
This is fixed in Rawhide with 1.1.2-14.7 (and RHEL4) and should show up in FC3 and FC2 updates at some soon point.