I completely agree that it has been poor communication from Adobe, especially after what they have announced at AdobeMAX this year. So, timing could have been better and the messages that they initially shared could have been better formulated. Adobe acknowledges this and have sent out their apologies for that as well. But the harm was already done. I even saw people leaving prerelease and other programs (I can’t mention by name) furious about what happened and turning their backs on Adobe entirely. I respect those decisions, but come on, is it really such a bad thing?

For those of you who are not quite up to speed on what exactly is going on at Adobe. Let me briefly state the latest developments.

Let’s start with LiveCycle. For those of you who don’t know what LiveCycle is, it is a product that allows you to define information workflows, mainly based on PDFs. So, for example, you could fill out a job application form in a PDF, digitally sign it with you eID card (in Belgium at least) and send it to a specific email address. The PDF attachment gets picked up from the mailbox and the information is extracted and put in a database. After that a “thank you” email is sent to the applicant, while in the mean time the HR manager is notified of a new application. Upon approval by the HR manager in the so called “workspace” a new PDF is sent to the unit manager, notifying him that he should interview this candidate, together with the candidate’s résumé. After the interview the unit manager can then input his findings in a evaluation form and LiveCycle will pick that up as well to put it into the database and notify the HR manager that the evaluation has been submitted. Would the candidate be rejected, the can be marked in the “workspace” again for example, an automatic email will be sent to the candidate notifying him of his rejection.

Now, this is just one example of what LiveCycle can do. Even though Adobe is shifting its focus towards other strategic solutions, they will continue to develop LiveCycle (as you can read here), invest in finding new customers and product support is still guaranteed, so you’re not left alone with your solution if you’re currently using LiveCycle.

As for dropping the Flash Player on mobile devices, I don’t think that is a bad thing. You see, if Adobe wants to keep the same version of the Flash Player on all devices (desktop, mobile, tablet) then a lot of code will have to go in checking whether or not things certain features are available. This requires a lot of effort and slows down progress on the features that matter the most. I mean, come on, when did you actually use a Flash based website on you mobile device? Either it wasn’t mobile optimized causing frustration in content that is not scaled properly, or it just was overkill for a mobile device.

Now Adobe has the opportunity to focus on the desktop platform and make full use of the GPU hardware acceleration and other cool features that require more processing power than what the other devices can offer at this moment. It is clear that Adobe wants to move in the direction of gaming with Flash, which I have been expecting for some time now.

Remember, I just said that the Flash Player will be dropped on mobile. That does not mean that the cross-device AIR solution is being dropped. On the contrary! AIR for mobile devices will continue to be developed by Adobe and is one of the key products/features they will maintain. So you don't have to worry about your cross-device development.

However, the Flex SDK is going to be put into the Apache project, bringing along a new produt name as well, since Adobe won’t own the SDK anymore. Once the incubator is accepted, the product will be called "Apache Flex". You can read all about the Apache Flex Incubator right here.

That means that from that point on the SDK will be developed and maintained by the community. That will be a good thing in the sense that probably we’ll get more features more rapidly developed. But – and there’s a big "but" in here – I do see a problem in the adopt of the Flex technology in big companies. You see, what companies want is a support contract with time frame commitment. They want a red phone to the help desk when they encounter serious problems and at the moment they are paying big money for that. Once Flex is owned by the community, Adobe probably won’t be doing anymore support, because it is now up to the community.

This lack of support is what could harm Flex in the high end business companies. But then again, this will also lead to new opportunities for companies such as multimediacollege in the sense that we can now write and publish our own training material, as well as provide support contracts for helping out companies who need assistance with some Flex problems.

So, is Flex dead? Definitely not! And it isn’t dying either. We will have a huge community supporting the development and some highly skilled developers working on the features. I wish I had some magical device that allows me to see into the future to see what will happen with Flex when it becomes completely Open Source. But for now, I’m not yet worried about it’s future…

But for now, she’s not getting hold of the device, because I want to try several things out. And one of those things is the real cross-device development using the Flash Platform. In my case, that means Flex of course. That’s what I’ve be doing for the past couple of days and I must say it’s really working once you get the procedure down. That’s the tricky bit for now, so let me take you through my struggles and maybe I can save you from making the same endeavors as I needed in order to get it working.

Setting up the development environment

This is the first part you’ll have to go through. Blackberry has issued a tablet OS SDK, which is a plugin for Flash Builder that allows you to compile applications for the PlayBook directly from within Flash Builder. While this all sounds great, the latest releases of that plugin do not support Flex Mobile applications. That means you cannot use that SDK to compile your Flex Mobile application. You can only work with ActionScript Mobile application.

A second issue is the fact that the SDK is installed on top of an existing Flex 4.5 SDK and without giving away too much information, it is not compatible with all Flex 4.5 SDKs, so compiling and packaging the application from within Flash Builder is not possible with the latest versions. Hopefully BlackBerry will release another version of their SDK this is compatible soon.

Taking these two issues into accounad the fact that as a Flex developer I want to use a Flex Mobile project, I’ll have to package the application using the command line.

Compiling and packaging the application

Since the option of compiling directly for the playbook is not possible with the latest builds, I’ve used a little shortcut to get the release build of my application. I mean, if you’re working on a Flex mobile application and you compile using Flash Builder, you can only opt for the Android APK file. There is no release build that gives you the release version of the SWF file.

So that’s exactly what I’ve done. Then I unzipped the APK file and searched for the release version of my SWF file and used that to package my BAR file. The command to do the packaging is as follows

blackberry-airpackager -package <BAR file> <application>-app.xml <application>.swf blackberry-tablet.xml <assets required by the application>

Signing the application

Once you have the BAR file ready you have come to the trickiest part: signing the application. This is best done via command line again, but hopefully this will be included in the Flash Builder plugin once it’s updated to work with the latest builds and with Flex Mobile projects.

First, you need to be registered as a vendor with BlackBerry in order to obtain you code signing key. This is done only once per developer or company, depending on how you want to register yourself. Obtaining the key is done by filling out this form.

The key you receive will be a CSJ file. It all starts with that file, because now you have to register that CSJ file as well as create a keystore to communicate with the BlackBerry signing authority. So, we’ll start by setting up that keystore, which is done via the following command

blackberry-signer -csksetup -cskpass <create a password>

Then you need to register the CSJ file by using the following command

blackberry-signer -register -csjpin <PIN> -cskpass <csk password from previous step> <CSJ file>

The last thing to get you set up is to generate a coding certificate, a .p12 file that is not unlike the certificate you create for regular AIR applications. This is done by executing the following command:

blackberry-keytool -genkeypair -keystore <certificate.p12> -storepass <create a password> -dname “cn=<company name>” -alias author

Once you have this set up, you are all set to start signing your application. When signing an application for the BlackBerry App World you actually have to sign it twice. Once for the code signing itself and a second time to add the author data to the BAR file. This can be done by executing these two statements in this particular order.

blackberry-signer -verbose -cskpass <csk password> -keystore <p12 certificate> -storepass <certificate password> <application>.bar RDK

blackberry-signer -keystore <p12 certificate> -storepass <certificate password> <application>.bar author

If you go through this signing process several times, make sure that you increase the application versionNumber in the <application>-app.xml file every single time. Otherwise you will get the error message that the application was already signed.

Deploying the application on the device

At this point your application is ready to be submitted to the BlackBerry App World. However, you might want to install it on your own device already and not wait for approval. This can be done via command line too and it can only be done with the signed BAR file. Unsigned applications can be installed using a debug token that expires after 30 days, but the following command is not suited for that type of deployment. It will only work with signed BAR files.

blackberry-deploy – installApp -device <device IP> -password <device password> <application>.bar

When you execute this command the application will be installed on your BlackBerry PlayBook and you can run it as if you installed it through the App World.

This might not be the best way to get your Flex Mobile application on the PlayBook, but it sure has worked for me and as far as I know it is the only way to do this with my current setup of Flash Builder and PlayBook SDK.

If someone has a better way of doing this, please let me know as I find this not an easy process to do (what should be) a simple task

First thing to do, and this is what I always tend to do, is to export your Flash Catalyst components as a Flex library project. This allows you to get around the roundtripping issue, because this library project only contains Flash Catalyst generated components and will therefore remain compatible with Flash Catalyst when you need to alter the design at some point in the future.

Skinning your actual project is then done by linking the SWC file from the library project to your actual project and applying the proper skin to the component using the skinClass property. Now to be able to work with this properly, you’ll need to create a manifest file for that library as well. This will allow you to use only one single namespace for every component/skin in the library, even though the components/skins may reside in a number of packages.

Now, this approach will definitely work, but you still have to apply the skinClass property to every component in your application. However, you can apply all the styling on your application by defining a theme CSS that accompanies the SWC file containing the skins. Let me briefly explain this process by creating a very small example.

In this example I’m going to create a skin for a single component, namely the HSlider component. I want to make it look a little bit like the iOS slider, where you have a colored fill of the slider bar that follows the slider thumb position. To make things easier, I’m going to start out in Flash Catalyst. I simply create a new project with the default settings and I’m going to create the skin from scratch. Of course, you can certainly start out with an Illustrator or a Photoshop file. The process of creating the skin will remain exactly the same.

First I need to create the track and duplicate that layer to have the fill color as a separate item. Next, I’m creating the thumb for the slider by drawing two concentric circles with opposite gradients, one a little smaller than the other, to create a semi 3D lighting effect. The result looks like the image below.

The next step is to convert that design into a working component. Now, in Flash Catalyst, unless you’re putting components on the artboard, you actually just create some skin files. So, using the Heads-Up Display (HUD) I convert the artwork into a horizontal slider. After indicating the track and thumb, my skin file is now ready to be imported into Flash Builder.

Since I’m going to be creating a Flex theme, I don’t just save the Flash Catalyst project and open it in Flash Builder. I’m actually going to export the library components as a Flex library project (FXPL), as shown below. When you import the FXPL file into Flash Builder it will automatically create the library project for you.

If you look at the code now, you’ll see that the size of the slider skin is fixed. But since I want to create a theme that can be used in any circumstance and in any project, I need to make a few adjustments to the generated code to make the skin more dynamic. For that I’m going to make use of the [HostComponent] metadata tag. This gives me a reference to the actual component that this skin is applied to. Therefore I can get the size of that component and adjust the skin accordingly. The adjusted code for the main HSlider skin looks like this.

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:s="library://ns.adobe.com/flex/spark"
		xmlns:fx="http://ns.adobe.com/mxml/2009"
		width="300" height="17">
	<fx:Metadata>[HostComponent("spark.components.HSlider")]</fx:Metadata>
	<s:states>
		<s:State name="normal"/>
		<s:State name="disabled"/>
	</s:states>
	<s:Button id="track" x="0" y="5" skinClass="components.IOSSliderTrackSkin" width="{hostComponent.width}"/>
	<s:Rect x="1" y="6" width="{thumb.x + (thumb.width / 2)}" height="6" radiusX="10">
		<s:fill>
			<s:LinearGradient rotation="90">
				<s:GradientEntry alpha="1.0" color="#009CFF" ratio="0"/>
				<s:GradientEntry alpha="1.0" color="#002FD1" ratio="1"/>
			</s:LinearGradient>
		</s:fill>
	</s:Rect>
	<s:Button id="thumb" x="134" y="0" skinClass="components.IOSSliderThumbSkin"/>
</s:Skin>

You’ll notice that I’ve bound the colored rectangle’s size to the position of the center point of the thumb. This will assure that the colored section follows the slider thumb position instead of being static and covering the whole component.
Now, the default size for the slider is 300 pixels, but if you specify another width, the component will be resized properly. I didn’t take the height into account for this simple demo, but similarly you can also adjust the height of the component according to the height specified in the application.

Next thing to do is to create a CSS file that attaches this skin to all HSlider components. This is very simple and straightforward, as you can see in the code below.

/* CSS file */
@namespace s "library://ns.adobe.com/flex/spark";
@namespace fc "http://ns.adobe.com/flashcatalyst/2009";
 
s|HSlider {
	skinClass: ClassReference("components.IOSSlider");
}

OK, so now our theme is ready to be used. There are a couple more steps to take before you an actually use it. First of all, you need to compile the library project, so you can link it to the actual project that you are going to apply the theme to. Since I’m using Flash Builder with automatic builds, this is already taken care of.

The next step is to load the CSS file into the theme selector, so you can actually apply the theme to the project using a few very simple clicks. For that, I’m going to the Design view in my project and click on the Current Theme link in the Appearance panel. This brings up the theme selector dialog.

In that dialog I’m importing the new theme by selecting the CSS file that I’ve just created and giving it a proper name. Since I’m going for an iOS look, I’ve simply named it iOS. Now, after the import, you can see the new theme displayed in the list of themes to choose from. So, obviously I choose that theme and click OK.

Now that I have the new theme applied to the project, I can simply use a HSlider component in my application and it will automatically be styled according to the settings in the them. To prove that the theme is dynamically adjustable, I’m creating a component with a width property of 500 pixels.

