FYI. I moved your post from the "superscript" topic to this topic so that your post is close to the original discusion.
I argue this points the finger back at NeoOffice, and again raises the nasty question of why this works on my office G5 DP running OS 10.4.11, and not on my home G5Dp. One clue I think is that the PMingLiu is an font folder labeled "Fonts disabled" on the office G5 (runing Neoffice 3.1.2.
You may be right. I was able to drag this PMingLiU glyph from the character palette window into TextEdit, so that tells me the problem is occurring in Apple's CoreText text layout functions. NeoOffice does not parse fonts itself. Instead we pass Unicode strings and a native font handle to Mac OS X's CoreText functions and those functions return an array of glyph numbers and coordinates for each glyph.
In this specific case, I had confirmed in a previous post that the CoreText functions are returning glyph 0xffff which is the PMingLiU font's empty rectangle glyph.
What is weird is that while I can now see this glyph in TextEdit. Saving the TextEdit document to an HTML file yields flaky results: Firefox can display the glyph but Safari cannot.
This makes me think that TextEdit and Firefox are converting Unicode characters in this range to a different range and they are passing the converted characters to the CoreText functions.
I will look at this further over the next few days and see if I figure out what special logic TextEdit and Firefox are using.
I have bad news: after investigating this issue a second, I have reconfirmed that the problem in NeoOffice 3.2.1 is that Apple has been removing support for fonts that have glyphs in the Unicode control character range. While most Apple applications on Mac OS X 10.4 display these glyphs, only a few display it on Mac OS X 10.5 and none of Apple's application display it on Mac OS X 10.7.
The details of why using the U+0086 Unicode character with the PMingLiU font is at the end of my post. But first I wanted to tell you that there is a way to avoid this problem and display the Unicode dagger character in your documents: change all U+0086 Unicode characters in your document to U+2020. U+2020 is the official Unicode dagger character and many of the fonts bundled with each version of Mac OS X have a glyph for U+2020. You can replace all occurrences of U+0086 with U+2020 by doing the following steps.
1. Open your document in NeoOffice and select the Edit :: Find & Replace menu.
2. Open the Mac OS X character palette and drag the U+0086 character from the character palette into the NeoOffice Find & Replace dialog's "Search for" field (after dragging, the field will appear empty but that is OK). Then, drag the U+2020 character from the character palette into the Find & Replace dialog's "Replace with" field.
3. Press the Find & Replace dialog's "Replace All" button. All of the original U+0086 characters should then be visible in both NeoOffice 3.1.2 and 3.2.1.
So back to why U+0086 character won't display. Basically, any applications that use Apple's deprecated ATSUI text layout functions will work in your case through Mac OS X 10.6. However, Apple dropped support for these non-Unicode compliant characters when they introduced their new CoreText text layout functions in Mac OS X 10.5 so any applications that use the CoreText functions will not be able to display the U+0086 character.
NeoOffice 3.2.1 and, starting with Mac OS X 10.5, Safari both use the new CoreText text layout functions. In contrast, on Mac OS X 10.5 TextEdit and Firefox still used the old ATSUI text layout functions so those application can display the U+0086 character.
So you are probably wondering why NeoOffice 3.1.2 - which uses the old ATSUI text layout functions - cannot display the U+0086 character. The reason is that there is a bug in our NeoOffice 3.1.2 text layout code. Unfortunately, since we no longer have PowerPC build machines, it is not possible to investigate and fix the old code in NeoOffice 3.1.2.
Even if we could fix NeoOffice 3.1.2, the problem remains that on Mac OS X 10.7, even the old ATSUI text layout functions no longer display the U+0086 character so the only option available that will display the dagger character reliably on Mac OS X 10.4 through 10.7 is to replace the U+0086 character with the U+2020 character in your documents.
Do the dagger characters display after you replace all of the U+0086 characters with the U+2020 characters in your documents?
All times are GMT - 7 Hours Goto page Previous1, 2
Page 2 of 2
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum