Problems Adding New Weights to Large Font Family

Robby Woodard

My client wants to add three new weights to and existing 12 font family. I remember struggling with the whole family naming and style linking process for the original twelve a couple years ago and these additions have me worried…

The original set contained roman and italic Black, Bold, Semibold, Regular, Book and Light weights. They want to add Extralight, Thin and Hairline. 

The numerical weight value for the existing Light is 300. If I use the FL defaults, the next lighter weight values are Extralight - 200, Thin - 100, and then Ultralight back goes back up to 200.

I don’t understand this progression. Would I get into trouble if I went with Extralight - 250, Thin - 200, Hairline - 150 instead?

And another concern — I am starting to draw the Thin glyphs and I am realizing I don’t quite have the fidelity I would like for these really thin stokes. I am thinking about changing the UPM size to 2000… 

But is is smart to do that when all the rest of the family is set the standard 1000 UPM?

I have a lot of drawing to do but I would feel better if I could figure out some of these technical issues in the mean time and could really use some advice!

María Ramos

Robby Woodard said:

And another concern — I am starting to draw the Thin glyphs and I am realizing I don’t quite have the fidelity I would like for these really thin stokes. I am thinking about changing the UPM size to 2000… 

Robby are you using Glyphs? You can subdivide the grid for a more detailed control over the outlines, without changing the UPM size. Font info/Other settings

Robby Woodard

No, I am not using Glyphs. It does seem like a very interesting app but it has taken me a while to get a decent handle on FontLab. I am looking forward FL6 is coming out soon and I am planning to stick with it. For now anyway...

Nick Shinn

Fot the thinnest weight, make a path and stroke it…

Contour > Paths > Make Parallel Path 

(FontLab)

…by 20 or so. Then interpolate this with the Regular to make the other thin and light weights.

If it doesn’t seem like you are getting enough precision at UPM 1000, add an extra BCP to problem joints—the slight offsetting will never be noticed.

Robby Woodard

Thanks, Nick. I've drawn a few more glyphs and I am confident I can get the Thin to work at 1000 UPM with a few compromises here and there as you sugest. That is one less worry.

The whole linking thing is still stressing me out. I have such a difficult time with that whole process. I have printed out Lücke's treatise and I study Twardoch's charts. But still...

Maybe it is just me but, dang, that system seems crazy and convoluted. Makes my head spin!

María Ramos

Good to know. Thanks @Frode Bo Helland

Robby Woodard

Anybody got any insights about the numerical linking values?

The numerical weight value for the existing Light is 300. If I use the FL defaults, the next lighter weight values are Extralight - 200, Thin - 100, and then Ultralight back goes back up to 200. I don’t understand this progression. Would I get into trouble if I went with Extralight - 250, Thin - 200, Hairline - 150 instead?

My client want the whole family to link up and display properly in the browser list from Thin to Black.

I am still in the drawing stage. I will start testing soon but things that seem fine on my mac don't always work on other and older systems.

Jackson Showalter-Cavanaugh

Best place to start is to read the manual: http://old.fontlab.com/font-editor/fontlab-studio/download-fontlab-studio/

You can also hire people to master the fonts for you. 

Robby Woodard

I actually did looked through the manual before I decided to bother you guys. It doesn't seem to go into a lot of detail about weight the values. 

It says I CAN put in my own custom values. I am worried about wether or not I SHOULD.

I may consider hiring somebody with more experience dealing with this sort of thing in the end but I would like to give it a shot myself first.

Robby Woodard

I might have planned for these three new lighter weights if I had been aware of them and adjusted the Light (that USED to be the lightest available weight) up a bit to make room in the numbering scheme. My client doesn't want to change the originals, so I am stuck with them. Dang.

Robby Woodard

Thanks Frode! A lot to absorb but exactly what I was hoping TypeDrawers would point me towards.

Marc Oxborrow

@Frode, have you actually heard of anyone moving (back) to Quark Xpress? That seems unlikely to me. InDesign is so entrenched in multi-page print design as to be practically immovable. Other than irritation with Adobe, there's no compelling reason for designers to switch.

If you're hoping to see a piece of Adobe software knocked off its perch, look for Sketch (or other competitors, including Adobe's new XD) to replace Photoshop as the de facto web design tool.

Miles Newlyn

@robby sounds to me like you are being bossed around by your client. You are the type designer and if you need to renumber and re-arrange the family system then you need state this as a fact to the client. You're not a miracle worker.

Thomas Phinney

Short answer: if your existing Light is 300, and you wish to avoid going below 250, the three new weights could be pegged to 285, 265 and 250. Or something like that.

I do recommend not going below 250, else you will have problems in a significant portion of Windows GDI apps. If you and your client don't care about them, no worries. But my general experience is, such a decision is likely to bite you eventually.

Then again, CSS only accepts multiples of 100 for specifying weightclass for the web, despite my protests, because the W3C wants to make it impossible for us to make a font family that works everywhere. (OK, that's my slightly biased/frustrated interpretation of the discussions. Obviously I was not happy with the outcome.)

PabloImpallari

I'm actually happy W3C did that. Why should they perpetuate others people's bugs?

Robin Mientjes

PabloImpallari said:

I'm actually happy W3C did that. Why should they perpetuate others people's bugs?

The spec may have been vague, but nothing about the OpenType spec indicates that the number should be a multiple of 100. In fact, if that were the case, why not single digits? And furthermore, why does Microsoft have a 250 cut-off? I think they clearly expected the values to be triple digits, and then again I raise my single-digit logic.

The confusion existed because the initial CSS implementations must have read the examples and default values and interpreted them as hard law.

Michael Jarboe

Microsoft causes so many problems. 

Mark Simonson

why does Microsoft have a 250 cut-off?

Technically, it doesn't. But what happens is, if a font has a weight value of less than 250, the GDI renderer would artificially embolden the font, supposedly to ensure that the font doesn't get so thin that it is difficult to see or print. In practice, this causes very thin fonts (below 250) to be displayed bolder than less thin fonts (250 or higher). To avoid this issue, the "best practice" is to avoid values lower than 250.

I guess if you don't care about what happens with GDI, then nothing's stopping you from using weight values below 250.

James Puckett

Are weight values under 250 only emboldened in GDI, or was it introduced in GDI and something that also happens in DirectWrite?

Deleted Account

Thomas: "... the W3C wants to make it impossible for us to make a font family that works everywhere. (OK, that's my slightly biased/frustrated interpretation..."

What!? We can make font families that work anywhere thanks to the support and threats of the w3c to get woff done.:)

The issue here, I think, is responsiveness of several kinds. Our company's progress  in this area required inventing our own replacements for optical size, weight and width.

Typography today, needs relative specifications, (rem) as well and as absolute ones, 12 pt. ...it's got relativity, on the web, just for size. But to have relativity work in weight and width, one needs to leave the standards. Our Adios to those standards came when we had to make a 21st century font catalog online.

What do you think the standards owners are thinking when they push variations, while continuing to put on this parametric shit storm show for 20 Years? I mean, there is no variations name table and a bunch of other stuff, in the proposal. If they are be thinking of instances named with a series of numbers from the axis, or picking os2 values out of a hat?, or none, I feel sorry for their users.

I think the vartzars might think if one limits the scope of variations to what helps compression, then one can keep the parametric identities of the resultant styles as dumb as today, but they ain't done it yet, so their nuts are probably cold. Maybe when folks get closer to actually using variations and the os2 table together, they'll warm to reform?