Nisus Writer Pro Macros

Now that the Nisus Writer Pro public beta is out those users interested in exploring our macro enhancements can do so. However, we thought that we should let those users know that there will be additional macro commands available by the time we release. Probably the most needed of these extra commands are those that allow introspection and manipulation of the current selection.

Alphabet Soup

Essentially the only thing a computer knows anything about is numbers. So when it comes time to process text you have to assign each character a particular number. These matchings form a map, which is called a character set or text encoding. Back in Nisus Writer Classic many text encodings were used. You would use one encoding for English text, another encoding for Hebrew, another for Japanese, and so on.

The problem with this approach is that to properly understand a sequence of characters a program needs to know what text encoding was used. This assumes that all programs know all text encodings. If the encoding was unknown your text was as good as gibberish. To make matters worse some fonts had custom encodings. If you lost that font your text was again foobared.

Luckily those days are over thanks to Unicode, a character set designed to include every single character known to humans. Now your text, be it Arabic, Tibetan, or Thai, only requires one standard encoding that all modern software understands. And thanks to the foresight of the Unicode Consortium we even have an official numeric assignment for the snowman character.


Happy Holidays!

Binary Finary

Now we’ve got universal binaries of both Nisus Writer Express and Nisus Thesaurus ready for your hot little mice to download. So what goes into making a universal binary? For an application like Nisus Thesaurus, which was developed for Mac OSX from the start and has basically no file formats, it really is as easy as clicking a checkbox. Something like Express is a bit more complicated.

The problem is that PPC based Macs store numbers in memory differently than an Intel. To illustrate, how do you know that the character sequence “72” mean seventy-two and not twenty-seven? Could we not just as easily have decided that seventy-two should be written as “27”? Indeed, when speaking in German (but not writing it) you literally say “two and seventy”. PPC and Intel chips have exactly this issue, that one stores numbers from the little end to the big end, and the other in the opposite direction.

So how does this affect Express? Here’s when our old friend Nisus Writer Classic and its file format comes into the picture. All those Classic Nisus files you have sitting around from the good ‘ol days are stored using the PPC’s notion of numbers. Before your new Intel Mac can understand them the numbers need to be swapped around. It’s not a difficult problem to solve, but it is time consuming to go through the old file import code and figure out exactly what and where to swap.

Our Old Man

One of the tasks before me today was to fix a problem with our Classic Nisus Writer import code. Specifically there was a problem when pasting text with graphics (or tables) from Classic into Express. To properly fix this I had to look into our old Classic code to see exactly what it did for these situations. This was my first time taking a detailed look at the old code and to my delight I discovered a fair amount of colorful profanity regarding the problem. Nothing like having a confirming second opinion :)

But regardless of the work involved, Express 2.6.1 beta 2 is available for you cosmic kitties tonight with a few critical fixes.

Of Lizards, Pumpkins, and Such

One of the nice things about working for a small company like Nisus is that you don’t get bored because you’re always doing the same old thing. For instance, yesterday I had the pleasure of preparing our Halloween sale graphics. Now, I’m definitely not a graphic artist, but I’ve used PhotoShop a few times, so I was able to cobble something together. It’s not beautiful, but it was a great fun to create and the result is effective enough.

Oh, I’ll be wearing a gecko costume this year (some styrofoam balls for eyes glued to a green hoodie). Anyone else? ;)

Blog Comment Security Codes

Recently we’ve had such a sharp rise in comment spam that moderating our comment queue was a real chore. So we’ve installed a “security code” plugin to help weed out all the automated spam. Before you can post a comment now you’ll have to copy the random digits from the security code image. Hopefully this isn’t too annoying for you, I know the change will make poor Dave happy.

Defeasibility

One of the greatest advantages digital content provides is its immediate malleability. With the right software changes can be made quickly and globally. A hallmark of this flexibility is the great big undo/redo stack that nearly every piece of software maintains.

An application normally implements undo by recording inverse operations for every action the user takes. For instance, to undo adding 10 to a particular number, you simply subtract 10. When a user deletes a word from a document, the inverse operation is to simply insert that same word back in.

Looking more closely at the requirements necessary to undo the deletion of a word, you can see that you need to know not only what the word was, but where the word was located in the document. At a lower level this location is simply the number of characters that preceed the deleted word.

For instance, imagine a document containing only the text “ice is blue”. Note that the word “blue” is preceded by a total of 7 characters. So to undo the deletion of the word “blue” from the document, we simply insert the word “blue” after the 7th character in the document.

Locations are complicated by document content that automatically updates itself. One example might be a timestamp. One second the stamp could read “Thursday 23:59”, the next, “Friday 00:00”. You can see that the stamp shrunk by 2 characters. Had our imaginary document in the previous paragraph contained a timestamp such as this one, the location we need to reinsert the word “blue” at to undo the deletion would have changed. To accommodate undo after a timestamp we need to be able to describe locations in the document like “the 7th character after the 2nd timestamp”.

Spam

Ah, guess it had to happen sooner or later: we’ve been hit by a rash of blog spam. I’ve gone ahead and deleted all the current spam, but manually removing posts is not an effective long term solution. So, we’ve had to change our policies here a bit.

I’d like for us to keep allowing unregistered users to post comments, so that hasn’t changed (yet). Instead we’ve added some moderation rules that hopefully will target the spammers. We’ll see how it plays out. In the meantime, if your comment does not show up immediately, please be patient with us.

Tables: Touch Fuzzy, Get Dizzy

Tables are a major feature for Nisus Writer Express version 2.0, and we’ve been working hard on them. There are a lot of little details that take time to get things just right. For instance: drawing table cell borders.

When drawing table cells we wanted to make sure that the border edges look sharp and clean. To accomplish this we have to prevent the lines from being antialiased when drawn on screen. This means that a thin line has to be drawn at the exact same coordinate as the pixel it should fill.

On the Macintosh screen pixels are one point (1pt) wide. This means that if you imagine a pixel as a square, the bottom of the square is at y-coordinate of 0.0, and the top of the square is at 1.0. So for a 1pt line to exactly fill that pixel, it must be centered inside the pixel at a y-coordinate of 0.5. Had we tried to draw the line at 0.0 only the top half of the line would have fallen into the pixel. The other half would have wound up in the pixel below, and we would have a 1pt line that was drawn into two pixels, leading to a fuzzy image.

Drawing is slightly different with lines of even width. Imagine a 2pt line. If we try to draw the line at 0.5, then we fill the pixel with coordinates 0.0 through 1.0, but the remaining 1pt of the line would spill into the pixels above and below. So again we have 1pt of line drawn into 2 pixels, yielding a fuzzy line. So when drawing lines of even point widths, we have to align them on integer coordinates.

For tables things are made more complicated by different line styles, weights, joins, user specified row heights, and other kinds of table properties. When considering all these, you cannot just draw a border edge at the nearest 0.5 or 1.0 coordinate, since other cells depend on an edge being drawn at a particular location.

In some cases it is actually impossible to avoid antialiasing. For example, imagine a 1pt line and a 2pt line both centered along the same axis. If you draw them both at 0.5, the 1pt line will be sharp, but the 2pt line will be fuzzy. If you choose 1.0, then the 1pt line will be fuzzy.

Getting all this right took just about a day of work, but table borders are looking good. We hope you guys will enjoy using our slick table editor when 2.0 is released.