Best practices for multi-script families

Tofu Type Foundry · March 24

Is it recommended to separate font families by script? I see some multi-script families choose to split into different fonts per script (Futura Latin, Futura Cyrillic, Futura Georgian) and other times everything is under one umbrella (Futura, which supports Latin, Cyrillic, and Georgian in the same package). I’m guessing the difference in vertical metrics of certain scripts is a leading reason behind splitting families. Alongside file size for web fonts, perhaps?

For those that do create separate families, do you include other script’s characters in that font? Example: Does Futura Arabic only contain Arabic characters? To type an English word would you need Futura Latin? Or are there some common characters that all scripts will include, such as a basic ASCII character set?

[I’m not actually discussing Futura, just using it as a generic typeface name]

Nick Shinn · March 25

I recommend putting Latin, Cyrillic and Greek in the same font, on the principle that it’s easier for foundry, reseller (if any) and customer to manage and negotiate.
I did once split up a family by script, but the proliferation of files was daunting. Others might find it easier.

However, if there is a particular non-Latin language/script market that you are targeting, that might merit a single-script format for it.

Simon Cozens · March 25

OK. There are three perspectives to consider when planning and distributing large multi-script families:

The designers' perspective. How many designers will be involved in the project? Will you have a designer per script or script family? If you have multiple designers working on separate scripts, you then have a project management challenge - are they all going to work on the same font file? Probably not. So you will need to split the family at the source level to give each designer something to work with. However, this is slightly more complex than "Arabic designer just works on the Arabic glyphs". You will probably want to provide glyphs from other scripts as a design reference. So it may well be that your design source for Arabic also includes Latin. (or vice versa!) This does not mean that your fonts as supplied will be Arabic+Latin, necessarily. We're just clarifying what the inputs are.
The technical perspective. Can you put all the scripts into a single output font? There are a few technical reasons why it may not be possible, and these reasons will guide how you split out the scripts into fonts: differing vertical metrics are the obvious one; different script styles for the same Unicode code point (Nastaliq Arabic for Urdu versus Naskh Arabic for Arabic, for example); and if CJK or very large families are involved, number of glyph slots in the font being limited to 65535. On the other side there are technical reasons why certain scripts need to live in the same font, or at least some glyphs from certain scripts will need to be added - combining marks, Vedic marks, and so on will span Unicode blocks and need to interact with shaping.
The users' perspective. If you can't put everything in one font, what groupings of scripts does it make sense to put together for your users? Will you want to include a Latin even in an "individual" script-based approach? It's not technically necessary if people are able to use a fallback stack in their applications (web target), but users without a fallback stack (for example InDesign) will hate you if you don't.

So you may need to merge your input fonts, build them, and split them out again in different permutations to provide the script combinations you want. Which is why if you're planning a large multi-script family, you're going to need a really good font engineer...

SCarewe · March 26

Ha. Simon wrote exactly what I wanted to write, with the three perspectives. I've been in all three. Setting multilingual text, especially for closely related scripts/languages is a pain when they're not bundled. I was constantly switching between Latin, Greek and Cyrillic for a presentation, often within the same sentence.

It's not easy to find a good balance: the user will prefer everything in one, the engineer somewhat bundled, and the distributor everything separate.

Tofu Type Foundry · March 26

These are great points from all of you! It brings up some aspects I hadn’t considered, like the three unique perspectives. I was just seeing things from the perspective of a type designer working in isolation. Thanks again!

Florian Hardwig · March 27

There’s also the commercial perspective, of course. Nick already hinted at some aspects. Also, if you bundle everything in one font, then your pricing might be prohibitive for those licensees who only really need one script. Or you keep the price low and end up underselling your product, especially when there’s more than “just” two or three scripts.

Some foundries offer multiple options, including packages covering a subset of scripts that may be used together, like LC (Latin+Cyrillic) or LCG (+Greek) a.k.a. Pan European. From a customer perspective, you’ll ideally be able to customize the licensed product during checkout and pick and choose scripts, so that you only get and pay what you need. But that has drawbacks, too. It’s similar to selling variable fonts that potentially represent huge families while some licensees only need a single style.

John Hudson · March 31

We subset some of our families (using the Tiro Builder tool) and give customers the option to license either complete fonts or script-specific subsets. I don’t think we have any multi-script subsets, but I agree that Latin+Greek+Cyrillic would be a sensible grouping.

The script-specific subsets tend to include an ASCII Latin set, since they are based on Win/Mac 8-bit codepages.

Best practices for multi-script families

Comments

Categories