Closed
Bug 584769
Opened 14 years ago
Closed 10 years ago
[dwrite] Arial Black doesn't match properly
Categories
(Core :: Graphics, defect)
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>
Comment 1•14 years ago
|
||
(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?
Reporter | ||
Comment 2•14 years ago
|
||
For the record, IE 9 properly uses Arial Black
Comment 3•14 years ago
|
||
To me this looks like it's not even using the normal Arial font. I think it's using a fallback font.
Comment 4•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
(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.
Comment 6•14 years ago
|
||
(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]
Updated•14 years ago
|
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?
Comment 8•14 years ago
|
||
(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 :).
Comment 9•14 years ago
|
||
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).
Comment 10•14 years ago
|
||
(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.
Comment 11•14 years ago
|
||
(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.
Comment 14•13 years ago
|
||
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...
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 15•13 years ago
|
||
So John, are we going to add a hack or not? :)
Updated•12 years ago
|
QA Contact: thebes → jdaggett
Updated•11 years ago
|
Flags: needinfo?(jdaggett)
Comment 16•10 years ago
|
||
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 ago → 10 years ago
Flags: needinfo?(jdaggett)
Resolution: --- → INVALID
Updated•4 years ago
|
Resolution: INVALID → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•