New to Typophile? Accounts are free, and easy to set up.
Create an account
Typophile RSS | More Feeds
Does anybody know?
According to these fonts' properties:
Cambria: "Authors: Monotype Imaging and Tiro Typeworks".
Calibri: "Authors: Luc(as) de Groot"
hi John, what is the issue?
Theunis — Cambria was designed by Jelle Bosma (with Steve Matteson & Robin Nicholas of Monotype). Not sure what Tiro is doing in the font properties. Are you sure you didn’t mistakenly check Constantia (John Hudson’s contribution) instead?
I’m always mixing up those C faces, myself.
hi Kent, Tiro/John Hudson, did much of the work on the Math additions to the font.
Ross did most of the Cambria Math work, although some of it based on Jelle's initial work. I did most of the the languages extensions for the Win7 versions of Cambria Regular and Italic, with David Březina working on the bold weights.
The issue regards capital Cyrillic letters in italics with combining diacritics.
Can you give examples, illustrations of the issue? Also, which versions of the fonts are you using? The initial, Windows Vista versions did not support mark positioning; the Win7 versions do.
Yes, I can give you a screenshot. I've been doing some experimenting in Word (yup) and the issue arose when I wanted to use what Word calls "contextual alternates", ie. italic Cyrillic letters different from Russian ones. In order for that to work, I had to pick as a language the most bizarre thing ever Serbian (Cyrillic, Serbia and Montenegro (former)) and then select standard ligatures and contextual dialogues in Font properties.
This is what I get
The question is: how does one get the correct italics and correctly combined diacritics with capital Cyrillic letters?
Which Cambria version is the most recent? 5.93?
Okay, I've looked into this and found a problem in the VOLT source for the Cambria Italic and Cambria Bold Italic fonts: the 'ccmp' feature lookup that substitutes the cap versions of above combining marks for subsequent positioning when preceded by an uppercase letters is not mapped to the feature in the Serbian 'SRB' language system. So far as I can tell, this only affects the Italic and Bold Italic fonts.
Thanks for catching this. I'll get this logged as a bug and will send a fix to Microsoft today. I can't say how or when they will get the fix released, though.
Thank you very much! I have to ask: when this gets fixed, will it be available as an Windows (Office) Update? How does Windows update its fonts? And also will this enable these alternates also to be used with the simple Serbian (Cyrillic)?
Sylph, is the issue in Calibri the same? Or did you want to report a different problem?
The issue in Calibri is similar. I will post a screenshot.
Could you answer my question: do you know how will Microsoft release the fix? Thank you.
They're misplaced, leaning to the right.
In Constantia it doesn't work at all. I haven't checked the other Microsoft typefaces.
I'll ask Microsoft to look into this Calibri issue. It looks like the substitution of the cap accent forms (ccmp) is working fine, but the positioning (mark) is not. Possibly this is another situation with a lookup not being correctly associated with the SRB language system.
This is not expected to work in Constantia: of the original ClearType font collection, only Cambria, Calibri and Consolas were extended and mark positioning added for Windows 7.
I don't know how Microsoft will release a fix. Typically, critical bugs get rolled out using the Windows Update mechanism, but font issues are seldom considered critical in this sense.
Thanks John A for reporting the problems with these fonts. As John Hudson indicated, Microsoft is rarely able to update fonts via Windows Update. The fixed fonts will likely ship with the next version of Windows.
Oh, OK. Thank you, John! I figured that it will ship with the next installment of Windows, as Sii says.
As for Constantia, I was just wondering why do the combining diacritical marks exists when they don't work properly. I thought typeface designers checked if all of that worked well. Segoe is another such typeface.
A subset of combining mark characters are supported in Constantia and many other fonts without mark-to-base GPOS support in order to be able to create precomposed diacritic composites using these glyphs. It would be possible to do the same thing while leaving these glyphs unencoded, but that would result in a bigger fail when these characters occur in text, since the font wouldn't be able to display them at all.
Oh, I see. Of course. Thank you for all your help and explanations!
Also, in Cambria, is the Combining Ring Below supposed to look like this? With the Cyrillic r it doesn't even show up.
Here is what I get with XeLaTeX (Russian left, Serbian right) using Cambria italic.
Could you share the document preamble? Why does it differ that much? And how does XeLaTeX know how to use the correct italics forms?
That is the full input.
The line with \newfontfamily\serbian can be deleted.
Sylph: Also, in Cambria, is the Combining Ring Below supposed to look like this?
What is happening here is that the GPOS mark positioning is moving the mark beyond the OS/2 table usWinDescent value. This means that the mark will be clipped in some software, but not in others. If you are using MS Word, you can prevent this from happening by using an exact size of linespacing in the paragraph settings, rather than a multiple of the default linespacing.
In Michel's image, I'd say that the position of the mark under the default italic д is a bug. Probably my fault, I'm afraid. I think the mark height must be inherited from the upright font, where it needs to be lower because of the descenders of the д.
Thank you, Michael and thank you, John. I hope I'm not being too tedious about this.
John, yes, I've searched for your posts about this and managed to find here
the suggestion about leading. With a font size of 12 pt and line spacing set at Exactly 20 pt, this is what happens
Another matter with Cambria is the difference with a U+00E0 character and Cyrillic a with U+0300 (Combining Grave Accent):
XeLaTeX again, with Michael's preamble, does this correctly with the latter.
These characters with the ring below aren't invented – though they are extremely rare. It's used to denote a syllabic consonant, which is usually m, l, r, n.
Charis SIL does this correctly, but it doesn't have the correct italics whereas Gentium Plus does have the feature, but it has to be turned on with the TypeTune tool.
I have to admit that I've almost given up trying to understand how MS Word determines when and where to clip. Setting the linespacing to an exact value appears to do a better job avoiding clipping of marks above than below. Testing the sequence you show, less of the ring is clipped as the linespacing gets larger, but obviously this isn't a viable solution.
Note that this clipping should not occur when you print the document, including printing to PDF: it is the result of how Word paints each line of text on screen.
I'm not able to reproduce the problem you show with Calibri à vs а̀: these display identically in Word 2007 on my system.
Look closely at your image, above: the grave accent on the right appears to be from a different font, so maybe what you are seeing is a copy/paste error. Select the whole word and ensure that the font is Calibri.
Seems that language specific metadata for ascent and descent was slain and will never rise from the ashes... But maybe some clever dude(s) or dudette(s) will remedy the situation with a pan-linguistic cross-platform script to help typographers by making that metadata available on the fly... now.
I have to admit that I've almost given up trying to understand how MS Word determines when and where to clip.
But maybe some clever dude(s) or dudette(s) will remedy the situation with a pan-linguistic cross-platform script to help typographers by making that metadata available on the fly...
There is not need to even try understanding it. :) This is clearly an application bug and needs to be fixed by the application developers.
GPOS, and its arbitrary mark stacking mechanism in particular, by design (designed by Microsoft!) contradicts the idea that any font metadata would delimit the vertical region up (or down) to which attachments are visible. And likewise, the suggestion that OS/2 ascent and descent values would need to reflect every possibly additional mark is in contradiction to the idea and design of GPOS.
They sure do look stupid. But we owe them time to fix their QA process... again and again and again.
I have just checked the typeface version in Windows 8 Consumer Preview, and for Cambria it is still 5.96. Oh, Windows, will you update these fonts?
Oops, it's 5.98. Let me see if something has changed.
OK, the Cambria issues seem to be fixed in Windows 8 (albeit, one still has to pick a language for a non-existent state, you cannot get the right italics for Serbian (Cyrillic)), the Calibri misplacement of combining diacritics isn't fixed.
It seems also that both still don't have the U+203F character.
@John Hudson, who last year correctly said, ".. font issues are seldom considered critical in this sense."
A little late to the party, but as far as I know, the only time that MS issued a CRITICAL update for a font was some nine years ago when they removed the hindu/greek/american indian symbol that was a swastika from Bookshelf Symbol 7. If I remember correctly, they first replaced it with a star of David, but later versions have that unicode slot empty.
The inability to create text properly certainly isn't a critical bug to MS.
Not quite right, Herb. MS didn't replace the swastika with a star of David; in 2004 they removed two swastikas and the star of David from the font, presumably over GeoPol sensitivities.
[For another client, I once had to replace a six-pointed asterisk with a five-pointed on the grounds that the former might offend Arab customers by resembling the star of David. That was when I instituted the stupidity premium of +25%.]