The W3C has gone completely mad

XHTML-Print. That's right, it's an HTML specification for printers. For people who don't particularly care how the page is laid out. For really stupid computers to print to really stupid printers.

Let me emphasize that last: really stupid printers. Non bitmapped printers (see section 1.3.2 where the explain that their target market is only capable of three fonts). Printers without enough memory to lay an entire page out (aside: at, say, 72 dpi which is awful but minimally acceptable, on the printable area of an 8 1/2" x 11" sheet of paper which we will charitably assume to be 8" x 10", black and white monochrome, it takes perhaps fifty kilobytes to store a bitmapped image of the entire page. So really really stupid printers). Printers that, while they have three fonts and are obviously capable of printing these--a non trivial feat for any bitmapped printer--are totally incapable of any other fonts. The only printers that come to mind that meet those requirements are daisy wheel printers and their ilk, which have been obsolete since before I was born.

Oh, and these incredibly stupid printers are expected to parse, lay out, and in general correctly deal with HTML. Worse, they are required to support CSS (section 4.2), a standard that maybe three web browsers in the entire world come close to supporting well, and that causes subtle bugs in reflow algorithms for the naive implementor.

And oh, the HTML they have to support! They need to deal with HTML forms for, you guessed it, printing forms on the page. Apparently also for communicating with mobile phones, which are apparently also a target for this spec. Well, that explains better the three fonts requirement, but tables? CSS? On a phone?

Hypertext! For printers! Will wonders never cease--how is a printer supposed to print hyperlinks?

Section 4.4 implies that content generators should interleave the data for images that are rendered side to side. Now, printers that can deal with images--which probably involves either a GIF, JPEG or similar decoder--probably can afford 50K of memory.

At least they restrained themselves from forcing the printer to interpret Javascript.

Now, while I understand that supporting something useful, like PostScript, is beyond really simplistic printers, and that's fine. I own one of them myself. But whatever else this spec is, it is not an answer to this problem. And I have trouble having any respect for an organization that thought this was a cool idea.

Photos again

Tree and Clouds

An okay photograph flawed again by some concentric rings--this time they don't look like thumb prints, though. I'm quite curious, now, what they actually are; perhaps Newton rings (which would be an artifact of the scanner). Even without the rings, though, I don't think this is sufficiently impressive.

Shipping pallet

This is quite different. I like the shape a lot for some reason, and I couldn't have hoped for better lighting--the corner of the pallet is just visible. Unfortunately in processing I scratched the negative up a lot and it took a lot of work in Photoshop to make it acceptable. Tonight is apparently not my night. Oh, and that Neopan 1600 is hot shit. Remarkably good grain on this considering it's a 1600 film.

Sun and clouds

Also a little blah, but still an interesting cloud system. Taken on the F100, which works fine. The photo itself had the usual quota of small hairs and dust, but no gigantic scratches like with the pallet photo. I need to find a dust free way to dry film.

Now, bed.