create blog

go home go home
  1. about
  2. code
  3. wiki
  4. blog

Archive for the ‘Framework’ Category

For the Love of a Deity, Please Prove Me Wrong: IE Alpha

Tuesday, December 29th, 2009

Please no. Just, no. I mean, honestly, how far can IE sink? I really hope I am wrong here, but…

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?

Posted in Code, Framework, Please Prove Me Wrong, Script, SproutCore, Web | 2 Comments »

Notes on Bespin’s Model and Cursor Positions

Wednesday, June 17th, 2009

I am writing this so that I will remember (as I have forgotten some of the things here before). However, since others may find it useful, and since I’d really like any double-checking I can get, I am publishing it.

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.

(more…)

Posted in Bespin, Framework, Mozilla, Script, Web | 3 Comments »

PDF Embedding and So, So Much More

Friday, June 12th, 2009

The framework’s PDF engine has largely been rewritten. This adds a lot of new abilities which are quite exciting (and, in the meantime, we even changed a couple of unrelated things).

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.

Posted in Framework, PDF, What's New | No Comments »

PDF Parsing

Tuesday, May 19th, 2009

Just a little status update: yesterday, I finally managed to make the new PDF engine pass all PDF-related tests in the Create Framework. It is revision 100 in the pdf-parsing branch on Launchpad.

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).

Posted in Framework, PDF, Testing | No Comments »

DOM-Dependence in JavaScript Libraries

Wednesday, May 6th, 2009

The Create Framework supports JavaScript to a growing extent. When using JavaScript in the Create framework, I’ve often wanted functions that I’ve used or seen in libraries like Prototype. It is often easy enough to copy-and-paste the functions I want from the library into my own code. However, I cannot simply import the entire library, or include it in the Framework, because there are several functions which have direct dependence on the DOM (the HTML Document Object Model which describes web pages). This is a bit annoying, especially as JavaScript is becoming useful outside of the web. Obviously, these libraries were meant for the web, and they fulfill their purpose wonderfully. It would be nice, however, to have libraries for non-web scenarios (perhaps some already exist, and I just haven’t stumbled across them). The Create Framework will, undoubtedly, eventually get such a library of its own.

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.

Posted in Framework, Script | No Comments »

Auto-Configuring, the Build, and the Barcode

Tuesday, March 17th, 2009

Last night, I wrote about how I could not easily add the barcode functionality to the build because it was not guaranteed that the library would be on every computer compiling it.

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.

Posted in Barcode, Build, Framework, USPS | No Comments »

Script & the USPS Intelligent Mail Barcode

Monday, March 16th, 2009

We need a way to integrate the new USPS Intelligent Mail Barcode nicely into our existing workflow. The software we use for most of our composition seems to have some… disagreements (or something)… with it at times, even though it officially supports 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.

(more…)

Posted in Barcode, Framework, Script, Shell, USPS, V8 | No Comments »

Regression Tests

Tuesday, February 17th, 2009

The framework finally became complete enough to where I felt like I could add tests. Perhaps I should have started with tests, but the tests themselves require a composition of many of the components, so it would have been impractical.

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.

Posted in Framework, Testing | No Comments »

The Script Engine

Saturday, January 31st, 2009

One of the components of the framework on which I have been working particularly hard in the past week is the Script Engine.

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.

(more…)

Posted in Framework, Script | No Comments »