Using 3/8 build on Win 95, Win 98, Win NT, Linux and 3/3 build on Mac 8.5. Open URL. Expected result: The first sentence should have a wider font than the second. Actual result: Font in the first sentence displays the same as font in the second sentence. This behavior is the same for all other values of font-stretch: narrower, ultra-condensed, extra-condensed, condensed, semi-condensed, semi-expanded, expanded, extra-expanded, and ultra-expanded.

CSS2 feature that was never promised. Don't know if font code can even deal with it.

Is this a WONTFIX?

Pushing off non-beta 1 issues

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

See comments in #4101 that will be closed as dup.

*** Bug 4101 has been marked as a duplicate of this bug. ***

Pushing my M15 bugs to M16

Migrating from {css2} to css2 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...

As described in bug 4101, we need to pass the info to nsFont, then we'll see if it can be implemented on the different platforms. Nothing critical: M19.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Testcase: http://www.people.fas.harvard.edu/~dbaron/css/test/sec150203d

Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.

This would be very cool to have! BTW, does anyone know if the IE6 beta's support this? Mozilla *has* to if IE6 does. Can't be outdone :-) jake

hoju: Are you saying that if IE6 implements this you are willing to contribute the resources to implement this as well? Or is that just your opinion?

removing myself from the cc list

*** Bug 134936 has been marked as a duplicate of this bug. ***

ATSUI (see bug 121540) provides some enhanced font weight functionality for Mac OS X.

(Strike weight, make that stretch.)

Assigning pierre's remaining Style System-related bugs to myself.

This feature should automatically use real corresponding font variants if available. For example, "font-family: 'Helvetica'; font-stretch: condensed;" should cause Mozilla to use the real Helvetica Condensed font if available. FizzillaCFM/2002100308 doesn't do so.

*** Bug 186900 has been marked as a duplicate of this bug. ***

*** Bug 263670 has been marked as a duplicate of this bug. ***

Note that font-stretch is not in CSS2.1 (though it is still in CSS3 Fonts).

I've made sample fonts if you need to test the stretch feature http://home.sus.mcgill.ca/~moyogo/fonts/test/stretchtest.html Does anybody have this bug in their todo list?

This "bug" (really a feature-request) has been around for 9 years. It's clear that font-stretching as a *general* mechanism isn't feasible with existing font rendering technology. But web designers would be very happy to have a quite limited feature: being able to specify that a condensed font is to be used. As comment #23 pointed out, "font-stretch: condensed" will do fine. But the browser has to then provide, not an artificially condensed version of a font, but an actual condensed font such as Helvetica Condensed or Arial Narrow. The user could choose the condensed font to be used as the default in the Advanced Fonts window. This would be extremely useful to web designers and I'd think quite straightforward to implement.