If you compile the application now, you would get some errors, because the skin files cannot be found. The very last thing I need to do is to link the theme’s SWC file to my project. In this example I’ve just copied the SWC file to the libs folder in my project. However, you could create a RSL (Runtime Shared Library) even to have your theme deployed separately and only once for all your projects. The big advantage is that your resulting project SWF file doesn’t get affected by the theme and when you alter your theme, you can just deploy that RSL and every project that uses that theme will automatically be updated next time it is started up.

The result is a working slider bar that has dynamic content and is styled via a Flex theme inside of Flash Builder. Just try out the example below to see the result.

One such an improvement is the fact that you can now create your own custom components with skin parts in Flash Builder and use that component in the HUD (Heads-Up Display) in Flash Catalyst. That means that you’re no longer only working from Flash Catalyst towards Flash Builder, but you can go the other way around as well. Let me show you how.

First, you need to create a Flash Catalyst Compatible Project, which is just another option from the File > New menu. In the project you have to create an ActionScript Skinnable Component, which can again be found in the File > New menu. When you do this, make sure that you have the Generate Comments option checked in the popup dialog, because it will help you a lot in creating your first components.

In the ActionScript file, you define a couple of skin states using the [SkinState] metadata tag. In this example, we are going to create an “open” and “closed” state. Then you also need to define the skin parts. This is done by using the [SkinPart] metadata tag. Optionally you can make skin parts required by defining the metadata tag as follows: [SkinPart(required:"true")]. When we define a button, text input field and a label in the skin, the resulting file will look like this.

package
{
	/* For guidance on writing an ActionScript Skinnable Component please refer to the Flex documentation: 
	www.adobe.com/go/actionscriptskinnablecomponents */
 
	import spark.components.Button;
	import spark.components.RichText;
	import spark.components.TextInput;
	import spark.components.supportClasses.SkinnableComponent;
 
 
	/* A component must identify the view states that its skin supports. 
	Use the [SkinState] metadata tag to define the view states in the component class. 
	[SkinState("normal")] */
	[SkinState("open")]
	[SkinState("closed")]
 
	public class MyCustomComponent extends SkinnableComponent
	{
		/* To declare a skin part on a component, you use the [SkinPart] metadata. 
		[SkinPart(required="true")] */
		[SkinPart(required="true")]
		public var input:TextInput;
		[SkinPart(required="true")]
		public var button:Button;
		[SkinPart(required="false")]
		public var label:RichText;
		[SkinPart(required="true")]
		public var resizeButton:Button;
 
		public function MyCustomComponent()
		{
			//TODO: implement function
			super();
		}
 
		/* Implement the getCurrentSkinState() method to set the view state of the skin class. */
		override protected function getCurrentSkinState():String
		{
			return super.getCurrentSkinState();
		} 
 
		/* Implement the partAdded() method to attach event handlers to a skin part, 
		configure a skin part, or perform other actions when a skin part is added. */	
		override protected function partAdded(partName:String, instance:Object) : void
		{
			super.partAdded(partName, instance);
		}
 
		/* Implement the partRemoved() method to remove the even handlers added in partAdded() */
		override protected function partRemoved(partName:String, instance:Object) : void
		{
			super.partRemoved(partName, instance);
		}
 
	}
}

Once you’ve completed the ActionScript Skinnable Component you then have to export the project by choosing Project > Flash Catalyst > Export Flash Catalyst Project. In Flash Catalyst you then have to open the FXP file to work on the project. Then you create some graphics to represent the component. You may end up with something like this.

The next step is where the magic happens, because when you select all of the graphics and you look in the HUD, you’ll notice that you can now convert those graphics into a Skinnable Component. This is the last option in the conversion dropdown. Once you’ve selected that option you’ll get a popup dialog which allows you to choose which component if you have more than one skinnable component available.

In this dialog you also have the option to load an FXPL library project in case the component you want is not yet loaded into the project. But since we’ve created the component inside of the project, we’re already having the component available. So, select that custom component and click OK. Once you’ve done that, you’ll notice that Flash Catalyst indicates that the component still needs some work, since you need to indicate all of the different skin parts you’ve defined earlier in Flash Builder.

Digging into the component, you’ll also notice the two skin states you’ve defined earlier on as well, which allows you to work with these different view states for your custom component. Now, assign the different skin parts and make some changes to the closed state to have two distinct states. For example, you can remove the label, resize the colored rectangle and change the label of the resize button in the closed state. Don’t forget to capture the click on the resize button to change view states at runtime.

