See Adam's description and my illustration.

Windows allows for four Regular, Italic, Bold, Bold Italic styles per family only. There's no place for anything like Minor or Light. You'd need to move Minor Light to the Family Name and make sure that Style Name is exactly one of the above-mentioned four.
You can assign any number and kind of styles via Preferred Family/Style Name on the next Font Info page. This then is used e.g. in CS apps.

You may also try FOG5's Font Info dialog in Easy mode, fill in Family Name and Design Parameters and then check in Advanced mode which names it has produced.

Windows FAIL

You can split Lapidaria in Lapidaria Minor, Lapidaria Medior and Lapidaria Maior (FontLab info panel / OpenType-specific font names / OT Family Name). This would improve the comfort; if the user wants to switch between Minor, Medior and Maior, he would do it with the font main menu in Adobe applications. And the weight would be changed with the font sub menu. Because I assume, that you did not make mistakes with regard to Lapidaria Light only, you have to correct the names of the whole family.

If you decide to style link the semibold styles to the regular styles, the family names of the semibold and the regular styles must be Lapidaria Minor, Lapidaria Medior and Lapidaria Maior. And the family names of the Lapidaria Light styles must be Lapidaria Minor Light, Lapidaria Medior Light and Lapidaria Maior Light. If you don’t want to style link them, the style names must be regular in case of all nine styles. If you want to style link regular and semibold, the style names of the three semibold styles must be bold and the style names of the other six styles must be regular.

The thread on the FontLab forum is really good. In one of my posts you find links to all technical documents, that I have found with regard to the naming.

The FontLab info panel "Additional OpenType Names" is useful, if you really want to have full control over the naming.

@ Mike Jarboe

It’s not a Windows fail. In this case it simply is a Stötzner fail.

… it simply is a Stötzner fail

I doubt it is.

This is not the first typeface I market. I carefully named all fonts, checked again, it just works on the Mac. That’s how it ought to be, FINITO.
I don’t feel misguided when I just haven’t followed the misconception of others. And if MS is so stupid to confine a font family’s scheme of Reg-Bold-Ital-BdItal only, it is surely not my fault.

Thanks very much for your advice anyway.

I don't feel misguided when I just haven't followed the misconception of others.

