If you check my test case, you may notice that it looks different in Internet Explorer than it does in sane browsers. What is the culprit?

Simple: filter:alpha.

Supposedly, making elements somewhat transparent is possible in everyone’s favorite browser. Well, it is, but you have to use Microsoft’s proprietary “filter” CSS property.

Okay, fine, at least it works. Except in one case, from what I can tell: it will not apply transparency to absolutely positioned child elements of the element with the “filter” property set.

Why is this an issue? Let’s take the simple example of a button control (specifically, SproutCore’s SC.Button, but it should apply to other button controls as well): you have a left part (with nice rounded corners), a center part (that can be stretched), and a right part (again with the rounded corners). One part—for instance, the right part—is either positioned relatively or is the parent element itself, and simply has a background-position:right. The left and center parts, however, are positioned absolutely; something like left: 10; right: 10 for the center part; right:0; width:10; for the right part (I just made these numbers up! They aren’t real!)

So, what happens if you try to fade the button out in Internet Explorer? Well, it looks really odd. In the above example, the right part fades out, but the left and center do not. They just stay as they were.

There is only one workaround that I know of: seting filter:alpha on every element. There are a few problems with this:

• Performance. Each setting of “opacity” will have to recursively loop through all child elements.
• Performance * Animation fps. Yep, animating opacity in IE is plain screwed.
• Pure messiness.
• Long-term issues: what about when (if) Microsoft fixes the issue?

Don’t you just love Internet Explorer?

I keep thinking I must be wrong, and there must be some nice little workaround, CSS hack, or even the simple explanation of me just being plain wrong (I actually hope I am).

Anyone know?

In a web-based Create Framework related project, we are using Mozilla’s wonderful Bespin text editor. In the process of using it, we sometimes need to modify the editor in some way, perhaps by adding new features, perhaps by finding and fixing bugs.

The following is technical in nature.

In Bespin, characters are arranged in rows and columns. Any character may be referred to with a row number and a column number. This set of two numbers is referred to as a position.

Bespin’s editor has two significant parts which each have their own kind of position: the editor, and the model. This may seem silly at first: why should the editor’s position at row 5 column 4 be any different than the model’s?

There are a few different reasons for this, and the reasons could grow. It boils down to one concept: the editor, in order to enhance the usability, does not show characters exactly as they are in the model. For instance, a single tab in the model will usually be transformed into more than one space in the editor (for instance, four spaces). In this case, column 4 is the column immediately following a tab at the beginning of the line in the editor — the model position would be (5, 1), pointing to the column immediately following the tab character.

Also, code folding hides some lines of code, so row 4 could actually have been lines 4 through 30, but collapsed to take just one line. In this case, the model position for (5, 4) would be (31, 1).

The positions in the editor are called cursor positions (as they are possible positions of the cursor in the editor), and the positions in the model are called model positions.

As detailed in Gordon Hemsley’s guide on working with tabs, there are a few helper functions. There are two that are most important:

cursorManager.getCursorPosition(modelPosition);
cursorManager.getModelPosition(cursorPosition);

As you might expect by looking at their names and arguments, they convert cursor positions to model positions and vice-versa. There are two proxies to these functions in the editor component as well:

editor.getCursorPos(modelPosition); //note the lack of "ition"
editor.getModelPos(cursorPosition);

So what positions are used where? The model, naturally, always uses model positions. The editor always uses cursor positions. Actions (where most of the actual editing takes place) have convert between the two.

For instance, the action insertCharacter (in actions.js), used whenever you type in a letter (with extra comments inserted marking the conversions):

    insertCharacter: function(args) {
        if (this.editor.readonly) return;
 
        if (this.editor.selection) {
            this.deleteSelectionAndInsertCharacter(args);
        } else {
            // SEE HERE:
            // the "pos" argument given to insertCharacter is, of course, the current cursor position.
            // so, we convert it to a model position and hand it off to the model.
            this.model.insertCharacters(this.cursorManager.getModelPosition(args.pos), args.newchar);
            this.cursorManager.moveRight(true);
            this.repaint();
 
            // undo/redo
            args.action = "insertCharacter";
            var redoOperation = args;
            var undoArgs = { action: "deleteCharacter", pos: bespin.editor.utils.copyPos(args.pos), queued: args.queued };
            var undoOperation = undoArgs;
            this.editor.undoManager.addUndoOperation(new bespin.editor.UndoItem(undoOperation, redoOperation));
        }
    },

