Gergely on .NET

Using built-in, embedded and streamed fonts in Silverlight

March 1st, 2010

Silverlight gives the developer the possibility of completely customizing the developed application in all aspects. Defining fonts used for displaying text is no exception. However there are multiple ways on how to go ahead with specifying fonts to use, this article attempts to summarize the options.

Using built-in fonts

Silverlight comes with some fonts that can be used by default, often referred to as built-in fonts. This naming is not entirely correct as the Silverlight runtime does not contain any fonts. However if the specified font is present on the machine, it can be used by Silverlight. The list of these fonts can be found here.

Even though the list contains about 40 fonts, the selection is different on clients running Windows and those running OS X. The “web safe” list – the fonts that are generally installed on both Windows and OS X – are the following subset: Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Lucia Grande, Lucia Sans Unicode, Times New Roman, Trebuchet and MS Verdana.

To specify a font of the default font types, simply specify the FontFamily property of the visual element:

<TextBlock FontFamily="Arial Black">Hello, World!</TextBlock>

(Note that if the specified font can not be found on the client, Silverlight will fall back to the basic font type.)

Application displaying all of the built-in fonts available in Silverlight

To visualize the fonts available in Silverlight I’ve created a small application that lets one play around with the default fonts:

You can download the source of the example here.

Using embedded fonts

The problem with the default fonts is that the ones to choose from is quite limited and not all of them are available on client machines. To overcome this problem, Silverlight allows specifying custom fonts.

To use an embedded custom font, simply add the font file to the Silverlight solution as a resource. This font file then has to be referenced in the FontFamily property of the visual item, adding the exact name of the font family after a hash mark:

<!-- In this example AAJAX.TTF is the font file and the name of the font is AajaxSurrealFreak -->
<TextBlock x:Name="MainText" FontFamily="Fonts/AAJAX.TTF#AajaxSurrealFreak" FontSize="16">Hello World!</TextBlock>

(Note that the name of the font family can be seen when opening the font file.)

Using streamed fonts

Embedded fonts are a powerful and simple way of using custom fonts. However the drawback of them is that the fonts are included in the xap file increasing its size and the download time of the application. In certain scenarios it would be more advantageous to have the fonts loaded on demand. Silverlight makes this possible as well by providing the FontSource property:

private void ChangeFontButton_Click(object sender, RoutedEventArgs e)
{
    // Start downloading the font
    WebClient wc = new WebClient();
    wc.OpenReadAsync(new Uri("/ClientBin/BaroqueAntiqueScript.ttf",UriKind.Relative));
    wc.OpenReadCompleted +=new OpenReadCompletedEventHandler(wc_OpenReadCompleted);
 
}
 
void wc_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{
    // Once the font stream is read, set the FontSource to this
    MainText.FontSource = new FontSource(e.Result);
    MainText.FontFamily = new FontFamily("Baroque Antique Script");
}

Embedded and streamed fonts in action

I’ve put together a simple project demonstrating the usage of an embedded font and dynamically loading another font via streaming. Click on the button to in the example to change the font on the fly by loading the font file from the server:


Get Microsoft Silverlight

You can download the source of the example here.

Summary

Silverlight offers a plenty of options when it comes to working with fonts. Using default fonts is the simplest way to go, however one must be aware that Silverlight only uses fonts that are available on the client machine therefore only widespread fonts should be defined this way. If the font used is not always (or no even commonly) available on client machines, the fonts should either be shipped within the xap file or dynamically downloaded when needed. This tutorial has shown examples on how to implement the above mentioned three use cases.

(Note that the above example uses the freely available fonts Ajax Surreal Freak and Baroque Antique Script.)

Related post: Silverlight v3 ClearType Font Rendering – A comparison

Behaviour Driven Development for .NET developers

November 11th, 2009

