You might need to confirm that you have the latest Service packs installed for both Office and Windows.

Cheers, Si

Hi,
I have all the latest SPs for both.

I found one more possible bit of information. When I try to build a keyboard layout using the MS Keyboard Creator it squaks and says that the characters assigned to keys are not in the 1252 code page and may create problems with non-Unicode programs. When I enable the keyboard and type the diacriticals or modifiers some characters combine and some don't. For instance a U+0063 and U+0313 work fine but a U+0043 and U+0313 doesn't (the latter seems to override the ccmp and place the caroncomb over the C without the placement set up via ccmp...I'm assuming that some lower level Word/Windows action is doing this).

Ideas?

[I'm a bit confused by your example, because U+0313 is a combining comma above, not a caroncomb]

Test your keyboard in NotePad. Word has some key combinations hard coded as hotkeys, so will not accept character input from them. You may also find that RichEdit apps gets confused if you enter characters that are part of an 8-bit codepage but your font does not support that codepage: the app may switch fonts on your during inputting, which is extremely annoying. NotePad will give you a better indication of whether your keyboard layout is working.

NotePad will also indicate what Uniscribe is doing, without the layers of application API decision making that Word imposes.

If your font contains an encoded precomposed diacritic character such as U+010C, Uniscribe will make a character level substitution for U+0043 + U+030C, because this is the canonical decomposition for the former. It is faster for Uniscribe to do this at the character level than to process glyph processing lookups in the font. If, for some reason, you didn't want U+0043 + U+030C to result in the glyph encoded at U+010C, e.g. because you wanted to always use GPOS mark positioning, you would actually need to decompose U+010C -> U+0043 + U+030C in the ccmp feature.

Slightly off-subject but on-topic:

In Word 2003, there is an option to "Embed TrueType fonts".

Are OT/Type1 fonts also embedded when this box is checked?

I'm sure I could experiment, but I'm sure someone out there already knows the answer :)

No, sadly not. Regardless the font embedding feature in Word is a bit flaky, seems to work okay for one-off display fonts, but has problems with extended families.

Fred, if you have access to them try the Windows Vista versions of Tahoma or Microsoft Sans Serif to see if they exhibit the behavior you're expecting.

Cheers, Si

I solved my problem of odd behaviors with some diacriticals (for instance U+004D U+0323) by creating a composite with a codepoint of 1E42. However, have I made things worse by doing this? I'm trying to understand whether it is better to have all of the composite characters as non-codepoint composites...for instance uni004D0323...or have them point to a Unicode codepoint such as Mdotbelow.

The follow-on question is for subsequent characters, such as U+0043 U+030C U+0313, should I create an intermediate codepoint of 010C or use a composite of uni0043030C with no codepoint? What I've currently done is create a ccmp 'sub Ccaron commaabove by uni0043030C0313'. The alternative would be 'sub uni0043030C commaabove by uni0043030C0313'.

Hope I've phrased this right...I'm a novice and still trying to understand UniCode and OpenType. What I want to ensure is the best solution for spell-checking that is cross-platform. If I understand what you're explaining, then UniScribe will decompose a compsite and enter the codepoints for the separate glyphs. Does this happen in MacOSX? If not...it might seem better to not use codepoint composites as decompisition does not occur on the Mac and will support better cross-platform compatibility.

Thanks,

Hi,

Please help, I'm losing my sanity trying to create Word templates that will work on both a Mac and a PC. I thought i'd be clever and use OpenType fonts to avoid any font issues between the two platforms, but when i install the fonts on the PC, the bold and italic weights won't show up in the Word 2003 font menu (not to mention coming out in Courier and spoiling my beautifully created Word template!).

Please help, i don't want to have to resort to using different fonts for Mac and PC users and i'd love to learn how to solve this problem!

Cheers,

Jo

Jo, you should start a new thread with this problem. Make sure you title it in an exemplary way.

This is a known issue which is documented here, scroll down to the section Fonts do not map correctly in documents transferred from Mac OS to Windows. (Thank you Miguel!)
The problem is that Mac and Windows Word documents are not really cross-platform compatible when it comes to identifying fonts. The Mac version identifies fonts by name ID18/Mac if present, else by name ID4/Mac, while the Windows version identifies fonts by name ID1/Win.
I would consider this as a bug in Word. At least, the developers didn't care for document exchange from Mac to Windows. Smart applications identify fonts by name ID6.

For font developers:

With larger font families, this can be (partially) worked around -- see Thomas Phinney's TypoTechnica presentation on font naming (PDF), page 15.*
But even then a Word for Mac user needs to select only the base font of a style-linked sub-family from the font pulldown menu and then apply Bold/Italic buttons. With some luck, fonts are recognized when opening the document in Word for Windows. If, instead, a Word for Mac user selects italic etc styles from the font pulldown menu directly, most likely (s)he will get Courier when opening the document in Word for Windows ...

* Unfortunately, I was not aware of how important ID18/Mac is in style-linked families until yesterday when Bas Jacobs told me that something must be wrong with my Font Naming PDF. In a future update I will point out that
[1] name ID18/Mac should be present in larger, style-linked families
[2] name ID18/Mac should be identical with name ID1/Win in the base font ('Regular' style) of each sub-family (identified by a common name ID1/Win).
(Thanks to Thomas for clarifying this in his above-mentioned presentation!)

Translating name IDs to FLS5 FontInfo tags:
name ID1/Win -- 'Family Name'
name ID4/Mac -- 'Full Name'
name ID6 -- 'PS Font Name'
name ID18/Mac -- 'Mac Name' in 'OpenType-specific names' page, below of 'OT Family Name' and 'OT Style Name'

Karsten

It may actually be even worse than this - name ID 18 was used prior to OS X, but I gather OS X apps are largely no longer using it and instead use name ID 4 Mac, meaning that there's no reasonable way to get consistent cross-platform menu name mapping AFAICT. :( At least, if my understanding is correct this is so.

If Windows were to move to using name IDs 16 and 17 then we could manage it, but I wouldn't hold my breath for that.

T

Hello Thomas, I tested in OSX 10.3 and 10.4:
Identification is still by name ID18 if present, else by name ID4/Mac.
10.5 not tested.

[DISCLAIMER: JUST MUSING!] Couldn't we just forget about name ID18 and, by default, create name ID4/Mac by the rules that apply to name ID18, i.e. abbreviate this name if required? This because if name ID18 is present, then ID4/Mac is ignored by applications anyway. Such an abbreviated name ID4/Mac may even go into the CFF table's FullName since this too seems to be ignored. But this also means that then name ID4/Mac rather than name ID18 must meet the condition that it be identical with name ID1/Win in each base font.