551313 - Gill Sans font displays incorrectly when using DirectWrite / Direct2D

Status: RESOLVED FIXED

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

Description

[Mike Nicholls]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100309 Minefield/3.7a3pre

When rendering with DirectWrite/Direct2D, the Gill Sans font displays incorrectly.

Reproducible: Always

Steps to Reproduce:
1. Visit about:config
2. Set gfx.font_rendering.directwrite.enabled to true
3. Set mozilla.widget.render-mode to 6
4. Restart the browser
5. View the testcase
Actual Results:  
The wrong font is used to render the heading, it seems to be Gill Sans Ultra Bold or similar.

Expected Results:  
The heading should display using the Gill Sans font.

Relatively clean OS install, all fonts installed are probably those which come with Windows 7, Office 2007 and Adobe CS3.  Reproduced on a Vista SP2 machine with a similar configuration.

Comment 1

[Mike Nicholls]

Attachment: Testcase

Comment 2

[Bas Schouten (:bas.schouten)]

I don't have this font, could you post a screenshot? For me this shows in Times New Roman on both GDI and DW.

Comment 3

[Mike Nicholls]

Attachment: Updated testcase

Sorry, I overly-reduced the original testcase and it didn't behave entirely as I described - this one should.  The required fonts seem to come with Microsoft Office or Publisher according to http://www.microsoft.com/typography/Fonts/font.aspx?FMID=978.

The CSS which causes the problem is this:
font-family: 'Gill Sans','Gill Sans MT',Arial,Verdana,sans-serif;