(In reply to comment #28) > This "bug" (really a feature-request) has been around for 9 years. It's clear > that font-stretching as a *general* mechanism isn't feasible with existing font > rendering technology. But web designers would be very happy to have a quite > limited feature: being able to specify that a condensed font is to be used. As > comment #23 pointed out, "font-stretch: condensed" will do fine. But the > browser has to then provide, not an artificially condensed version of a font, > but an actual condensed font such as Helvetica Condensed or Arial Narrow. The > user could choose the condensed font to be used as the default in the Advanced > Fonts window. This would be extremely useful to web designers and I'd think > quite straightforward to implement. > Not quite, since this needs to apply per family. Your solution appers to presume it would only be used with default/builtin families, or that it would change the font family. It is impractical to ask the user for the font face because: 1. My grandma doesn't know that fonts have faces, ears, eyes, or even noses. 2. Burdening the user with this means many would have no choice selected, which for all intents and purposes means nothing has been solved. 3. Users can't be expected to select a condensed font per family, it is too difficult. I suspect this problem isn't receiving much attention because it isn't widely used, you can just use the 'xyz condensed' family most of the time, no other browsers support it, and the fix is probably os dependent. It would still be nice though. -[Unknown]

"this needs to apply per family" Why? The web designer simply wants to specify, say, a condensed sans serif font. It doesn't have to match a non-condensed font used elsewhere. Think of "condensed" as analogous to "monospaced". "you can just use the 'xyz condensed' family most of the time" On Linux there is only one condensed font that one can expect is always available: Nimbus Sans L Condensed (a clone of Helvetica Condensed). Unfortunately, Firefox doesn't even allow the user to choose this font, much less use it automatically if "font-stretch: condensed" is specified, nor even if font-family: "Nimbus Sans L Condensed" is specified. Now do you see why something has to be done about this? Web pages that use a condensed sans font can't possibly be rendered properly in Linux, no matter what the web designer specifies. Please, at least fix this in the Linux version of Firefox.

The question is whether font-stretch is more like font-style (normal / oblique / italic) or font-weight (normal / bold / etc.). For font-style if the font-family given doesn't have an italic font, the family is supposed to lose. For font-weight, the closest weight available is chosen. The CSS2 spec (which describes font-stretch) doesn't say anything at all, but I suspect font-stretch ought to act more like font-weight (in other words, I agree with comment 29). (See http://www.w3.org/TR/CSS21/fonts.html#algorithm for the most current work, but in a spec that doesn't have font stretch. Also see http://www.w3.org/TR/css3-fonts/#font-properties and http://www.w3.org/TR/1998/REC-CSS2-19980512/fonts.html#algorithm although neither answers the question despite the specs having font-stretch. I haven't actually checked if any of this is how things really work.) That said, implementing it would let authors get to fonts that they can't currently get to, and we probably should do so for that reason. But it's not a top priority (which bug was filed first doesn't imply which bug is more important to fix), and we generally try to avoid implementing things on only one platform.

So maybe font-stretch is a red herring. Surely the failure of Firefox on Linux to recognize Nimbus Sans L Condensed is a *bug*. (I originally thought it was in fontconfig, but it's not.) If web authors could specify it in a font-family list and Firefox would respect that request, a serious deficiency could be fixed. Should I file a separate bug report?

(In reply to comment #32) > So maybe font-stretch is a red herring. It's not. font-stretch is the only standardised way to select a condensed font reliably (cross-platform and future-proof). > Surely the failure of Firefox on Linux to recognize Nimbus Sans L Condensed > is a *bug*. If it does not appear in Firefox dialogs that would be a bug all right (I thought this had been fixed, but Firefox definitely assumes in places you have font family, then regular/bold/italic/bold italic, when the font reality is more complex than that. And fonts that take advantage of this complexity are not limited to expensive niche designer font libraries anymore). > If web authors could specify it in a font-family > list and Firefox would respect that request, Even if it did appear that would not make it selectable in CSS by web authors. Because the font family is not "Nimbus Sans L Condensed" but "Nimbus Sans L", with the "Condensed" variant, so the font family selector won't work. Many condensed fonts are like that and "Arial Narrow" (where Narrow is actually part of the family name) is far from representative. It's sad that this font (which has never been distributed on free/open platforms, and not even been part of the "core fonts for the web" free-beer-download operation, is used as argument to delay implementing font-stretch. IIRC the Behdad of Pango fame had found some documents that described the font selection algorithm used by Microsoft for OpenType fonts, and intended to closely follow it pango/fontconfig side. This logic should probably apply to CSS font selectors if there is any ambiguïty in the w3c specs.

See also http://bugs.webkit.org/show_bug.cgi?id=12530#c11

(In reply to comment #33) > (In reply to comment #32) > > If web authors could specify it in a font-family > > list and Firefox would respect that request, > Even if it did appear that would not make it selectable in CSS by web authors. > Because the font family is not "Nimbus Sans L Condensed" but "Nimbus Sans L", > with the "Condensed" variant, so the font family selector won't work. Nimbus Sans L Condensed is a valid family name, and so can be specified and served by Gecko. It's just not present on most Linux systems like the condensed variant of Nimbus Sans L is. See e.g. https://bugzilla.novell.com/show_bug.cgi?id=367188

I'm going to try to reword and summarise the problem there. 1. When software was young fonts were sparse and their format limitative. One typically had different font files and names per encoding and variant of the same font, and all those files exposed different font family names. Applications manipulating formatted text just had to expose a raw font family list to users, and make minimal effort to regroup the most frequent variants/faces (regular, bold, bold italic, italic) together. Font users browsed the raw font name list and selected the right font file directly. Everyone knew the Microsoft font list (for example, use Aral Black for an heavy font, use Arial Narrow for a condensed one). 2. Strong demand from artists led to creation of more complex fonts and font formats. Modern fonts are no longer limited encoding-wise, faces are no longer limited to regular, bold, bold italic, italic, and more critically they're no longer exposed under different font names. All the faces declare the same font name, and software is expected to provide users ways to select the face they want. 3. Those complex fonts were at first limited to expensive font collections, but are now being commodized 4. After the success of its "core fonts for the web" initiative Microsoft decided to use its new fonts as a commercial argument. So they're no longer freely distributed, and alternatives to Windows, IE and Office need to propose their own font offerings. Since font names are protected, that means exposing users to new font lists, where the workarounds they learnt in 1. no longer apply. It is therefore becoming critical to revamp the font selection mechanisms of FLOSS apps so : 1. they can expose to users all the faces of the complex fonts which are now getting widely distributed 2. they can help them use non-Microsoft font libraries, so they don't run back to Microsoft products just because they can't manage anything but the commercial fonts it bundles with its offerings Fortunately the technical analysis has already been done as part of W3C OpenType and probably other specifications. Selecting the right face inside a font family depends on three parameters: 1. font slant (font-style, FontStyle): normal, italic, oblique... 2. font weight (font-weight, FontWeight): normal, bold, light... 3. font stretch (font-stretch, FontStretch): normal, condensed, expanded... This classification is adopted by every major actor: http://www.w3.org/TR/css3-fonts/#font-styling (Web) http://blogs.msdn.com/text/attachment/2249036.ashx (Windows) http://fontconfig.org/fontconfig-user.html (Unix/Linux) Firefox is not implementing the third CSS axis right now. That means it can not browse the full font universe, and effectively pushes its users to use fonts distributed on the Windows platform at a time font family games were the only way to expose stretch. This kind of indirect dependency on an editor which has no love lost for Firefox is not good for Firefox users, not good for the Free web the Mozilla foundation wants to promote, and therefore not good for Firefox itself.

Nicolas and I have disagreed about some simple short-term fixes for this on the Linux platform (which doesn't involve FF). But he's claimed that a short-term fix will contribute to deferring implementation of a long-term general solution of this problem on Firefox. So let me say that I do support implementation of font-stretch ASAP (though I wish a less misleading term such as "font-width" had been used). Bob T.

Discussion about whether we should implement a temporary hack to allow these fonts to be specified does not belong in a bug about implementing the permanent solution.

Given the wider prevalence of condensed/expanded faces on platforms like Mac OS X and the increasing number of open source fonts like the Deja Vu family which contain condensed/expanded faces, I'm going to bump up the priority of this one. Without this attribute these faces are effectively unusable, since no combination of font-xxx attributes will resolve to a condensed face if a normal face is around. On Windows, where font families are currently unified using the "four faces per family" rule, the font-family attribute can be used but this doesn't work when name unification is done to include a fuller set of faces within a single font family, as is done under Mac OS X. Stuart says he has a work-in-progress patch.

Here's a patch that gets this through the style system (it was already half-implemented) so you guys have something to test with. This passes style system mochitests, but the "FIXME" comments should really be fixed before landing. (I used the existing constant structure in layout/base/nsStyleConsts.h, which may not be ideal, but it should work.)

Er, missed one thing that's important for handling dynamic changes.

this mostly implements font-stretch on windows. narrower and wider aren't supported yet and there are some bugs. this doesn't do any kind of synthetic width stuff so you have to have font families with various widths installed for it to work.

So, for what it's worth, the patch here has the same issue with narrower and wider that we have with bolder and lighter for font-weight; we really need to store an ordered list of narrower/wider values if we want to get this correct relative to the fonts available, on a per-character basis. So if we fix one, we might want to fix the other at the same time.

There are nine base font-stretches, just as there are nine base font-weights. Thus, how about encoding the ordered list in both cases as an ASCII string, with this format: the first character is always a digit '1' ... '9', which is mapped to a font-weight or font-stretch in the obvious fashion, and subsequent characters are either '+' (meaning "bolder" or "wider") or '-' (meaning "lighter" or "narrower"). This is easy to process and also conveniently human-readable in debugging dumps. Won't do for getComputedStyle, but we're supposed to propagate gfx's actual choice of font back up for that anyway. And we already hang other strings off style structs, so it shouldn't be a memory management headache.

marking wanted1.9.1? to get this in the triage queue.

(In reply to comment #43) > So, for what it's worth, the patch here has the same issue with narrower and > wider that we have with bolder and lighter for font-weight; we really need to > store an ordered list of narrower/wider values if we want to get this correct > relative to the fonts available, on a per-character basis. So if we fix one, > we might want to fix the other at the same time. That's actually what we do for bolder/lighter, at least on Mac/Windows. The real tricky part of the problem is dealing with synthetic bold because you need to know whether a face was available for "weight + n steps of bolder" when deciding whether to enable synthetic bold or not, as in the inner-most span below: Font family: Bongo (two weights 200, 400) .base { font-family: Bongo; font-weight: 200; } .b { font-weight: bolder; } <p class=base>Should be light face <span class=b>with regular face <span class=b>and synthetic bolded regular face</span> </span> </p> So for font-stretch we may have to deal with the same issues if we're going to do synthesized condensed/expanded (Stuart is in favor, I'm on the fence). As for the numbers, we probably need to pass around relative widths also (e.g. 501 for "normal + 1 step wider") as we do for font-weight.

This patch does a similar encoding to font-weight; that's actually broken when bolder and lighter are used in combination (i.e., bolder on something where the parent is lighter, etc.); an ordered list is required to get those cases right. See some of the discussion in bug 93725.

The problem with a single-number coding scheme like "501 = normal + 1 step (wider/bolder)" is that wider/narrower, like bolder/lighter, are required to make a change if they can. So, consider <span style="font-stretch: normal">a <span style="font-stretch: wider">b <span style="font-stretch: narrower">c </span></span></span> Suppose that the font family for this entire thing has two widths: normal and condensed. (Pretty common.) Then the spec says "a" and "b" should be rendered at normal width, and "c" at condensed width. But with a single-number scheme, the style for "c" is indistinguishable from the style for "a".

(In reply to comment #48) Hmmm, what spec defines this? Are you using the wording for font-weight from the 2.1 spec to infer how font-stretch works? I would argue that for your example a and c should render the same no matter what font faces were available. I could definitely see how one might interpret the 2.1 font-weight description to infer the behavior in your example. Damn spec writers. ;)

I am reading between the lines of http://www.w3.org/TR/css3-fonts/#font-stretch a bit, but I would argue that "next (expanded|condensed) value [from] the inherited value" does imply the behavior I described, and also I would argue that it would be bizarre if font-stretch worked differently from font-weight.

(In reply to comment #50) I totally agree that wider/narrower should work the same as bolder/lighter. I'm not sure I agree with how you are interpreting the spec though but I can definitely see the ambiguity in the way font-weight is defined in the 2.1 spec. This is something we should get cleared up with the 2.1 spec and describe more clearly in the CSS3 Fonts spec.

(In reply to comment #51) > I'm not sure I agree with how you are interpreting the spec though For the record, I totally agree the spec can be read your way I should point out that "my" interpretation is actually Ian Hickson's; see the test case attached to bug 93725.

If that can help disambiguate the W3C spec do not forget stretch properties are also discussed in other documents such as http://blogs.msdn.com/text/attachment/2249036.ashx

This is updated to have a change I missed in nsThebesDeviceContext (missing that change was causing valgrind warnings) and to use SetDiscrete.

So I want to get the part that I've already done landed. Here's a pre-patch that fixes the problem that we have font constants defined in multiple places. I decided not to do any search-and-replace, given that there are some big patches other people have floating around. (I've adjusted the main patch to add to this file.)

Here's the main style system patch updated, with the constructors fixed, which let me find some other places that needed to be patched. I've put some "FIXMEs" in gfx where they were obvious, but I'm sure a lot more things are needed. Requesting review from bzbarsky for the layout/* code and vlad for everything else; jdaggett is also welcome to review if he wants.

Comment on attachment 358121 [details] [diff] [review] patch for style system computation and adding stretch to gfx structures Looks fine to me, though maybe add in something grep-able into the comments for the obsolete constants, so that we can periodically do a grep across the tree and fix as needed?

Comment on attachment 358121 [details] [diff] [review] patch for style system computation and adding stretch to gfx structures >+++ b/gfx/src/nsFont.cpp > nsFont::nsFont(const char* aName, PRUint8 aStyle, PRUint8 aVariant, Might be worth it to move these constructors to initializer syntax, maybe. That can be a separate patch, of course. >+++ b/gfx/thebes/public/gfxFontConstants.h >+#define NS_FONT_STRETCH_ULTRA_CONDENSED -4 >+#define NS_FONT_STRETCH_EXTRA_CONDENSED -3 >+#define NS_FONT_STRETCH_CONDENSED -2 >+#define NS_FONT_STRETCH_SEMI_CONDENSED -1 >+#define NS_FONT_STRETCH_NORMAL 0 >+#define NS_FONT_STRETCH_SEMI_EXPANDED 1 >+#define NS_FONT_STRETCH_EXPANDED 2 >+#define NS_FONT_STRETCH_EXTRA_EXPANDED 3 >+#define NS_FONT_STRETCH_ULTRA_EXPANDED 4 >+#define NS_FONT_STRETCH_WIDER 10 >+#define NS_FONT_STRETCH_NARROWER -10 Document or PR_STATIC_ASSERT that WIDER needs to be > ULTRA_EXPANDED - ULTRA_CONDENSED (or rather the min and max "normal" values of font-stretch) and that NARROWER needs to be -WIDER? I assume it does so that we can tell apart ULTRA_CONDENSED+WIDER and other values. >+++ b/layout/style/nsComputedDOMStyle.cpp >+nsComputedDOMStyle::GetFontStretch(nsIDOMCSSValue** aValue) >+ PR_STATIC_ASSERT(NS_FONT_STRETCH_NARROWER == -10); >+ PR_STATIC_ASSERT(NS_FONT_STRETCH_WIDER == 10); How about: PR_STATIC_ASSERT(NS_FONT_STRETCH_NARROWER % 2 == 0); PR_STATIC_ASSERT(NS_FONT_STRETCH_WIDER % 2 == 0); >+ } else if (stretch <= -5) { ... >+ } else if (stretch >= 5) { And make that |stretch <= NS_FONT_STRETCH_NARROWER / 2| and |stretch >= NS_FONT_STRETCH_WIDER / 2| ? That looks like it should be eqivalent given the range asserts in the header, right? Alternately, if we had a FONT_STRETCH_MIN/MAX declared in the header we could compare to them here (with strict < and >, presumably). sr=bzbarsky with the nits.

(In reply to comment #58) > Document or PR_STATIC_ASSERT that WIDER needs to be > ULTRA_EXPANDED - > ULTRA_CONDENSED (or rather the min and max "normal" values of font-stretch) and > that NARROWER needs to be -WIDER? I assume it does so that we can tell apart > ULTRA_CONDENSED+WIDER and other values. I'll go with the "document" primarily because using PR_STATIC_ASSERT in header files is a real mess, because it depends on prlog.h, but we in turn depend on setting up FORCE_PR_LOG macros in special ways before the first include of prlog.h, so I'd really prefer to avoid including prlog.h from header files (and I don't want to get into that mess as part of this patch).

OK, I landed those pieces: http://hg.mozilla.org/mozilla-central/rev/cbcf14ce64cc http://hg.mozilla.org/mozilla-central/rev/e2182ed1e129 so I think what's left here should be the platform-specific parts.

Will this make it in for 1.9.2, or is it for a later version?

Ignore my previous comment. But, how much more work would it take to support this fully now (the platform-specific parts)?

The DirectWrite backend implements this to a certain extent, although from my quick testing it's still a bit buggy (will pick a condensed face when it should pick an expanded face)

Is this going into 1.9.3? I ask because it's documented as unimplemented yet there's a patch that's landed to add support for CSS transitions of font-stretch.

I noticed that the font-stretch property parsing is now implemented and that each DOM element has the correct runtime value though the stretching itself is not implemented. I also noticed that the @font-face declaration parsing mechanism knows about font-stretch. I was wondering if it was difficult to implement the font switching when using user fonts defined with @font-face regarding the value of font-stretch as it does with the font-style and font-weight ones. Ex: @font-face { font-family : MyFont; src : url(myfont.otf); font-stretch : normal; } @font-face { font-family : MyFont; src : url(myfont-condensed.otf); font-stretch : condensed; } ... @font-face { font-family : MyFont; src : url(myfont-expanded.otf); font-stretch : expanded; } Actually, the latest @font-face declaration overrides the previous one and there is no font switching at all. In case that not all of the stretch variants are defined through @font-face, the closest stretch font could be applied. I don't think this represents a lot of work as all the basis are already implemented (font-stretch and @font-face parsing) Anyone can tell me if this partial implementation represents a lot of work to include it in the future release?

Whats the status of this bug? pdf.js wants this.

This seems to work on Mac OS X (in my limited testing, at least), but the Windows and Linux (pango/fontconfig) backends need some additional love; they appear to ignore the stretch setting during font selection.

This seems to work in initial testing, for both "installed" fonts and fonts loaded via @font-face. We should add a test for this, at least covering the @font-face case.

Comment on attachment 555845 [details] [diff] [review] patch to pass font-stretch to the linux/pango/fontconfig backend >+ if (width <= (FC_WIDTH_ULTRACONDENSED + FC_WIDTH_EXTRACONDENSED) / 2) { >+ return -4; >+ case -4: >+ return FC_WIDTH_ULTRACONDENSED; Would it make sense to use NS_FONT_STRETCH_* for the constants here? >@@ -444,16 +444,24 @@ gfxUserFcFontEntry::AdjustPatternToCSS(F >+ int fontWidth = FC_WIDTH_NORMAL; >+ FcPatternGetInteger(aPattern, FC_WIDTH, 0, &fontWidth); >+ int cssWidth = gfxFontconfigUtils::FcWidthForThebesStretch(mStretch); >+ if (cssWidth != fontWidth) { >+ FcPatternDel(aPattern, FC_WIDTH); >+ FcPatternAddInteger(aPattern, FC_WIDTH, cssWidth); >+ } >+ A missing FC_WIDTH is treated differently from a FC_WIDTH_NORMAL, so I think its best to initialize fontWidth to something invalid like -1 (as for FC_WEIGHT) above to ensure that FC_WIDTH is set.

(Reassigning this bug to me, as I'm hoping to actually make progress here.) Testing showed somewhat erratic results with @font-face families, because the style-matching code didn't differentiate among font-stretch mismatches - it would use the matching width if available, but if there was no exact match, you could get any of the available widths. To fix this, we need to improve the calculation of "style distance" so as to prefer the closest available width if no exact match is available. This gives the expected behavior (as per CSS3 Fonts draft, I believe) for @font-face families, and should apply to platform fonts on OS X and Windows as well (not yet tested with those - I think Windows will need further work). Note that we get slightly different behavior with platform fonts on Linux, because apparently fontconfig uses a different matching algorithm. This may need further investigation.

An initial reftest for font-stretch with @font-face, using nine faces of DejaVu Sans. Additional tests for families with a wider range of widths would be good to add, too.

There's not much we can do for platform fonts under GDI, as the GDI font family model doesn't support "rich" families with multiple widths (similar to the limitation on number of weights). However, for @font-face families we should have the same behavior across all backends. This patch adds support for font-stretch to the GDI font entry, so that user fonts work as expected. With this, the DejaVu Sans [Normal/Condensed] testcase works on all desktop platforms (OS X, Linux, Win-DWrite, Win-GDI).

Previous version did not correctly implement the CSS3-Fonts draft for the case where requested stretch is "normal", but the family contains *only* condensed and extended faces. Spec says to prefer condensed in this case, so fixed the computation to behave accordingly.

Checked that with the StyleDistance patch applied, the @font-face testcase from attachment 556155 [details] [diff] [review] also works correctly on Android.

Additional reftests to test a variety of font families. Note: IE9 passes all but one of the tests, they appear to map font-weight: medium incorrectly in one instance.

Comment on attachment 556253 [details] [diff] [review] (updated) patch to fix computation of StyleDistance to account for font-stretch more accurately > // TODO (refine CSS spec...): discuss priority of italic vs stretch > // (currently, font-stretch takes precedence; not sure this is good) One minor nit, the comment above no longer belongs here, it's really a todo for you to post on www-style if you think italic should take precedence over stretch. When I revised the font matching algorithm, I made font-stretch higher priority because it has the greatest effect on layout. We discussed the font matching algorithm at the spring CSS F2F in Mountain View and there seemed to be general concurrence with this approach. I'm happy with discussing this again on www-style but I don't think a comment like this in the code is appropriate at this point.

Comment on attachment 558206 [details] [diff] [review] patch, reftests for font-stretch with a variety of font families Review of attachment 558206 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for putting these together - looks good. I was thinking we could "misuse" weights of mplus to stand in for different widths, rather than trying to find (or create) a family that really has them all; the only downside is that it makes visual review of the test cases a bit confusing, I think, but we can live with that for now. ::: layout/reftests/font-matching/stretchmapping-all-ref.html @@ +206,5 @@ > + src: url(../fonts/csstest-widths-wd9.ttf); > + font-stretch: ultra-expanded; > +} > + > +.fstest-3-5-mixed-weights tr { font-family: fstest-3-5-mixed-weights; } A small nit - this "mixed-weights" class (and hence the following @font-face rules) in both the reference and testcase files is redundant, AFAICS; it doesn't seem to be used in the test at all. Clean up before landing (or were you intending to have additional content in the test that would use this?)

Pushed to mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/b264ee97923a [Linux impl] http://hg.mozilla.org/integration/mozilla-inbound/rev/36d230088375 [fix matching algo] http://hg.mozilla.org/integration/mozilla-inbound/rev/0d8e92d3138e [GDI impl] http://hg.mozilla.org/integration/mozilla-inbound/rev/910e5f55a57e [reftest] Not yet landed: John's additional tests (comment #77).

Vivien, can you test this with pdf.js?

http://hg.mozilla.org/mozilla-central/rev/b264ee97923a http://hg.mozilla.org/mozilla-central/rev/36d230088375 http://hg.mozilla.org/mozilla-central/rev/0d8e92d3138e http://hg.mozilla.org/mozilla-central/rev/910e5f55a57e

(In reply to Jonathan Kew from comment #80) > Not yet landed: John's additional tests (comment #77). Don't forget to land these. :-)

Additional reftests pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/e675a8b040a7

Docs updated: https://developer.mozilla.org/en/CSS/font-stretch And mentioned on Firefox 9 for developers.

comment #82 on 2011-09-05 says this is fixed but I dont see any difference on my attachment font_stretch.html and also at http://dbaron.org/css/test/sec150203d Can anybody explain..

I think you're misunderstanding what the font-stretch property means.[1] It does *not* cause a geometric transform of arbitrary fonts; it is a font selection property that can affect which face is chosen from a family that has multiple widths. So if you're using a family that has, for example, Ultra-Condensed, Condensed, Normal, Expanded and Ultra-Expanded faces, you should be able to use font-stretch to select them. But if you're using a font family that just has the "standard" four Regular/Bold/Italic/BoldItalic faces, font-stretch will not have any effect. [1] http://dev.w3.org/csswg/css3-fonts/#font-stretch-prop

I've added a note in the documentation to make this clear.

Some comments on https://developer.mozilla.org/en-US/docs/CSS/font-stretch 1. current summary >> The font-stretch CSS property selects a normal, condensed, or extended face from a font family. is it extended or expanded ? >> The font-stretch CSS property selects a normal, condensed, or expanded face from a font family. 2. I think content of the "Note:" can be second sentence of the "Summary" para instead of standing as a separate box. 3. The "Note:" content still dont make it clear for dump like me. May be we can borrow words like "arbitrary", "font family", "multiple widths" from :jfkthame to make it >> The font-stretch CSS property selects a normal, condensed, or expanded face from a font family. This property does not change the geometry of an arbitrary font, stretching or shrinking it. It merely chooses the appropriate face of the font, if this font family offers multiple widths. 4. We can also add :jfkthame second para to the "Summary". May be as a second para. >> So if you're using a family that has, for example, Ultra-Condensed, Condensed, Normal, Expanded and Ultra-Expanded faces, you should be able to use font-stretch to select them. But if you're using a font family that just has the "standard" four (Regular/Bold/Italic/BoldItalic) faces, font-stretch will not have any effect. PS: it looks like I am not the only one got fooled for google search https://www.google.com/#output=search&q=font-stretch first link goes to http://www.w3schools.com/cssref/css3_pr_font-stretch.asp and there it is listed as non of the browsers implemented this css property.

I edited and added images. WRT w3schools, this site is ridden with errors and only updated once every few years regarding browser compatibility. They play on a similar name as W3C (though they have no relation with them) and a good Google positioning to make money from ads and certifications without real meaning.

(In reply to Jean-Yves Perrier [:teoli] from comment #90) > I edited and added images. thanks it looks great now