Here’s a list of changes:

• Page Trees. We used to write one PDF array of pages. Now, we write trees of pages, allowing us to keep only a small number of page nodes in memory at a time.
• Compression. Content streams in PDF files are now compressed. Why did we implement this now? Well, that’s a funny story…
• Decompression. It turns out that, in our effort to embed one PDF inside of another, we may have to deal with multiple content streams. It further turns out that they still represent one long stream (as opposed to several individual segments) and as such cannot be used separately from each other. So, to put them in one object in the PDF file that may be reused you have to decompress and concatenate them. And, since we’re decompressing, why not compress as well?
• PDF Parsing. After the near-rewrite of the PDF component, it was actually quite easy to allow PDF parsing. It only took us around a week or so. Now, we are able to open a PDF file and rip contents out of it.
• PDF Embedding. It has, for awhile, been possible to embed PDFs inside PPML. However, to embed PDFs inside other PDF files, you need to actually deconstruct the PDF to be embedded. That’s why we implemented parsing. Amazingly, it all appears to work — although, unfortunately, it does not (currently) work for PDFs with compressed cross-reference streams or compressed object streams.
• Better PDF Embedding. Not only does PDF-in-PDF embedding work, but PDF-in-PPML embedding has been improved nicely. The width and height of any embedded PDF are read in, so it is now possible to do lots of fancy stuff. Now, PDFs are treated almost exactly like images. You can make them fill a frame, you can make them fit in a frame, you can make them centered in a frame… basically, you can do anything you can do with an image with a PDF — in both PPML and PDF outputs.
• Text Processing Bug Fixed. Imagine the words “Hello World.” What if both cannot fit on the same line? They should, then, naturally be put on separate lines. But what if it was just the space between the words making the difference? Still, they need to be on separate lines. Unfortunately, the framework had a bug here — it was determining that it needed to break, but although it split at the right point, it did not actually go to the new line. This has been fixed!
• Line Height = 1.2. The framework now supports line heights for runs of text. This is, basically, the amount of spacing there should be between lines. Because we use InDesign quite often here, we made the framework default to line spacing of 1.2 — like InDesign’s — which changes how text flows in any application that has text boxes with more than one line of text.

Where Are We Going So what’s left? Well, there could be some memory usage issues; the engine was using a suspiciously large amount of memory the other day when processing a set of a few thousand records. It may or may not have been a small (or large) leak. We will get around to fixing this problem (if it exists) when it starts to bother us.

We want to implement scripting support for PDF, and by that, I mean that we want to be able to open a PDF using Script, determine things such the size of a page, and so on. It does not necessarily need to talk directly to PDF — it could talk to PDFLink — but we want a tool we can use to automate things such as imposition.

Of course, scripting of views could allow this, and this is an eventual goal. In the meantime, however, we may see some form of compiled dC, where dC is generated (compiled) live through some script, allowing forms of meta-programming.

A big part of all of this will be the conversion from the Engine to the Shell, which is a JavaScript based platform. The Shell will be able to simply run scripts, or do Create Framework related things. This will make it much easier to maintain the current Shell, which is used for running some current scripts here at TPSi.

Finally, dC namespaces need a rewrite, and that will happen eventually.

We have another project we will be working on for a little while. It is related to the Create Framework, but a bit too experimental to announce quite yet.

Yes, all of the tests have been updated, but they were hand-checked first. As the new engine handles the timing of the writing of objects differently, the tests will work differently. They will change further, in fact, because I just realized that the maximum size for a page tree node is still set to 3 (for debugging purposes) — which is not at all what the final size should be — so the tests that have more than three pages are, unfortunately, wrong. Further, it is possible that some areas of the Create Framework may even have some leaks regarding PDF, so fixes to those could cause problems. This is not a stable branch, is not meant to be a stable branch, and is not guaranteed to even be in a compilable state. I’ve disclaimed, so if your computer blows up, it is not my fault.

Now, I’ve finally started PDF parsing. Currently, I’ve got the first XRef table being read in. I’m excited. Hopefully, by the end of the week, I’ll have some form of PDF-in-PDF embedding working. Currently, I’m aiming to support only PDF 1.4 — before all of that cross-reference stream and object stream business came about that would require the ability to handle compression (which, while on the eventual to-do list, is not currently a priority).

