A Few <P>s on HTML Display in Flash

If you intend to repurpose html-formatted text for use in Flash, you will be surprised by Flash’s rather unique parsing. This can be a pleasant surprise [like when Flash skates over certain tags that you can then reserve for browser-only content], but this can also be a very frustrating constraint. A glaring case in point is Flash’s parsing of the paragraph tag.

The standard browser method of displaying a paragraph is to block the text and follow it with a line feed. This provides a visual gutter between paragraphs and improves legibility of the text. In Flash, the paragraph tag blocks the text and follows it with a break, but not a line feed. The result can be a scrunched-up mess.

One possible solution is to add artificial ingredients to set the paragraphs apart. Unfortunately, this will also double-space these items when the source html is parsed raw to a browser — not to mention how this will complicate editing the source via a WYSIWYG application such as Dreamweaver. You can try applying disparate CSS styles or a Flash TextFormat — one or the other, mind you — but you will be frustrated in finding an adequate solution.

A solution that I have developed takes the html source and parses it as an xml structure in Flash. Once parsed, you can then traverse the nodes and slip an empty <br> node into the end of each paragraph node and toss the result into the htmlText property of a TextField object. It works and it keeps your source pristine. Plus, this subroutine can easily be conditioned out if future players modify the parsing behavior.

Note, however, that If you do this it will be very important that your source be xhtml compliant, otherwise the content will “break off” when open or overlapping nodes are encountered in the source. Most notably, you must self-close all image and break tags, ie: <img src=”pix.jpg”/><br/>. Do that, then do this …

xhtml = new XML();
xhtml.ignoreWhite = true;
xhtml.load (“someSource.html”);
xhtml.onLoad = function () {

  massage (this);
  someTextInstance_txt.htmlText = this;
};

massage = function (xml, node) {
  if ( !node ) { var node = xml; }
    for ( var pnode = node.firstChild; pnode; pnode = pnode.nextSibling ) {
      if ( pnode.nodeName.toLowerCase () == “p” ) {
      pnode.appendChild (xml.createElement (“br”));
    }
    // recursively search through deeper nodes
    if ( pnode.hasChildNodes ) { massage (xml, pnode); }
  }
};

Lingo PDF Generators

Years ago, I thought I was pretty cool for knowing enough about PostScript to be able to write a tool to import simple EPS and PostScript files into Director as vector shape data (PS2VS).

Now that I’m old and all of my creativity has dried up, I can only look admiringly on as people move into areas I thought about but never managed to explore. Specifically, Daniel Nelson and Valentin Schmidt, who have both posted code demos and libraries showing how to generate PDF files with Lingo.

Check out Daniel’s BlueJade demo page or download Valentin’s latest PDF Class library.

P.S. Valentin also has a Windows-only PDF-creation Xtra!

P.P.S. Daniel’s got a set of vector shape import scripts that beat PS2VS on speed, too.

Circular Lingo

A thread on DIRECT-L came up wondering about a handler that could draw a vector shape circle of a specific size. This little knock-off script is just reverse-engineered from a circle drawn with the vector shape tools.

on createVectorCircle diameter
  vs = new (#vectorshape)
  radius = diameter / 2.0
  rhsqh = radius * sqrt (0.5)
  cpoffset = rhsqh * 0.5625
  vs.vertexlist = [[#vertex: point(-rhsqh, -rhsqh), \
                    #handle1: point(cpoffset, -cpoffset), \
                    #handle2: point(-cpoffset, cpoffset)], \
                   [#vertex: point(rhsqh, -rhsqh), \
                    #handle1: point(cpoffset, cpoffset), \
                    #handle2: point(-cpoffset, -cpoffset)], \
                   [#vertex: point(rhsqh, rhsqh), \
                    #handle1: point(-cpoffset, cpoffset), \
                    #handle2: point(cpoffset, -cpoffset)], \
                   [#vertex: point(-rhsqh, rhsqh), \
                    #handle1: point(-cpoffset, -cpoffset), \
                    #handle2: point(cpoffset, cpoffset)]]
  vs.closed = true
end



Director ROI

Over the past couple of months, I’ve updated a number of Macromedia products: Flash, Fireworks, Dreamweaver, Freehand — and now Director — to the MX 2004 level. In addition, I’ve gotten ColdFusion, JRun and Flash Communication Server developer editions and copies of Contribute for both platforms, as well as a year’s worth of Developer Resource Kits.

What’s annoying is that the Director upgrade cost me $399 per platform, while everything else cost only $599 as part of a DevNet Professional upgrade.

Flash underwent some major changes in MX 2004. The other applications in the DevNet upgrade didn’t change as much (at least not in ways I cared about, apart from the greater incorporation of CSS in Dreamweaver), but Macromedia’s push is definitely behind Flash in a way that you just don’t see there for Director. It’s clear that Macromedia sees a future in Flash.

That’s not so obvious for Director. Yes, much has changed in DMX2004, but it’s not getting the kind of overhauling that it needs for long-term development. We’re still missing standard controls. Compare the text display engine in Director with the inlined graphics and style sheets text in Flash. Shockwave 3D, the thing that was supposed to save Director and which siphoned off development resources four years ago has been relatively stagnant for two versions; nobody’s shipping new SW3D exporters.

I wish my Director dollars went as far as my Flash dollars do.