There is some situation on Windows in which, if you use a value of 200 or lower, the screen image will be doubled up to make it thicker, as if the weight specified would be too thin to display otherwise. Needless to say, this would interfere with the designer's intent about how the font should look. The solution (i.e., hack, workaround) is to not use a value lower than 250.

(Sorry for the lack of concrete information. There was a discussion about this either here or on the FontLab forum, but I can't seem to find it. This is all from memory.)

I remember Adam talking about it during a FontLab training session in New York. The problem is the naming and value number. I may be mistaken, but I think the idea was to not select the category extralight and to use Light instead (even if your stem widths really are xtralite). Also, include Xtralite in the name of the font. My memory of the screen weight doubling in Windows is the same as Mark's above.
It is pretty rare to see an xtralite weight used for small sizes so screen draw is less of an issue. At text sizes, there just aren't enough pixels to display the font.

ChrisL

The workaround is to name the font whatever you damn well please, but change the weight fidure to something north of 400. I have done this in my font families, and they work fine. Font Validator sees that there is a disconnect between the name and the number, but this doesn't (seem to) cause any actual problems. The other great thing about manual tinkering with the weight figure: you can name fonts whatever you like, and OS X will list the fonts in the font menu in the numeric order. So, if you want to have "emaciated", "skinny", "plump", and "bootylicious", you could do that by numbering the fonts 500, 600, 700, and 800 respectively.

“bootylicious”

Now that is a font that would sit well with me :-)

ChrisL

At Thirstype we had "published" an image font of Rick Valicenti's formed from molds using a certain gelatin product. The font was called J'Lo...

"The font was called J’Lo…"

LOL!!! Salza flavored Jello :-)

ChrisL

Chester,
Is this the font you were refering to?

The minimum value is actually only 250. You can name the weights whatever you want. However, things get more complicated if you have a style-linked bold: there are certain weightclass combinations that are okay, and others that are not.

The problem is on Windows only, and only with some apps (though "some" means "about half").

Details HERE:
http://partners.adobe.com/public/developer/opentype/afdko/topic_font_wt_...

Note that I just noticed that the text table of style link info is not 100% right - we updated the graphical version of the table a short while back, but the text version was missed. I'm getting that updated, but in the meantime, here's the latest version of the table, in a useful visual format:

NM

NM?

Never Mind

I wanted to ask you something, but I'm too too tired (my original post: >The problem is on Windows only/ why is that? )

This is a great table, thank you!

I had exactly this problem recently, and
Mr Twardoch found out that it was due to
weight values, not false naming as was my
assumption ...

Will you add the graphic representation
to the site which you mentioned?

Karsten

Thanks for sharing that Thomas. I have used "half values" - ie: 550 - for weight ids in recent designs, and MS Font Validator flagged this as an error.

well, just reporting back, i set the font weight of my ExtraLights to 250 and no weirdness in Word at least. Does anyone know what some of the other potential problem applications would be that might display ExtraLight fonts incorrectly?

Check the rest of the Office Suite?

ChrisL

Also, things like "Notebook" and other little text utilities.

>The problem is on Windows only

As their lawyers told Sony...

AFAIK, if you identify one of the problem applications, you don't need to test in all of them. They are working the same way.

It's my theory that the reason for the bug is a combination of a stupid assumption by the application, and the way Windows GDI works.

The dumb assumption is that any font that isn't the bold style of another font has a weightclass of 400, and anything that is the bold style of another font has a weightclass of 700.

So, you select a font. The app says, "okay, that's the base font 'Glurbish', so the weightclass is 400." Doing this WITHOUT checking the weightclass.

The app then calls GDI for Glurbish with a weightclass of 400. GDI as always returns the closest match it can find. GDI will also automatically embolden fonts for you if you don't have a bold. So let's say there is no bold version of Glurbish, and there is only an ExtraLight (weightclass 200). The app asks for Glurbish-400, and GDI says, well, I could give them Glurbish-200, or I could do a faux bold and add 300 to that. Well, Glurbish-500 would be closer, so I'll do the faux bold on top of Glurbish-200. Or if you have a real style-linked bold, you get that instead.

So that's why 250 is the exact lowest value that works safely in such an application.

Some of the style-link combination stuff is *really* weird though, and I don't think I ever figured out all the reasons why it works the way it does.

Regards,

T

Thank you Thomas! That was a very clear explanation. I only wish the folks who make it work in the bizarre way you described, would sit down and have a chat with you and John Hudson to straigten out their solution.

ChrisL

It's a common error for the apps to make. I've pinged Si Daniels to see if he can pass word on to the MS Office folks. I know that the MS Typography folks have known about this issue for a few years already, though.

T

"I know that the MS Typography folks have known about this issue for a few years already, though."

Thomas,
Seems like the MS Office folks don't see typographic issues as the priority that the MS Typography experts do.

Thanks for trying though!

ChrisL