At some point, I hope to port Protovis to the framework. It seems to be made in such a way that it should be relatively easy to port: almost all of the work is done in Canvas, so if I just implement a canvas act-alike in the Create Framework, everything should work fine.

I did two main things:

1. Added ENABLE() and HAVE() macros. Inspired by WebKit’s, here. This allows enabling and disabling the capabilities through a configuration header file (now located in config/config.h).
2. Added a simple generate-config script. I know there are existing tools for this — I think GNU’s Autoconf does it — but I didn’t have time to learn something new, and I also didn’t want to invest in such complexity for a system which would not work in Windows. The Windows script is a command file; the Mac one is a shell script.

I like how the scripts have no prerequisites on Mac and Windows. Unfortunately, I will probably have to rewrite them later in a consolidated form, so that I only have on script; at this point, it will likely cease to have no prerequisites.

So, how do compile with support for the barcode? On Mac, you have to put the libUSPS4CB.dylib in /usr/local/lib/. On Windows, you have to put in in your WINDOWS folder. And that’s it.

Other people using the same software recommend using the USPS’s library. That’s fine and all, but we don’t want to write a C program for each job — writing in C or C++ can be quite time consuming. And it requires compiling, creating projects, etc. In short, a lot of hassle.

While this may not be the course we end up following, I decided, tonight, that although I was half-asleep, I’d attempt to add scripting support for USPS’s library. At around 10:00, I downloaded the software from USPS. Now, roughly fifty minutes later, I have managed to write a script that uses the USPS barcode.

Here’s the script:

function main(input, output)
{
	var inputFile = new InputStream(input);
	var outputFile = new OutputStream(output);
 
	while (inputFile.ok)
	{
		//get line
		var line = inputFile.getLine();
 
		//split
		var fields = line.splitQuoted(",");
 
		//if there aren't the required amount of fields, continue to next line (if any)
		if (fields.length < 2)
		{
			outputFile.writeLine(line);
			continue;
		}
 
		//get needed fields
		var track = fields[0].trim(), route = fields[1].trim();
 
		//set output
		line = line + ",\"" + USPSBarcode.encode(track, route) + "\"";
 
		//write
		outputFile.writeLine(line);
	}
}
 
<!-- snipped: the splitQuoted string function -->

The Framework’s Script Engine made adding this to the Shell very easy (really, it should be moved into Spec, and Shell should get it from there, but for now…).

I will, over the course of the next couple of days, figure out a workflow for how I can get this code online without breaking the build for compiles without the library. Perhaps a command line switch? I will probably also move it to where it belongs: in Spec.

I will, however, go ahead and post the majority of the code here. I could have done it much quicker with a single function in global scope, but I prefer the cleanliness of using a JavaScript object (I could have still used an empty dummy object, but that wouldn’t have been proper).

#ifndef SHELL_WRAPPERS_USPSBARCODEWRAPPER_H_
#define SHELL_WRAPPERS_USPSBARCODEWRAPPER_H_
 
#ifdef SHELL_WITH_USPS_BARCODE
 
#include <string>
 
extern "C" {
	int USPS4CB( char *TrackPtr, char *RoutePtr, char *BarPtr);	
}
 
namespace Shell
{
	class USPSBarcodeProvider
	{
	public:
		USPSBarcodeProvider()
		{
 
		}
 
		std::string encode(std::string tracker, std::string route)
		{
			if (tracker.size() != 20)
			{
				return "";
			}
			if (
				route.size() != 11 && 
				route.size() != 5 && 
				route.size() != 9 &&
				route.size() != 0)
			{
				return "";
			}
 
			char res[66];
			int result = USPS4CB(
								 const_cast<char *> (tracker.data()), 
								 const_cast<char *> (route.data()), 
								 res
			);
			if (result != 0)
				return "";
 
			res[65] = NULL;
 
			return res;
		}
	};
}
 
ScriptBaseNative(Shell::USPSBarcodeProvider);
 
namespace Shell
{
	SWrap(USPSBarcodeWrapper, USPSBarcodeProvider)
	{
	public:
		USPSBarcodeWrapper()
		{
			set("encode", $(encode));
			className = "USPSBarcodeProvider";
		}
 
		SMember(encode)
		{
			if (extract(self))
			{
				return $(extract(self)->encode(arguments[0]->stringValue(), arguments[1]->stringValue()));
			}
 
			return $();
		}
	};
 
}
 
