One of the lead developers of Inkscape, Jon Cruz has been advocating for better color management in the Libre Graphics projects a lot recently. According to a post on Jon’s blog today, Inkscape is going to grow its support for swatches and swatch books. If it includes strong support for spot (solid) colors these changes will definitely affect graphic designers quite a bit. Some of the efforts listed include enhancing the swatch UI including more drag and drop, including gradients in swatches, and support for swatch book swapping and sharing. The description seems to indicate that switching a swatch book/set will replace the color on all objects that used swatches. The would allow a designer to explore and present different versions of the same work without any change to the objects at all. Sweet.

For the second summer in a row now Inkscape has benefited from the Google Summer of Code. However this year there were some very significant features that resulted. I have been using a pre-release of Inkscape with these features on a new website for Fairmount Printers and I am very impressed.

The new docking system improves MS Windows window focusing issues. The bitmap to path tool seems much faster although the SIOX selection is not fixed yet. They have added a number of raster filters so you don’t have to switch back and forth from The GIMP or Photoshop. They have a lot of aesthetics to work on in the Effect area though. Text manipulation has not been improved much on the surface yet. You still have to adjust letter spacing and manual kerning from key combos.

I saved the best for last. Inkscape can now import PDF directly which means that it can import a large number of formats indirectly. The resultant SVG is surprising cohesive. For those who have tried to open a PDF or PS file intended for a printer before you will be pleasantly surprised.

Congratulations are in order to the Ben Franklin Racing Team for being selected to go to the qualifying round (and beyond) for the DARPA Urban Challenge in October. This thing was put together in a year and it seams safe enough to drive itself effectively now and at relatively high speeds. It can distinguish lanes and intersection markings, differentiate and circumnavigate obstacles, and make k-turns. If you have time, check out the videos on their website. I understand the next phase will include turbo boost and super pursuit mode

More Productive Key Bindings
The following lisp gibberish allows you to search for the definition of the symbol under the mouse pointer and a way to search for all the uses of that symbol in your code. In Emacs you can return to the jumping point by pressing Alt-* (default key binding). I use XEmacs (which is superior) but you can put this in your .emacs file as well.

^^^^ .xemacs/init.el ^^^^

;;;;;;;;;;;;;;;;;
;; Tags setup
;;;;;;;;;;;;;;;;;

(defun tags-search-tag-at-point (tagname &optional file-list-form)
  "*Find tag whose name contains TAGNAME.
Identical to `find-tag' but does not prompt for tag when called interactively;
instead, uses tag around or before point."
  (interactive (if current-prefix-arg
		   '(nil nil)
		 (list (find-tag-tag "Search tag: ") nil)))
  (tags-search tagname file-list-form))

;; Find definition of the tag under the pointer
;; This nicely parallels M-*, which pops the tag stack.
(global-set-key '(control *) 'find-tag-at-point)

;; Find uses/calls of the tag under the pointer
;; This nicely parallels M-, , which cycles through the search results.
(global-set-key '(control ,) 'tags-search-tag-at-point)

;; Search and replace all uses of a tag
;; This nicely parallels M-%, which is the normal search and replace.
(global-set-key '(control %) 'tags-query-replace)

;; Complete the name of a symbol using the tag table
(global-set-key '(meta return) 'tag-complete-symbol)

Fancy Ways to Building Tag Files
The following is a shell script template that you can use to find which files have changed and only reindex as needed. Replace project_dir and src_dir as needed.

^^^^ make_tags.sh ^^^^

#!/bin/sh

function build_tags () {
  tag_file="$1"
  target_dir="$2"
  file_pattern="{*.[ch],Makefile}"
  if [ -e "$tag_file" ]; then
    files=`find "$target_dir" -maxdepth 1 -name '*.[ch]' -cnewer "$tag_file" -print`
    echo $files
    if [ "$files" ]; then
      etags -f "$tag_file" "$target_dir"/*.[ch]
    fi
  else
    etags -f "$tag_file" "$target_dir"/*.[ch]
  fi
}

TAGS_DIR="$HOME/project_dir/tags"

if [ ! -e "$TAGS_DIR" ]; then
  mkdir -p "$TAGS_DIR"
fi

build_tags "${TAGS_DIR}/src_dir1.tags" "$HOME/project_dir/src_dir1"
build_tags "${TAGS_DIR}/src_dir2.tags" "$HOME/project_dir/src_dir2"
build_tags "${TAGS_DIR}/usr_include.tags" "/usr/include"
build_tags "${TAGS_DIR}/usr_include_sys.tags" "/usr/include/sys"
build_tags "${TAGS_DIR}/usr_include_GL.tags" "/usr/include/GL"

# make tags for src_dir1 which depends on src_dir2
cat "${TAGS_DIR}/src_dir1.tags" "${TAGS_DIR}/src_dir2.tags" \
    "${TAGS_DIR}/usr_include.tags" "${TAGS_DIR}/usr_include_sys.tags" \
    "${TAGS_DIR}/usr_include_GL.tags" > "$HOME/project_dir/src_dir1/TAGS"

#make tags for src_dir2
cat "${TAGS_DIR}/src_dir2.tags" \
    "${TAGS_DIR}/usr_include.tags" "${TAGS_DIR}/usr_include_sys.tags" \
    "${TAGS_DIR}/usr_include_GL.tags" > "$HOME/project_dir/src_dir1/TAGS"

^^^^^^^^^^^^

http://www.openoffice.org/

Someone just compiled a turd. Hmm, how can we make a bigger mess of things. Lets make it harder to install, use, and maintain. Then we can make it really slow. Oh yeah we can add in annoying crap to make it more like M$ Office too. Enjoy.

http://reader.google.com/

char *c_strtok_r( char *str, char *delim, char **save_ptr ) {
  char *ptr;

  if( !str ) {
    if( !*save_ptr || !**save_ptr )
      return( NULL );
    str = *save_ptr;
  }

  while( *str && strchr( delim, *str ) )
    ++str;

  if( !*str )
    return( NULL );

  ptr = str;

  while( *ptr && !strchr( delim, *ptr ) )
    ++ptr;

  *save_ptr = *ptr ? ptr + 1 : ptr;
  *ptr = '\0';

  return( str );
}