The Phantom Inker's blog

The Last NVIDIA Card I'll Ever Own

Thu, 02 Apr 2009 13:17:41 GMT

This is an angry rant about something that is simply plainly stupid. Be forewarned.

Bye bye, NVIDIA

This computer has an NVIDIA GeForce 9600GSO video card in it.

I bought this card last August (or thereabouts) to replace another NVIDIA card that was dying (sometimes it wouldn't display anything at all, at random). I had purchased that card only a year before that to replace another video card that was dying (the picture would occasionally fritz out or jump around the screen, until one day it simply displayed no picture at all). I had gotten that card as a replacement for another card that was dying that was less than a year old.

In total, in the last ten years I've owned twelve cards with NVIDIA chipsets on them. And if you do the math on that, the average card lasted less than a year. In fact, there were three years in the early 2000s that I had a card with ATI chips instead, so that means the average NVIDIA card has lasted less than eight months.

Simple Needs, Simply Unmet

I don't know why I didn't learn my lesson before. My needs are simple. I don't do gaming. I'm just a software engineer, and I need two screens. That's it. That's all. This current card has the issue that if I put the computer in hibernation, sometimes one of my screens isn't working when I start it back up. Oh, and there's also the issue that one of the two big 22" widescreen displays I purchased for this computer doesn't work with the card at all (literally: The screen goes randomly white when I connect it to this card, as though the card is using the wrong voltage; when I connect it to my wife's computer, it's fine, so my second monitor is her old small 17" one, and she gets my second big one).

The only fix for the non-working screen is to uninstall NVIDIA's drivers, reboot the computer, and completely reinstall them, and reboot again. Then it works fine until I try to put the computer into hibernation, after which there's a 10% chance I'll have to do the same stupid thing all over again.

Fool me once...

I've learned my lesson. A dozen dead NVIDIA cards — I have a box of 'em here — each from different manufacturers leads me to conclude that it's not the manufacturer but the chip vendor. So I say never again. Never again will I be held hostage to NVIDIA's broken garbage. The three years I had that ATI card it performed flawlessly. Perfect. It never asked me any questions; it never told me any lies. It just did what it was supposed to do.

I've contacted NVIDIA's tech support, of course, and they don't really seem to care. They never have, not in ten years of buying their stupid crappy products. So I repeat: NEVER AGAIN.

You hear that, NVIDIA? You've lost a customer for good, and not just any customer — I'm technically saavy, and people all around me ask what they should buy and what they should avoid. I'll be teaching classes soon, and giving recommendations to dozens of novices on what kinds of computer equipment to buy — and your name will be in the "avoid at all cost" list.

You could have prevented this. You could have fixed outstanding bugs instead of focusing on new software features. You could have worked on your hardware quality control. You could have at least acted like you cared when I called or e-mailed you in the last ten years. But you didn't. And I now have a mission: To ensure that no-one I know ever buys your stupid broken garbage again.

Lest you think I'm just sour over everything computers, I intend to talk in another journal posting about some of the "winner" products I've used over the last twenty years, and show what they do right that you're doing so wrong. Because this is not a rant against everything computer-related: This is a rant by someone who knows better against a company whose products define the very word fail.

And so, in summary, let me say this: If you're an average user buying computer equipment, DON'T BUY NVIDIA. YOU HAVE BEEN WARNED. I learned my lesson the hard way, and I'll never make this mistake again so long as I live.

ProColor, Part 2: Mouse Capturing

Fri, 20 Mar 2009 22:45:36 GMT

It's time for the second article in my occasional series on the ProColor color-picker. Last time, I gave a rough overview of what ProColor is and why it's designed the way it is. In this article, I'm going to cover some the topics in reverse and discuss capturing the mouse on a web page.

What's an event?

Let's start at the beginning: What's an event, and why would you ever want to capture one?

An event in most user-interfaces means an action performed by the user: A key press, a mouse movement, or a mouse-button press, among others. There are other kinds of events, too, but these are the ones we'll be concerned about. Events are little structures, little tiny chunks of data, that describe what happened and where it happened, in full, so that they can be sent to appropriate places to be processed. A key-press event, for example, typically includes which key was pressed, whether Ctrl or Shift or Alt was held down while it was being pressed, and maybe where the mouse was on screen at the time.

Capturing and focusing are two different ways of ensuring that the events go where they need to. Usually, events go to whatever window is appropriate for them: A "this window was just hidden" event gets sent to the window that was hidden, for example. But what about keypresses? Where should they go? The keyboard is external, after all, and not necessarily attached to any one window.

Focusing solves this problem: Only one window can have the focus at a time, and input from devices that have no way of directing themselves to a specific window (keyboards, joysticks, microphones, etc.) all have their input go to the focus window. So when you click on, say, a textbox, the window system assigns that textbox the focus, and then all input events get directed to that textbox. At least that's the theory: Different window systems do this with different levels of directness and precision, but all of them have the concept of focus for the keyboard device at least.

Capturing solves a different problem. Some devices, like the mouse, have the concept of position built into them: When you move the mouse, the window that should receive the events for that action is obvious, because the mouse is "over" it. But what if your program doesn't want those events to go to that window?

You might be wondering why events shouldn't go where they belong, but it's a common need in user interfaces. When you press the mouse button while you're over a scrollbar's thumb, the scrollbar should receive all events until you release the mouse button so that the thumb can be dragged around to follow the mouse — even if the mouse isn't over the scrollbar.

Capturing mouse events, then, is a core component of modern window-system functionality, and most window systems provide some sort of tools to support it: Microsoft gives us SetCapture(), X-Windows gives us XGrabPointer(), and others have a variety of ways to handle the problem, from calling functions to attaching event handlers to creating whole new specialized event-processing loops.

Unfortunately, the web doesn't.

And this means that implementing page elements that track the mouse — elements that look like buttons or scrollbars or dropdowns, for example — isn't something that's built into your web browser. Fortunately, there's a very good way around this problem, and that's what we're going to talk about here.

How events get dispatched

Many of us programmers know how a traditional event-processing model works in a window system: The window system collects events from devices, posts those events into a queue, and your program retrieves those events and (optionally) dispatches them to some target window or processes them directly. Most window systems work like this; there's GetMessage() in Windows; there XNextEvent() in X-Windows; there's even EvtGetEvent() on the old Palm Pilot to retrieve events, and dispatching them is usually an indirect function call or giant switch statement.

Sadly, the web doesn't work like that.

On the web, the event-processing loop occurs outside your page in the browser itself. The browser collects events and dispatches them to the various page elements whenever it feels like doing so. In current implementations, you at least have the guarantee that the events are dispatched using a single thread, but the Document Object Model (the DOM) doesn't actually guarantee even that much. Worse, there's no function named Event.BeginCapturing or something like it. So if event dispatching is totally outside your control, how do you take control of it?

Well, the good news is that every time an event arrives and needs to be dispatched, the web browser sends it to not one page element but several. The event dispatches are grouped into two categories: capturing and bubbling. During the capture phase, the web browser walks down the DOM tree until it reaches the target element, asking each parent element if it wants the event. Then, during the bubbling phase, the web browser goes back up the tree, asking each element again if it wants the event. Only then if the event gets all the way back to the top of the tree and nobody wants it does the web browser perform default actions like "select text" or "click checkbox."

This is better explained visually. Consider a very simple page like the one below. It has a left sidebar with some links, and a central area with a form and an <input> field and also a <div> that has a background image that makes the <div> look like a snazzy shiny black pushbutton.

Let's say the user clicks on the <div> "pushbutton." The web browser first follows the red arrows, asking the <body> and then the <div> and then the <form> and then finally the innermost <div> if they want the event (the "capturing" phase, so named because it was designed to make capturing events easy). And then the browser goes back up the blue arrows, asking the innermost <div> and then the <form> and then the <div> and then finally the <body> if they each want the event (the "bubbling" phase, so named because the event seems to "bubble" to the top of the document).

"Great," you think. "So all I have to do to capture events, then, is to attach an event-handling function to the <body> and have it grab events on their way down the tree, right? Easy as pie!"

Good thought, but sorry, you're wrong.

You see, there's a minor problem with the above diagram, which is that's how most web browsers send events. Unfortunately, Internet Explorer does it differently: IE doesn't do the "capturing" phase at all — no red arrows, which means that an event handler attached to the <body> will never see an event if that innermost <div> — or any other element higher up — processes it first.

Doesn't it figure that IE's the fly in our ointment?

Capturing events, portably

Since you can't use the "capturing" side of event processing — and the Prototype Javascript library doesn't even support that on non-IE browsers because they don't want you to get your hopes up that it'll actually work — how do you actually capture? The answer, as is often true with hacky technology, is that you need to cheat.

In this case, we're going to do something that you can do with web browsers but that you can't readily do with window systems: We're going to use transparent objects.

First, rather than thinking of your page as flat, imagine looking at it sideways. Each element is like a flat chunk of plastic and sticks out just a little bit. Elements are not "inside" other elements but "stack on top of" other elements, so that really "deep" elements in the tree are actually very "tall" when looked at from the side. You can see this depicted below:

From this perspective, the browser's actions during the bubbling phase take on a new appearance: Rather than starting at the deepest element in the tree, the browser starts the event at the highest element in the stack and walks down the stack with the event until it runs out of elements or until one of the elements actually claims the event.

This distinction is important, because it allows us to take control of the dispatching in a way that's almost a little magical: What if we had another element higher than all the others? If we did, that element would be the one that received the event first! In fact, if that layer covers the entire page, then the event will only "bubble" across two elements total: That "cover" element and the <body> itself — none of the other page elements would ever see the mouse event at all.

This, then, is how we reliably capture mouse events reliably in Javascript: During the period where we want to capture events, we create a new topmost layer and attach the event handler to it, and then when we're done capturing, we destroy the topmost layer.

Implementing MouseCapture

Once you know the principle, the code is pretty easy. In fact, ProColor comes with a MouseCapture class that encapsulates this basic principle in a simple, reusable way. The complete code for the MouseCapture class is short, and is included at the end of this article.

