FontFamily Class

Silverlight supports a list of font family values that are supported in the initial, default Silverlight font set for non-East Asian cultures. This list is documented in the topic Text and Fonts. 

For a list of the East Asian fonts, see Text and Fonts.

The default value for a referenced FontFamily is initialized with the value Portable User Interface. For non-East Asian cultures, this value is an alias for the font family value (shown here as a string) of "Lucida Sans Unicode, Lucida Grande". Lucida Grande and Lucida Sans Unicode in turn are aliases for the same font and are specified as a pair for compatibility reasons.

Note that the Portable User Interface value is not always the apparent default value when a given object is referenced at run time, even if your user code made no changes to the value. Controls, even the default Silverlight controls, will generally apply a template that defines their appearance. These templates frequently change the values of properties such as Control.FontFamily to be different than the pure code default value. The templates also might be written differently for different locales. Also, your own application might apply different templates or styles to a control.

If you specify a FontFamily that does not exist, even if it is the only font family value available, Silverlight will still provide fallback to the Portable User Interface value for rendering purposes.

You can specify a font family either as a single font family name, or as a series of font family names that describe a fallback sequence. The separator between fallbacks (both for XAML, and for the string used to construct a FontFamily in code) is a comma. To avoid ambiguity, if a supplied font family name contains a comma in its internal value, then each single comma in the supplied font family name must be replaced with a double comma (,,).

If you specify a font family that is not typically present on a user's system, you may have to redistribute the font. Restrictions apply when specifying a font file or a zip containing font files.

Note:
As with most types of software, font files are licensed, rather than sold, and licenses that govern the use of fonts vary from vendor to vendor. As a developer it is your responsibility to ensure that you have the required license rights for any font you embed within a document or application, or otherwise redistribute.

In general. Silverlight processes XAML values that are actual URIs (or resemble a URI) through a fallback sequence of resource lookup. FontFamily values that have a URI portion are an important exception. The only places where a font file resource can be resolved is as a resource target within the current assembly.

For system fonts, you provide only the font family name, not the name of a font file. For instance, to specify a font family value of Verdana with an Arial fallback, you would specify this XAML: <TextBox FontFamily="Verdana,Arial"/>.

For non system fonts, a FontFamily will include a URI portion. The value of the URI portion for a FontFamily value depends on the relationship between the assumed base URI of the calling XAML file and the resource location of the font file in the assembly.

For example, if you are calling from a XAML file at the assembly and project root, and have included a font file as a same-assembly resource also at the project root, the URI portion is simply the font file name with no path. The specific font family within the font file is appended, with the URI portion and font family portion separated by a hash sign (#). For example: <TextBox FontFamily="Contoso.ttf#Contoso" />.

You can also use folders within your resource structure in the main assembly. For instance if your build structure contains a folder Fonts, your XAML is at the assembly root, and Contoso.ttf is a resource within that folder, you would use this XAML: <TextBox FontFamily="Fonts/Contoso.ttf#Contoso" />.

Another level of complexity emerges if the referencing XAML is in one structured folder of the assembly and resources are in another folder. For example, your project and assembly might be composed with the following structure:

SilverlightApplication1 (project root for creating assembly SilverlightApplication1)

XAML (a folder)

Page1.xaml (a XAML Page)

FONTS (a folder)

contoso.ttf (a Resource)

You could reference contoso.ttf from Page1.xaml using a relative URI that traverses upwards one level: <TextBox FontFamily="../Fonts/Contoso.ttf#Contoso" />

However, relative URI traversals can be fragile if you do any refactoring of content. To avoid this, another option is to use the component; qualifier along with a named assembly reference. In this case you are self-referencing the same assembly. The component; qualifier is a case-insensitive qualifier that is supported for any Silverlight URI usage, which informs the client that the path should be evaluated from the assembly root of the specified assembly. Using this technique, you can unambiguously refer to an assembly resource from an assembly no matter how the referencing XAML page and the referenced font resource are relatively pathed within the assembly. For example, the following is a usage that could find the Contoso font file from any frame of reference within the SilverlightApplication1 assembly: <TextBox FontFamily="/SilverlightApplication1;component/Fonts/Contoso.ttf#Contoso" />

A component; reference may also be useful if you are applying a root FontFamily value to a custom UserControl that is defined in another assembly, because the templated XAML for the UserControl when applied uses its own defining assembly for URI scope.

The [] and * characters in the XAML syntax are not literals. They are a convention to indicate that zero or more fallback font families can be specified in the syntax. The [] characters enclose the repeatable atom of the syntax, and the * character indicates the one-or-more convention if fallbacks are specified.

If you use the object element syntax, which is useful for declaring a FontFamily value within a ResourceDictionary, you must specify initialization text that names the font family name and possible fallbacks. Failing to specify initialization text results in a parsing error, because the underlying FontFamily constructor in the backing code requires a string.

Rather than specify a FontFamily as a URI in XAML, you can also specify a FontSource in code. This gives you more options for packaging or obtaining a font file. Basically you obtain a stream of either a font file or a zip of font files, and set FontSource using that stream. This is equivalent to specifying a URI portion of a FontFamily value, and makes that font file available to the object. All you need to do now is specify a fontFamilyName to reference one of the specific families in the current FontSource value. See FontSource.