This site has had 1006 visitors since December 1, 2002! I know that’s how many visitors some people get in a day, but you’ve gotta start somewhere. Thanks to Google, traffic has been slowly but steadily climbing (currently receiving between 20 and 30 visitors per day).

It’s interesting to note that a lot of visitors are coming in on the right kind of search terms but not necessarily landing on the most appropriate page. It occurs to me that it might be useful to add some Javascript code which checks the referrer and does its own marshalling of new arrivals based on keywords. For example, anyone who arrives after searching for "unicode text editor" could be offered a link directly to the beta download for since such a query implies a degree of technical proficiency.

There really are an infinite number of interesting things to do when you are a programmer, and every single one of them has the potential to distract you and prevent you from doing the infinite number of boring but necessary things that need to be done.

The JujuSketch snapshot on the right gives away my secret ambition to travel back in time and invent the Flash rendering engine. I just love this type of graphics, with its anti-aliased edges and perfect gradations. Purdy.

Curves

The circles rendered by JujuSketch are not actually perfect circles; they are each composed of 8 quadratic bezier curves . On the left you can see the effect of choosing different numbers of curve segments, starting with the minimum of 3. At this scale there is virtually no visible difference between 8 and 16 segments, but at a larger size (full screen) it may make sense to choose higher numbers.

The reason I am sticking with quadratic curves [for now] is that although greater numbers are required to represent complex shapes, they are the easiest types of curves to work with by far. When it comes to calculating area, intersections etc, the equations for shapes composed of quadratic curves are much simpler [and therefore computationally less expensive] than would be required for a mixture of higher order curves, perfect arcs and ellipses.

Advantages

Any quadratic curve can be transformed into any other quadratic curve with an affine transform [ie any transformation that can guarantee the preservation of parallel lines, including scaling, rotation and skewing], and therefore the whole family share the same useful properties.

Eg: given a quadratic curve defined by ABC (where B is the control point) the area contained between the curve and the interval AC is equal to 2/3 of the area of the triangle ABC. It is also fairly easy to mathematically determine whether a point is inside the region.

Quadratic bezier curves also very easy to break down into line segments for rendering… in fact the algorithm to do so is so simple that you can construct a quadratic bezier curve geometrically (ie you could draw it using a ruler and compass, without doing any actual calculations) To attempt the same with a cubic curve would give you an awfully big headache.

Of course, the real reason I like quadratic curves is that they are the very same curves you get from that amazingly tacky arty/crafty trend from the 70’s [which I knew as "string art"] which involved nailing a whole bunch of pins into a slab of wood painted black, and then winding brightly colored thread around the pins to produce abstract shapes [and revolting pictures of schooners.] I remember being keen on this stuff when I was 11 years old, being particularly impressed that one could make curves out of straight lines.

is what a lot of developers seem to do, and it’s something I find very annoying. They don’t add code to catch exceptions. It’s like refusing to build a hospital because you can see no reason why people should get sick.

When the average program crashes - an eventuality virtually impossible to rule out - its allocated memory most likely still contains a perfectly serviceable copy of your valuable data. A simple exception handler (special code which the program provides to be run in the event of an exception) could, in most cases, offer the user the opportunity to save [or at least dump] document data. Most software doesn’t provide this, so when your program crashes you can say goodbye to whatever you’ve been typing for the last half hour.

Programs which have lost me data in this way, I believe unnecessarily:

• MS Developer Studio - somehow managed to lose an entire file recently, very unusual behaviour, lost about an hour of work.
• Outlook express - seems to be an issue with the latest version of MS DHTML control on my machine, I can be typing an email and the thing will just crash, apparently randomly.

The thing is, most of the time software creates temporary structures and buffers to manipulate data, then puts it back. The chances that your data is still intact when a crash occurs are actually pretty good, but because of the lack of exception handling you’ll never get to find that out.

Ages ago I added what at first seemed a lazy feature to JujuEdit: should an exception occur, it is "caught" and recorded, and you are given the option of continuing. I say lazy because the proper thing to do is of course to fix an exception, not to catch it. The thing is, this handling actually makes it a lot easier to track down bugs, because I can immediately try to get the exception to happen again [establishing a pattern], rather than having to restart the program in debugging mode and trying to reproduce the situation. [On the few occasions this has happened unexpectedly, I have always found my data still intact.]

To sum up: software should be built with the assumption that it contains bugs, and top priority should be given to the conservation of unsaved data.

Here is a really good test for an antialiasing renderer: A set of 128 parallel lines, angled at 45 degrees, tapered so that at one end they all just touch, and at the other they vanish. This is exactly the kind of thing that will tend to give hideous moire patterns when rendered to the screen. The thumbnails below have been rendered at such a small size that the lines merge together, but clicking on them will show larger versions in which the individual lines are visible.

As rendered by Adobe SVG viewer - Note that what should be midtones are virtually black, and the top right edge is still quite dark, even though the tips of the lines there are virtually zero thickness.

Click the image to see a larger version rendered in SVG (requires SVG viewer ) Try experimenting with different zoom levels to see how patterns change.

As rendered by JujuSketch- Nice midtones, eh? And check out the smooth transition to white on top right edge.

Click the image to see a version rendered at a larger scale. I’m very pleased with the quality I’m getting out of my new renderer!

