Closed Bug 584769 Opened 14 years ago Closed 10 years ago

[dwrite] Arial Black doesn't match properly

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 835204

People

(Reporter: jrmuizel, Unassigned)

References

Details

The following page displays using a different font with direct write than GDI

<p style="font: 130px Arial Black">.<br>
(In reply to comment #0)
> The following page displays using a different font with direct write than GDI
> 
> <p style="font: 130px Arial Black">.<br>

I believe Arial Black is a seperate font on GDI, while it's just an Arial face on DirectWrite. I thought the latter was correct. Johnathan, does this have anything to do with what's going on here?
For the record, IE 9 properly uses Arial Black
To me this looks like it's not even using the normal Arial font. I think it's using a fallback font.
So I think the problem here is that Arial Black is not a font. It doesn't exist, it's a face name, local-src should find it since it does face name look-up, but I'm guessing normal font look-up doesn't. I wonder if we should go for backward compatibility or if we should evangelize the correct usage or using a very heavy weight Arial font to get the Arial Black face.

I believe IE9 at some point didn't use DirectWrite for font lookups yet but they were working on that, I wonder if that's already in or not. And if they chose to go for backward compatibility?

I'll let jfkthame and jdaggett decide what the correct approach is here.
(In reply to comment #4)
> So I think the problem here is that Arial Black is not a font. It doesn't
> exist, it's a face name, local-src should find it since it does face name
> look-up, but I'm guessing normal font look-up doesn't. I wonder if we should go
> for backward compatibility or if we should evangelize the correct usage or
> using a very heavy weight Arial font to get the Arial Black face.
> 
> I believe IE9 at some point didn't use DirectWrite for font lookups yet but
> they were working on that, I wonder if that's already in or not. And if they
> chose to go for backward compatibility?
> 
> I'll let jfkthame and jdaggett decide what the correct approach is here.

Personally, I'd prefer to use the "proper" (DirectWrite-style) family names, rather than perpetuating the GDI limitation of 4 faces per family, and splitting out extra pseudo-families when a font family has a larger number of weights/styles/etc.
(In reply to comment #2)
> For the record, IE 9 properly uses Arial Black

Not completely correct.  There are two problems here:

(1) GDI uses the family name (name ID 1) to group families which are restricted to four basic faces per family.  Under Vista/Win7, Windows groups fonts based on the Weight-width-slope family name (name ID 21) and this is what DirectWrite supports.  The net effect of this is that Arial Black is treated as a separate family when GDI-style groupings are used and as a separate weight of Arial when DirectWrite-style groupings are used.

Look in your fonts folder, under Windows 7 there's no family called "Arial Black".  Double-click on icon for the Arial family and there you'll find five faces, one labeled "Arial Black".

(2) Browsers that use GDI typically use CreateFontIndirect which matches more than just simple family names, it matches (a) fullnames (e.g. Arial Bold) for TrueType (.ttf) fonts and (b) Postscript names (e.g. Helvetica-BoldOblique) for Postscript CFF (.otf) fonts.  The result is all sorts of things that are *not* family names will improperly match.

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

Safari/Chrome on OSX has a similar problem, they match Postscript names.  Firefox 3.6.x has the same problem under Windows but it's fixed on trunk.

I've also added an explicit testcase for problem (2) to the CSS 2.1 test suite, we'll see if Microsoft or Apple pushes back on it.

Since Arial Black is the only font among system fonts that's affected by this, we could hard-code hacks that map 'Arial Black' to 'Arial' but I'd prefer to avoid doing this.

I suggest we mark this INVALID.

[See also the discussion in bug 550128]
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
I am having issues on Firefox4 beta6 (winVista32bit) with regards to this issue,
namely firefox 3.6.10 and ie8 render this page:
http://empty-sky.net/font-test.html the way I expect them to.
However ff4beta6 seems to ignore my request for 'arial black'.
Does marking this as invalid mean that i won't be able to call on the arial black font? (if it is not a font, but a variant, do i go font-weight: {black|normal|bold|bolder|lighter} ?) Is there a followup discussion I should be following?
(In reply to comment #7)
> I am having issues on Firefox4 beta6 (winVista32bit) with regards to this
> issue,
> namely firefox 3.6.10 and ie8 render this page:
> http://empty-sky.net/font-test.html the way I expect them to.
> However ff4beta6 seems to ignore my request for 'arial black'.
> Does marking this as invalid mean that i won't be able to call on the arial
> black font? (if it is not a font, but a variant, do i go font-weight:
> {black|normal|bold|bolder|lighter} ?) Is there a followup discussion I should
> be following?

You should go for font weight, font-weight 600 will probably get you Arial Black. Maybe 700. Family should just be Arial. I think so anyway :).
I'm not at the right machine to confirm this just now, but I'd expect "font-weight: 700" to give you Arial Bold, not Black, as 700 is the "standard" value for Bold. To get Arial Black, I'd suggest trying "font-weight: 900" (and "font-family: Arial", of course).
(In reply to comment #9)
> I'm not at the right machine to confirm this just now, but I'd expect
> "font-weight: 700" to give you Arial Bold, not Black, as 700 is the "standard"
> value for Bold. To get Arial Black, I'd suggest trying "font-weight: 900" (and
> "font-family: Arial", of course).

You are right it seems, 900 is what you want.
(In reply to comment #7)
> Does marking this as invalid mean that i won't be able to call on
> the arial black font? (if it is not a font, but a variant, do i go
> font-weight: {black|normal|bold|bolder|lighter} ?) Is there a
> followup discussion I should be following?

The simplest way to cover all your bases in all browsers is to use
something like this:

  font-family: Arial Black, Arial;
  font-weight: 900;

This will give you the black face of Arial on Win7, WinXP, and OSX across all browsers.
It looks like IE9 has added a compatibility hack to *also* support the use of "Arial Black" and "Arial Narrow".

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

Note that extra bold weights for Arial that are the same as Arial Black.

I think we may need to consider something along the same lines for these two families, so that authors don't have to deal with browser inconsistency.  Ick, ack, patooey...
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Blocks: 644385
Blocks: 604991
Blocks: 644162
Blocks: 649941
No longer blocks: 649941
So John, are we going to add a hack or not? :)
QA Contact: thebes → jdaggett
Flags: needinfo?(jdaggett)
I don't think we should add this hack at this point. Chrome has recently enabled DirectWrite and they are using the system font collection without modification. They are not adding in the additional name swizzling that IE has added.

It would be much better if authors used CSS styles that work across platforms. In this case, the style rules below are a better way to select the black face of Arial:

  .useArialBlack {
    font-family: Arial Black, Arial, sans-serif;
    font-weight: 900;
  }

This will select the black face of Arial independent of whether the platform is OSX, Win/GDI or Win/DirectWrite and the same font will be used by all user agents in environments where this font is available.

I'm going to resolve this as invalid. If Chrome adds an IE-like hack, we'll reconsider.
Status: REOPENED → RESOLVED
Closed: 14 years ago10 years ago
Flags: needinfo?(jdaggett)
Resolution: --- → INVALID
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.