Last Comment Bug 3512 - (font-stretch) Implement font-stretch property
(font-stretch)
: Implement font-stretch property
Status: RESOLVED FIXED
[Hixie-PF] hit during nsbeta2 standar...
: css3, dev-doc-complete, fonts, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P2 enhancement with 21 votes (vote)
: mozilla9
Assigned To: Jonathan Kew (:jfkthame)
:
Mentors:
http://dbaron.org/css/test/sec150203d
: 4101 134936 186900 263670 589653 589655 (view as bug list)
Depends on: atsui 437356
Blocks: css3-fonts 104166 644385 1057680
  Show dependency treegraph
 
Reported: 1999-03-08 15:29 PST by Christine Hoffman
Modified: 2014-08-22 21:00 PDT (History)
63 users (show)
roc: wanted1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test Case tailored for Jaguar's default fonts (1.25 KB, text/html)
2002-09-07 04:34 PDT, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
no flags Details
Expected results on Jaguar for attachment 98267 (21.14 KB, image/png)
2002-09-07 04:35 PDT, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
no flags Details
patch for style system end (11.30 KB, patch)
2008-04-03 22:26 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details | Diff | Splinter Review
patch for style system end (11.78 KB, patch)
2008-04-03 22:29 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details | Diff | Splinter Review
v0.5 - dbaron's layout style stuff + windows font implementation (37.89 KB, patch)
2008-04-06 23:29 PDT, Stuart Parmenter
no flags Details | Diff | Splinter Review
patch for style system end (20.49 KB, patch)
2008-09-13 18:23 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details | Diff | Splinter Review
pre-patch: only define font constants in one place (9.10 KB, patch)
2009-01-21 19:46 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
vladimir: review+
Details | Diff | Splinter Review
patch for style system computation and adding stretch to gfx structures (46.29 KB, patch)
2009-01-21 19:48 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
vladimir: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
patch to pass font-stretch to the linux/pango/fontconfig backend (8.19 KB, patch)
2011-08-25 14:20 PDT, Jonathan Kew (:jfkthame)
karlt: review+
Details | Diff | Splinter Review
patch to fix computation of StyleDistance to account for font-stretch more accurately (3.53 KB, patch)
2011-08-26 15:35 PDT, Jonathan Kew (:jfkthame)
no flags Details | Diff | Splinter Review
reftest for support of font-stretch with DejaVuSans[Condensed] family (3.10 MB, patch)
2011-08-26 15:40 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Splinter Review
patch to support font-stretch in the GDI font backend (for @font-face families) (8.43 KB, patch)
2011-08-27 01:57 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Splinter Review
(updated) patch to fix computation of StyleDistance to account for font-stretch more accurately (3.37 KB, patch)
2011-08-27 04:22 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Splinter Review
patch, reftests for font-stretch with a variety of font families (56.32 KB, patch)
2011-09-04 18:49 PDT, John Daggett (:jtd)
jfkthame: review+
Details | Diff | Splinter Review
font_stretch.html (1.10 KB, text/html)
2012-11-22 08:24 PST, Biju
no flags Details

Description Christine Hoffman 1999-03-08 15:29:01 PST
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.
Comment 1 Peter Linss 1999-04-02 15:58:59 PST
CSS2 feature that was never promised. Don't know if font code can even deal with
it.
Comment 2 Christine Hoffman 1999-06-10 15:56:59 PDT
Is this a WONTFIX?
Comment 3 Peter Linss 1999-09-07 17:45:59 PDT
Pushing off non-beta 1 issues
Comment 4 Pierre Saslawsky 1999-10-21 01:06:59 PDT
Reassigning peterl's bugs to myself.
Comment 5 Pierre Saslawsky 1999-10-21 01:12:59 PDT
Accepting peterl's bugs that have a Target Milestone
Comment 6 Pierre Saslawsky 1999-10-26 15:26:59 PDT
See comments in #4101 that will be closed as dup.
Comment 7 Pierre Saslawsky 1999-10-26 15:26:59 PDT
*** Bug 4101 has been marked as a duplicate of this bug. ***
Comment 8 Pierre Saslawsky 1999-12-20 21:10:59 PST
Pushing my M15 bugs to M16
Comment 9 Hixie (not reading bugmail) 2000-01-13 16:06:59 PST
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...
Comment 10 Pierre Saslawsky 2000-05-07 18:53:55 PDT
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.
Comment 11 Pierre Saslawsky 2000-06-12 03:43:50 PDT
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. 
Comment 12 Hixie (not reading bugmail) 2000-07-31 15:17:40 PDT
Testcase:
   http://www.people.fas.harvard.edu/~dbaron/css/test/sec150203d
