Blog

Posts Tagged ‘font’

Converting Fonts to the PostScript Format

Wednesday, December 16th, 2009

I’m writing this post as a follow-up to the Adobe Captivate Font Rendering post from October because an issue was left unresolved. If the standard font formats are OpenType and TrueType, and even the Adobe Collection of fonts distributed with Adobe programs contains all OpenType fonts, where canyou find the PostScript fonts you need for Captivate projects?

Of course you could purchase them, but that’s not ideal. The price for the PostScript version of one of our client’s fonts is $500 because it’s packaged with the TrueType version (which we already have).

So I searched the Web for an open source converter and found FontForge. To install FontForge on a Windows OS you must also install cygwin. On a Mac you need to install the X11 server. Cygwin and the X11 server will make your machine look enough like a UNIX machine to run the program. This is a fine solution for a developer or technology-savvy person, but I know our Instructional Designers who use Captivate will certainly be intimidated and deterred by the process.

The best solution I found for converting any type of font to a PostScript format is FontLab‘s product TransType Pro, which costs $179. Unfortunately the demo download for TransType does not allow you to test the conversion of a font to PostScript. Although FontLab products come with a 60-day money-back guarantee, if you wish to test a conversion before making a purchase, you may use the demo download for FontLab Studio to convert 20 characters of your font set. You can then test the font in Captivate using only those 20 characters to see if the conversion will meet your standards.

Alternative Method to Display HTML Text in Dynamic Textfields

Wednesday, December 9th, 2009

I have been trying to figure out the best way to display HTML text in dynamic text fields for ActionScript 3.0 projects over the past six months. The best solution for Five Star is one that keeps the file size small, is versatile enough to handle different fonts with ease and adapts to different projects with little or no customization.

The solution that has evolved is a function named DisplayText, which I have copied below. The comments explain how the function works and an example call is included.

If you try implementing this solution and find it useful, if you need help or would like to enhance it, please leave a comment below.

/**
 *  Takes a string of text that may have bold and italic tags.
 *  Displays string properly in an HTML TextField by replacing the bold and italic
 *  tags with font tags.
 *  Fonts should be linked in the library.
 *  Each version (regular, bold, italic) should have its own link.
 *  If 2 versions of the font (ex. regular and italic) have the same name
 *  in the Font Symbol Properties dialog Font menu you don't need specify the italic
 *  or bold version.
 *  Example Call:
 *   var s:String = "Hi, and welcome to <b>Lesson 1:</b><i>Topic 1</i>."
 *   DisplayText( display_txt, s, 13, "Franklin Gothic Book", "Franklin Gothic Demi" );
 * @param    tf                TextField to format
 * @param    s                 Text to place.
 * @param    size              Size of text display.
 * @param    defaultFont       Regular font.
 * @param    boldFont          Optional. Bold font.
 * @param    italicFont        Optional. Italic font.
 */
 function DisplayText ( tf:TextField,
                         s:String,
                         size:Number,
                         defaultFont:String,
                         boldFont:String = "",
                         italicFont:String = "") : void
 {
     tf.htmlText = true;              // Set this to allow HTML text to be set
     tf.embedFonts = true;            // Set embed fonts to true
     tf.text = s;                     // Assign text - but not as htmlText yet

     // If a bold font is specified, replace bold tags
     if ( boldFont != "")
     {
         var boldStart:RegExp = /<b>|<B>/gi;            //    Match opening bold tags
         var boldEnd:RegExp = /<\/b>|<\/B>/gi;         //    Match ending bold tags

         tf.text = tf.text.replace( boldStart , "<font face='" + boldFont + "'>" );
        tf.text = tf.text.replace( boldEnd , "</font>" );
     }

     // If a italic font is specified, replace italic tags
     if ( italicFont != "")
     {
         var italicStart:RegExp = /<i>|<i>/gi;          //    Match opening italic tags
         var italicEnd:RegExp = /<\/i>|<\/I>/gi;        //    Match ending italic tags

         tf.text = tf.text.replace( italicStart , "<font face='" + italicFont + "'>" );
         tf.text = tf.text.replace( italicEnd , "</font>" );
     }

     // Wrap the text in a tag defining default font face and size
     tf.text = "<FONT FACE='" + defaultFont + "' SIZE='" + size + "'>" +
                tf.text + "</FONT>";
     // Assign the text
     tf.htmlText = tf.text;
 }