It is really nice to have an application that lets you scribble just like on paper [if you have a graphics tablet that is]. I am already using it more than my recently purchased whiteboard, which hangs on the wall behind me with surprisingly indelible marks all over it.

The big problem facing JujuSketch is: feature creep!

It’s such a pleasantly simple app at the moment, but there are a bunch of ‘typical’ features which it is currently lacking, such as the ability to select and group objects, or change the fill and stroke styles. I’m even starting to think about layers. Question is, how many of these "essential" features can I add before cute little JujuSketch turns into monster time-sucking drawing program?

Has not been forgotten…. I have been working on it this week, attempting to handle very long lines in text files (currently coping with 16000+ characters, would like to make it unlimited). Because there are people using it right now, I feel less like ripping up things and replacing them completely, and that’s probably a good thing. So my current focus for JujuEdit is to fix outstanding bugs and robustify the code a little.

Downloaded some nice code from CodeGuru to get me started on Shell Extensions. So as to minimize the number of DLL files being loaded and maximize the flexibility, I am using it to create a customizable shell extender, which will basically allow the sort of simple changes I had wrongfully assumed standard registry editing would provide. It seems to be working now so that JujuEdit and JujuTool behave normally when installed with all context menu options, and I have to admit, it is very nice to be able to add separators and sub menus.

…and my new project, JujuSketch, is looking pretty neat. Although already I feel like the honeymoon period is coming to an end, and it’s becoming just like a regular project. I think my attention span is not what it once was.

What other software?

Oh yeah, the other software, the stuff that’s supposed to be undergoing rigorous beta testing right now. Well, it’s doing ok, I guess. I’m a little down about some issues with JujuEdit and JujuTool regarding context menu options, so I have changed the installers a bit to suit. Not much else to report there at the moment…

To the right is a little animated gif depicting the same image viewed in JujuSketch at different scales and orientations. Technically speaking, I think it is way cool.

At the globe level you may be able to make out some detail near the north pole. The tiny white blip against the black outline of the world is a tiny igloo, which can be zoomed in on until you can write directly onto one of its bricks.

Hopefully this example clearly illustrates the primary advantage of object based drawing over pixel based. Whilst everything you see on a computer screen is of course pixel based, the idea of object based drawing is to keep a list of instructions for drawing the image, rather than just storing the pixel values themselves. Here’s a page with a more detailed description of the 2 methods.

No more embedded crap

Okay, this page is now back to good ol’ vanilla HTML (or about as close as you can get these days). There are no more embedded Java or SVG objects herein. These things will now be launched only in separate windows and only when you choose to do so. I decided this after seeing just how unpleasant it can be to load such a page on a "virgin" machine. Ech!

I’ve been having a lovely time lately refining my path rendering algorithms, so as to result in what seems to be the best quality drawing possible for a given resolution. No shimmer or dropouts in the latest incarnation, and it’s faster too!

So inspired am I that I had to write that the imaginary person out there who’s really interested in this material has something to read. [Really, I write this tech stuff for myself 10 years ago. Unfortunately that guy is unreachable, so instead I post it here so that people with regular interests can ignore it ;) ]

Oh crap

Apologies for missing objects and annoying dialog boxes and all that stuff which is what people are probably experiencing on visiting this page… I went to all the trouble of adding Adobe’s code for installing the SVG viewer and all the sodding thing actually does is take you to the download page! A single hyperlink could have done that. And the bloody thing is over 2 megabytes, which is still a bit big for a dial-up connection.

Anyhoo, despite the fact that it’s currently a poorly integrated pile of crap, I do think SVG has the great potential for web graphics. Flash is certainly nice looking, but it is still a bit of a black box as far as it’s composition is concerned. SVG provides commands for drawing shapes in the same way that HTML provides commands for drawing text.

In theory you could do an entire web site with SVG, including text, hyperlinks etc, but then you can already do that with Flash MX can’t you…

Ah, persistence pays off eventually. Here is a little embedded SVG thing, which has been exported from my new app [which, as you can probably gather, is for drawing pictures]. You need the Adobe viewer [or other?] in order to see it, but theoretically this should have been offered to you for download if you didn’t have it already. Also I should mention that for now this only seems to work for me in IE right now, so if you’re not using IE and this thing ain’t working, just mutter something under your breath and move along ;)

An SVG of Unfortunate Size

The SVG version of the picture above [for those with the viewer installed] is 220K in size, which ain’t exactly small. It would be even larger (700K) if it were not also compressed. Part of the reason it is fairly large is that I have used pen strokes to color-in with [ie scribbling], and just like with Textas, that’s a bit of a waste. Every single pen movement is stored in this file, with no optimization process to remove redundant data points. Another reason it is large is that, for better or worse, SVG is an XML application, and hence made of bulky text rather than more compact binary representations of values. For example the number 14550 takes up 5 bytes [+ spaces] in a text file, but in a binary file could be stored in only 2 bytes. This kind of difference in file size is just one of the reasons that people may be slow to embrace SVG. The ‘native’ representation of this image (in my own compressed binary format) is around 110K.

__________

UPDATE: With a bit of tweaking on the number ranges used, the use of relative path steps, and the removal of redundant spaces, it seems that SVG might not have to be quite so space hungry. Such measures have whittled the image on the right from more that 230K to less than 85K, whilst maintaining a reasonable level of sub-pixel detail. Note also that this image has been filled ‘properly’ rather than by scribbling wildly. Click on the image to view it as an SVG in a separate window.