6 different widths – not displayed by order
Options

Dusan Jelesijevic
Posts: 68
Hello,
It's been a while since I worked on family with second axes beside Weight, this time I have Width as well. So I'm having one issue – currently there are 6 different Widths within one font family:
– Condensed (75);
– Semi Condensed (100);
– Normal (125);
– Semi Extended (150);
– Extended (175);
– Ultra Extended (200).
Each Width got 7 Weights.
In total 42 font files.
When I install all the fonts, instead of being grouped by Width, they are displayed like this:
– Light Condensed
– Light Extended
– Light Semi Condensed
– Light Semi Extended
– Light Extended
– Light
and on same model for each different Weight.
What I'm doing wrong?
Any idea?
Fontlab VII


It's been a while since I worked on family with second axes beside Weight, this time I have Width as well. So I'm having one issue – currently there are 6 different Widths within one font family:
– Condensed (75);
– Semi Condensed (100);
– Normal (125);
– Semi Extended (150);
– Extended (175);
– Ultra Extended (200).
Each Width got 7 Weights.
In total 42 font files.
When I install all the fonts, instead of being grouped by Width, they are displayed like this:
– Light Condensed
– Light Extended
– Light Semi Condensed
– Light Semi Extended
– Light Extended
– Light
and on same model for each different Weight.
What I'm doing wrong?
Any idea?
Fontlab VII


0
Comments
-
Check your OS/2 table usWidthClass values.
In FontLab 8, make sure that you have selected the appropriate width setting for each master in the Names panel of Font Info:
Then for each instance, make sure that the appropriate width value is set at the bottom of the Instances panel:
0 -
Each application may do its own thing for sorting fonts. You don’t say what app is showing the problem behavior.
It looks like it is just sorting by weight and then... sorting styles within that weight alphabetically. If you have the usWidthClass set for each style as you say, then I suspect there is nothing you can do about that — for that particular app.
Edit: Also, did you previously have those styles generated and installed as separate fonts, before you had the width values set? Could you be having a problem with old versions of the font being cached?
(As a separate question, I am a bit baffled by your choice of width assignments... 125 is normal instead of 100? Is this because your normal width is relatively extended?)1 -
It is a choice how you think of your family and, hence, how you name the fonts, but personally I think of width variation as a higher level style grouping than weight because regular-to-bold weight mapping has been baked into the name table and downstream software for so long. So I would be inclined to have
Badrick Condensed Light
Badrick Condensed [Regular]
Badrick Condensed Medium
Badrick Condensed Semibold
Badrick Condensed Bold
...
rather than
Badrick Light Condensed
Badrick Regular Condensed
Badrick Medium Condensed
Badrick Semibold Condensed
Badrick Bold Condensed
...
3 -
@John Hudson
I missed to assign width for each weight in section from your 2nd printscreen. Somehow completely missed to notice it! Thank you very much for bringing it as printscreen!
And I did finally like you suggested:
Condensed Light
instead of:
Light Condensed
All sorted and arranged as it should be now!
@Thomas Phinney
It was strange cause sorting was by weight and within that sorting, widths were sorted alphabetically.
When doing test, I always remove old versions in whatever names they were, to avoid confusion. And very often I delete font cache file as well.
About 100 vs 125 for Normal width.
Whole design of this typeface were a bit unplanned. At first aim was to have variable weights only. And after I decided to add width axis, 100 ended to be actually Condensed width by it's design. So I assigned 125 for Normal width.
0 -
...100 ended to be actually Condensed width by it's design.I’m unsure how to interpret that statement, and in the internal design units of the typeface you can set the axis scale however you want, but the wdth axis scale as specified in the OT spec indicates that Normal = 100% width. So you might have the internal axis scale such that Normal = 125, but that should be mapped to 100% wdth in the avar table (i.e. via the axis graph in the FontLab 8 Axes panel).
I recommend making Normal = 100%, and then adjusting the rest of the scale accordingly. Note that the width name entries do not necessarily need to correspond exactly to the percentage condensed or expanded widths in the OS/2 spec. Historically, ‘condensed’ types were seldom as narrow as 75% of normal width. So you can make the narrower and wider named instances of your typefaces whatever widths make most sense in terms of the design and how it will be used, and then set the width value based on the name rather than the percentage. But the Normal = 100% should be the one fixed point.1
Categories
- All Categories
- 46 Introductions
- 3.8K Typeface Design
- 476 Type Design Critiques
- 556 Type Design Software
- 1.1K Type Design Technique & Theory
- 640 Type Business
- 831 Font Technology
- 29 Punchcutting
- 508 Typography
- 120 Type Education
- 313 Type History
- 75 Type Resources
- 109 Lettering and Calligraphy
- 30 Lettering Critiques
- 79 Lettering Technique & Theory
- 533 Announcements
- 86 Events
- 110 Job Postings
- 167 Type Releases
- 169 Miscellaneous News
- 274 About TypeDrawers
- 53 TypeDrawers Announcements
- 119 Suggestions and Bug Reports