It's great that nglayout supports small-caps. I propose tweaking the scaling factor -- when generating small-caps from caps -- slightly. As it stands, I find the nglayout scaling factor to be too small. I perfer the scaling factor OPera 3.50 use. See section (9) of the test page for an example. This has nothing to do with conformance and you should have enogh typographers in place to find the best factor.

I [todd fahrner] agree that the synthetics are too small - looks like you're using .5em. I think you'll have better results visually with .67 or .75em - might even embolden the downscaled guys to maintain consistent weight with the capped cap

Looking at small-caps as used in the "real world", e.g. in printed publications and on TV, it would seem that 0.67 is the scale factor most frequently used. Also, the small letters are indeed usually boldened a little, as Todd suggests, so that the visual effect is that the small caps look like they have the same weight as the big caps.

Actually, the small caps are .70em (and always have been)

Actually, having had a closer look, the size of the letters looks ok. It's the boldening thing that is making it look bad. See, for example, the level 2 headers in: http://www.bath.ac.uk/%7Epy8ieh/internet/html40/

Moving non-beta 1 items to M15

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

The handling of NS_STYLE_FONT_VARIANT_SMALL_CAPS is done in nsTextFrame.cpp. Reassigning to mjudge who seems to have worked on that file lately. If you need some help, you may want to contact Don Cone <dcone> has some cross- platform experience in gfx & fonts.

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Nominating nsbeta2,nsbeta3,rtm. Recc. nsbeta2+, falling through to nsbeta3+ and rtm+ if necessary. This is a W3C CSS1 Official Test Suite compliance bug. Changing severity to normal.

Sorry, to clarify: this is not an nsbeta2 stopper, but I'd permit checking in prior to nsbeta2 if we have a fix. Recc. nsbeta2+[some lenient date-], falling through to nsbeta3+ hard stop if not fixed during nsbeta2. This is a W3C CSS1 Official Test Suite compliance bug.

PDT needs info for nsbeta2 evaluation: is this a conformance issue or not? The reporter's comments say it's not, but Eric's comments on 6/14 says it is.

Putting on [nsbeta2-] radar. Not critical to beta2. ekrock at bug triage mtg and agreed.

This isn't *really* a conformancs issue, but it looks so ugly the way we have it that we *really* don't want to ship with it. It's a high-priority polish issue, I guess.

per beppe, reassigning back to pierre i thought this was dup of bug 13348. on closer look this has nothing to do with anything i know about. This really is a layout issue only.

Per meeting with ChrisD, taking QA.

See my comments from [2000-03-18 23:48] in bug 32252: the scaling factor has been increased and small-caps are now displayed identically in MacIE5 and Mozilla. *** This bug has been marked as a duplicate of 32252 ***

Ooooh! Pret-ty. Cheers Pierre! :-)