Under GDI "Gill Sans" is skipped (as there's no font installed with that exact name) and "Gill Sans MT" takes effect, but under DirectWrite "Gill Sans" seems to cause the "Gill Sans Ultra Bold" font to be used.

Comment 4

[Mike Nicholls]

Attachment: Screenshot of testcase under GDI

Comment 5

[Mike Nicholls]

Attachment: Screenshot of testcase under DirectWrite

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #3)
> Under GDI "Gill Sans" is skipped (as there's no font installed with that exact
> name) and "Gill Sans MT" takes effect, but under DirectWrite "Gill Sans" seems
> to cause the "Gill Sans Ultra Bold" font to be used.

That sounds like it could be correct behavior.  Windows GDI had very limited handling of families with lots of weights, but DirectWrite might be better.  cc:ing jdaggett and jfkthame for their opinions.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Is this reproducible with only DirectWrite? i.e. mozilla.widget.render-mode set to 1

Comment 8

[Mike Nicholls]

I've tried setting mozilla.widget.render-mode to both 1 and -1, it's still reproducible under both.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to comment #6)
> (In reply to comment #3)
> > Under GDI "Gill Sans" is skipped (as there's no font installed with that exact
> > name) and "Gill Sans MT" takes effect, but under DirectWrite "Gill Sans" seems
> > to cause the "Gill Sans Ultra Bold" font to be used.
> 
> That sounds like it could be correct behavior.  Windows GDI had very limited
> handling of families with lots of weights, but DirectWrite might be better. 
> cc:ing jdaggett and jfkthame for their opinions.

Yes, I think this is probably correct (I don't have MS Office or Publisher, to actually check the details of the bundled fonts, so what follows is my interpretation based on the description above, and what I know about how Windows organizes fonts).

Under GDI, "font families" are limited to 4 members (regular/bold/italic/bolditalic), and so when a typeface has a large number of weights (such as "light", "semibold", "extrabold", etc) it has to be artificially split into separate families for GDI purposes. (This is also why Arial Black is separated from the main Arial family under GDI.) To support this, members of such font families may include a couple of "family" names - one for Windows, where subgroups of the "real" family are given separate Windows family names so that GDI can access them, and a second, "preferred" family name for systems that can handle additional weights.

DirectWrite can cope with more than just the regular and bold weights in a family, and so it organizes fonts according to their preferred family names rather than the old Windows name. So Gill Sans Ultra Bold is recognized as belonging to the Gill Sans family, rather than being isolated in a separate family of its own. The problem arises because of the inconsistency where the other weights are apparently named "Gill Sans MT" rather than "Gill Sans", so the Ultra Bold weight is the ONLY member of the "Gill Sans" family. And so that's what you get.

FWIW, I believe you'd see the same behavior on the Mac if the same set of fonts were installed. It seems to indicate a poorly-organized or inconsistently-named collection of fonts, and there's nothing we can do about that. In this particular case, reordering the names in the CSS to put Gill Sans MT before Gill Sans should fix the issue, but of course this is dependent on what fonts are actually installed; people with different collections may see different results.

Comment 10

[Doug Wright]

I noticed this on part of the W3 website: http://www.w3.org/QA/ , which has the following font declaration:

font-family: "Gill Sans", "Trebuchet MS", sans-serif;

Normally, that would be rendered with Trebuchet on my system, but I'm getting the ultra bold Gill Sans.

Interestingly, the IE9 preview which also uses DirectWrite still displays using Trebuchet on that site. Maybe they're limiting the allowed font-weight variance somehow when deciding which font to use? Is that allowed per spec? (it seems like a good idea to me)

Comment 11

[John Daggett (:jtd)]

(In reply to comment #10)

> Interestingly, the IE9 preview which also uses DirectWrite still displays using
> Trebuchet on that site. Maybe they're limiting the allowed font-weight variance
> somehow when deciding which font to use? Is that allowed per spec? (it seems
> like a good idea to me)

I had the same concern and contacted a developer on the IE team.  The current IE9 preview doesn't include DirectWrite family groupings simply because they didn't have time to hook it up.  So hopefully both IE9 and a DirectWrite-enabled Firefox will treat font families the same way and evangelize authors to pay attention to their stylesheets.  Arial having an extra bold face with DirectWrite groupings is the same problem.

Comment 12

[Bas Schouten (:bas.schouten)]

Can we resolve this WONTFIX? Or do we want to look into it more.

Comment 13

[Michael Brown]

I'm having this issue with Firefox 4.0beta7 on Windows 7 on sites that where "Gill Sans" appears first in the font-family list (eg http://daringfireball.net/). As far as I know DirectWrite is not enabled (gfx.font_rendering.directwrite.enabled is set to false).
As Doug Wright pointed out above, the only "Gill Sans" font installed on my machine is the Ultra Bold version, so this would appear to be correct behaviour.

However, Firefox 3.6, Chrome 7.0.517.44 and Safari 5.0.2 all render the sites with this problem correctly so this will be seen as a FireFox bug. And believe me, if it affects a site you use regularly it's enough to make you switch browsers. I think this needs looking into more, resolving it with WONTFIX would not be a good idea IMHO.

Comment 14

[Jonathan Kew [:jfkthame]]

(In reply to comment #13)
> I'm having this issue with Firefox 4.0beta7 on Windows 7 on sites that where
> "Gill Sans" appears first in the font-family list (eg
> http://daringfireball.net/). As far as I know DirectWrite is not enabled
> (gfx.font_rendering.directwrite.enabled is set to false).

DirectWrite is *always* used, regardless of this setting, if the browser is running in Direct2D mode (which is true by default in the latest betas).

> As Doug Wright pointed out above, the only "Gill Sans" font installed on my
> machine is the Ultra Bold version, so this would appear to be correct
> behaviour.

Yes.

> However, Firefox 3.6, Chrome 7.0.517.44 and Safari 5.0.2 all render the sites
> with this problem correctly so this will be seen as a FireFox bug. And believe
> me, if it affects a site you use regularly it's enough to make you switch
> browsers. I think this needs looking into more, resolving it with WONTFIX would
> not be a good idea IMHO.

As I don't have access to the specific fonts involved, could you (or someone) dump the 'name' and 'OS/2' tables to verify exactly what metadata the fonts provide? You can use ttx (see http://www.letterror.com/code/ttx/index.html) for this, with a command such as "ttx -t "name" -t "OS/2" /path/to/gillsansultrabold.ttf".

Comment 15

[Michael Brown]

Attachment: "name" and "OS/2" tables for Gill Sans Ultra Bold TTF font

Comment 16

[Michael Brown]

Attachment: "name" and "OS/2" tables for Gill Sans Ultra Bold Condensed TTF font

Comment 17

[Michael Brown]

(In reply to comment #14)
> 
> DirectWrite is *always* used, regardless of this setting, if the browser is
> running in Direct2D mode (which is true by default in the latest betas).

OK, I didn't know that.

> As I don't have access to the specific fonts involved, could you (or someone)
> dump the 'name' and 'OS/2' tables to verify exactly what metadata the fonts
> provide? You can use ttx (see http://www.letterror.com/code/ttx/index.html) for
> this, with a command such as "ttx -t "name" -t "OS/2"
> /path/to/gillsansultrabold.ttf".

I've attached the .ttx files you requested for the two "Gill Sans" fonts that exist on my Windows 7 system: Gill Sans Ultra Bold and Gill Sans Ultra Bold Condensed. It is rather odd that the regular (and italic, bold etc) versions of Gill Sans are all called "Gill Sans MT" on Windows.

However, surely the font weight should take priority over the font family? So, if the style requests Gill Sans and regular weight, and all that is available is ultra bold then the next preferred font should be used. If this were the case then sites such as http://daringfireball.net/ would actually render correctly as the font style includes "Gill Sans MT" (font-family: 'Gill Sans', 'Gill Sans Std', 'Gill Sans MT', Verdana, 'Bitstream Vera Sans', sans-serif;).

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to comment #17)
> I've attached the .ttx files you requested for the two "Gill Sans" fonts that
> exist on my Windows 7 system: Gill Sans Ultra Bold and Gill Sans Ultra Bold
> Condensed. 

Thanks. I'm a bit puzzled by the DirectWrite behavior, in the light of this data: these fonts appear to have a "family name" (name id 1)  of "Gill Sans Ultra Bold" (and "... Condensed"), which I expected (so that GDI recognizes them as distinct from a regular, 4-face "Gill Sans" family), but they don't have a "preferred family name" (id 16) of "Gill Sans", which is what I thought DWrite would be using.

So it's unclear to me why these faces are treated as belonging to "Gill Sans", unless DWrite is somehow trying to amalgamate families using some heuristics to strip common "style" elements off the full name, in order to automatically consolidate families that were split up for GDI.

However, there's also another interesting piece of data here: the usWeightClass field of the OS/2 table is set to 400, which is the standard weight for a "Regular" face. So even if we tried to ensure that the selected font does not deviate "too far" from the requested weight, that wouldn't help in this case - the fonts claim to be normal weight, so we'd have no basis to reject them.

> It is rather odd that the regular (and italic, bold etc) versions of
> Gill Sans are all called "Gill Sans MT" on Windows.

Yes (see comment #9).

> However, surely the font weight should take priority over the font family? So,

No, the CSS algorithm (http://www.w3.org/TR/CSS2/fonts.html#algorithm) says that matching weight will never fail. So if any weight whatsoever is available in the first-requested family, it will be used.

> if the style requests Gill Sans and regular weight, and all that is available
> is ultra bold then the next preferred font should be used.

That's an interesting idea and might be worth exploring, although it contradicts the current CSS spec (and so it's a discussion that would need to take place in the CSS working group, not just in a mozilla bug). However, given that Gill Sans Ultra Bold declares its weight to be 400, it wouldn't help here!

Comment 19

[Michael Brown]

Attachment: test HTML file that illustrates the Gill Sans issue.

Comment 20

[Michael Brown]

I just did some interesting tests with the test HTML file I just attached (attachment 491852 [details]), which just displays a single line of text with the style "font-style: Gill Sans;font-weight: normal".

(In reply to comment 11)
> So hopefully both IE9 and a DirectWrite-enabled Firefox will treat font families the same way

That appears to be the case. Both IE9 preview 7 and FF4.0b7 display the text on the page in Gill Sans Ultra Bold. Interestingly however, Safari, Chrome, FF 3.6 and IE 8 all display the text in Times Roman (meaning they failed to find a Gill Sans font and used the HTML default).

(In reply to comment 18)
> So it's unclear to me why these faces are treated as belonging to "Gill Sans", unless DWrite is somehow trying to amalgamate families using some heuristics to strip common "style" elements off the full name, in order to automatically consolidate families that were split up for GDI.

If I open the C:\Windows\Fonts folder on my machine Windows shows me a "Gill Sans" font and a "Gill Sans MT" font. Opening either of these then shows their various variants, which in the case of "Gill Sans" are just "Ultra Bold" and "Ultra Bold Condensed". That would seem to indicate that some kind of amalgamation of families is going on.

(In reply to comment 11)
> evangelize authors to pay attention to their stylesheets. 
I'm not sure what authors could reasonably do, as this appears to be a problem with Windows fonts, and that they're now being used "correctly". Perhaps putting "Gill Sans MT" ahead of "Gill Sans" in the font-family list would work and not break things on non-Windows clients. Still, most "normal" users will still see this is as a Firefox (and IE9) bug.

Comment 21

[Doug Wright]

Over in bug 611855, a workaround was recently put into place on Mac for an incorrect font that Apple ships. Can the same thing be done here?

Comment 22

[John Daggett (:jtd)]

Attachment: name tables from Gill Sans MT fonts on Windows 7

I analyzed the Gill Sans MT fonts that Michael Brown has in his fonts folder.  I'm somewhat mystified as to why these are mapping to "Gill Sans", all of the fonts have family names beginning with "Gill Sans MT".

Comment 23

[John Daggett (:jtd)]

Attachment: text listing of all en-us family/style related names

Comment 24

[John Daggett (:jtd)]

GILLUBCD.TTF: <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
GILLUBCD.TTF:   Gill Sans Ultra Bold Condensed
GILLUBCD.TTF: <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
GILLUBCD.TTF:   Regular
GILLUBCD.TTF: <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
GILLUBCD.TTF:   Gill Sans Ultra Bold Condensed

GILSANUB.TTF: <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
GILSANUB.TTF:   Gill Sans Ultra Bold
GILSANUB.TTF: <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
GILSANUB.TTF:   Regular
GILSANUB.TTF: <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
GILSANUB.TTF:   Gill Sans Ultra Bold

Eeeek!  The cause of this bug appears to be the behavior of the font
name mapper on Windows 7.  I didn't realize this but it actively
*alters* the family names.  The documentation for this is in the "WPF
Font Selection Model" paper from MS:

  http://bit.ly/aJR0dZ

See pg. 6, in the section under "Build combined family and face name". 
Apparently the font mapper is sniffing the *family* name for things like
"Bold" and "Ultra Bold".  If it finds them it strips them off and
creates a new family.  So the two fonts above are grouped into "Gill
Sans" while other fonts in the family are grouped into Gill Sans MT:

  Gill Sans:
  GILSANUB.TTF - Gill Sans Ultra Bold
  GILLUBCD.TTF - Gill Sans Ultra Bold Condensed
  
  Gill Sans MT:
  GILBI___.TTF - Gill Sans MT Bold Italic
  GILB____.TTF - Gill Sans MT Bold Italic
  GILC____.TTF - Gill Sans MT Condensed
  GLSNECB.TTF  - Gill Sans MT Ext. Condensed Bold
  GILI____.TTF - Gill Sans MT Italic
  GIL_____.TTF - Gill Sans MT Regular
  
This is really an MS bug which should be fixed by shipping Ultra Bold
versions of Gill Sans using the Gill Sans MT names.

Another aspect of this is that it can also be fixed by setting bit 8 of
the fsSelection field of the OS/2 table.  Effectively this bit said
"don't mess with me please":

  http://www.microsoft.com/typography/otspec/os2.htm#fss

So there are a few options here:

1. Do nothing, suggest that MS Office team not ship incongruent font families
2. Explicitly disable the "Gill Sans" family
3. Simply treat "Gill Sans" as a substitute for "Gill Sans MT"

I created a pair of fonts that demonstrate the problem and a testcase
that uses them. View the page below and download the zipfile containing
two fonts.  Then quit and restart the browser.

  http://people.mozilla.org/~jdaggett/tests/gillsansproblem.html

The first font doesn't have fsSelection bit 8 set, the second one does.

Comment 25

[Jonathan Kew [:jfkthame]]

(In reply to comment #21)
> Over in bug 611855, a workaround was recently put into place on Mac for an
> incorrect font that Apple ships. Can the same thing be done here?

Possibly, though it may be tricky to find a workaround that doesn't risk interfering with correct pages. In principle, there's nothing to prevent someone having two entirely distinct families, Gill Sans and Gill Sans MT, each with its own collection of styles, and using them independently; it would then be wrong to amalgamate them. But we might decide that's a sufficiently marginal scenario that it's more important to hack around this problem.

Comment 26

[Michael Brown]

(In reply to comment #24)
> So there are a few options here:
> 
> 1. Do nothing, suggest that MS Office team not ship incongruent font families
As this bug also affects IE9, they might give this more urgency than otherwise, or the IE9 team might just fix the problem with a 'hack' of their own. Even if they do fix the font problem though, it will still take ages for this to filter through to all MS Office users. There needs to be a workaround until then.

> 2. Explicitly disable the "Gill Sans" family
> 3. Simply treat "Gill Sans" as a substitute for "Gill Sans MT"

Option 3 would be my preferred option, all though of course this would obviously have to be restricted to Windows systems only. On my Mac "Gill Sans" is a valid and 'correct' font.

(In reply to comment #25)
> In principle, there's nothing to prevent someone having two entirely
> distinct families, Gill Sans and Gill Sans MT, each with its own collection
> of styles, and using them independently

Yes, but as you suggested, in my opinion that's a scenario that's so marginal it's merely hypothetical and will never exist in reality.

Comment 29

[John Daggett (:jtd)]

Another example from bug 627270:

http://www.pbs.org/wgbh/pages/frontline/are-we-safer/reporting-the-story/

Comment 30

[Boris Zbarsky [:bzbarsky]]

Should we be making the duplicates into evangelism bugs?

Comment 31

[John Daggett (:jtd)]

(In reply to comment #30)
> Should we be making the duplicates into evangelism bugs?

Actually, I'm thinking we should implement a hack around this.  Basically, option (3) in comment 24, using this logic:

  if (family 'Gill Sans' exists and has only UltraBold faces) then
    map 'Gill Sans' to 'Gill Sans MT'

MS Office users will see something that roughly makes sense and anyone with a full version of Gill Sans (i.e. not a family whipped together by DirectWrite name swizzling) will see the page in their fonts.

I'd prefer not to implement hacks like this and I'm sure the same holds true for the IE guys but Gill Sans is used widely enough that I think this is probably something we should add.

The evangelism solution is to tell everyone who wants Gill Sans to use 'Gill Sans MT, Gill Sans' in their font lists.

Comment 32

[John Daggett (:jtd)]

Attachment: patch, hack to substitute Gill Sans MT when only Ultra Bold faces are present

Something like this.  Still needs testing and the diff is against my local queue so it won't apply cleanly.

Comment 33

[John Daggett (:jtd)]

Attachment: patch v2, substitute Gill Sans MT for Gill Sans when only Ultra Bold faces are present

Tested and confirmed with original fonts.

It sucks that we have to do this sort of thing but I think it's best for users.  Gill Sans is used commonly enough on the web that seeing pages rendered in the *really* ugly UltraBold faces would be a big problem for users.  And I don't expect a solution from MS that fixes the names in the fonts anytime soon.

Comment 34

[John Daggett (:jtd)]

MS is considering a slightly different workaround:

If Gill Sans family exists (in DWrite enumeration), and it only
contains Ultra Bold fonts then:

- Gill Sans family is hidden, page can’t match it.

- Even if there are no true Gill Sans MT fonts installed, Gill Sans MT
  family still “exists” and consists only of Gill Sans UB fonts.

- Members of Gill Sans UB are virtual members of Gill Sans MT, font
  matching code includes them into calculating best matching font within
  Gil Sans MT family.

- Although members of Gill Sans UB have regular weight specified in
  OS/2 table, they are treated as UltraBold.

Otherwise, Gill Sans is family on its own, with all fonts DWrite
thinks belong to it.

The primary difference is that with this approach, only Gill Sans MT would match but not Gill Sans, so pages designed to pick up the OSX Gill Sans would render just as they do in FF3.6/IE8 (i.e. when GDI font groupings are used).

Comment 35

[Jonathan Kew [:jfkthame]]

Comment on attachment 505697 [details] [diff] [review]
patch v2, substitute Gill Sans MT for Gill Sans when only Ultra Bold faces are present

>+        NS_NAMED_LITERAL_STRING(kGillSansUltraBold, "Gill Sans Ultra Bold");
>+        PRUint32 badNameLen = kGillSansUltraBold.Length();

This looks redundant; it's not used anywhere.

If we're going to do a hack for this - which I really dislike, but I suppose we have to - then I think we should do it a little differently. I don't have the MS Publisher fonts to check the behavior here, but it looks to me like this will effectively make the Ultra Bold weight inaccessible, which is less than ideal. Instead, I suggest that we "adopt" the Ultra Bold faces into the Gill Sans MT family (with weight 900), creating a blended family that we use for both the Gill Sans and Gill Sans MT names. I'll post a modified patch taking this approach.

Comment 36

[Jonathan Kew [:jfkthame]]

Attachment: patch, merge Gill Sans Ultra Bold faces into the Gill Sans MT family

Here's an alternative for consideration....

Comment 37

[John Daggett (:jtd)]

Attachment: alternate patch, add ultra bold faces to gill sans mt

Use the MS logic instead.  When both Gill Sans and Gill Sans MT are present as families, if all the faces of Gill Sans are "Ultra Bold", then add them to the Gill Sans MT family and remove the Gill Sans family.

Ironically, the PBS Frontline page also uses 'Franklin Gothic Medium' in the font list it displays Verdana rather than Franklin Gothic, which are displayed by FF3.6, Chrome and IE8.

Comment 38

[John Daggett (:jtd)]

heh, dueling patches...

Comment 39

[John Daggett (:jtd)]

Attachment: alternate patch, revised based on review comments

Revised based on comments, I think our patches are basically in alignment now.  I omitted the weight = 900 part, I don't think that's needed.  DirectWrite already assigns the font a weight of 800 which looks correct based on the OpenType spec defn of what "Ultra Bold" should map to.

I agree that hacks like this are extremely distasteful and a pain to maintain.  But the downside of this bug is really problematic and quite common unfortunately.

Comment 40

[Jonathan Kew [:jfkthame]]

Comment on attachment 506327 [details] [diff] [review]
alternate patch, revised based on review comments

>--- a/gfx/thebes/gfxFont.h
>+++ b/gfx/thebes/gfxFont.h
>@@ -494,6 +494,7 @@ public:
>     
>     void AddFontEntry(nsRefPtr<gfxFontEntry> aFontEntry) {
>         mAvailableFonts.AppendElement(aFontEntry);
>+        aFontEntry->SetFamily(this);
>     }

It makes sense to do this, but in that case you should also remove the now-redundant to fe->SetFamily() at http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxFT2FontList.cpp#144. Also note that this will cause the mFamily field to be set in font entries for some cases where we aren't currently bothering to set it. That should be harmless, I think, but it's something to keep in mind if anything weird happens on some other platform!

Remaining question: should we add the mFontSubstitutes entry so that Gill Sans -> Gill Sans MT? I'm not convinced by the argument from PBS Frontline ("designer expects Gill Sans for Mac users, Franklin Gothic for PC users"); I'd read that font stack as "designer prefers Gill Sans if available; Franklin Gothic is the next best". ISTM that if we're merging the Gill Sans Ultra Bold faces into Gill Sans MT, this is in effect an acknowledgement that the two families are interchangeable, and if that's the case then we should render Gill Sans [MT] whichever name the page used. Skipping the merged Gill Sans [MT] family entirely on a page that requests "Gill Sans" seems wrong to me.

Comment 41

[John Daggett (:jtd)]

Attachment: alternate patch, move Gills Sans Ultra Bold faces to Gill Sans MT

Removed redundant calls to SetFamily.

Comment 42

[John Daggett (:jtd)]

As to whether to add 'Gill Sans' as a substitute for 'Gill Sans MT', I can see the case for doing this, and that's what my original patch did, but now I think it would be better not to do this.

The underlying reason for fixing this with a hard-coded hack is to avoid a single pathological case (i.e. a site designed for Gill Sans ends up displaying in Ultra Bold).  In general I think we should avoid manually added substitutions like this, if for no other reason than IE9 is not going to do this and we'd make things difficult for web authors that way.

Comment 43

[John Daggett (:jtd)]

Comment from MS: 

"My understanding here is that we are "fixing bug" in name table of two particular fonts. Adding virtual Gill Sans family is out of scope and orthogonal of this fix."

Comment 44

[Joe Drew (not getting mail)]

Comment on attachment 506660 [details] [diff] [review]
alternate patch, move Gills Sans Ultra Bold faces to Gill Sans MT

frigging gill sans

Comment 45

[John Daggett (:jtd)]

Landed on trunk
http://hg.mozilla.org/mozilla-central/rev/4ece1ca8430d