Adobe Captivate Font Rendering

Friday, October 16th, 2009

The Problem

When trying to create a theme for Captivate, I discovered our client’s preferred font, Whitney set to 12 pts, which was illegible in the program and in the published SWFs. So I did some research on font rendering in Captivate and came across several possible solutions. Below is a summary of my research, test results, and conclusions:

The Research

I started by searching the web for documentation on Captivate’s font rendering engine and I requested information from RJ Jacquez, the Adobe Evangelist for Captivate. The web search for documentation resulted in one useful article on the CommunityMX web site: Text in Captivate, by Tom Greene. The article does not have a date but the support file for this article was dated 9/12/2005, therefore I assumed it was written about one month after Flash 8 Player was released and the author would have been using Captivate 1. Considering the age of the article I read it with caution.

According to Greene, Captivate turns letters into bitmaps, using Microsoft products such as MS Word as the benchmark for font rendering. The Captivate team chose to do this rather than use the Flash font rendering engine because Flash could not display small point sizes adequately. Greene would have preferred the Captivate team to just inform developers to stop using bitmap fonts. One additional issue with Captivate is that Captivate displays fonts 2-3 points larger than Fireworks, so a 9 pt Arial in Captivate looks like 12 pt Arial in Fireworks.

I requested help from Jacquez through Twitter (@rjacquez). At first he replied saying he would look into my problem and get back to me as soon as possible. He later replied that he is “not in documentation” but would share my query with the team. A dead end for me… and so it was time to sit down and do some testing to see if Greene’s insights would still hold true with the Flash Player 10 and Captivate 4.

The Testing

Initially I set up a font test in Captivate and one in Flash using Postscript, TrueType and OpenType fonts. Below is a screen capture of my results. Notice how all the fonts in Captivate have jagged, unaliased edges while the Flash fonts are smooth because they are aliased. The distortion of the Captivate fonts is worse for OpenType and TrueType fonts because Postscript fonts are meant to be rasterized for print, and therefore look better when they are rasterized and turned into bitmaps.

Although these were the results I should have expected after reading Greene’s article I was still surprised. The OpenType format was developed by Microsoft in partnership with Adobe, and Adobe has a set of OpenType fonts they distribute for use with their programs, so I never would have expected one of their products would do such a poor job of displaying those font types.

Lastly, take note of the variation in display size between the Captivate and Flash fonts, despite all fonts being set to 25 pts. I measured the difference between the first letter in the Captivate font and compared it to its Flash partner. For each font the Captivate display was 5-7 pixels larger!

This test reveals that the information in Greene’s article from 2005 still holds true. The basis of Captivate’s font rendering engine has not been improved since Captivate 1. The next step was finding a work around.

The Solutions

My mind first jumped to embedding the fonts in Captivate. There is no embed option in the program so I thought I might be able to place a Flash SWF embedded with the fonts in the Captivate project. When that didn’t work I searched the Adobe forums and tried many other potential solutions that involved changing settings in Captivate and on my computer. All I learned is that I’m not the only frustrated person, and there is no way to embed fonts in Captivate or make the fonts render better without Flash.

If you can use Flash for a project, there are two solutions. The first is to save your Captivate file as a Flash file, open the file in Flash, embed fonts in any dynamic text fields and then publish the SWF. This is the best solution if you need a font to be used throughout a project that does not render well in Captivate.

The second option is best if you plan to use a font that does not render well in Captivate on a limited number of slides. Simply create your slide in Flash, publish the SWF and insert it into Captivate. If you are using dynamic text fields in the SWF, ensure all text is embedded, because Adobe warns that Captivate does not display device fonts. This means that if you don’t embed your text in Flash, you won’t see any text at all. I also found you cannot allow dynamic or static text to be selectable because if a user selects it, the text may disappear.

The Summary

In summary, if you need to work in Captivate and cannot use Flash for a project, you are limited to carefully choosing your fonts. My general recommendation is to use Postscript fonts since they tend to look best. If you plan to have any dynamic text fields in your project (i.e., text entry fields) you will want to stick to common fonts since Captivate cannot embed fonts, and users who do not have the fonts installed on their computer will not be able to see them.