This is split from bug 94319 From bug 94319: >------- Additional Comment #58 From David Baron 2002-10-18 05:54 ------- > >(From update of attachment 103298 [details] [diff] [review]) >This isn't going to work right since: > > 1) In the current style system code the variant isn't treated as a bitmask, >but rather as a value. > 2) Other rule mapping functions that sent the font family would need to set >something that says the symbol-font hack should be undone, so that the >CSS-specified fonts in the descendants of a FONT element wouldn't be treated >incorrectly. > >Essentially, that means that while it would be possible to use the mVariant >value in the style struct (set in nsRuleNode::ComputeFontData), it's not >acceptable to use it in the rule struct (nsCSSFont), and you need to add a new >value. need a new value in nsCSSFont to indicate the fontFamily is set by HTML FONT element instead from css and pass from nsHTMLFontElement to GFX

make 94319 blocked by this. Put topembed on this bug too since this is blocking a topembed bug.

from bug 94319: >------- Additional Comment #63 From David Baron 2002-10-18 12:35 ------- > >Adding a new bit and making font-variant a bitmask will not cascade correctly, >which will cause some CSS-specified fonts to be broken, as I said in my previous >comment. That is a very good point. I think neither shanjian nor me are experts in the StyleSystem. It will be nice if you can solve this infrastructure work for us. Does that make sense ?

testcase provided with attachment 103298 [details] [diff] [review].

Whatever is done for this should also remove the Wingdings hack, and should be enabled in the Mozilla trunk.

This is untested. Most of the patch is search-replace since I implemented what's described in bug 105199 comment 43 for all structs, since it's a general problem and it's also something I need to do to make progress for other things.

(This patch propagates whether the font-family is set up to the style structs, i.e, nsStyleFont.)

dbaron- could you tell us with your changes. How could we tell gfx the setting of font name is from nsHTMLFontElement instead of CSS?

dbaron- ETA?

Probably the cleanest way to pass the information from layout through to gfx would be to make nsFont's mVariant only take up 7 bits (using a field width) and add a one-bit PRPackedBool mFamilyFromHTML to it as well. Do you want me to land it too? I was expecting you to take this patch and incorporate it into your changes. After all, it's a bad precedent to set to force reviewers to write code to meet their review comments (we've been through this debate before), and I probably shouldn't even have written the patch in the first palce. I am willing to land it in this case, though.

Revised to put the value in the nsFont object instead of within the nsStyleFont but not within the nsStyleStruct. Compiled but not tested.

dbaron, it will be great if you can land this patch. The purpose why frank filed this bug is treated as a separated issue, and you are better person than us to handle issue in CSS area.

This differs from the previous version only in the removal of an obsolete comment from nsCSSDeclaration.h. This patch does two things: * subclasses nsCSS* to nsRuleData*, and moves members not used for CSS stylesheets (one existing one, and one new one below) into the nsRuleData*. This will also make it easier to reorganize the CSS stylesheet backend in the future, and to allow new pieces of information to propagate through the style system without adding extra bloat. * Propagates the information of whether the font family name comes from the face attribute of the font element through CSS cascading, and then sets a new member variable of nsFont to request family name quirks if the name is from HTML and we are in quirks mode.

Comment on attachment 105520 [details] [diff] [review] patch sr=kin@netscape.com

Comment on attachment 105520 [details] [diff] [review] patch + aFont->mFont.familyNameQuirks = (compat == eCompatibility_NavQuirks) + ? aFontData.mFamilyFromHTML + : PR_FALSE; Would this be clearer as: aFont->mFont.familyNameQuirks = (compat == eCompatibility_NavQuirks) && aFontData.mFamilyFromHTML; ? Your call either way.

Fix checked in to trunk, 2002-11-12 07:16/17 PDT.

verifying based on comments