I sympathise with this in a way (especially in terms of rasterization), though not entirely (uncompromising fonts wouldn't work anywhere), and definitely not when it comes to naming: If your fonts are supposed to be Mac-only or Adobe-CS-only fonts, all is fine. But if your fonts are supposed to be cross-platform fonts, there's no way around addressing Windows' peculiarities.

… addressing Windows' peculiarities.

… which is what I’ll do to my level best.

And one day I wish to see MS adressing typography’s peculiarities, to bother us no longer.
Cheers, A. St.

@ Andreas

And one day I wish to see MS adressing typography’s peculiarities, to bother us no longer.

Even if Microsoft applications would make use of the same name records as Adobe applications, you still should care about backwards compatibility. We are not talking about a hack for Windows, that might cause problems with your fonts, when Microsoft has addressed “typography’s peculiarities”.

It is your fail, if you don’t care about other platforms, the specifications or the recommendations of experts like Adam. I only wonder, that it was the first time, that you got a bug report. The MAC is not the mother of all computers and even for creatives it is not necessarily better than Windows.

Addition to my first post in this thread: I don’t style link weights, but uprights and italics only, because in most cases the regular weight is style linked to the semibold, but not to the bold weight. If there is a bold style in the family, the Office user could accidentally take that instead of the semibold weight and the other way around.

It is clearly Microsoft's fault, imposing non-sense, artificial restrictions have never been a good thing. Every one, but Microsoft, does not impose such a restriction, not only Mac. It might be desired to get around Microsoft's, or any other behemoth corporation's, faults, but this does not magically make it other's fault.

@ Khaled

Damn. The namerecords in question are just for those applications, that have a menu like Office on Windows. Microsoft could make use from the name records in the same way, as Adobe actually does on Windows. The user, that has posted the bug report to myfonts had not a problem with Lapidaria in the Creative Suite, but in Office, OpenOffice, Notepad, Wordpad et cetera. It would be Microsoft’s fault, if they would block the development of the specification. Just name the fonts according to the specification and they work in Office. It is absurd to pass the buck to Microsoft. Microsoft makes use of the namerecords according to the OT specification. They often misinterpret specifications, but this time they didn’t. If you don’t want to care about applications like Office, it is your decision, but not Microsoft’s fault. If you buy a pair of shoes without having a look at their size, it is not the fault of the manufacturer, if they are too big or too small. Apple is not the measure of all things and Windows neither.

The user was not bothered by Office, but by the font.

Family Name: Lapidaria Minor Light
Weight: Light
Weight Class: 300
Style Link: None
Style Name: Regular
PS Font Name: LapidariaMinor-Light
Full Name: Lapidaria Minor Light
Menu Name: Omit
FOND Name: Omit

OT Family Name: Lapidaria Minor
OT Style Name: Light
Mac Name ID 18 (Below OT Style Name): Lapidaria Minor Light

or alternatively

Family Name: Lapidaria Minor Light
Weight: Light
Weight Class: 300
Style Link: None
Style Name: Regular
PS Font Name: Lapidaria-MinorLight
Full Name: Lapidaria Minor Light
Menu Name: Omit
FOND Name: Omit

OT Family Name: Lapidaria
OT Style Name: Minor Light
Mac Name ID 18 (Below OT Style Name): Lapidaria Minor Light

Andreas: It is because of issues like this that Adobe developed the "CompareFamily" test tool, part of the AFDKO. It will catch such things and report on them.

Folks developing fonts, or testing an application's font usage, owe it to themselves and their customers to set up a suite of test tools, and CompareFamily should be one of them.

Cheers,

T

I think I misunderstood the issue in hand, indeed OpenOffice don't show extra styles (there is no way to access them at all), on can only select the four common style from the text formatting tool bar. If it is something confined to office applications (I first though, from the summary, it is a common Windows issue), then it is a much less dramatic issue. Though I still it is a software limitation (lets not say fault, since apparently some finds it rude), from customer point of view it is still the duty of font vendor to work around such limitations, it is up to the font designer to choose what applications or use cases he wants to support.

This is indeed a common Windows issue affecting a majority of Windows apps. Although it is possible to write a Windows GDI app that does not have this limitation, most of them do.

T

Thanks all for suggestions, Arno and Karsten in particular.

I looked into your impressive Fontnaming_kltf document, Karsten. It reminds me of being a typeface designer and not a software guy.

However, I gratefully adopted your proposed naming schemes and for now it looks like this:
.

.
The (Opentype specific font names) I left entirely blank.
›Style name‹ remains "Regular" for Light and Regular fonts but would become "Semibold" in the relevant fonts, plus Style link "Font is Bold".
– Should work this way?

Andreas, if you leave the OpenType specific names blank, the fonts will not group anymore in the font menu of applications like InDesign. Better to fill them in like Arno wrote, for your example font:

OT Family Name: Lapidaria
OT Style Name: Minor Light

Ok. I just thought I might follow Karsten’s recommendation on p. 3 of his manual.

Honestly, who is to seriously overview all the pitfalls of this business?
Could there be a way to bring some handy logic into the system?

Andreas, I just have uploaded a naming scheme for Lapidaria to my personal attachement container: Lapidaria-Naming.TXT.

Honestly, who is to seriously overview all the pitfalls of this business?
Could there be a way to bring some handy logic into the system?

I think, this would require a new font format with a new specification and the good will, not to violate the specification. It would require, that font developers don’t violate the specification just because their fonts don’t work in a program, that was developed by people, that don’t care about specifications. In case of the naming the actual situation is less problematic than the way, in which different platforms and programs handle the leading values. Although Microsoft doesn’t violate the specification with regard to the naming, the spec could be simplified.

I've used Adams' namining system for some six years with no hitch. But I must say that there should be a lot more simple way for naming fonts.

I would like to challenge the people from Apple, Microsoft and Linux to write a proper piece of code to get all of us out of this totally unnecessary tinkering.

Hey all:

The source of our troubles is that people need new fonts and new font formats to:

1) work with previously existing apps and OSes
2) work with both Mac and Windows
3) display more typographically reasonable behaviors (or in this case, names) in savvy apps

So we end up with needing to have multiple sets of info in the fonts, to handle legacy Mac constraints, legacy Windows constraints, and the preferred way we want things to work going forwards.

Many of the most confusing aspects of OpenType font development stem from this issue: naming, vertical metrics, etc.

If you want font naming to be easier, Apple, Microsoft and Linux are the wrong folks to bother:

1) Neither you nor they are likely to be willing to abandon compatibility with existing apps and OSes.

2) If you did want to abandon that, you'd want your approach enshrined in the OpenType / Open Font Format specification as well, and you should make your pitch on the appropriate mailing lists.

3) If you are going to work within the existing framework of the world, the place to deal with this is in the tools! Adobe has already contributed work on *testing* families to show whether the names seem to be properly coordinated. What is needed is a framework to make it easier to properly coordinate font names across an extended font family in the first place.

Adam Twardoch is one of a handful of people (including me as well) who know this naming stuff inside out and backwards, and understands the hassles it creates. He did a bunch of research towards this in working on the new Fontographer. Probably one of the most useful things they could do in FLS 6 would be to further develop this, and if done right could drive some upgrade revenue.

Cheers,

T

I've always had the usual problems described above - following Adam's and Karsten's recommendations I think I finally got it working.

I wrote this script to automate the process, it's always worked for me.


from robofab.world import CurrentFont
from robofab.interface.all.dialogs import AskString
f = CurrentFont()
#
fontName = AskString('Font Name')
Weight = AskString('Weight')
#
def naming( short, weight, weight2 ):
f.info.familyName = fontName+" "+short
f.info.widthName = "Normal"
f.info.styleName = weight
f.info.fontName = fontName.replace(' ', '')+"-"+weight2.replace(' ', '')
f.info.fullName = fontName+" "+weight2
f.info.menuName = fontName+" "+short
f.info.fondName = fontName.replace(' ', '')+" "+weight2.replace(' ', '')
f.info.otFamilyName = fontName
f.info.otStyleName = weight2
#
#
if Weight == "Thin":
naming("Th", "Regular", "Thin")
f.info.weightName = "Thin"
f.info.weightValue = 250
print f.info.fullName+" "+"Named"
elif Weight == "Light":
naming("Lt", "Regular", "Light")
f.info.weightName = "Light"
f.info.weightValue = 300
print f.info.fullName+" "+"Named"
elif Weight == "Regular":
naming("Rg", "Regular", "Regular")
f.info.weightName = "Regular"
f.info.weightValue = 400
print f.info.fullName+" "+"Named"
elif Weight == "Medium":
naming("Lt", "Bold", "Medium")
f.info.weightName = "Medium"
f.info.weightValue = 500
print f.info.fullName+" "+"Named"
elif Weight == "Bold":
naming("Rg", "Bold" ,"Bold")
f.info.weightName = "Bold"
f.info.weightValue = 700
print f.info.fullName+" "+"Named"
elif Weight == "Thin Italic":
naming("Th", "Italic", "Thin Italic")
f.info.weightName = "Thin"
f.info.weightValue = 250
print f.info.fullName+" "+"Named"
elif Weight == "Light Italic":
naming("Lt", "Italic", "Light Italic")
f.info.weightName = "Light"
f.info.weightValue = 300
print f.info.fullName+" "+"Named"
elif Weight == "Italic":
naming("Rg", "Italic", "Italic")
f.info.weightName = "Regular"
f.info.weightValue = 400
print f.info.fullName+" "+"Named"
elif Weight == "Medium Italic":
naming("Lt", "Bold Italic", "Medium Italic")
f.info.weightName = "Medium"
f.info.weightValue = 500
print f.info.fullName+" "+"Named"
elif Weight == "Bold Italic":
naming("Rg", "Bold Italic", "Bold Italic")
f.info.weightName = "Bold"
f.info.weightValue = 700
print f.info.fullName+" "+"Named"
else:
print "Ooops that's not a weight"
print fontName+" "+"is not named"
#
f.update()


I think it is settled now.

Thanks for your advice to all.
A. St.