On the Scot ALT.NET meeting held on 4th November Robert Lewis gave a talk on BDD explaining the basics, motivations and demonstrating the .NET tools available to support this methodology. I found the talk to be really interesting, mostly because Robert was focusing on the practical side of BDD – that is how .NET developers can use this methodology and at what projects might this be beneficial.

What is BDD?

If you haven’t heard of BDD yet, Dan North’s Introducing BDD or the BDD summary on Wikipedia is a good place to start. In a nutshell BDD is making another step of abstraction from TDD with the help of Domain Driven Design.

Instead of specifying atomic level unit tests, it tries to describe the desired behaviour of the software with natural language sentences. These sentences can then be written by the non-technical end users allowing them to get involved in the testing process. The sentences – often referred to as user scenarios – are then implemented by the developer as a series of unit tests.

BDD Frameworks for .NET

There are currently two BDD frameworks .NET developers can use to implement this methodology: NBehave and the IronRuby compiled version of Cucumber.

NBehave is a .NET version inspired by Dan North’s JBehave. It basically allows user defined stories in a text file to be mapped to a series of test functions. For example the sentence “Given I have logged in to the system, when I start a new transaction, then I will have to enter my password” can be mapped to the test functions:

[ActionMethod]
public void Given_I_have_logged_in_to_the_system() 
 
[ActionMethod]
public void When_I_start_a_new_transaction() 
 
[ActionMethod]
public void I_will_have_to_enter_my_password()

The mapping can be be done in a more readable way, by having attributes containing the mapping strings e.g.

[ActionStep("I have logged in to the system")]
public void Login()

The framework goes through the user defined sentences, does the mapping and outputs whether the user stories have failed or succeeded. This way BDD can be implemented via the Red-Green-Refactor cycle which is familiar to ones using TDD.

NBehave has support for using regex expressions when mapping user stories and test functions which gives it a larger flexibility compared to having to define individual test methods for every test. It’s also worth noting that it supports most .NET unit testing libraries suggesting integration into existing projects using these libraries is smooth.

The main drawbacks of the framework are that it’s not really documented and there’s no support for defining the same user stories with different parameters – you have to write them down again each.

Cucumber is a Ruby based tool which seems to be better documented and more feature-rich than NBehave (e.g. having the support for defining parameters for a given user story in a table-like format). Thanks to the IronRuby implementation it can be compiled to run on .NET.

However the performance of the application is really slow at the moment – probably due to the limitations of IronRuby. Both Robert Lewis and the audience at the ALT.NET event agreed that IronRuby has to improve before Cucumber could be used in production.

Summing it up there is some existing .NET BDD support but at the moment it seems quite basic. If you want to integrate BDD in your project the best bet at the moment would be NBehave – or if you have specific needs then implementing a tool for yourself.

When and how does BDD help me?

Just as any other agile methodology, BDD is not a universal solution and won’t always help your software process. As it’s basically another abstraction over TDD it is a more expensive process so it’s unlikely to be efficient in small projects.

BDD can be a realistic option in complex projects where TDD approach does not work well or it’s hard to automate lots of tests. BDD might help at these projects to help describe complex test cases in a simple format. It can thus allow to focusing on the big picture instead of getting lost in small details.

One of the biggest strengths of BDD is that when using this methodology customers get involved in the software development cycle from end to finish. In the classical approach, conversation between the customer and developer in the software development life cycle only tends to happen at the testing phase. If this conversation starts sooner than the testing phase, issues due to previous miscommunication will be identified sooner and fixing them will cost less.

BDD brings this conversation to the very start of the process by having the customer defining the user stories. If communication is critical with your customer then implementing BDD – or at least some methodology that helps the customer be involved from start to finish – is an option to be seriously considered.

To sum it up, BDD is a methodology that is quite fresh and gaining more and more attention. Tools in the .NET world are not really mature but they’re constantly evolving. The principle however I think is really viable and if you’re working on larger projects or on special fields where TDD does not deliver satisfying results then BDD just might be a better option for you.