Let's start by seeing how you might use the MouseCapture class to track a pushbutton. I'm going to dispense with the usual event-handling boilerplate code and just use a onmousedown handler to keep the presentation simple (but note that in real code, you'll want to handle the "mousedown" events properly).

Here's our example HTML:

<img id='mybutton' src='mybutton.png' width='120' height='30'
    alt='Button' onmousedown='TrackButton("mybutton")' />

<script type='text/javascript'><!--
function TrackButton(id) {
    $(id).src = 'mybutton_pressed.png';
    var capture = new MouseCapture;
    capture.begin(function(event) {
        switch (event.type) {
        case 'mouseup':
            $(id).src = 'mybutton.png';
            capture.end();
            break;
        }
    });
}
--></script>

Let's look at how this works. The TrackButton() function will get called when the mouse button is pressed over the image. The TrackButton() function changes the image to appear "pressed," and then creates a new MouseCapture object. MouseCapture.begin() is used to initiate the capture, and it gets passed a callback function — a function that will receive all of the events until the capture ends. Our capture function here watches the events it receives, and when the mouse button is released ("mouseup"), it changes the image back to the unpressed version and ends the capture.

Simple enough, really. There are a few caveats. First, the event's coordinates (the mouse's coordinates) are relative to the entire document — not any one specific element within it: They're absolute coordinates. You can retrieve those coordinates by calling the standard Prototype functions event.pointerX() and event.pointerY(). You can also cheat by calling Element.isEventIn(), a custom function included with ProColor that tells you whether an event occurred within a given element.

Let's use Element.isEventIn() to implement a second version of the tracking routine; in this version, if the user slides the mouse off of the "pushbutton," the "pushbutton" will pop up:

<img id='mybutton' src='mybutton.png' width='120' height='30'
    alt='Button' onmousedown='TrackButton("mybutton")' />

<script type='text/javascript'><!--
function TrackButton(id) {
    $(id).src = 'mybutton_pressed.png';
    var button_is_pressed = true;
    var capture = new MouseCapture;
    capture.begin(function(event) {
        switch (event.type) {
        case 'mousemove':
            var mouse_is_over = Element.isEventIn(id, event);
            if (mouse_is_over != button_is_pressed) {
                if (mouse_is_over) $(id).src = 'mybutton.png';
                else $(id).src = 'mybutton_pressed.png';
                button_is_pressed = mouse_is_over;
            }
            break;
        case 'mouseup':
            $(id).src = 'mybutton.png';
            capture.end();
            break;
        }
    });
}
--></script>

This is a slightly more complex version of the same routine. This one watches when the mouse moves while the mouse button is being pressed, and if the mouse moves outside the "pushbutton", the "pushbutton" is redrawn as unpressed; and if the mouse moves back in, the "pushbutton" is redrawn as pressed.

You can use similar techniques for all sorts of tricks: For example, ProColor uses the MouseCapture solution to handle dragging of the selection on the color wheel, to handle dragging of the slider next to the color wheel, to handle clicks on the color palette, and to handle clicks on the color-picker dropdown. There are lots of other ways you could potentially use it as well. Use your imagination: The sky's the limit!

Conclusion

I hope I've shed some light on how a very useful programming technique can be readily applied to elements on web pages as well. The invisible upper-layer technique is simple and flexible, and works on every major browser; my MouseCapture class and example scripts will run just fine on IE6, IE7, IE8, Firefox, Safari, Opera 8+, and Chrome — anywhere Prototype will run.

In closing, below you can find the source code to my MouseCapture class and the associated Element.build() and Element.isEventIn() methods. This is designed to work with Prototype, but I have no doubt that with some effort, you could rework it to behave nicely with JQuery or Dojo. If you have any questions, please feel free to post them: This is a blog, and that's what the comment section is for!

The Code

/*---------------------------------------------------------------------------------
**  Add two useful methods to Element.  Many other libraries add build(), and ours
**  is, in theory, compatible with all of their versions.
*/

Element.addMethods({
    /* Create a child element with the given options (attributes) and style. */
    build: function(element, type, options, style) {
        var e = $(document.createElement(type));
        $H(options).each(function(pair) { e[pair.key] = pair.value; });
        if (style) e.setStyle(style);
        element.appendChild(e);
        return e;
    },

    /* Return true if this event was a mouse event inside the given element. */
    isEventIn: function(element, event) {
        var d = element.getDimensions();
        var p = element.cumulativeOffset();
        var x = event.pointerX(), y = event.pointerY();
        return (x >= p.left && y >= p.top
            && x < p.left+d.width && y < p.top+d.height);
    }
});


/*---------------------------------------------------------------------------------
**  This is a simple class for capturing all mouse input after a mouse button
**  is held down until the mouse button is released.
*/

var MouseCapture = Class.create({

    initialize: function() { },

    onEvent: function(event, callback) {
        if (callback && event.type != 'mouseover' && event.type != 'mouseout')
            callback(event, event.type);
            event.stop();
    },

    setCursor: function(c) {
        if (this.div)
            this.div.setStyle({ cursor: c });
    },

    begin: function(callback) {
        /* Create our event listener.  We'll need this object now, and later on to
           be able to stop listening to events too. */
        this.listener = this.onEvent.bindAsEventListener(this, callback);

        /* Start observing events. */
        Event.observe(document, 'mouseup', this.listener);
        Event.observe(document, 'mousemove', this.listener);
        Event.observe(document, 'mousedown', this.listener);
        Event.observe(document, 'mouseover', this.listener);
        Event.observe(document, 'mouseout', this.listener);
        Event.observe(document, 'keyup', this.listener);
        Event.observe(document, 'keydown', this.listener);

        /* Don't let the browser perform text-selection while capturing. */
        this.old_body_ondrag = document.body.ondrag;
        this.old_body_onselectstart = document.body.onselectstart;
        document.body.ondrag = function () { return false; };
        document.body.onselectstart = function () { return false; };

        var body = Element.extend(document.body);
        var dim = body.getDimensions();

        /* Build a (nearly) invisible <div> that covers the entire document and that
           will capture all events, even those that would go to iframes. */
        this.div = body.build('div', { }, {
            display: 'block',
            position: 'absolute',
            top: '0px', left: '0px',
            width: dim.width + 'px', height: dim.height + 'px',
            zIndex: 999999999,
            cursor: 'default',
            backgroundColor: '#FFFFFF',
            opacity: 0.0001
        });
    },

    end: function() {
        /* Remove our invisible event-capturing <div>. */
        this.div.remove();

        /* Stop event observing. */
        Event.stopObserving(document, 'mouseup', this.listener);
        Event.stopObserving(document, 'mousemove', this.listener);
        Event.stopObserving(document, 'mousedown', this.listener);
        Event.stopObserving(document, 'mouseover', this.listener);
        Event.stopObserving(document, 'mouseout', this.listener);
        Event.stopObserving(document, 'keyup', this.listener);
        Event.stopObserving(document, 'keydown', this.listener);

        /* Reenable selection. */
        document.body.ondrag = this.old_body_ondrag;
        document.body.onselectstart = this.old_body_onselectstart;
        delete this.old_body_ondrag;
        delete this.old_body_onselectstart;
    }
});

The ProColor color-picker

Thu, 12 Mar 2009 19:08:54 GMT

I'd like to talk a little bit about web coding, specifically client-side Javascript and DOM coding.

For CMXpress, I needed a good drop-down/pop-up color-picker for use with Prototype, and it seemed to me like such a thing ought to be an easy thing to find, but in reality, it turned out to be as rare as a blue moon. There are some basic controls out there, some with irritating popups, some with tolerable design but ugly licensing, and I couldn't have any of that. CMXpress is open-source, under the BSD license, and I needed something that would play nice with that. I also needed something that would play nice with Prototype, and that ideally would be friendly to your garden-variety end-user and that would also ideally look like a control that was native to the browser.

So, since nothing fit the bill, I built ProColor. You can see a screenshot below, or you can visit ProColor's website and download yourself a copy.

In a future posting, I'll talk about how ProColor works internally. And if you want to learn how to use it, that's well-documented on ProColor's own website. Here, I'd just like to spend a little time elaborating on what it is, why it is that way, and what it can do for you.

What is it?

ProColor is a color-picker: It lets end-users choose RGB colors, and it records the chosen color either in its Javascript object or in an input field (or both). They can choose them by sliding the slider, moving around the color wheel, picking a color from a palette of "web-safe" colors, or typing in absolute values. It's smooth and fast, even on Internet Explorer, and "feels" like a built-in popup box in most web browsers (with Safari being the notable exception, since it's styled to look very Windowsy).

It's implemented as a single Javascript source file with some associated images, and the Javascript source file is available in compressed form. It works properly on most modern browsers from IE6 upward, and has been tested on IE, Firefox, Opera, Chrome, and Safari. It is accessibility-friendly, too, since it responds to keyboard events, has its internal controls able to take the focus, and can readily fall back to just a simple text field if necessary. It's easy to insert into your sites, too, since it can be implemented with almost no Javascript coding (and can even be implemented with no Javascript coding on your part in many cases).

Why is it designed the way it is?

ProColor has several features that are designed to come together from a user-interaction perspective. First, it has the color wheel, which is arguably more artist-friendly than the color wash or color wave used in some color pickers. Yes, Photoshop uses the color wave model, but artists are taught to think in terms of the color wheel, so ProColor uses the color wheel to stick to artists' mental model.

It also displays the color palette. Some people may wonder why there's a color palette when you have a color wheel, but there are good reasons: First, the color palette consists only of "web safe" colors, and some web designers may prefer those for compatibility. Second, a good user-interaction axiom is to present users with a few initial options and then let the user choose one and alter it, rather than forcing the user to choose everything from scratch, and ProColor believes in that: A user who wants a shade of dark red, for example, could go the long route of choosing red on the wheel and then dark on the slider, but that's two clicks just to get to an initial value: But with a color palette, the user can click "dark red" directly to choose the initial color, and then alter it with the other settings. The color palette, in short, makes users able to "design" their colors faster.

It displays the RGB value in two different forms, the #hex form in the input field (using a variety of formatting options), and the raw decimal values in the input boxes. This lets users type in exact colors, and they can tab between the input fields.

It displays the HSB value as well, since some users want to be able to work with that.

It does not display a CMYK equivalent, since the web's colors do not match those from printers very well.

And all of the fields respond intelligently to the keyboard: The wheel and slider move with the arrow keys and shift and ctrl and home/end/pageup/pagedown; and keys like Esc and Enter/Return close the popup, as you'd expect.

What can it do for me?

For one thing, it's free, open-source, and well-documented. You have no excuse not to use it, other than page-load times, and in the age of broadband, that's a poor excuse.

For another, it's incredibly easy to use. It can be attached to any <input> element on a page, and it even has an incredibly easy form where you can write this:

<input type='text' class='procolor' value='...' />

By simply adding "procolor" to the input field's classname, that input field will automatically have a color-picker dropdown button displayed beside it. Or you can create ProColor objects dynamically in your Javascript. The library is very flexible, and very customizable, and is designed to easily fit into any page you can throw at it.