As a final step, you just have to save the project and import it again in Flash Builder. You can overwrite the existing project now and when you run it, you’ll notice that the component is fully functioning now, as you can see below. Just hit the resize button to see it in action.

But all that hard work is now done for the first time, so it should become a little easier for the next couple of tutorials. So, if you fancy the visual side of tutorials instead of just reading the blog post, you can now view my very first one here. Of course, you can still read the blog post on the subject in the blog section of the Flexpert website.

Enjoy !!!

When I’m using view states, I apply transitions to make the view state changes more fluent an attractive. There seems to be a problem though, because when I have a component in the second view state that I want to fade out upon returning to the base state, that effect is never played. Do you have a clue why this doesn’t happen and if there a solution for this problem?

Solution:

If you are using view states and want to apply certain transitions between these states, there are some things to keep in mind. When adding components to a state, the transition effects (also called behaviors) are applied to that component while adding it. So this means that the effects will be visible during initialization of the view state. However, when you go back to the original base state, the component is removed again before the effects have had the chance of being displayed. Luckily, in Flex there are a couple of ways of dealing with this issue.

The first way of making sure the effects are visible is to not make use of a transition when going back to the base state. Instead, you use the effect triggers of the component itself to trigger the effect. When the component is removed, you need to use the removedEffect trigger like in the following example:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
 
<!-- The font needs to be embedded for the texxt to fade out
as well. Otherwise, the button will fade, but the text
will simply remain fully opaque througout the effect -->
<mx:Style>
@font-face {
src: local("Verdana");
fontFamily: myFont;
fontWeight: bold;
}
 
global {
fontFamily: myFont;
}
</mx:Style>
 
<!-- This is the Fade effect we are going to use when the component is removed 
          from the display list -->
<mx:Fade id="fade" alphaFrom="1" alphaTo="0" duration="2000"/>
 
<!-- Define the view state -->
<mx:states>
<mx:State name="extraButton">
<mx:AddChild>
<!-- This button will fade in through the transitions and will fade out via the 
          removedEffect trigger -->
<mx:Button id="btn2" label="Click me now" click="currentState=''" removedEffect="{fade}"/>
</mx:AddChild>
</mx:State>
</mx:states>
 
<!-- Define the view state transition -->
<mx:transitions>
<mx:Transition fromState="" toState="extraButton">
<mx:Fade target="{btn2}" alphaFrom="0" alphaTo="1" duration="2000"/>
</mx:Transition>
</mx:transitions>
 
<!-- This component will be visible by default and triggers the second view state -->
<mx:Button id="btn1" label="Click me" click="currentState='extraButton'"/>
 
</mx:Application&gt;

The problem with this approach is that the transition effects are scattered throughout your code. However, there is also a second, in my opinion more appropriate way of dealing with this transition problem and that is through the use of transitions. This means that all of your transitional code will be located in 1 spot and this is so much easier to maintain.

But how do we solve the issue of the effect not being shown? Well, in fact (and this is not often mentioned in books and courses), you do have total control of when an item is being added or removed considering the effects that need to be played on the component. To do this, you can simply use the <mx:AddChildAction> and <mx:RemoveChildAction> tags. Just place them in the right order within a <ms:Sequence> tag after the appropriate effect and your effect will be displayed properly. Just take a look at this example code:<

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
 
<!-- The font needs to be embedded for the texxt to fade out as well.
Otherwise, the button will fade, but the text will simply remain fully opaque
througout the effect -->
 
<mx:Style>
@font-face {
src: local("Verdana");
fontFamily: myFont;
fontWeight: bold;
}
 
global {
fontFamily: myFont;
}
</mx:Style>
 
<!-- Define the view state -->
<mx:states>
<mx:State name="extraButton">
<mx:AddChild>
<!-- This button will fade in and out through the transitions -->
<mx:Button id="btn2" label="Click me now" click="currentState=''"/>
</mx:AddChild>
</mx:State>
</mx:states>
 
<!-- Define the view state transition -->
<mx:transitions>
<mx:Transition fromState="" toState="extraButton">
<mx:Fade target="{btn2}" alphaFrom="0" alphaTo="1" duration="2000"/>
</mx:Transition>
 
<!-- The fade out effect is accomplished by adding a sequence with the 
          RemoveChildAction after the effect -->
