Open Bug 729848 Opened 12 years ago Updated 2 years ago

DirectWrite is creating phantom font families such that font family name matching varies depending upon the font backend

Categories

(Core :: Layout: Text and Fonts, defect)

12 Branch
x86_64
Windows 7
defect

Tracking

()

REOPENED

People

(Reporter: zart, Unassigned)

References

()

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Firefox/11.0 SeaMonkey/2.8
Build ID: 20120216171326

Steps to reproduce:

The page is using simple CSS rule «font-family: 'Script MT Bold';».


Actual results:

Modern Gecko-based browsers (I checked with SeaMonkey 2.8 and Aurora 12.0a1) don't match this font with this rule anymore. They match with 'Script MT' however. Using font-weight normal or bold doesn't make a difference.


Expected results:

I have checked the rendering with IE8, Chrome 17, Opera 11-12, Safari 5. They all match on 'Script MT Bold' but not on 'Script MT' for what it worth. This was also the Gecko's behavior in the past as well as far as I recall.

Note that this font has exact name 'Script MT Bold' (scriptbl.ttf) and doesn't have corresponding regular typeface.
Did you test IE9?  This is almost certainly a GDI vs DirectWrite issue....
Installed IE9 and tried it there. Funny enough it renders all permutations of 'Script MT'/'Script MT Bold' and normal/bold as 'script mt' font.
Fixed 'font-weight: bold' in example image, added IE9 rendering.
Attachment #599881 - Attachment is obsolete: true
The font-family property is intended to match family names, not fullnames.  In browsers using GDI in the past, fullnames would match.  This produces incongruencies across platforms where 'Arial Bold' would match on GDI browsers but not under OSX.

Matching fullnames doesn't make sense at a fundamental level either.  Consider this style rule:

  body {
    font-family: Arial Bold;
    font-weight: normal;
  }

The use of a font face name rather than a font family name leads to imprecision here.

The CSS 2.1 test suite includes tests that explicitly check that browsers don't match against the fullname.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You're ignoring the fact that word "bold" is in "script mt bold" font family name here which leads to difference in rendering.
Tentatively reopening this as I can reproduce the behavior reported.  I was able to find an available copy of ScriptMT here:

http://fontzone.net/download/Script+MT+Bold/

My guess is that's a ripoff site but with this version I can reproduce the bug.

The relevant name table entries:

<namerecord nameID="1" platformID="1" platEncID="0" langID="0x0">
  Script MT Bold
</namerecord>
<namerecord nameID="2" platformID="1" platEncID="0" langID="0x0">
  Regular
</namerecord>
<namerecord nameID="4" platformID="1" platEncID="0" langID="0x0">
  Script MT Bold
</namerecord>
<namerecord nameID="6" platformID="1" platEncID="0" langID="0x0">
  ScriptMTBold
</namerecord>

<namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
  Script MT Bold
</namerecord>
<namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
  Regular
</namerecord>
<namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
  Script MT Bold
</namerecord>
<namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
  ScriptMTBold
</namerecord>

On OSX, we only match "Script MT Bold" which matches the name table data.  But under Windows 7/DirectWrite we match 'Script MT' but not 'Script MT Bold'.  In the GDI case we match 'Script MT Bold' only.  IE9 matches both (?!?).

My guess is that this is a weird byproduct of the name swizzling that DirectWrite is automagically doing.  Not sure why IE9 is somehow matching both the swizzled and unswizzled family name.  This is related to the Gill Sans Ultra MT problems, where the name swizzling algorithm was creating phantom family entries that mucked things up.

For now, the best workaround is to use:

  font-family: Script MT Bold, Script MT;
  font-weight: bold

This should produce consistent results across all browsers.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: font-family doesn't match font by its full name → DirectWrite is creating phantom font families such that font family name matching varies depending upon the font backend
What family name does Win7 show for that font when you look in the Fonts control panel? What about in the font menus of various applications? What about in our font list in the Options / Content dialog?
The fonts control panel shows "Script MT Bold" as does the list of fonts in Options > Content tab.  As does the font selection panel in IE9!!  Damn font name swizzling...
On my localized Win7 it's named "Script MT Полужирный" in Control Panel which seems to show that Win7 itself splits "Bold" part from family name. Full family name is shown if opening font example there.

The other font which shares the similar treatment is "Gloucester MT Extra Condensed", which is shown as "Gloucester MT сверхуплотненный", where "extra" part seems to be removed for display purposes.

NB. Found some relevant info on http://blogs.msdn.com/b/text/archive/2009/04/15/introducing-the-directwrite-font-system.aspx which mentions GDI vs DirectWrite font family handling.
(In reply to John Daggett (:jtd) from comment #8)
> The fonts control panel shows "Script MT Bold" as does the list of fonts in
> Options > Content tab. 

Interesting... I'd have thought that if we show that name in the list, we should also recognise it by that name in CSS. That seems like an inconsistency we ought to be able to track down and resolve.

What do we show in the font list if h/w acceleration (D2D/DW) is turned off?
The root of the problem is this:

http://blogs.msdn.com/b/text/archive/2007/04/23/wpf-font-selection-model.aspx

Full details white paper:

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-02-24-90-36/WPF-Font-Selection-Model.pdf

Read Step 2, that's where it's "extracting" a unified font family name.  That's the cause of this.  I'm guessing IE is doing some careful swizzling of families with only one font in the family, or something like that.

The question now is whether we can do anything about this?
(In reply to Jonathan Kew (:jfkthame) from comment #10)
> (In reply to John Daggett (:jtd) from comment #8)
> > The fonts control panel shows "Script MT Bold" as does the list of fonts in
> > Options > Content tab. 
> 
> Interesting... I'd have thought that if we show that name in the list, we
> should also recognise it by that name in CSS. That seems like an
> inconsistency we ought to be able to track down and resolve.

Yeah, quite possibly.

> What do we show in the font list if h/w acceleration (D2D/DW) is turned off?

The GDI code behaves like Chrome does, it matches "Script MT Bold" but not "Script MT".
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: