In most places, no, but there are issues with style linked families and css weight declarations.

CompareFamily is picky, but it has nothing against usWeightClass going up in increments of 10. (Unless it has been changed in recent years.)

Ok, that sounds good. Also, are there any issues with values between 900 and 1000? They seem to work, but the specification stops at 900.

"Do usWeightClass values absolutely have to be a multiple of 100..."

They do for use in CSS. Regrettably, the unenvisioners at the controls of OT and CSS specifications seem to have gummed up all but 10 values and passed gas on the idea of more useful ranges of values last I heard.

If you're using EOT fonts referenced by @font-face, Internet Explorer doesn't like a weightclass of 1000, but seems okay with 950. ("Doesn't like" means "the font will not be imaged.")

Cheers,

T

In defence of the 'unenvisioners' of CSS handling of weight class, they were trying to deal with existing incompatibilities between various software and font makers and come up with something that would produce reliable results in browsers when authors specify relative rather than absolute weights in CSS. It was a messy problem. They could have envisioned and defined some totally new and extensible weight range mechanism -- they still could -- , but that wouldn't remove the need for some standardised mechanism of handling existing fonts in a way the produces the fewest breakages, which is how I understand what they've done.

cf. John Daggett's slides from his TypeCon 2010 briefing (slides 17-26):
http://people.mozilla.org/~jdaggett/css3fontstypecon2010.pdf

and Dave Crossland's notes from that session:
http://www.advogato.org/person/crossland/diary/1.html

What exactly would be the downside of having more values available, if as you say they still could allow more values?

Also, who/what made the decision that only relative use of this scale was initially desired/ possible?

I spent a good deal of time in conversation on this when the OT spec was still not set on this, and left happily when all present "agreed" that this oversight was going to be corrected, considering " computers can count to 1000 just about as fast as they can count to ten."

My point to change this now and then, seems like the best idea considering people are still scratching their heads at the goofy current state of OS WT and OS width...

Tisk tisk :) This in an environment where developers NOW want reactive design, which these two properties sit rather inaequatey in the thick of, instead of being the useful forward looking parameters we could now have... :)

David: What exactly would be the downside of having more values available, if as you say they still could allow more values?

I didn't say that they could allow for more values under the existing (usWeightClass) mechanism: I was suggesting that they would need a new mechanism, because the usWeightClass-CSS interaction is hampered by what text handling systems, e.g. GDI, were already doing with usWeightClass, e.g. applying faux bolding to certain weights, while other software makers, notably Apple, had decided to treat usWeightClass as unreliable data and sniff font names to guess weight. As I said: a messy problem.

I don't see a way to make a clean, extensible CSS text weight system without uncoupling it from usWeightClass.

Also, who/what made the decision that only relative use of this scale was initially desired/ possible?

If you want absolute weights, then you can always reference a specific font in the CSS. It is in the use of relative weights that notions of lighter and bolder need to be related to individual members of a font family.

>I was suggesting that they would need a new mechanism

Nonsense, but I will believe anything from the foot-draggers who require CSS to remain inferior, and to the confused rulers of W3C who seem typographically ambivalent to the future.

Pay close attention to the undeniable facts
1. Apple ignores OS width and weight, clinging to antiquated sniffing of name? Where Regular, Normal, Roman, Standard, Medium and Book make this untenable, Apple’s usual position is to wait for an integrate-enabled solution to solidify. No mess there if OS's Wt and OS width become better through use of a more complete set of values, and better used by developers. Repeat, No Mess, like font names will remain forever.

2. MS’s use of these values is broken in GDI? They fall further every day in market share, and the share using the GDI tail end falls faster than their market share. Besides which, using OS2 Width and weight to perform effects! is so far away from the true intended use of these parameters as to be in a totally different class of functionality. Again! No mess.

3. FreeType… not used yet? No mess.

What made/makes the use of these fraternal twin parameters critical a couple years ago, and in crisis mode today? This pair of parameters is flying into a storm of need where an increasing population of developers and web sites perform the composition of web pages on-the-fly for reactive and restive design situations. The former relates to sites that need to look descent on phones, tablets and desktops via media query. The latter is required to better guide and increasingly typo-un-savvy market of users. And backing it all up further into the typography, most visual identities are made from a small number of font families per ID. In such a situation the families need to have Wt and Wth metadata that allows them to interact in the making of good lookin’ shit.

Comp-ren-do?

Yes, comprendo, and I don't disagree. I was just pointing out that what CSS specs re. weight class is a response to what that data looked like in existing fonts, what the OT spec says, and what different software makers were doing with that data. Yes, its a reactive solution, not a visionary one.

JH>" I was just pointing out that what CSS specs re. weight class is a response to what that data looked like in existing fonts..."

As I was and am saying .... Not all fonts, and not our fonts, have values so poorly defined. Me, I've been under the false impression that the W3C do not even recognize OT as a STD, and are more interested in the right long term solution... Which is why I'm dumb founded at their/your short sighted approach to these key parameters!?

David: I've been under the false impression that the W3C do not even recognize OT as a STD...

Oh, they definitely do that (officially as the 'Open Font Format' under ISO, I suppose). There's also a lot of stuff in the CSS Fonts spec that ostensibly permits of other formats -- especially with regard to layout features, e.g. AAT and Graphite --, but OpenType is referred to throughout. Note also that CSS typography has been designed with an option to directly address low level OTL tags rather than higher level CSS syntax.

David, do you have documented some place what you think it is important to be able to do with width and weight classes, and how you think this should be done? I think there are plenty of people in CSS who would be happy to engage with this issue.

>...what you think it is important to be able to do with width and weight classes...

In light of the fact that we already have:

font families where the total number of weights exceeds 11;)

font users employing multiple font families where both weight and width of the combined styles = > 11, and need relative order of wt and wdth for intelligent composition

and variation technology allowing indiscreet output of widths and weights from a single family master...

What's to document?

> ...they definitely do that [...] I suppose).

Lol at definite suppositions. W3C is schizophrenic on the issue of OFF/OT to the great peril for the future of several classes of web development and developers.

Simply telling them to define these parameter with 1000, or 999 values, should be sufficient if their aim is progress. The more I know about the fonts WG, the less I believe in progress, the more I shun the waste of my truly precious time.

CSS font attributes are used as a font descriptor to match a given face in a font family or to substitute something similar when the specified family doesn't exist on a given platform. This isn't a taxonomy scheme for font families, it's not an attempt to classify font families in their many different variations, it's a simple mechanism to deal with font selection and fallback. Whatever weight values are used, there needs to be a way of matching those values with the values available in a given font family and they need to be consistent across families.

The key is that if usWeightClass worked as initially intended, it wouldn't be hard to extend CSS to make it support a range instead of just multiple's of 100's. But as long as platform API vendors (e.g. Apple, Microsoft) view it as unreliable and instead try to infer the weight from the name, while Adobe puts in skewed weight values to avoid synthetic bolding in GDI, there isn't really a standard to base something on.

Consider the weight values for the Helvetica Neue family:

  Helvetica Neue on Mac OS X 10.6
  100   UltraLight 
  300   Light 
  400   Regular 
  700   Bold 
  900   Black (only condensed) 
  
  Helvetica Neue LT Std in Adobe's Font Folio 11 
  250   Thin 
  275   Ultra Light 
  300   Light 
  400   Roman 
  500   Medium 
  700   Bold 
  750   Heavy 
  900   Black 

Note how the Thin and Ultra Light faces differ from each other and from what's described in the OpenType standard. Apple also uses a slightly different scale than the OpenType standard, UltraLight and Thin are in a different order.

This is important because the OSX font API's sniff the style name and will assign a weight if they recognize a weight name in the style name. Only if they can't recognize a weight name will they use the usWeightValue.

For the OpenType spec, the simplest solution I guess would be to add a flag to the fsSelection field similar to the USE_TYPO_METRICS flag, something like USE_OS2_WEIGHT_CLASS maybe, then evangelize folks at Apple, Microsoft, Adobe and at Google to use this in their platform font API's. This flag would certify that the useWeightValues were in fact consistent with the relative scale defined by the OpenType spec and not skewed to hack around GDI-related problems on Windows.

For fonts loaded via @font-face rules, authors define what weight/width values are assigned to individual faces, there's no reference to any weight/width data in the font itself, only what is defined in the @font-face rules. So unless an author is using more than 9 weights simultaneously, that's not much of a limitation currently.

John D: For the OpenType spec, the simplest solution I guess would be to add a flag to the fsSelection field similar to the USE_TYPO_METRICS flag, something like USE_OS2_WEIGHT_CLASS maybe, then evangelize folks at Apple, Microsoft, Adobe and at Google to use this in their platform font API's. This flag would certify that the useWeightValues were in fact consistent with the relative scale defined by the OpenType spec and not skewed to hack around GDI-related problems on Windows.

That's the same mechanism I sketched out today. The problem for usWeightClass is very similar to that of the OS/2 usWinAscent and usWinDescent metrics, which were implemented in almost all software in a way that was contrary to their original intention and specification, so a similar solution seems likely. Of course, there would still be problems in the selection and rendering of correct fonts in systems that were not updated to accept the new mechanism, and which would treat the fonts according to past practice, i.e. ignoring usWeightClass or faux bolding certain weights.

_____

Aside:

David: The more I know about the fonts WG...

To clarify, there is no 'fonts WG'. The W3C has a Webfonts working group, which is responsible for defining formats and comformance requirements for served fonts, and a very much larger CSS working group, which is responsible for a massive amount of stuff, one part of which is 'CSS Fonts', which would be more accurately labelled CSS Typography.

Johns, the issues surrounding these parameters are not what font WG means (silly drover) how the OS show divergent interests in contradiction to an open publishing platform, or even how you think the parameters will be used. The issue is whether CSS will be able to offer these parameters for use in their currently hobbled conditions, vs how they could be more useful as they were originally intended.

If you need an existing example, parallel to the interpretation if these parameters, the interpretation of hints should suffice... Exactly. :)

David: The issue is whether CSS will be able to offer these parameters for use in their currently hobbled conditions, vs how they could be more useful as they were originally intended.

And you have your answer from both John Daggett and from me: CSS can use usWeightClass more usefully, as originally intended, only if there is a mechanism that can be used to tell platform APIs -- on which CSS user agents (browsers) rely -- that they should trust and treat the font's usWeightClass as originally intended, instead of treating them as they currently do. None of those API makers are going to break backwards compatibility for how they currently do things with existing fonts, which means that a different behaviour has to rely on a switch in the font itself, e.g. a new fsSelection bit flag.

It stays broken your ways. My way has nothing to lose following the STD!

Johns (D and H):

I hate to say it, but since AFAIK many GDI apps even on Windows 7 are still broken in handling usWeightClass, it seems to me that sane font vendors are not likely to use usWeightClass values less than 250. It's not only Adobe who does such odd things in this regard.

Just as the only way to get around awful legacy metrics and awful legacy names was to invent new ones, while keeping the old ones for backwards compatibility, it seems to me like we need a new "weightclass and this time we really mean it!" entry in the OS/2 table if we want to get out of this.

There could be some advantages to doing this, such as explicitly allowing values in between the 100's, and explicitly going as low as zero and as high as 1000. That would among other things accommodate families that don't fit into the Procrustean bed of 9 values from 100 to 900, with three weights below "regular" and five above.

I probably ought to propose this on the OFF and/or OpenType lists.

T

Thomas, a whole new data set was my original notion (see above), but then I started thinking if there might be a way, using a flag mechanism, to preserve the existing data structure. I see your point, though, about the benefits of a clean set of data, which would enable fonts to remain backwards compatible with their GDI behaviour while providing new weight information that CSS and new APIs could access instead of usWeightClass. And, of course, defining the new data as a range 0-999 rather than multiples of 100.
_____

David: My way has nothing to lose following the STD!

Presuming STD=standard (rather than sexually transmitted disease), what standard? The OpenType/OFF spec explicitly limits the correct setting of usWeightClass to one of nine multiples of 100.

http://www.microsoft.com/typography/otspec/os2.htm#wtc

So that standard clearly doesn't address your requirements for 'font families where the total number of weights exceeds 11'.

And if, following that standard, you set the usWeightClass value of any of your fonts as 100 or 200, they may end up displaying as heavier than a font with a value of 300 in GDI.

And if the range of weights in the family don't correspond exactly with the stated weights of the spec, Apple is going to select incorrect weights based on font name.

So I don't see an existing standard that you can follow, unless your family has seven or fewer weights and these correspond precisely to

300 	Light
400 	Normal (Regular)
500 	Medium
600 	Semi-bold (Demi-bold)
700 	Bold
800 	Extra-bold (Ultra-bold)
900 	Black (Heavy)

John Hudson wrote: "The OpenType/OFF spec explicitly limits the correct setting of usWeightClass to one of nine multiples of 100."

Hmmm. That's not how I read it. There's a comment that these nine values have specific meanings, but no guidance one way or another about the (il)legitimacy of other values.... Plus if only those values were legal, why even have usWeightClass on a 100-900 scale instead of the 1-9 scale that usWidthClass is on?

But otherwise, yeah, I think we are ~ in agreement.

T

Thomas, I guess we can agree that the usWeightClass spec is thoroughly ambiguous about the legitimacy of values other than multiple of 100 and offers no information at all about how these should be implemented or interpreted. No wonder software makers have judged the data to be unreliable and no standard implementation has been possible.

Yes, one possible interpretation of usWeightClass being on a 100-900 scale instead of 1-9 is that intermediate values are permitted, but it is just as feasible that it was defined this way to be future proofed against the definition of additional standard weights.

There's nothing in the spec, by the way, to suggest that GDI's synthetic bold of usWeightClass <250 is not, in fact, a legitimate use of this data, even though we consider the results in many cases to be 'broken'.

Of course, we know that the OT format spec in general is very short on implementation guidance.

Well?
if typography is 75-90% of all web content,
and the font formats of the web are sketchy,
then the majority of web content is unready for the next big thing(s).
So what's the problem?
The worst idea I can imagine is starting over with a new mechanism, which a caveperson could fig'ger that out in ten seconds if (s)he could time travel, "ugga bugga."

So what's the problem?

The problem has been explained above by several people. In a nutshell, as John D put it, there is no standard re. usWeightClass on which CSS can base an extensible recommendation of the kind we need to handle fonts with other than nine specific weights. The OT spec is underwritten and ambiguous, and existing software on which Web browsers rely handles usWeightClass data in inconsistent and incompatible ways.

So, you can have either the status quo or you can have something new. Even if the something new were not new font data, it would still require new APIs to be able to handle the new interpretation of usWeightClass (and in the process break backwards compatibility, which most software makers will balk at).

Excellent summary, thanks.

The one detail you are glossing over is that "most software makers" = Microsoft.

The one detail you are glossing over is that "most software makers" = Microsoft.

I think any software maker whose current handling of usWeightClass would produce different results from a new handling would be concerned about backwards compatibility issues, and that is as true for those who currently ignore usWeightClass as for those who perform specific functions with it. So, for example, if fallback font selection is currently based on parsing font names rather than on usWeightClass, shifting to using usWeightClass data will result in different fonts being selected in some situations (cf. John D's comparison of two different cuts of Helvetica and their incompatible name and weight class data).

I don't think anyone has looked yet at all the existing dependencies, or polled the various interested parties to find out just how seriously they take the backwards compatibility issues. I wouldn't like to guess.

When you get over your apparent fixation for pimping typographic chaos via industrial stagnation, please do let us all know so we little people can gather at the base of the mountain and receive your blessed solution.

David, that is very unfair.

Really? Is an inept 17 year rollout of web typography unfair enough to balance it all out for ya? You are not paying for this chaos so I'm going to ignore you now. Sorry...

David, you have my sympathies.
You should be designing typefaces, not battling Microsoft's ongoing legacy of technical impediments in screen display and font naming.
Or is that what passes for type design these days?

So what's your solution, David? You express an aversion to any new mechanisms, data types or formats, even when the existing mechanisms etc. are underdefined for Web purposes and have legacy implementation problems that already affect browsers and cross-platform compatibility. So how you you propose to create serenity from the chaos? This is a serious question. I want to know what you think should be done and how it will work.

PS. What I thought unfair was your characterisation of me. I'm not delivering mountain top solutions -- you are the one suggesting that everyone except you lacks vision --, I'm trying to work with other people to understand problems and examine solutions. At every stage of which I'm also struggling to understand what you are getting at, which is never easy and usually results in my being insulted, again. Very tired of that.

NS>You should be designing typefaces

Over the last month, I have been shoving more type problems in my face just to keep it out of this morass. Thanks for the encouragement nontheless.

JH> You express an aversion to any new mechanisms, data types or formats

You would have to show me where I say anything of the sort. Underdefinement is my enemy and something I have yet to provide. The solution here is to shove the parameters in question straight up the W3Cs standards stack and let them be properly filled by an ever increasing roster of well behaved fonts. If I gave any other impression, or wrongly insulted you, I am very sorry for that, but it seems like I'm talking to one brick in the wall after another, which I am very tired of as well.

David: The solution here is to shove the parameters in question straight up the W3Cs standards stack and let them be properly filled by an ever increasing roster of well behaved fonts.

Which is roughly what Tom and I are suggesting, except that we think the parameters in question need to be a new data structure independent of usWeightClass because the latter is pretty hopelessly broken in places that, unfortunately, are going to continue to have an impact on Web text rendering. Or, put it another way, there is no clear definition of what constitutes 'well behaved fonts' with reference to usWeightClass, since the data set and its uses are themselves underdefined.

If everyone were willing to dismiss backwards compatibility issues per se, and usWeightClass was better defined so that, moving forwards, standards for implementation could be specified, we'd still have to deal with existing font data in some way. Hence John Daggett's suggestion that some kind of flag mechanism would be needed to indicate the validity of the usWeightClass data according to the new, clean definition.

Regardless of whether a new data structure or a flag indicating particular use of the existing data structure is employed, new APIs are going to be needed to know what to do with it. So, that being the case, I'm inclined to agree with Tom's suggestion of a new data structure because it provides for the possibility of making fonts that would be compatible with both new APIs and the old usWeightClass interpretation/ignoring. The flag mechanism would only be compatible with the new APIs, and fonts with that data would break in various ways under the old system (synthetic bolding in a lot of versions of IE; different fonts being selected on different platforms).

>need to be a new data structure independent of usWeightClass because the latter is pretty hopelessly broken in places that, unfortunately, are going to continue to have an impact on Web text rendering.

They are No More Broken than hints ever were (a total parallel imho), and look how that is shaping up.

>some kind of flag mechanism would be needed to indicate the validity of the usWeightClass

Not as bad as a new structure, but... in the broken world of hints, the repair was foundry support for quality guides to the fonts, and! proof on the web of which fonts are and are not following the spec. No new APIs, just publicly scrutinizable fonts. That, I believe is the only solution to the pollution, and one that fits well with W3C's mission to make what's common — standard.

All the best from Dr. Jekyl

It seems that at least for the user and developer, it should be a simple matter rather than this craziness. A simple numeric progression seems achievable.

Chris: A simple numeric progression seems achievable.

Let's go back to John Daggett's helpful summary of the purpose of weight class vis à vis CSS:

CSS font attributes are used as a font descriptor to match a given face in a font family or to substitute something similar when the specified family doesn't exist on a given platform. This isn't a taxonomy scheme for font families, it's not an attempt to classify font families in their many different variations, it's a simple mechanism to deal with font selection and fallback. Whatever weight values are used, there needs to be a way of matching those values with the values available in a given font family and they need to be consistent across families.

[See the last paragraph of John's post for an explanation of why weight class isn't an issue for @font-face served fonts.]

So we need two things: 1) a clear definition of the acceptable range of values, and 2) consistent application across font families. It should be the case that two fonts with a usWeightClass value of 300 are pretty close to each other in weight, even if the fonts come from different vendors. This is where David's 'well behaved fonts' come in. At present there is no standard that defines the data in a way that can guarantee such consistency.

I think the creators of Panose understood something fundamental about font selection and fallback that most other people have missed: matching fonts needs to be based on measurement not on subjective and variable notions of 'Ultra-Light' 'Medium' 'Semibold' 'Heavy' etc. It isn't enough to know that two fonts are both called 'Medium' or that both have usWeightClass values of 500 if one is appreciably heavier than the other and if one family's 'Semibold' font (usWeightClass = 600) is actually closer in weight to the 'Medium' in the other family. That is not going to help what David so excellently described as 'making of good lookin’ shit.'

It seems to me that the only really sound way to use weight class data to indicate true weight (whether usWeightClass or some new data structure) is to link the data to a key stem weight relative to some standard value (which could be proportional, e.g. capheight, or fixed, e.g. em square. [This gets complicated because the system needs to be extensible to non-Latin types (which also means the the key stem might be horizontal in some scripts rather than vertical), and should be able to interact with other CSS fallback mechanisms, especially font-size-adjust.]

David: They are No More Broken than hints ever were (a total parallel imho), and look how that is shaping up.

I think it is a partial parallel. The problem of different platforms interpreting/ignoring hint data in different ways is that the same font renders differently in different places. One problem of different platforms interpreting/ignoring usWeightClass in different ways is that you can end up with different fonts in different places.

The hinting problem can be addressed by taking steps to equalise quality of rendering at the design level, i.e. compensating for the variable interpretation of hint data by targeting outlines to grids at select size ranges. The usWeightClass problem has to be addressed at the data level.

The hinting problem can be addressed in such a way that the same font looks good and is readable on multiple platforms (the renderings remain different, but the quality of the renderings is brought closer to each other). The usWeightClass problem, currently, can't be addressed in a way that will produce the same or even qualitatively equivalent results in different places; the only way to stick with the existing data structure and not require new APIs is to declare that you don't care about some of those places.
___

PS. I like Dr Jekyl.

>Let's go back to John Daggett's helpful summary of the purpose of weight class vis à vis CSS:

Let's not. It shows a distinct lack of imagination and envisioning of the future. It also disregards the approximately 37.5 billion possible combinations of glyph, font, typeface, user, device and poodle.

Hold horses for a minute, and survey the view from this ridge.

There appear to be some people on the plain below talking about what CSS actually does with a particular set of font data and how to ensure that it can be done reliably in a way that doesn't restrict font families to a very limited number of members. But there also appears to be a lone ranger galloping away into the distance, who is talking about completely overhauling CSS font handling in imaginative and visionary ways to do things other than what it currently and actually does.

I consider both of these to be entirely valid and important conversations. But let's be clear that they are two different conversations.