kaioa.com

Be sure to watch the video in HD

Oh boy... I totally forgot to post this. A year ago Farbrausch and Neuro (their site has been down for a while) made a nice real time invitation demo for Nvision 08 featuring gorgeous vector graphics, which were done with Inkscape.

Check the demo if you got a decent Windows machine. Otherwise (or if you're just a bit lazy) take a look at the video over at YouTube.

By the way if you'd like to save the video you can do that easily with the Video DownloadHelper extension for Firefox.

That's some shiny logo

CSS grid frameworks in a nutshell

There are various CSS grid frameworks, which try to make the life of front-end designers easier. There's YUI Grids, Blueprint, a bunch of other frameworks, and well, the 960 Grid System.

All those frameworks do their magic through non-semantic classes, which are added to your containers. While this sounds pretty bad, it actually isn't much of an issue in reality. Well, that is if you don't use those classes in your content. Fortunately there is very little reason to do so if you're using some kind of CMS – and if you aren't, you probably should.

Personally I happen to like the 960 one most. It's pretty minimalistic while offering enough flexibility. It's also shipped with a bunch of templates for Fireworks, Illustrator, Omni Giraffe, Photoshop, and Visio. Inkscape, however, was missing. It's time to fill that gap! :)

More accurate now

This is the updated extension for Inkscape which simulates 9 different types of vision. It's a color effect and therefore it can be found over at Effects->Color->Color Blindness after installation.

It still supports the same set of modes:

• normal trichromatic color vision
• protanopia red-green blindness (no red cones)
• deutanopia red-green blindness (no green cones)
• tritanopia blue-yellow blindness (no blue cones)
• typical achromatopsia (no cones; rod monochromat)
• protanomaly (anomalous red cones)
• deutanomaly (anomalous green cones)
• tritanomaly (anomalous blue cones)
• atypical achromatopsia (low cones; cone monochromat)

*squish*

SWF gaiden (side story)

This is some kind of spin-off from my previous mini project. As I said back then Deflate is everywhere. SVGZ files are just gzipped SVGs for example. I thought it would be nice to have some specific tool for SVGZs, but since it's just GZip I decided to generalize it a little bit.

It's basically a logical sub step on the way to the next SWF re-compression utility. It spawns several worker threads which invoke different ZIP utilities with different switches. E.g. with 2 cores there are 2 worker threads by default, which means it can keep up to 12 cores busy with the current default configuration (it contains 12 tasks). At the end the smallest Deflate stream is extracted and put into a GZip file.

The tool is similar to PNGOUT, OptiPNG, or PNGCrush insofar as it clearly puts the priority on size over time — except that it's for GZ/TGZ/SVGZ/etc. files instead of PNG.

A low poly spaceship

Without net access there wasn't much to do. However, modeling was one of the few things I actually could do. Fortunately I had some recent version of Wings3D installed. A few futile attempts later I got something that looked alright. Semi-satisfied with my low poly (52 polygons, 104 edges, 54 vertices) spaceship I went ahead texturing it with Inkscape.

Since the intended rendering size is rather small there isn't a need for fine details. I also wanted to try some bold semi-futuristic look with a touch of military blandness. Using vectors seemed like the most natural choice. Hard vector edges also fit the flat shaded rendering a lot better.

Before I could start with the texturing I had to do the UV mapping first. UV mapping is a bit annoying in Wings3D, but it's alright for simple models. If you aren't familiar with the term: it's about which part of the texture goes where on the model.

EeePC Tile Size Cheat Sheet (SVG)

The current EeePC generation uses the typical UMPC minimum resolution of 800x480 pixels. Accordingly to some rumors future generations will most likely use 1024x600. [Update: The resolution has been confirmed. The EeePC 900 has a 8.9" display with a resolution of 1024x600.]

As you can imagine this will cause some issues with full screen 2D games. One can always bi-linearly scale the sprites (or the whole back buffer/FBO), but the blurring may not be desired. After all it's plain ugly. Additionally, it may cause other side-effects such as color bleeding. That is: color values from one frame of the spritesheet may be mixed with the edges of neighbor frames, which causes visible artifacts such as seams or stray pixels.

Batik 1.7 comes with SMIL improvements (it's almost complete now) and some SVG 1.2 features were added as well. Check out the change log for details.

Batik is pretty much THE reference implementation. If an SVG doesn't work there, chances are very slim that it will work elsewhere. So, even if you aren't a Java developer get it anyways. The SVG-Viewer Squiggle (which is basically just a demo of the toolkit) is a great tool for doing quick cross-checks if the rendering isn't consistent between different browsers.

Intro

In this week's episode of I hate repeating myself I'll explain how to make Apache send the right headers. With the correct headers SVG and SVGZ can be displayed directly in all browsers which support it.

I'll try to keep it as brief as possible and as detailed as necessary. If there are any questions feel free to ask.

Testing

To check the current situation and to verify the results of our changes we need to know how the desired result should look like.

As you can see the Content-Type headers for SVG and SVGZ are identical, but SVGZ also comes with a Content-Encoding header, which is used by the client to determine how to decode the data.

Introduction

SVGs can be optimized for three different things. File size, rendering speed, and editing. For the most part you want to optimize for editing - especially with complex drawings. Towards the end you may want to lean toward the 2 other goals tho.

Optimizing for rendering speed is very interesting for devices with limited capabilities such as cellphones or PDAs. Things to keep an eye on are node counts, overdraw, clones, clipping, masking, gradients, and even simple stuff such as strokes. Nokia published some pretty decent guide (PDF) on this topic.

Optimizing for size shares a few aspects of the speed optimization. Keep the node count as low as possible, combine paths where possible... that kind of thing. However, you completely ignore overdraw, and you use clones/clipping/masking/stroke/gradients all over the place. It's certainly lot more entertaining than speed optimizations and it also won't affect editing speed that much. That's why I'll experiment with that.

I almost forgot to fix this. There was some silly bug, which caused the evaluated new color values to overwrite the old ones. E.g. if your red function changed the red channel and if you use the red channel in the green or blue function, the calculation was way off.

Well, this is fixed now. Finally you can do stuff like custom grayscale functions. For example if you don't like the NTSC/PAL scheme, which is used by Effects->Color->Grayscale, you can now use a different one. For the ITU-R Recommendation BT.709 conversion you would use the following line for all three channels:

0.2125 * r + 0.7154 * g + 0.0721 * b

For comparison the NTSC/PAL one looks like this:

0.299 * r + 0.587 * g + 0.114 * b

Feel free to try your own weights. You can also try slightly heavier weights in the red channel and a tad heavier weights in the green channel for sepia-ish pseudo grayscale. Or something completely different. Since the calculated values are clamped (0 to 255), there won't be any problems.