#endif
 
#endif

Implementing tests had a very nice side-effect. Tests are meant to test expected behavior. As it turns out, there were a lot of areas where the framework did not behave as expected. I fixed at least seven bugs over the course of the two days when I wrote the current four tests. I say “at least” because I often fix bugs as I see them and promptly forget about them, or group them into larger categories when I write the revision release notes.

In short, just by writing a few tests, I drastically increased the system’s stability. And, since they will run often, they will ensure continued stability as well. Short term and long term, testing can be great.

It is what it sounds like: a module designed to allow scripting to work inside the framework. Although most definitely still a work-in-progress, it now has a lot of the features I want it to have.

My goals were:

• It should be extremely easy to make an object scriptable (less than ten minutes)
• It should be extremely easy to pass objects to JavaScript
• It should be extremely easy to retrieve objects from JavaScript
• It should be possible to implement other scripting languages in future

I don’t know about the last, as I haven’t tried it yet, but the first three I think I may have succeeded in to some extent.

Basically, to give you the idea of what it does, I’m going to give a code dump showing how the script engine works. You very likely will not be interested. On the other hand, you could. So, I am posting it.

/* Create a point class */
//Mem is a base class which allows reference counting.
class Point : public Mem
{
public:
	Point()
	{
		this->x = 0; this->y = 0;
	}
 
	Point(double x, double y)
	{
		this->x = x; this->y = y;
	}
 
	double x, y;
};
 
/* register Point as a type that might be scripted */
ScriptBaseNative(Point);
 
/* Create a wrapper named Point Wrapper for point */
SWrap(Point, PointWrapper)
{
public:
	PointWrapper()
	{
		//add the x and y fields
		this->set("x", $(getX, setX));
		this->set("y", $(getY, setY));
 
		//specify that it is constructable
		constructable = true;
 
		//set the class name
		className = "Point";
	}
 
	SGet(getX)
	{
		//"self" was passed as an argument, so get the point out of it
		Point *point = self->as<Point>();
 
		//if it is not null, return x
		if (point)
			//wrapping it for Script
			return $(point->x);
 
		//otherwise, return undefined
		return Script::Undefined();
	}
 
	SSet(setX)
	{
		//"self" was passed as an argument, so get the point out of it
		//the easy way this time
		Point *point = extract(self);
 
		//if not null, set to value, the other argument
		if (point)
			point->x = value->numberValue();
	}
 
	/* Almost identical Y functions go here... */
 
	//called when a script wrapper is created
	//not when a new point needs creating
	SConstruct
	{
		Point *point = extract(self);
		//add a reference count
		if (point)
			point->ref();
	}
 
	//called when the script wrapper is destroyed
	SDestruct
	{
		Point *point = extract(self);
 
		//return if nothing
		if (!point)
			return;
 
		//deref and delete if needed
		if (point->deref() == 0)
			delete point;
	}
 
 
	//called when new Point is called in JavaScript
	SCreate
	{
		double x = 0, y = 0;
 
		if (arguments.length() > 0)
			x = arguments[0]->numberValue();
 
		if (arguments.length() > 1)
			y = arguments[1]->numberValue();
 
		return $(new Point(x, y));
	}
};
 
/* Elsewhere */
//create contexts
R<GlobalContext> myContext = new GlobalContext();
R<V8Context> v8Context = new V8Context();
 
//register type
myContext->registerType<Point>(new PointWrapper());
 
//test constructor using v8
v8Context->runScript("var jsPoint = new Point(42, 42);");
 
//load a function using v8
v8Context->runScript("function something(point){ return point.x; }");
 
//get the function
SFunction f =  myContext->get("something")->functionValue();
 
//prepare arguments
SArguments args;
args.add($(new Point(4, 2));
 
//call function
double x = 0;
if (f) x = f->apply(Script::SUndefined(), args)->numberValue();
 
std::cout << "The X value of the point is: " << x; //should be 4

It has been a bit difficult to make all of this work, and it is still very much a work-in-progress. One of the largest sources of difficulty was V8. I originally picked it because its Embedder’s Guide looked friendly, but I discovered that there was actually quite a bit that was very poorly documented. The code in v8.h had somewhat more thorough documentation, but I found it lacking as well. What is really needed is several examples, showing the best way to do everything one might want to do.

If you are curious and want to see the code, it is hosted on Launchpad.