<mx:Transition fromState="extraButton" toState="">
<mx:Sequence target="{btn2}">
<mx:Fade alphaFrom="1" alphaTo="0" duration="2000"/>
<mx:RemoveChildAction/>
</mx:Sequence>
</mx:Transition>
</mx:transitions>
 
<!-- This component will be visible by default and triggers the second view state -->
<mx:Buttonid="btn1" label="Click me" click="currentState='extraButton'"/>
 
</mx:Application>

You can view the results of the latter solution in the application below.

I’m trying to develop a Flex application that uses a Text component which will take an html rendered text. So far, no problem there. However, I would like to use more than 1 font (regular, bold, italic) in this text component and I’m not sure if the fonts are all on the user’s computer. What’s the best way of tackling this problem?

Solution:

If you don’t know for sure the fonts are installed on the user’s computer (because it’s some exotic font or some typical OS dependant font, the best way of dealing with that would be to embed the font in your Flex application (or any Actionscript application). Now, how do you do this exactly when you want to embed multiple fonts for a single component? Well, I’ll show you.

There are actually 3 ways of embedding your fonts in an application:

1. embed fonts in your Actionscript code
2. embed fonts directly in CSS
3. embed fonts in CSS using a SWF file that has (part of) the fonts embedded

1. Embed your fonts directly in Actionscript

To embed a font in Actionscript, you’ll have to assign it to some static variable to be able to incorporate it in the compilation of your application. Just before that variable definition, you specify a metadata tag “Embed” (just like you would if you were to embed an image). The properties for this metadata tag are:

• source: the location of your font file
• fontName: the name you want to use in the application for your font. I’ve chosen to use myFont to indicate it can be anything you like. But you could also choose the font name itself if you prefer it like that
• fontStyle: italic if it is an italic font (can be in combination with fontWeight)
• fontWeight: bold if it is a bold font (can be in combination with fontStyle)
• mimeType: e.g. application/x-font-truetype if it’s a truetype font

Repeat this step for all the different fonts you want to embed, but make sure that the fontName property is exactly the same for all of them. So, when for example you want to embed a Verdana font in regular, bold, italic and boldItalic, your code would look something like this:

[Embed(source="C:\\Windows\\Fonts\\Verdana.ttf",
       fontName="myFont",
       mimeType="application/x-font-truetype")]
public static const VerdanaTTF:String;
 
[Embed(source="C:\\Windows\\Fonts\\VerdanaBold.ttf",
       fontWeight="bold",
       fontName="myFont",
       mimeType="application/x-font-truetype")]
public static const VerdanaBoldTTF:String;
 
[Embed(source="C:\\Windows\\Fonts\\VerdanaItalic.ttf",
       fontStyle="italic",
       fontName="myFont",
       mimeType="application/x-font-truetype")]
public static const VerdanaItalicTTF:String;
 
[Embed(source="C:\\Windows\\Fonts\\VerdanaBoldItalic.ttf",
       fontWeight="bold",
       fontStyle="italic",
       fontName="myFont",
       mimeType="application/x-font-truetype")]
public static const VerdanaBoldItalicTTF:String;

2. Embed your font directly in CSS

Now, you can do exactly the same using only an external CSS file. The embedding part itself is a little bit different though. You would have to use the @font-face style for each of the separate font styles you want to incorporate in the resulting SWF file and provide it with the following attributes:

• src: the location of your font file.
• fontFamily: the name you want to use in your application for your font. Again, I’ve chosen to use myFont to indicate it can be anything you like. But you could also choose the font name itself if you prefer it like that
• fontStyle: italic if it is an italic font (can be combined with fontWeight)
• fontWeight: bold if it is a bold font (can be combined with fontStyle)

The src style attribute can either point to a file on the local file system or to a file somewhere on the web or another location. For embedding a font which resides on the local file system, you would specify local(“<font name>”) . The font name will remain the same for all the variations you want to embed, because it’s the style attributes that will make up the difference here. You’ll probably use this local specification most of the time, because you’ll probably want to embed a font that you have on your own computer. However, if you were to incorporate a font file which resides somewhere on a remote location, you would use url(“<path to font file>”). This path can either be a relative or absolute path.

Of course you need to repeat the @font-face style for every font variation you want to embed. Again, make sure that the fontFamily property is exactly the same for all of them, because you will use that name in the fontFamily attribute of the style you are going to apply on the component in order to use the different font styles.

For the same Verdana font definitions, your code should look like this:

@font-face {
	src: local("Verdana");
	fontFamily: myFont;
}
 
@font-face {
	src: local("Verdana");
	fontFamily: myFont;
	fontWeight: bold;
}
 
@font-face {
	src: local("Verdana");
	fontFamily: myFont;
	fontStyle: italic;
}
 
@font-face {
	src: local("Verdana");
	fontFamily: myFont;
	fontWeight: bold;
	fontStyle: italic;
}

3. Use a SWF file with partially embedded fonts

These first 2 methods work just fine. However, they do add several hundreds of kilobytes to your SWF file size. And this is only for 1 specific font, so imagine what it would do to a SWF file that compiles a couple of fonts into your application. This is due to the fact that a font is more than just alphabetical characters. Most of the time you don’t need all of those characters, but just the basic ones like digits, lowercase and uppercase letters and punctuation signs.

Fortunately, there is also another solution that allows you to limit the number of glyphs (this is what the individual font signs are called) to incorporate in your application. To be able to do this, we are going to have to take our development out of Flex Builder (or Flash builder of course) and bring it into Flash.

So, in Flash, you start by creating a new ActionScript 3 Flash file. On the stage, you place a text field and type some text. In the properties of that text field, you have to set it to Dynamic Text. In the Character subframe of the properties panel, you then select the font you want to embed as well as the style (regular, bold, italic or bold italic).

At the bottom of that same properties panel, you also see a button labeled “Character Embedding”. Just click on that one and you’ll get a dialog box which allows you to select the glyphs you want to embed in the Flash file. Select the uppercase, lowercase, numerals and punctuation glyphs and click ok to embed them in the SWF.

Now, perform the same procedure for the other font styles you want to embed, so you’ll eventually end up with 4 different dynamic text fields that all include a different style of your font.

The next step is then to compile your SWF file, so you can use it in your Flex or AIR application. To do that, you’ll first have to go to the Publish Settings, which you can find in the File menu. In the Format tab of the settings dialog, make sure that only Flash type is selected and then click on Publish. A SWF file will now be generated and that file will contain all the characters from the different font styles that you’ve just indicated.

Go back to Flex Builder (or Flash Builder of course) and add a fonts directory to your project. In this directory you place the SWF file that you have just generated. Now, to actually use the embedded fonts from the SWF file, we have to rely again on CSS. This is quite similar to the second method I’ve explained. However, this time the fontFamily property must be exactly the same as the actual font that you have included. So, in my example here, it has to be “Verdana”. You cannot choose the fontFamily name you want to use in your application freely anymore.

So, enter the different @font-face styles that match the embedded fonts from the SWF file in the same way as you would do when using the second method, bearing in mind that the font name is fixed now. Your code should look like this:

@font-face {
	src: url("../fonts/Verdana.swf");
	fontFamily: Verdana;
}
 
@font-face {
	src: url("../fonts/Verdana.swf");
	fontFamily: Verdana;
	fontWeight: bold;
}
 
@font-face {
	src: url("../fonts/Verdana.swf");
	fontFamily: Verdana;
	fontStyle: italic;
}
 
@font-face {
	src: url("../fonts/Verdana.swf");
	fontFamily: Verdana;
	fontWeight: bold;
	fontStyle: italic;
}

When you take a closer look at the generated SWF file, you will certainly notice a big difference in file size between the first 2 methods and this last one. This is because now, not all glyphs are embedded in the SWF file.

All you have to do now, is just set the fontFamily for the necessary components to the name you’ve just used in your CSS or Actionscript style embedding of the fonts, make sure you use the htmlText property and you’re all set to go.

This is the very first post on this website to clarify a little bit what the flexpert is all about. This is by no means intended to be just another blog about Flex, AIR and LiveCycle related subjects. For techical matters on those things, I kindly refer to our company’s blog at http://blog.multimediacollege.be.

This site however is meant to be a site with specialist info on those topics with articles on demand. However, I’m not starting up a helpdesk website with trivial issues which can easily be found by using google. So please, no ordinary requests about how to structure a project or whether or not to use VBoxes and HBoxes. Every other technical or analytical request is welcome and I’ll try to write an interesting article about it, hoping the community can benefit from it.

If you have a request, please use the contact form on this website and I’ll try to convert it into an article as soon as possible.

So bring on those requests,

The flexpert