In short, if you have a page that ever asks users to type in colors, you can use ProColor to significantly improve the user-friendliness of your page.

In my next few postings, I'll spend some effort talking about how ProColor works. When I built ProColor, I found that there was very little good documentation out there on how to build good, native-feeling Javascript controls, and I think it'll be useful to tell people what I learned. I think the sequence of blog postings will go something like this:

ProColor's overall design
How web based color-pickers work
Building popup windows in Javascript
Capturing the mouse

If you have anything else you'd like to know on this or a related topic, feel free to suggest it, and I'll be happy to cover it. Information is a good thing :-)

Gainless Employment :-(

Sat, 29 Nov 2008 14:32:28 GMT

I've been hunting for a new job since the start of October.

It started out as a light search two months ago, but I'm now searching really hard, and I'm starting to be worried. The economy's bad, and it's not a good time to be hunting for jobs. In theory, I'm in the one sector that has growth potential — computers, especially web programming — and I'm highly skilled and well-educated, but those facts don't seem to be helping much.

My current employment consists of a lot of consulting work, and some sales of some software I wrote. That was fine when I was a bachelor, but now that I'm married, I'm earning for two, because my wife got laid off in July and hasn't successfully found full-time work yet.

It's not like I'm asking for much; I'm a talented, skilled professional, darn it, but I'm willing to work for peanuts just to get off my feet: Several folks in the industry think I'm worth about $75K/year, so I started out hoping for $70K/year with benefits, and I've watched my price point slide from $65K to $60K to $50K and now I'm getting close to being willing to settle for anything over minimum wage. (Okay, I'm not <i>quite</i> that desperate yet, but ask me again in a month...)

We're already not buying Christmas gifts this year, and we've cut back on everything. We don't waste money: I'm half Dutch and half Jewish! We haven't bought electronics of any kind in over a year, we haven't bought clothes, we have a small 900-square-foot apartment — we've been thrifty. But even so, thanks to my wife's lack of income, her (large) student loan payments, the rising cost of everything (including our depressingly large health-insurance premiums), and my current meager income, about a week ago we hit negative for the first time: We owe more money than we actually have. I don't know how I'll pay December's bills when they come around, much less my $1000 quarterly tax bill in January.

So the upshot is that lately I'm highly unambitious about art and writing and life in general. I'm doing little else lately but job-searching and hearing "You're a great candidate" but never hearing anything beyond that, and I'm feeling generally pummeled by the world. Maybe this'll seem like nothing in a few months, but right now, I'm at the bottom of a pit, and the narrow shaft of sunlight that's sustained me is thinning by the day, soon to vanish altogether.

A Final Politics Post

Thu, 06 Nov 2008 19:49:27 GMT

lj-music: Ikimono-gakari

Well, folks, the election's done, and I wish to offer my heartfelt congratulations to Barack Obama. He won soundly, and earned his new job. Let's now all cross our fingers and hope that he really is as good as we all think he is. It's gonna be an interesting four years, folks.

I'd like to conclude the series of journals I've been writing on politics here with a commentary on something I read in the news today. It probably comes as no surprise that the Republican Party is doing some soul-searching right now, demonstrated well by this AP interview with RNC Chairman Mike Duncan:

Republicans, Duncan said, "are going to take a deep breath and listen to the American people." The party is creating a new online forum that will allow people to explain "how we let them down" and "what we can do to restore confidence in our party," he said.

I'm a registered Republican, a moderate centrist. I voted for Obama.

Why? I voted for Obama not because he himself was a centrist — he's definitely not — but because the modern Republican Party and its platform moved so far away from the center that it didn't include me anymore, and Obama at least tried. There is no "big-tent GOP;" if anything, the GOP's tent shrank remarkably over the last few years to exclude nearly everyone who's not a hardcore evangelical Christian.

So, GOP, when you get your forum up, here's what I'd suggest if you want my vote again:

No more dumb wars. You can wage a war if you want, but focus on the target and have an end-game. If you can't explain from the outset in exacting terms precisely what victory looks like, you shouldn't be involved in the war in the first place. I know people who voted against you because they lost friends in Iraq — but you dishonored those losses by never giving them meaning, by never showing how they could add up to victory. Iraq's a loser because it has no end-game; Afghanistan's tolerable to the American public because there's an exacting target: If we kill or capture bin Laden, the war's over.
Curb your evangelicals. I know the Christian Coalition is a respectable chunk of the Republican base, but there are a lot of us out here who see the Jerry Falwells and Pat Robertsons of the world as cut from the same cloth as the Ayatollah. The more influence they have over you, the less I want to be anywhere near you.
Prioritize wisely. Guns, God, and gays are fine topics, but when there's a war on and the economy's in the toilet, most of the public doesn't care whether gays are marrying or teenagers are getting abortions because we have bigger problems to deal with. All politics is local, and you lost because you didn't pay attention to the highest local priorities.
Litmus tests scare people away. In the same vein, if you want a bigger tent, you'd better be willing to let moderates back into it. I don't cast my vote based on which candidate shouts loudest about abortion, pro or con: I'm more concerned with fiscal issues than social ones, so when you play up the social ones, I tune out, with good reason.
Remember your platform. You're the party of small government and fiscal conservatism --- or at least you used to be. For eight years now, you've wasted money like a drunken teenager on spring break. When you were actually conservative, people voted for you, but right now, you're more liberal than your opponents, and the voters can see that.

So there you go, GOP. You have four years to reform yourself and show me why I should be voting for you again. Good luck; you'll need it.

Inkscape 0.46

Sun, 26 Oct 2008 05:11:58 GMT

I do most of my artwork with CorelDRAW version 11, and today I was encouraged to try Inkscape (again). Now the last time I tried Inkscape (about two years ago), it just wasn't even close to powerful enough for my needs. I'd get supremely frustrated if I tried to use it for anything big too; it was missing a large number of the features (especially PowerClip) that I (ab)use heavily to create drawings like this.

So I played around with it, and it's improved a lot over the last couple of years, but it's still incredibly weak in its handling of clipping objects, which are pretty much essential to all of my shading. Its clipping support has gone from a usability grade of F to a grade of D+; that's an improvement, but it has a long way to go. Overall, it went from a D- to B-; there's a lot to like there, but it feels very incomplete compared to its commercial competitors. Much of what it improves over CorelDRAW 11 is stuff that CorelDRAW X4 or even CorelDRAW 12 has, if I ever get around to upgrading; and there's a lot that CorelDRAW does that it doesn't.

So if you ever talk to the Inkscape people, this is what I'd need to see them change (at a minimum) for me to consider switching to it:

A clipping system (like PowerClip) that (A) doesn't destroy or hide the clipping object, (B) lets me readily alter the clipping object's shape, (C) lets me easily add multiple objects to the clipping object or remove them on a whim, and (D) lets me go inside the clipping object and alter its contents without removing them first. Their clipping system does none of these.
An objects docker that shows the entire document tree. Maybe Inkscape has such a thing, but I couldn't find it, and I looked all over. This is an incredibly useful tool, and I refer to it frequently. It has other dockers (right-side tool panels); there's no reason it can't have this one too.
Direct import of CorelDRAW .cdr files; I won't switch if I can't bring my artwork with me. Having a dubiously-supported third-party tool doesn't really cut the mustard.
Object blend. I use this a lot, and while their path thing can do this (I think), it seems very cumbersome compared to simply selecting two objects and clicking "Blend."
Right-click zoom-out. When you have the zoom tool selected, the right mouse button should zoom back to the previous zoom level, not pop up a menu. There is not even a button anywhere in the interface that I can click on to perform this same simple task right now, which makes navigating around the picture a real chore.
An actual useful right-click menu for the node tool. I expect node-related operations to be on its menu, not object-related operations. Having to move the mouse up to the toolbar for every node operation involves a lot of wasteful mouse motion.

This doesn't even get into printing support, color management, paragraph text, or any of a hundred little niceties that are missing. About the only thing it gives me over CorelDRAW is bug fixes for some features, and I'm willing to place bets those bugs have been long since fixed in newer versions of CorelDRAW.

On the plus side, some features I did like in Inkscape were its nice handling of alpha on all objects and its ability to easily gaussian-blur objects. Those are really neat features, great for performing really sophisticated shading, and I'd love to have them be a part of my standard toolset; but things like PowerClip and blend and other tools I use daily are more critical to me.

So, well, good try, guys, and keep it up; you'll be competitive eventually, but for now, Inkscape is still a little too weak for me to use regularly; but, unlike two years ago, I can at least now see myself potentially using it in the future, if the feature set becomes capable enough for my needs.

Wedded Bliss

Wed, 01 Oct 2008 16:48:21 GMT

On Saturday, October 4, 2008, just as the fall leaves start to turn (and a mere three days from today), the lovely Songbird and I will be married near sunset in a little white Methodist church in the even littler town of New Milford, Pennsylvania, a pretty picture that's right out of a Norman Rockwell painting. Say hello to the soon-to-be Mr. and Mrs. Inker :)

We have about 120 guests who will be coming from all over the world (literally!). There'll be the ceremony itself (very traditional, too!), the reception, music, a sit-down dinner, dancing, and an open bar, so it's gonna be one heckuva party.

On the night of the reception, she and I will disappear around ten o'clock, to hop into our limousine to the Philadelphia International Airport to catch our early-morning flight to the sunny warm aqua waters and fresh winds of the Aloha State.

Me, I'm incredibly happy and terrified out of my knickers at the same time. I've never been good in front of large crowds, and I'm a lot more comfortable behind the scenes than being the center of attention. But I really, really want to be married to Songbird; she's the best thing that's ever happened to me, and if that means I have to spend a day scared [bleep]less, I'll do it in a heartbeat. Songbird, I love you, and I can't wait to see you walking down the aisle on Saturday.

Update and Cleanup

Sat, 13 Sep 2008 00:21:09 GMT

So it's been some time since I last posted here, not because I really wanted to delay, but because the past few weeks have been pretty rough. First, I banged up my arms on the boat and could barely type for a week; then I accidentally jabbed a knife into my thumb (ow) and couldn't type for most of another week; and lately I've just plain been busy.

Part of that's because I've been preparing (gulp) to go job hunting: My current work is good, but I'm getting married really soon, and my current income and Songbird's current income just aren't enough to cover our collective bills — that, and I've been thinking for a while now that it was time to start doing something different career-wise. Despite the fact that I own my own (very small) company, I really do feel like I'm going in the wrong direction right now.

Luckily, I work in the computer industry, and folks pay pretty well here, so we'll be okay once I find a new job, hopefully in web-dev stuff; that's been a lot of fun to work on as I've been doing it more and more over the last couple of years, and it's a place where I feel like I can actually contribute something meaningful. But job hunting is scary no matter when or where you do it, and as it's been seven years since I last did it, I'm pretty rusty on the whole resume-and-interview process — not on my work skills, which are, as always, in tip-top shape and very current, but on my interview skills.

Anyway, to that end, I've decided to clean up this blog a little; I've removed some of the sillier postings and personal postings from awhile back, and left mainly the more recent postings and stuff about CMXpress, since that seems to be why most people are coming here anyway. Anybody who really wants to delve into my private life can find plenty of it elsewhere online.

But let's get into the meat of the topic: What's the status of CMXpress?

The answer is that it's in progress. We did a successful rollout of it to Crossworlds back in June, and Crossworlds has been running on it ever since, which is good. That said, I learned a lot during that rollout, and realized that it wasn't quite ready for the general public yet. Thom was willing to put up with some installation headaches to gain its administration tools, but the average Joe-on-the-street isn't going to be able to. (C.D. Rudds, who draws and writes SailorSun.org, has been working with it a little bit for his new site, Wolfpac, and that's also demonstrated some areas where it's needed more cleanup and end-user-friendly-ization.)

So some parts of it were pulled back into the workshop for retooling; during the Crossworlds rollout, I went through three or four version numbers in a hurry, patching and fixing and upgrading. I've since done a lot of work on the installer, and fixed a lot of interesting (and ugly) bugs in the backend, and added in some services that really should've been there since the start (like logging). It also needs documentation by the barrel; this is a huge and powerful package, and right now, I'm really the only person who understands it fully, and a lot of folks who are testing it have been griping about that fact.

And, of course, there was about a month during July when I was swapping out its BBCode parser with NBBC, because the old parser was slow and was covered under GPL, which isn't very friendly toward my preferred BSD license.

So where's that leave us? Right now, I'm working on the logging-and-statistical facilities, so that site owners can get a handle on their visits and visitors, which is useful for a wide variety of purposes (not the least of which is paid advertising). I've backported some of the new code to the old Wotch site, so that their database is kept in sync with CMXpress's preferred format (Lordy, Lordy, I can't wait to finally switch in the new code at the Wotch site). The search engine is in pieces right now, too, and needs some work; and I've seen a lot of evidence from the test sites that the custom-page facilities will need to be done, finis, finito before I can release CMXpress to the public too.

I know I told folks that I was hoping to have it released this summer, and I'm sorry for not releasing it yet. But I think it's better this way: The test sites have identified some places where it still needs work, and their discoveries (and my subsequent bug-fixes, patches, and upgrades) will help all of you who are waiting on it. Ideally, this thing should just be install-and-go, but it's just not quite there yet.

One other topic that arose as I was talking with Becky Heineman the other day was a simple enough question: She pointed out that she'd needed a webcomic engine for Sailor Ranko, and so she just built one in a weekend, and added most of the facilities she wanted within a week or two after that; and given that that was so easy for her to do, what was the point of CMXpress? To this question, I have several answers, and I think they're all valid:

Most webcomic authors aren't a Becky Heineman, for one thing: Becky's a star programmer, capable of coding anything she wants in relatively short time. Whereas a typical webcomic author knows how to write and draw, and if he's lucky he can scrabble together a few lines of PHP to help automate the site a little, but coding a solid backend is beyond him.
Becky's engine is no doubt powerful and well-suited to her needs, but it probably doesn't scale to other sites. That's the same problem the current Wotch code has and that many webcomic sites have: The code's acceptable enough code for the needs of that site, but it was designed to run that one site, not hundreds of others, and isn't easily customizable for another site. There's a very good reason we've repeatedly turned down requests for the current Wotch site code — it's ugly and unportable.
CMXpress provides sophisticated and easy-to-use administrative services. A coded-over-the-weekend system provides very minimal administration (I should know; I've built enough of those kinds of things). A good general-purpose package should be so incredibly point-and-click-crowd-friendly that anybody can manage reams of data, and the Crossworlds rollout has shown CMXpress is meeting that goal: Darin Brown, the artist for Crossworlds, is very computer-phobic but has used CMXpress to post a comic or two by himself, and I consider that a very successful benchmark.
CMXpress provides a solid API. The API of most backends is somewhat ad-hoc: You add stuff by altering a line of code here and there. For CMXpress, I wanted to do better than my last webcomic engine, and build a system that a programmer could love, with a clean, tight API that makes a lot of nasty stuff (page templates, BBCode, form handling, administration, etc.) really easy, and that ensures that site changes can usually be done without altering the engine. I'm tired of reinventing the wheel, and I think that even the webcomic authors who are programmers probably would rather the hardest work be done for them too.
CMXpress is maintained. This thing was built first and foremost to meet the exotic needs of the Wotch, and that means I still am going to be regularly adding features and patching bugs because of my involvement with them. Although I've drawn some webcomic pages in the past, I'm not a webcomic author and don't really want to be; I'm a coder, and I'm quite happy with that job. This means that you can fix bugs and add upgrades to your own site just by downloading the latest copy of CMXpress and installing it: It's a lot easier to steal my bug fixes than to make them yourself, even if you are a programmer.
CMXpress is needed — whether any other site ever uses it or not, Crossworlds is already using it, and the Wotch needs it very badly, and Tsel's asked several times if he can install it on Cheer! too. For those reasons alone, I will continue working on it. People want it; it has a purpose; there's the answer.

All that said, there's nothing stopping anybody from building their own webcomic engine and distributing it; competition is healthy for the market, and in the end, the users win, and the readers (like me!) win too. I'm gonna keep working on CMXpress because people want it and need it, but if a competitor arises? May the best webcomic engine win :-)

Oops

Fri, 22 Aug 2008 03:36:05 GMT

I had a fight with a steak knife and lost today. I'm typing this one-handed right now. My hand will heal, and I (thankfully) didn't need a hospital visit, but this touch-typist is down for the count right now. So... uh... there you have it. If I'm not talking over IM or responding to your comments, now you know why.

I'm glad I knew to quickly apply a tourniquet, and I'd like to thank my Songbird for her support; I doubt I'd be doing well right now without her.

Edit, 12 hours later: I can type a little better today (still minus a finger and on painkillers), so here's what happened: Hold your hands out in front of you, palms down, about shoulder-width apart. Pretend you have a knife in your right hand, and a scrubby brush in your left hand, and that your hands are over a sink. You've finished cleaning the knife, so you put the scrubby brush behind the sink. You go to put the knife away in the rack to your left, but you miss, and the tip of the knife strikes the back of your thumb, right at the joint.

Lots of blood spurts out of the stab wound, because you hit an artery. You cry out, your fiancée comes over, and she quickly helps you apply a tourniquet to stop the bleeding while you wash it under cold water. The stab wound is small but deep, but doesn't hit the bone, thankfully. But the loss of blood is making you woozy, so you lay down. She applies antibiotics to the cut, and then a bandage, and makes you take a bunch of painkillers, and you spend the next few hours laying down and drinking liquids, trying not to pass out. Eventually, you slowly recover, but your thumb hurts like hell. It's a very small but very deep cut, so there's not much a hospital could do, so you don't go, but it still hurts.

Funny thing is, I know knife safety. I carry a swiss army knife in my pocket, and have since I was 16, and I use it all the time. I've never gotten even so much as a tiny cut from it; I get more injuries from paper cuts than I do from knives. But... all it takes is one mistake.

On the plus side, I learned firsthand that our new steak knives are really nice and sharp! :D

NBBC and open-source thoughts

Wed, 30 Jul 2008 22:44:44 GMT

As most of you know, I've been working hard on a webcomic software package called CMXpress, and one of its distinguishing features is that for nearly all the places where a user can type text, it uses BBCode to allow you to format it.

I discovered around the start of this month (July) that the BBCode parser I'd been using was covered under the GPL. This is bad.

See, here's the thing: CMXpress is covered under a BSD license, which is about as open as open-source gets: Free as in speech, free as in beer, you can download your copy, modify it, sell it, do anything you damn well please with it --- you just can't claim you wrote it. Which is fair, I think: BSD and similar open licenses have helped spur the development and the spread of a huge number of software packages.

The major competing open-source license is the GPL, which is similar in principle, except for two things: First, you can't take the code, modify it, and not release your modifications to the public. BSD allows you to have a private copy, effectively, and GPL doesn't. Second, the GPL is, as Micro$oft rightly argues, somewhat like a virus: It infects everything it touches, and overrides everything it touches. If I had (stupidly) included that GPL'ed BBCode parser with CMXpress, CMXpress itself would have been forcibly covered under the GPL.

I don't like people telling me what I can and can't do.

So the old GPL'ed BBCode parser is out, and I couldn't be happier, really. It wasn't really that great a piece of code to begin with; it was cranky and somewhat inflexible, didn't handle whitespace in ways I really wanted, and the original author stopped supporting it two years ago. I did some searching, and there weren't any other good BBCode parsers out there; seems a lot of people are looking for one, and nobody's written one...

...Until now. Introducing NBBC, a fast, flexible, well-documented BBCode parser that's covered under a BSD license. Unlike most open-source code, it's well-commented, includes a huge user's manual, includes several examples, and is small and lightweight to boot. It's a validating parser, meaning that no matter what broken garbage your users type in, you get XHTML 1.0 Strict out. It runs under PHP 4.0.5 or later, and is everything that old parser wasn't. It's long overdue. Go download your own copy now.

NBBC will quickly replace all of the places where I used that old BBCode parser: It's faster, more flexible, works flawlessly right out of the box, and has a nice API for adding extensions and new tags and smileys and other stuff.

NBBC is hosted by SourceForge, and I have mixed feelings about that. On the one hand, SourceForge is a nice clearinghouse for open-source projects. On the other hand, SourceForge seems to me to be a royal pain in the @$$ to work with, and somewhat slow. Still, I'm giving it a try, and maybe SourceForge will grow on me over time.

And those of you who have been wondering where CMXpress is can stop wondering: CMXpress has been inside the garage while I replace its BBCode parser and get rid of anything that smells even vaguely like the stink of the GPL.

The Acceptance Speech

Mon, 16 Jun 2008 03:58:05 GMT

My fiancée is a theater geek, and tonight's her big night of the year: the Tonys. It's a bit more entertaining than the drivel embodied by most award shows, since theater tends to be a bit more substantive than most other fields of entertainment, but still, at three and a half hours, it drags like a bad prom dress.

Much of the boring part is, of course the acceptance speeches. Sometime around the 900,000,000,000th award, I found myself wishing that someone would stand up and actually make a good and entertaining acceptance speech for a change. It would be spoken slowly, and it would go something like this:

"I couldn't be here tonight, so I asked myself to come in my place and read this speech I wrote. Please bear with me."

(He reaches into his jacket and withdraws a written acceptance speech. He begins reading it slowly and carefully.) "Screw you. I hate you all. Backspace. Backspace. Backspace. Thank you all so much for giving me this award in the field of acting, writing, and/or directing."

(Pause.) "Note to reader: If I have been nominated for a different category, please alter the speech accordingly, and remove references of loathing and anger where appropriate."

(Deep breath.) "I could not have acted, written, or directed this play or musical without support from loved and cherished immediate family members whose names I conveniently forget when I write speeches. I would like to thank the producers who saw my obvious brilliance and asked me to star, write, or direct this play or musical, knowing that my talents would win them an Oscar, a Tony, an Emmy, a Pulitzer Prize, and/or a Nobel Prize. I would like to thank Jesus, Ghandi, Mohammed, Buddha, Zeus, and my mother, not necessarily in that order. Finally, I would like to thank my wife, whose name I cannot recall, having just married her in Vegas last Thursday."

"Thank you all once again for this statue or certificate, and please know that if you were to star, write, or direct a play I would gladly give you a similar one in return, so long as it is made entirely of chocolate, preferably without nuts, as nuts are expensive."

See that? That's an acceptance speech with some cohones. That's an acceptance speech they'd be talking about around the water cooler the next day. Anybody can thank everyone they've ever met. Not everybody can thank nobody, much less make it fun to watch.

P.S. If you're nominated for something and want to steal my speech, steal the damn thing. Maybe that'll be one less boring, lame-ass acceptance speech I'm stuck having to sit through. Thank God for TiVo.

CMXpress, getting closer

Sat, 17 May 2008 06:04:56 GMT

I built a comic-import tool for CMXpress over the past two days, mainly because while CMXpress makes it pretty easy to upload a comic, if you have to upload, say, a hundred of them at once, it can get to be a chore. The initial test installation on the Crossworlds comic is going well; once I had the bugs worked out of the import tool, I was able to import, sort, and categorize all 93 comic pages (that's 75 in-canon comics, 2 cover pages, and 16 fillers) in the space of about a half hour; and most of that time was spent going through the comics and trying to decide which ones belonged in which story arcs.

Overall, CMXpress is starting to feel very good. It's still a little rough around the edges, and there are some bugs to deal with, and a few things that aren't fully implemented yet, but the overall feel, to compare it to cars, is "Porche in need of some body work" (which is a lot better than "Yugo in need of demolition"): There's more work yet to do, but it's starting to finally really feel like something people can and would willingly use.

For the record, the initial version of CMXpress we installed on the Crossworlds test site was v0.9.2, and the current version installed there is v0.9.4.

CMXpress, rolling out like a snail

Tue, 13 May 2008 05:46:45 GMT

Okay, we're not quite at the stage of a major rollout, but we hit a milestone with CMXpress tonight. I got enough of the installer done that I was able to package up CMXpress in its current beta form and install it successfully on another site --- or, more accurately, I watched and fretted while my friend Thom installed it ;-)

There are a number of bugs to squish yet, but overall, I'm pleased; we got it installed relatively painlessly on his site in about an hour and a half (it'll take only about fifteen minutes for most people to install once CMXpress is released, but we were finding and fixing bugs during the install), and the next step is to start configuring it to the needs of Crossworlds and import his existing data.

Based on his needs, I think I need to spend a lot of time working on importer code, even though that wasn't part of the original design spec, because he's got a decent-sized comic that really needs to be inhaled more easily than importing the comics one at a time, and he's also got a blog that he'd like to turn into CMXpress's built-in news system. A package for managing data isn't very useful if you can't get your data into and out of it easily.

Still, though, I'm a relatively happy camper; I've suffered through far worse initial software rollouts than this.

The IE8 beta: Nice try, guys

Thu, 06 Mar 2008 16:09:03 GMT

So today I tried out the newly-released Internet Explorer 8 beta. You can download it and install it yourself, but it's a beta, not a final release, so don't expect polished edges.

Overall... well... my results were mixed. Yes, it passes the vaunted ACID2 test. That's good. It's definitely a step in the right direction. However, ACID2 isn't a test of all of the CSS 2.1 language specification; it tests a lot of important cases, but not everything. And while IE8 does correctly render ACID2, it definitely doesn't get all the other parts of the CSS 2.1 spec correct.

I pointed IE8 today at the current build of CMXpress to see how it'd handle it. CMXpress is a very Web 2.0 program, and its back-end (the administration side of it) makes extensive use of CSS, XHTML, Javascript, and AJAX for its page layouts. Its front-end (the part visitors see) uses whatever page template the site is set up with, and the default front-end I've been working with is an XHTML+CSS variant of the Wotch's front page.

Both the back-end and front-end are rendered, perfectly, unchanged, by Firefox 2, Opera 9, and Safari 3. They do have embedded IE-conditional comments so that they can render acceptably on IE6 and IE7 by including additional stylesheets.

IE8 gets it wrong. Not massively wrong, but wrong enough that the site is unusable. The front-end has a lot of formatting and layout glitches, with many of the link images being scattered around the page semi-randomly. The back-end's Javascript is broken in its entirety; IE8 gives up somewhere in the middle of the code, and I'm not really sure why yet. Without that Javascript working, all the AJAX and Web 2.0 stuff that it does is non-functional, so the back-end is effectively unusable.

Don't get me started on other Web 2.0 sites like the new Yahoo! Mail (crashes on a Javascript error) or Google Maps (looks like it went through a blender) even a simple page like script.aculo.us's front page (flickers and animates all wrong).

Google Maps on IE8 or postmodern art? You decide.

And did I mention the speed? You can tell when IE8 is rendering a page in "Standards Mode" because it's slow. Slow like molasses in January. Slow like a dead sea turtle crawling up the beach with a towtruck on its back. Maybe they have a lot of debugging code in there: I don't know. But what I do know is that its page-render times are better-expressed in geologic terms than in seconds. I dare you to resize the browser window. Go on, do it. Let me know how that turns out for you, if it ever finishes.

Oh, about all those new features... Yes, IE8 comes with a raft of new features, most of which seem to be designed to point IE's users at various Microsoft Live services. You can right-click on text and search for it on Microsoft Live Search. You can translate it with Microsoft Live. You can post it to your blog on Windows Live Spaces. Anybody see a trend here?

Conclusion? IE8 breaks pages that worked under IE7. We knew that going in, and that's okay, because IE7's rendering sucked. The problem is that it didn't replace IE7's pseudo-standards mode with a real standards mode: It still breaks pages that are standards-compliant, pages that work fine with three different competing renderers. And it adds in new "features" that seem to me more about targeting people toward Microsoft services than anything else. From my perspective, it looks like Microsoft spent some of their time making IE8 appear less broken without actually making it less broken, and the rest of their time extending the monopoly.

I wanted to like IE8. I really did. I wanted to believe the hype about CSS compliance and all the other good rumors. I've been telling other devs, well, just wait for IE8, you'll see, it'll be great. But this is just pathetic. Seems to me like it's business as usual in Redmond, and now we web developers will have yet another nonstandard renderer to support.

Thanks, guys, thanks a lot.

The lessons we learn

Fri, 29 Feb 2008 14:26:30 GMT

Nobody's above learning a new lesson, and I'm no exception. Today, I spent several hours going through many large chunks of PHP code I'd written removing security vulnerabilities. Yes, that includes the Wotch and CMXpress.

On last week's 910CMX podcast, I explained that website coding should really be left to the experts: If you want to have a webcomic site, let somebody else write the code, and stick to drawing and writing your script, because I can pretty well guarantee you'll produce code that's a hacker's dream. There are a hundred well-known pitfalls, and there are really weird, obscure pitfalls too, like the two I cleaned up today.

The first pitfall was that of not including the "D" modifier on all regular expressions that use the "$" operator. (If that sentence confuses you, you'd better skip to the bottom of this post, because it only gets more technical from here.) For those who don't know what the "D" modifier does, you're not alone: It's not mentioned in most commentaries on preg_match(). But it does something very important: It says that the "$" operator matches the end of the string, not the first newline embedded within it.

This means that this simple-looking code has a huge, huge security vulnerability, a gaping hole big enough for a dragon to fly through:

$page = $_GET['page']; if (preg_match("/^[a-zA-Z0-9_]+$/", $page)) { ... do some stuff with $page, which has been checked and found safe ... }

Don't see the hole? You're not alone. It's perfectly-reasonable code that checks to make sure that the incoming parameter "page" is a C-like identifier --- doesn't it?

Turns out that it doesn't do that at all. This code will allow "apple" through and "apple2" through... and it'll also allow "apple2\n@^#$" through and "x\n<script>Insert evil code here</script>" through, because the "$" operator will match any newline. If a malicious attacker were to feed a newline into this script, he could insert any characters he wanted after that newline and they'd go right through.

The right way to code it is this:

$page = $_GET['page']; if (preg_match("/^[a-zA-Z0-9_]+$/D", $page)) { ... do some stuff with $page, which has been checked and found safe ... }

The all-important "D" modifier on the end says, "Match the whole string, not just up to but not including the first newline." Without it, an attacker can potentially inject anything he wants to into your variables, bypassing your checks. Nasty.

And this isn't just a PHP problem, either. Anything using the PCRE library to process regular expressions is a potential victim --- Python, I'm looking at you too, and I wouldn't be surprised if Ruby were also a victim here.

The second one I ran into is a PHP-only issue, which is that the $_SERVER['PHP_SELF'] and $_SERVER['HTTP_HOST'] parameters are wildly, terribly unsafe to use. In fact, many security advocates are generally now recommending that people avoid using $_SERVER whenever possible. Which, of course, it often isn't, but that's beside the point.

The issue here is that PHP_SELF and HTTP_HOST come from the client and aren't generated by the web server itself. Which means that a suitably-nasty client can insert all sorts of unpredictable stuff into those, some of which will definitely break your code. This is discussed much better here, if you want to study it in depth.

The upshot is that in your code, you should never use the variables on the left below and always use the variables on the right:

PHP_SELF ----> REQUEST_URI
HTTP_HOST ----> SERVER_NAME

As usual, you should never, ever, ever trust HTTP_USER_AGENT, because that can be (and often is) readily spoofed. DOCUMENT_ROOT is marginally reliable, as it comes straight from the server's httpd.conf file. SCRIPT_FILENAME is relatively safe, but often not useful; and SCRIPT_NAME should be avoided because it often isn't what you think it is (on a server that uses PHP in CGI mode, it points to the PHP binary, not to your script).

Again, mishandling these can allow an attacker to inject nasty things into your variables that you don't expect to be there.

These holes now are fixed on the sites I maintain (including the Wotch), so don't bother trying to take advantage of them. But before a few hours ago, they were there, which just goes to show how difficult web security can be: By all measures, I'm an expert --- I have a degree in computer science, I've been coding for 23 years, and I speak PHP very fluently --- and I still made these mistakes. So be careful when building web sites, folks, and if you're not sure what you're doing, leave the code to the experts (who at least know how to fix these problems when they learn about 'em).

On Commissions and Requests

Fri, 22 Feb 2008 19:31:39 GMT

It's been asked (again) why I don't take commissions and don't do requests. So I think I'd better boil this down one more time.

Commissions: To put it bluntly, you couldn't afford it. Not because the art's so wonderful, but simply because it takes me hours and hours and hours to do a typical picture. Lineart often takes four to ten hours, and a finished colored work can be anywhere from twenty to sixty hours. At even ten bucks an hour, I'd have to charge anywhere from $200 to $600 for a finished work, and that's far outside the price range of most potential commissioners --- especially for all-digital artwork where you don't even get a canvas in the mail for your money.

Requests: I usually have plenty of ideas of my own, for one thing, and for another, most ideas that have been suggested don't inspire me. My muse is fickle, and if she doesn't get inspired, I don't draw: It's that simple. You can propose a thousand ideas, but if none of them strike me, it just won't happen. Sorry. So to save you the embarrassment of being turned down a thousand times in a row, I just say upfront, "No requests."

That's it. No commissions because you can't afford them, and no requests because my muse won't like them anyway.

But, hey, if ya got a few hundred bucks burning a hole in your pocket and you're just dying to get a PI original, maybe we can still talk ;-)

Antivirus Software Sucks

Mon, 21 Jan 2008 19:21:04 GMT

Okay, I'm getting pissed.

I just uninstalled my antivirus program (Kaspersky AntiVirus Trial Version) and it took a very large percentage of my computer's functionality with it when I did. Everything worked fine yesterday before I uninstalled it, and now --- well, now it might be simpler just to reformat the thing and start over:

The Windows login screen is borked. Clicking on names to login does nothing; you have to hit Ctrl+Alt+Del twice to get to the old login screen and login from there.
The mouse is borked. I have a six-button mouse that now thinks it's a two-button mouse no matter what mouse drivers I have installed.
The UI is borked. Clicking on windows to bring them forward often doesn't work, and neither does the taskbar and usually the only reliable way to switch between applications now is Alt+Tab (and even that doesn't always work).
The software is borked. Sure, some stuff runs, but a lot of the most essential applications I use, like Firefox and CorelDRAW, now have weird glitches --- like in CorelDRAW, I can use all of the tools --- except the critical select tool, which makes the entire package now utterly useless. It's like having a word processor that lets you type text, but that prohibits you from changing anything you've already typed in the document.

I hate antivirus software.

I hate antivirus vendors.

It wasn't always this way. Once upon a time, an antivirus program was something you ran at your leisure, and it would search, find things, and then go away. No intrusion, no logos, no blasting alerts in your face, no hooking its tendrils into the core of the operating system.

But faced with declining revenues and declining interest, every one of the antivirus vendors now installs a package that is brutal, gargantuan, dictatorial, and, whether you ask for it or not, sinks its hooks into every last corner of the OS. It's not just Kaspersky --- I've seen the same exact behavior (on other computers, thank God) from McAfee, Norton, Trend Micro, Panda --- they all uniformly suck.

So, AV vendors, you want to mollify me? I've been in the computer industry longer than many of you have, and I have expectations. If you want a thumbs-up from me, here's the criteria:

You add or modify a single file in C:\Windows or any subdirectory under it? You fail.
You may add ONE key to the Registry under HKLM\Software and HKCU\Software, but if you add or change anything outside that key, you fail.
You may add ONE directory under C:\Program Files, and you may not place anything executable --- EXEs, DLLs, OCXs, you name it --- anywhere other than that directory. You alter or replace any other EXEs or DLLs anywhere else? You fail.
You may add ONE directory under [username]\Application Data if you need to store configuration files somewhere. Store them anywhere else, or alter files anywhere else? You fail.
You may not "call home". No exceptions. If you call home, you fail.
You may not use system hooks, API hooks, or input hooks of any kind, no exceptions. If you hook anything, no matter how temporary the hook, you fail.
You may not monitor my actions, for good or for evil. If you monitor even a single byte, you fail.
I will tolerate false negatives, but not false positives. If you give me a false positive, you fail.
If you run without me explicitly asking you to run, you fail. No exceptions.
If I cannot manually uninstall you by simply deleting your single directory like any other application, you fail.

So, antivirus vendors, you want my thumbs-up? That's what it takes. There's not a current antivirus product on the market that even comes close to meeting those criteria --- most can't even meet two or three of those criteria, much less all of them. Hell, by those criteria, Notepad is a better antivirus program than any current antivirus software. If you want my thumbs-up, those are my rules. They're not hard rules to meet --- unless you don't give a flying f*** about your customers.

Which, I think, pretty well explains most of the current antivirus software on the market.

Sheer Exhaustion

Tue, 11 Dec 2007 08:04:44 GMT

Well, folks, on Saturday (that's a mere four days from now by my clock), I'll be moving.

It's a big move, in that my fiancée, Songbird, and I, are moving to a new apartment together.

All of my life is packed in boxes right now, from the credit-card bill I paid last week to the book of Christmas carols a six-year-old boy received and then kept for another twenty-five years. It's a strange thing to have your life compressed down into countable units, to say, everything that defines me except for what's in my head is sitting in a Tetris-shaped pile on the floor, awaiting large men to whisk it away and my past, my present, and my future with it.

Maybe that's a little too deep. What can I say: I'm exhausted.

The packing isn't done yet, either.

We're moving to an apartment complex about a half hour away, and it's a nice place, with good nearby amenities, ready access to public transportation, a reasonable driving distance to Songbird's job, and a nice little office for my work. I've been here for eight years now, almost eight years on the dot since graduating college, and I've felt a little like I was in a holding pattern the whole time, neither child nor adult, neither student nor salaryman, despite making a reasonable income and not being in any kind of school.

I wonder at what point you go from being a boy to being a man. I'm certain that in elementary school and middle school, I was just a boy, but somewhere after that I evolved into just "a guy," and I think I'm still waiting for that next step where Mr. Name actually sounds normal instead of a phrase referring to my father. I don't know if this move will do that, but it feels like it might.

Or maybe getting married will. We'll find out in ten months...

Anyway, I'm exhausted tired, and still haven't finished packing, and have four days of semi-coherent emboxing to perform before I can consider myself moved, followed by an equal quantity of imboxing (ain't English grand?). I apologize if this posting was less lucid than most of my writing; it's 3 AM and I've been running on very little sleep lately.

The upshot is that this week's and next week's Caity's World installments will likely be delayed due to circumstances way, way, way psychotically beyond my control. Fear not, though: The story will continue!

Quickie CMXpress progress update

Wed, 21 Nov 2007 16:33:30 GMT

Okay, so I don't have too much new to say about CMXpress, but I thought it'd be nice to show off a few of the handful of new and changed things in it, especially since I get to show off the Wotch's current status page. Here's a screenshot that gives you about 90% of what's new all at once:

Here's what's new, in short:

Admin pages with a modern theme! That's right, folks, the old flat-shaded '90s Macintosh look is out, and a shiny new orange-and-blue theme is in! Functionality is no less, and the software isn't significantly slower, so all hail the shiny and new! (Admin-page themes are not swappable, at least not in the current design. They might be in a later version, I suppose, but not for now.)

Tip-of-the-day to help remind you of things you should remember to do or things you might not already know about CMXpress or (web)comics in general.

Artists' comments (not shown) is about 80% done now, from its former ten-ish percent as of the last posting. A lot of progress there, but the remaining 20% is gonna be a bear, since it's very AJAX-heavy.

Personal settings (not shown) allow individual administrators to set personal preferences for the admin pages, like how many comics you'd like to see in a comic gallery or whether you'd like to see tips-of-the-day.

And last, but not least, there's the "events" feature, which congratulates you on having reached significant milestones. It existed in the last announcement, but as you can see, the Wotch has reached its 5th birthday today, so a big hearty congratulations to Anne and Robin on reaching five years!

CMXpress Progress Report

Fri, 02 Nov 2007 05:53:17 GMT

Okay, so here's what we're up to. The official CMXpress homepage is always reliable for the latest statistics, but as of midnight, November 1, 2007, this is what we're up to. These are the completion levels of the code, more-or-less:

~~Core page renderer~~ (100%)
~~Core admin system~~ (100%)
~~Database subsystem~~ (100%)
~~Security subsystem~~ (100%)
~~Template subsystem~~ (100%)
~~Plugin subsystem~~ (100%)
Standard plugins (85%)
~~News archives~~ (100%)
Comic archives (70%)
Custom page renderer (95%)
Search system (20%)
Admin: Comic mgt. (90%)
~~Admin: News~~ (100%)
Admin: Artist cmts. (10%)
Admin: Search (10%)
Admin: Custom pages (10%)
Admin: Site (75%)
Admin: Users (80%)
Installer (0%)

And this is how much code there is in this thing. (If you're thinking of writing your own Web 2.0 content-management engine, this ought to give you an idea of the kind of work that's involved.)

563 kb : 15,753 lines : PHP
 87 kb :  2,501 lines : Javascript (custom for CMXpress)
 80 kb :  3,652 lines : CSS
 21 kb :    592 lines : HTML templates
 32 kb :    645 lines : CMXpress documentation (very minimal at present)
 35 kb :                GIF, JPEG, PNG images (custom for CMXpress)

 89 kb :  3,504 lines : BB code string parser 0.3.1 (PHP library)
333 kb :  9,982 lines : Smarty 2.6.0 (PHP library)
 96 kb :  3,276 lines : Prototype 1.5.1.1 (Javascript library)
140 kb :  4,030 lines : script.aculo.us 1.7.1-b3 (Javascript library)
 64 kb :  1,850 lines : Window 1.3 (Javascript library)
 11 kb :    308 lines : Misc. Javascript libraries (sprintf, Tab control)
  8 kb :    395 lines : Window CSS
 23 kb :                Window GIF and PNG images

Yep, that's a lot of code, with more yet to come. I'd estimate the overall completion level of the project at around 75%, give or take a bit.

Okay, numbers are nice, but new screenshots are more fun! :D

Here we have the newly-completed news-management module, in two different configurations. Most of the administrative stuff in CMXpress is designed so that you can look at your data from a variety of different angles, and "News" is no exception. In the first screenshot, we have each posting in short form, and in the second screenshot, we're correlating news postings to whichever comic was posted closest to the same date. Cool, huh?

Note that the "Delete" button you see there is safer than it looks: Both news postings and comics don't simply vanish when you delete them; they simply get moved to the trash can. At any time, you can empty the trash and destroy them for real, or pull them back out, just like managing files on your desktop. CMXpress is designed from the perspective that its average user isn't likely to be a computer guru, and to that end, is designed to be safe and comprehensible for anybody who's even a little web-saavy.

The third screenshot is from the arc-management module, which lets you organize your comics into larger sets. Yes, we're in the process of using drag-and-drop to rearrange the arcs in this screenshot. Drag-and-drop is cool and easy to use :D

The fourth screenshot shows the user-management module. CMXpress is a fully secure multiuser system, since many comics are managed by two or three people, and allows each user to be assigned different rights and access levels. You can even grant limited comic-management rights by story arc, which is useful if you're going to have a guest artist provide filler: The guest artist can be allowed to post their comics directly, but can still be prohibited from altering any of the comics you've posted.

What's next? Artist comments have to be finalized, and some of the menu-management stuff has to be added, and the initial template has to be finished off. Once that's done, we can roll this out on the Wotch site and see how well it works under a heavy load of visitors (I expect it'll perform well).

After the Wotch, assuming there are no major glitches, I need to build a simple installer, and then we'll be rolling it out on Crossworlds, and after Crossworlds, Cheer!. If everything goes well with those three sites, then I'll open up a limited beta-testing program (a couple dozen people or so) to try to crush any remaining bugs in it and get some initial site templates built so that it can come prepackaged with a few so that true newbies can get a new webcomic up-and-rolling in a matter of minutes, no coding necessary. Sometime around early 2008, CMXpress should be available to the public, and as I said before, it'll be 100% free to use and abuse as you see fit.

CMXpress

Fri, 28 Sep 2007 15:28:19 GMT

I've been spending a lot of my time developing a piece of software called CMXpress, a package which is designed for publishing webcomics. (Pronounce it like "Com-express" or "Comics press".)

I've actually been working on this thing for years, depending on how you look at it: The Wotch runs a (much) older version of the same software, and we've gotten a lot of requests there by other people to let them use our software on their site. For most of its history, the Wotch's software hasn't really been appropriate for other sites: The administrative side was ugly as sin, and much of the code behind the front page was custom code for the Wotch site: It simply wouldn't work on other sites.

But the demand is there, since there's not really another really sophisticated, professional-grade webcomic-publishing package out there. There's iStrip, but that feels more like a hacky student project than a professional software package, and as of a year ago, it's been officially abandoned. You could publish with a provider like DrunkDuck or ComicGenesis, but those don't help much if you want to run your own site, and from what I've heard, the administrative systems there aren't all that great either. There are addon packages for things like Drupal, but that's not really designed for the specific (and I believe unique) needs of webcomics. There's no good, open-source, professional-grade webcomic-publishing package. Yet.

As long as Anne and Robin keep writing and drawing the Wotch comics, they need something to power their site, and since I'm the head programmer around there, it's my responsibility to make it something good. That's why I've taken the backend there, given it a massive overhaul, and renamed it CMXpress. They're not using the new version yet, but they will be soon, probably by the end of October. The Wotch gets tens of thousands of readers every day, which means that CMXpress is gonna go through some pretty heavy testing before it ever gets released to the public. Actually, a lot of it already has gone through heavy testing, but even so, you're only gonna see it once it's had a chance to get most of the bugs worked out.

The three biggest foci (that's plural "focus," folks: check your dictionary) in CMXpress's design are:

Security. Webcomics are a major mega-high-profile target for people who like to hack stuff, and I've put every bit of my two decades of experience into this code. Database calls are all carefully protected against injections; all I/O is wrapped and checked with calls like htmlspecialchars() and preg_match(), all necessary web requests are checked for XSS and CSRF attacks, and generally the software is just plain paranoid.
Ease of use. Most webcomic authors know computers about as well as I know rap music: Not at all. CMXpress is designed with a hefty dose of Web-2.0 and AJAX and cool clicky-draggy-droppy stuff so that it feels easy to use. The admin system looks like a web site, but it really functions a lot closer to an application on your computer.
Customizability. It's your site, not mine, which means I don't get to decide how your site looks. The front-end for CMXpress is built around a sophisticated templates-and-plugins system, which allows you to pick (literally) any design you want for your site. CMXpress does the grunt work, and if you want your site to look snazzy and cool or plain and ugly, that's your responsibility. I'm hoping that by the end, some people will contribute some initial style templates so that the system offers some nice defaults out-of-the-box: The standard one that CMXpress will come with is probably gonna be pretty plain, but you can readily alter the HTML and CSS and CMXpress will happily deal with whatever you come up with.

CMXpress runs under PHP4 or PHP5, and requires MySQL 3 or newer, and GD 2.0 or newer (GD is a common PHP extension). It's only been tested on 'nix servers (specifically Linux and Apache) and, for various reasons, probably will not run as-is on a Windows+IIS server. Sorry. CMXpress's administrative system requires a reasonably new-ish browser: IE 6+, Firefox 1.0+, Opera 9+, or Safari 1.2+. The user-side stuff requires whatever minimum browser your site template requires: If you design a template that's pure HTML 1.0, your site will run even in Lynx; in the case of the Wotch, we're targeting the same list of browsers I just gave, just because IE 5 and Netscape 4.7 are really old and moldy these days and not worth trying to support.

CMXpress will be released under the BSD open-source license when it's finally released. It uses a number of other packages, including Prototype and script.aculo.us, Christian Seiler's BBcode parser, the Smarty template engine, Sebastian Gruhier's window library, the PEAR JSON encoder/decoder, and even some modified Nuvola icons. All of these are also open-source, and are included with CMXpress. (If you need to find 'em all, use Google; I don't feel like looking up all the links again right now.)

(And now this is the place where I get to gripe about IE, which I've been waiting to do this entire post. IE sucks. Do you hear me, Microsoft? IE is the least reliable, least compatible, most bug-ridden of any of the browsers I've been testing in. It's genuinely painful for me to have to see how IE mangled my code when all the other three browsers get it right, and there's a lot of IE-specific bugfixes in CMXpress, I'm sorry to say. About the only bad thing I can say about Firefox is that it doesn't support "inline-block," but IE has barfed on almost every line of CSS and Javascript in this thing. Market leader my ass! IE7 not only produces the worst appearance of any of the browsers I test in, it also is hands-down the slowest of the browsers I test in too! Drag-and-drop for rearranging things is almost unusable in IE7 --- you people should see how slick the Opera 9.5 beta handles that! Clean up your collective act or get your butts out of the browser business, because you're patently, obviously, utterly clueless. IE8 had better have a usable layout engine, or I'm coming over there and stapling a big sign to your foreheads that says, "HASLAYOUT IS STUPID!" Er... oy. End of rant.)

Anyway, let's show some screenshots! I snapped these just a short while ago of the CMXpress beta running on the Wotch site. There's a bit of work yet to do, but you can get a feel from these what it's gonna be like.

Well, so there ya have it. Keeps me busy, if not employed. But it's long overdue.

Fun with biology and statistics

Sat, 15 Sep 2007 19:10:14 GMT

When your hobby is designing mythical creatures, sometimes you can produce better results by injecting them with a solid dose of reality. I often read up on all sorts of random biology stuff, from simple stuff like the names of horse breeds to weird obscure things like the design of a spider's cardiovascular system (and yes, it's unusual). One question that's often bugged me is: What is the mass of a centaur?

It seems like a simple enough question at first, but it really isn't all that easy.

First you have to guess what kind of proportions to use; in my case, I use a relatively small horse body and a normal-size human body, and generally assume that the resulting creature would be about a foot taller than it would if it were fully human: Males average about 6'9", and females average about 6'4". Some other artists make them smaller, and some make them larger; I think that results in fairly believable proportions, though.

Anyway, so today, I stumbled across this gem at NASA, which takes the human body and breaks it down into various parts and then measures the mass of each part individually. There's a ton of other biometric stuff on that page, so I'll copy it down for you here (50th percentile --- the classic "average" male body):

Total mass: 77.1 kg = 170 lbs = 100%

1. Head: 0.44 kg = 1.0 lbs = 0.6%
2. Neck: 1.1 kg = 2.4 lbs = 1.4%
3. Thorax: 26.11 kg = 57.6 lbs = 33.8%
4. Abdomen: 2.5 kg = 5.5 lbs = 7.1%
5. Pelvis: 12.3 kg = 27.1 lbs = 16.0%
6. Upper arms: 2.5 kg = 5.5 lbs = 3.2%
7. Forearms: 1.45 kg = 3.2 lbs = 1.9%
8. Hands: 0.53 kg = 1.2 lbs = 0.7%
9. Hips: 3.64 kg = 8.0 lbs = 4.7%
10. Thighs: 6.7 kg = 14.8 lbs = 8.7%
11. Calves: 4.04 kg = 8.9 lbs = 5.2%
12. Feet: 1.01 kg = 2.2 lbs = 1.3%

1..8 Upper body: 46.93 kg = 103.5 lbs = 60.9%
9..12 Lower body: 30.17 kg = 66.5 lbs = 39.1%

1..7 Upper body, no pelvis: 34.63 kg = 76.3 lbs = 44.9%
8..12 Lower body with pelvis: 42.47 kg = 93.6 lbs = 55.1%

(Note that the numbers for paired body parts represent both parts: For example, one hand weighs only 0.265 kg, while two weigh 0.53 kg, which is the number in the table above. NASA's figures, by the way, are the value in kilograms; the pounds and percent I computed myself, and have been rounded to one decimal place.)

Here's the same information, only as a pie chart this time:

Total: 77.1 kg = 170 lbs = 100%

1. Head: 0.44 kg = 1.0 lbs = 0.6%
2. Neck: 1.1 kg = 2.4 lbs = 1.4%
3. Thorax: 26.11 kg = 57.6 lbs = 33.8%
4. Abdomen: 2.5 kg = 5.5 lbs = 7.1%
5. Pelvis: 12.3 kg = 27.1 lbs = 16.0%
6. Upper arms: 2.5 kg = 5.5 lbs = 3.2%
7. Forearms: 1.45 kg = 3.2 lbs = 1.9%
8. Hands: 0.53 kg = 1.2 lbs = 0.7%
9. Hips: 3.64 kg = 8.0 lbs = 4.7%
10. Thighs: 6.7 kg = 14.8 lbs = 8.7%
11. Calves: 4.04 kg = 8.9 lbs = 5.2%
12. Feet: 1.01 kg = 2.2 lbs = 1.3%

(Apparently the human brain isn't all that heavy, at least as far as NASA's concerned.)

So armed with this information, we can reliably say that the upper half of an average male centaur is probably about 80 pounds.

But there's a lot of weight in the equine pelvis and thorax though, and more still in all four legs. If we assume that the equine pelvis region weighs about the same as the entire humanoid part (since they seem to have about the same volume), and again assume similar body-proportion ratios to those above (which is admittedly a big assumption too), then we can make a (very) rough guesstimate at around 500 pounds for the equine part, which seems reasonable. (We arrive at this by noticing that the human pelvis is about 1/3 of an 80-pound torso; so if the equine pelvis is equal to the 80-pound human torso, then the equine parts have about three times the mass of their human equivalents. Admittedly, that's a pretty big jump, but the resulting numbers don't seem too unreasonable, especially considering we're talking about a fairly small horse here.)

So the total, then, is that a 6'9"-tall average male centaur weighs about 600 pounds.

The weight of an average human female is about 86% of that of an average human male.

If that ratio holds in centaurs also, then a 6'4"-tall average female centaur weighs about 520 pounds.

Starting at an average human male weight of 170 pounds, we can note that below about 145 pounds, you have an underweight man, and above about 215 you have an overweight man. This suggests that a valid healthy weight range for a human male is the average weight plus or minus about 15%. If the same holds true for centaurs, we can say that the 6'9" average male centaur would be underweight at 510 pounds and overweight at 690 pounds. The 6'4" average female centaur would be underweight at 440 pounds and overweight at 600 pounds.

Of course, sadly, there aren't any centaurs out there to actually put on a scale and find all this out. But the science (what little there is of it) seems reasonable enough, and it's definitely a better set of numbers than just pulling something random out of the air.

Clinton Angrily Denies Surgery

Fri, 31 Aug 2007 17:06:37 GMT

New York (AP) A defiant Hillary Clinton today denied rumors that her overnight stay at New York's Metropolitan Hospital was for the purpose of breast enhancement surgery. "My breasts are fine," said Clinton. "I do not need implants."
    Clinton was scheduled to speak at a rally in Iowa on Tuesday, but canceled at the last minute. Aides claimed that she had caught the flu; however, a photographer from People magazine caught her leaving her New York apartment on Wednesday and entering Metropolitan Hospital. Rumors began circulating about plastic surgery on popular Republican blogs, and a media frenzy began outside the hospital.
    Clinton staff members initially declined comment. However, Clinton herself spoke today to calm worried supporters. "I did not get breast enhancement surgery. I did, in fact, have an outpatient plastic surgery operation performed by Dr. Milo Bergstein. It was a testicular implant. But not breast enhancement surgery."
    When asked whether she would consider said surgery, Clinton responded, "Let's focus on what happened here. I had a testicular implant. That's balls. Not a boob job, okay? I don't need breast enhancement surgery and definitely don't want it."
    Clinton was asked as to the purpose of her surgery. "Republicans have pinned me as weak on Iraq and national security. I am not weak and never have been, and the best way to demonstrate that with balls. Real balls. I can now say unequivocally that I have bigger balls than they have, and I will never be weak on my foreign-policy stances."
    Bill Clinton, attending the rally, was asked for comment. "It's no big deal," he said. "I support her decision fully. We haven't schtupped since the '90s anyway."
    Barack Obama was asked about Clinton's surgery during a campaign stop in Muncie, Indiana. "You've gotta be kidding me," said Obama. "How the heck can I be tied in the polls with her?"
    In related political news, Obama's support dropped by two percentage points today when his campaign publicly denied that he was Tiger Woods. "Muffy and I are just devastated," said Bentley H. Tuffington III, a former Obama supporter from Southampton, New York. "Even if he was once poor, he was a respectable golfer, and we rather liked that. He seemed like a wonderful candidate when he won the Green Jacket. We feel like we don't know anything about him now."
    Asked about the Obama campaign's statement, a Clinton aide said, "Just vote for Hillary! She can be whatever you people want her to be! Really! Black, white, a golfer, a basketball player, male, female, good, evil, anything! Just tell us what you want and she'll do it! I bet Obama won't tell you that!"
    All 193 other Democratic presidential candidates declined comment.

Bush Announces Months Bill

Tue, 28 Aug 2007 23:29:25 GMT

Washington, D.C. (AP) President George W. Bush today announced a new Senate resolution, cosponsored by Sens. Orrin Hatch (R., Utah) and Zell Miller (D., Georgia), that aims to ease the burden on General David Petraeus's forthcoming status report on the ongoing conflict in Iraq. The bill, if passed, would create four new months between August 2007 and September 2007 to give Petraeus's report, in the words of Bush Administration spokesman Tony Snow, "more time to gel."
    The four new months would be named "Octember," "Quatember," "Pentember," and "Larry." The last was chosen by Bush over the Pentagon's preferred "Hexember" or "Sexember" because, said Snow, "we felt 'sex' was simply inappropriate, and 'hex' sounded too much like witchcraft." The Christian Coalition has already filed suit against the Administration, claiming that the name "Pentember" is also too strongly related to the occult.
    Each of the proposed new four months will be thirty-one days long, despite the Pentagon's recommendation that "Larry" be only thirty days. "We felt that it was best to keep them uniform," said Snow, "to make them easier to remember, and so that you don't have to change the rhyme. It's only coincidence that they have the same number of days as the month with the President's birthday."
    The bill will require that the onset of autumn be accordingly delayed by four months. When asked whether that was possible, the Union of Concerned Scientists declined comment.
    However, the bill already faces heavy opposition from another Senate resolution, proposed by Sens. Ted Kennedy (D., La-La Land), and Hillary Clinton (D., New York), which proposes that "time shall be stopped until all United States forces are withdraw [sic] from Iraq." When asked, Clinton declined comment, but Kennedy stated: "This bill guarantees that children will not die in vain on those rice patties and in those jungles."
    Petraeus declined comment on both bills, but an aide, speaking on condition of anonymity, said, "I think they're all a bunch of frickin' crazies in the Senate. By the way, you wouldn't be willing to let me borrow that flak jacket, would you?"

An English Lesson

Sun, 26 Aug 2007 17:32:41 GMT

Since so many people seem confused about centaur-related terms, let me help you with your grammar, if I might:

"Centaur" is typically the male term, yes, but it's also commonly used to describe the species too. Specialized female forms of the word do exist, though: If she were young, you could call her a "centaurette"; but the general female term is a "centauress".

So you can correctly say:

"He is a centaur."
"She is a centaur."
"She is a centauress."
"They are centaurs."
"That little girl is a centaurette."

But you can't say:

"He is a centauress." (! wrong gender)
"That woman is a centaurette." (! wrong age)

The term "centauroid", meaning "centaur-like", refers to any creature with four legs and two arms. "Centaura" is a poor back-formation, occasionally used by uneducated writers to refer to a female centaur, but it should generally not be used: If you must refer to a female, use "centaur" or "centauress" or "centaurette", or "mare" or "filly" or "woman" or "girl", depending on your circumstances.

The suffix "-taur" is generally used in English to describe other non-horse half-human creatures: Cat-taur, zebra-taur, wolf-taur, lion-taur, human-taur (a four-legged human), and unicorn-taur, among others. (Note that the hyphen is often omitted from these.) You may also occasionally see "alicentaur" and "alicorntaur" used --- these refer to a winged centaur and a winged unicorn-taur, respectively.

If a centauroid character is otherwise horse-based but has cloven hooves or horns or a slender tail or some other minor modification, the character still qualifies under the classical term "centaur", just like a drawing of a human girl with a tail is still basically a "human" character.

Despite modern usage, the term "centaur" does not, in fact, have anything to do with horses, etymologically speaking: It is derived from ken-, meaning "pierce" or "slay", and -taur, meaning "bull". Centaurs were said by the Greeks to be wild hunters, riding horses (or possibly part horse), so adept at their riding that they could readily slay a bull. At least, that's one explanation; there are several differing theories as to the true origin of the term. Either way, the original form is a combination of "slay" and "bull", and has nothing whatsoever to do with current usage.

(This is why "minotaur", despite having a "-taur" suffix, refers to a creature that is otherwise a man but has the head of a bull: It is literally the "bull of Minos" and refers to a specific monster that was said to lurk in underground caverns on the Greek island of Minos.)

By the way, "dryad" is a term used by Warcraft III and World of Warcraft to refer to elven goat-based part-tree 'taurs; historically, it has just meant "tree girl", and refers to a spirit of the trees in Greek mythology.

Oh, one last note, on spelling: In the word "centaur", the "A" comes before the "U", just like it does in the alphabet: A "centaur" is a horse-legged person; and a "centuar" is a spelling error.

And now, just for completeness: In French you will see "centaure" and "centaures"; in Spanish you will see "centauro" and "centauros"; in German you will see "zentaur" and "zentaurin"; and in Japanese you will see "ケンタウロス" (literally, "kentauros") and occasionally "馬人" (horse person) or "馬男" (horse man) or "馬女" (horse woman).

So there you have it.

(Please excuse my placement of punctuation relative to quotation marks: I was going for preciseness in terminology here and not necessarily fully-valid punctuational constructs. That said, I've often had a beef with the "punctuation always goes before the quotation mark" rule, because it's logically inconsistent, and can readily produce meaningless sentences. I know that it's supposed to be correct to write this: She is called a "centauress." But that can imply that the period is part of the term itself, and not a separate construct that terminates the sentence. English rules have really let me down on this, so in this posting I used what I consider to be the more meaningful way to structure it, even if the proscriptive grammarians in the audience will cry foul.)

Edit, August 30: Added mare, filly, woman, and girl into the sentence on recommended replacements, and also changed "effete" to "adept," a rather embarrassing error that was pointed out to me by Don Simpson.