Comment 13 Hixie (not reading bugmail) 2001-04-26 17:07:30 PDT
Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.
Comment 14 Jacob Kjome 2001-05-20 00:07:07 PDT
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
Comment 15 Hixie (not reading bugmail) 2001-05-23 00:47:12 PDT
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?
Comment 16 rubydoo123 2002-03-08 11:58:39 PST
removing myself from the cc list
Comment 17 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-04-02 12:59:31 PST
*** Bug 134936 has been marked as a duplicate of this bug. ***
Comment 18 Greg K. 2002-04-03 01:04:14 PST
ATSUI (see bug 121540) provides some enhanced font weight functionality for Mac
OS X.
Comment 19 Greg K. 2002-04-03 01:04:56 PST
(Strike weight, make that stretch.)
Comment 20 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-19 21:04:54 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 21 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-09-07 04:34:31 PDT
Created attachment 98267 [details]
Test Case tailored for Jaguar's default fonts
Comment 22 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2002-09-07 04:35:22 PDT
Created attachment 98268 [details]
Expected results on Jaguar for attachment 98267 [details]
Comment 23 Greg K. 2002-10-10 22:37:44 PDT
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.
Comment 24 Hasse 2002-12-27 06:15:13 PST
*** Bug 186900 has been marked as a duplicate of this bug. ***
Comment 25 Bill Mason 2004-10-09 14:55:58 PDT
*** Bug 263670 has been marked as a duplicate of this bug. ***
Comment 26 Boris Zbarsky [:bz] 2004-10-16 16:09:30 PDT
Note that font-stretch is not in CSS2.1 (though it is still in CSS3 Fonts).
Comment 27 Denis Jacquerye 2006-06-07 11:00:54 PDT
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?
Comment 28 Bob T. 2008-03-04 16:19:52 PST
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.
Comment 29 Unknown W. Brackets 2008-03-04 17:24:13 PST
(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]
Comment 30 Bob T. 2008-03-04 17:54:18 PST
"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.
Comment 31 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-03-04 22:08:03 PST
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.
Comment 32 Bob T. 2008-03-05 04:37:14 PST
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? 
Comment 33 Nicolas Mailhot 2008-03-05 05:31:00 PST
(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.
Comment 34 Nicolas Mailhot 2008-03-06 09:06:37 PST
See also http://bugs.webkit.org/show_bug.cgi?id=12530#c11
Comment 35 Felix Miata 2008-03-06 10:32:04 PST
(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
Comment 36 Nicolas Mailhot 2008-03-07 05:25:42 PST
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.
Comment 37 Bob T. 2008-03-07 12:01:51 PST
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.
Comment 38 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-03-07 14:16:16 PST
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.
Comment 39 John Daggett (:jtd) 2008-04-03 18:05:55 PDT
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.
Comment 40 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-04-03 22:26:16 PDT
Created attachment 313538 [details] [diff] [review]
patch for style system end

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.)
Comment 41 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-04-03 22:29:23 PDT
Created attachment 313539 [details] [diff] [review]
patch for style system end

Er, missed one thing that's important for handling dynamic changes.
Comment 42 Stuart Parmenter 2008-04-06 23:29:38 PDT
Created attachment 314023 [details] [diff] [review]
v0.5 - dbaron's layout style stuff + windows font implementation

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.
Comment 43 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-06-04 10:04:41 PDT
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.
Comment 44 Zack Weinberg (:zwol) 2008-06-04 14:56:44 PDT
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.
Comment 45 Damon Sicore (:damons) 2008-06-04 16:54:18 PDT
marking wanted1.9.1? to get this in the triage queue. 
Comment 46 John Daggett (:jtd) 2008-06-04 17:23:10 PDT
(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.
Comment 47 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-06-04 17:29:17 PDT
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.
Comment 48 Zack Weinberg (:zwol) 2008-06-04 17:30:58 PDT
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".
Comment 49 John Daggett (:jtd) 2008-06-04 18:57:30 PDT
(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. ;)

Comment 50 Zack Weinberg (:zwol) 2008-06-04 19:05:33 PDT
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.
Comment 51 John Daggett (:jtd) 2008-06-04 21:09:03 PDT
(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.


Comment 52 Zack Weinberg (:zwol) 2008-06-04 21:46:22 PDT
(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.
Comment 53 Nicolas Mailhot 2008-06-04 23:24:08 PDT
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
Comment 54 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-09-13 18:23:51 PDT
Created attachment 338479 [details] [diff] [review]
patch for style system end

This is updated to have a change I missed in nsThebesDeviceContext (missing that change was causing valgrind warnings) and to use SetDiscrete.
Comment 55 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-01-21 19:46:10 PST
Created attachment 358120 [details] [diff] [review]
pre-patch: only define font constants in one place

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.)
Comment 56 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-01-21 19:48:20 PST
Created attachment 358121 [details] [diff] [review]
patch for style system computation and adding stretch to gfx structures

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 57 Vladimir Vukicevic [:vlad] [:vladv] 2009-01-22 12:57:41 PST
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 58 Boris Zbarsky [:bz] 2009-01-28 10:58:00 PST
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.
Comment 59 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-01-28 11:17:17 PST
(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).
Comment 60 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-01-29 15:46:23 PST
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.
Comment 61 d 2009-08-18 12:54:28 PDT
Will this make it in for 1.9.2, or is it for a later version?
Comment 62 d 2010-03-12 14:42:52 PST
Ignore my previous comment. But, how much more work would it take to support this fully now (the platform-specific parts)?
Comment 63 Alex 2010-03-25 00:33:13 PDT
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)
Comment 64 Eric Shepherd [:sheppy] 2010-06-18 12:17:05 PDT
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.
Comment 65 Ryan Flint [:rflint] (ping via IRC for reviews) 2010-08-22 21:13:39 PDT
*** Bug 589655 has been marked as a duplicate of this bug. ***
Comment 66 Ryan Flint [:rflint] (ping via IRC for reviews) 2010-08-22 21:22:42 PDT
*** Bug 589653 has been marked as a duplicate of this bug. ***
Comment 67 caribou 2010-10-19 00:39:05 PDT
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?
Comment 68 Andreas Gal :gal 2011-08-25 08:33:07 PDT
Whats the status of this bug? pdf.js wants this.
Comment 69 Jonathan Kew (:jfkthame) 2011-08-25 09:15:18 PDT
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.
Comment 70 Jonathan Kew (:jfkthame) 2011-08-25 14:20:01 PDT
Created attachment 555845 [details] [diff] [review]
patch to pass font-stretch to the linux/pango/fontconfig backend

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 71 Karl Tomlinson (:karlt) 2011-08-25 17:20:55 PDT
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.
Comment 72 Jonathan Kew (:jfkthame) 2011-08-26 15:35:29 PDT
Created attachment 556151 [details] [diff] [review]
patch to fix computation of StyleDistance to account for font-stretch more accurately

(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.
Comment 73 Jonathan Kew (:jfkthame) 2011-08-26 15:40:05 PDT
Created attachment 556155 [details] [diff] [review]
reftest for support of font-stretch with DejaVuSans[Condensed] family

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.
Comment 74 Jonathan Kew (:jfkthame) 2011-08-27 01:57:15 PDT
Created attachment 556238 [details] [diff] [review]
patch to support font-stretch in the GDI font backend (for @font-face families)

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).
Comment 75 Jonathan Kew (:jfkthame) 2011-08-27 04:22:44 PDT
Created attachment 556253 [details] [diff] [review]
(updated) patch to fix computation of StyleDistance to account for font-stretch more accurately

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.
Comment 76 Jonathan Kew (:jfkthame) 2011-08-27 09:44:11 PDT
Checked that with the StyleDistance patch applied, the @font-face testcase from attachment 556155 [details] [diff] [review] also works correctly on Android.
Comment 77 John Daggett (:jtd) 2011-09-04 18:49:53 PDT
Created attachment 558206 [details] [diff] [review]
patch, reftests for font-stretch with a variety of font families

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 78 John Daggett (:jtd) 2011-09-04 18:59:44 PDT
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 79 Jonathan Kew (:jfkthame) 2011-09-05 00:37:30 PDT
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?)
Comment 81 Andreas Gal :gal 2011-09-05 02:15:58 PDT
Vivien, can you test this with pdf.js?
Comment 83 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-09-06 11:30:00 PDT
(In reply to Jonathan Kew from comment #80)
> Not yet landed: John's additional tests (comment #77).

Don't forget to land these. :-)
Comment 84 John Daggett (:jtd) 2011-09-06 21:04:27 PDT
Additional reftests pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/e675a8b040a7
Comment 85 Eric Shepherd [:sheppy] 2011-10-14 09:57:53 PDT
Docs updated:

https://developer.mozilla.org/en/CSS/font-stretch

And mentioned on Firefox 9 for developers.
Comment 86 Biju 2012-11-22 08:24:45 PST
Created attachment 684431 [details]
font_stretch.html

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..
Comment 87 Jonathan Kew (:jfkthame) 2012-11-22 08:49:52 PST
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
Comment 88 Jean-Yves Perrier [:teoli] 2012-11-22 12:30:59 PST
I've added a note in the documentation to make this clear.
Comment 89 Biju 2012-11-22 23:55:59 PST
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.
Comment 90 Jean-Yves Perrier [:teoli] 2012-11-23 02:50:06 PST
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.
Comment 91 Biju 2012-11-23 21:21:54 PST
(In reply to Jean-Yves Perrier [:teoli] from comment #90)
> I edited and added images.

thanks it looks great now

Note You need to log in before you can comment on or make changes to this bug.