Refactoring C to C++ Part 2 - Strings, Strings, and More Strings

In the previous entry in this series, a general info dump on a converted class was taken. This time a more general rule will be examined: string usage in C++.

One large improvement in C++ coding over C is in the area of strings. With C, a string is just a random memory pointer to what should be a NULL terminated sequence of proper characters. In practice there ends up being many ways that problems with C strings can creep in.

• the final zero-byte null terminator might be missed during creation.
• some common library functions will ensure null termination, while others do not.
• to determine the length of a string, the entire buffer needs to be walked
• resizing and appending to strings can be complex multistage operations with many potential failure points.
• resizing a string most often invalidates the existing pointer.
• tracking different character encodings can be difficult.

With C++ in general strings are represented by the standard class std::string. However that still does not address the issue of encodings. What the meaning of an individual byte or set of bytes is can depend on many factors. Modern programs have to deal with multiple encodings... even if their developers do not always realize it.

With GTK+ programs there are three main encoding values to keep aware of: locale encoding, filesystem encoding and internal encoding. The internal encoding is used for UI widgets and most internal GTK+ calls. The encoding itself is UTF-8. The locale encoding can vary at runtime, and although it is commonly also UTF-8, it can be any other. The filesystem encoding is different, and used for paths. This can vary greatly for systems that have been upgraded over time.

I'll cover encodings a bit more at a different time, but in the context of GTK+ and C++ the potential encoding allows us to select between the two main classes for strings:

std::string

The standard class for strings in C++. Should be used when the data might be in an encoding other than UTF-8. This is such for GTK+ and Glib APIs that operate with either locale or filesystem encodings.

Glib::ustring

A class from Gtkmm that represents strings of UTF-8 data. Aside from other things it manages details of multi-byte UTF-8 single characters, etc.

Thankfully we end up with some fairly simple rules for C++ programs:

• Use a single common encoding for as much of a program as possible. For GTK+ this is UTF-8.
• Avoid using legacy C strings such as "char *" or "gchar *"
• Use Glib::ustring for all UTF-8 encoded strings.
• Use std::string for strings that might be in different encodings.
• Be very careful about string conversions, and use explicit encodings.
• Do not mix strings and byte data.
• Use std::vector<uint8_t> for random byte buffers.
• For parameters passed into functions, use "Glib::ustring const &" or "std::string const &".
• For return values, prefer functions that return "Glib::ustring" or "std::string" (note that these do not use 'const' nor references).
• For functions that return multiple strings, take in parameters of either "Glib::string &" or "std::string &"

Finally we end up with a very important question: does any of this make sense? Hopefully some guidance can be quickly drawn from this information. However, if any point needs more clarification, or was missed, please speak up and let me know what to address.

Read more!

Refactoring C to C++ Part 1

It turns out that a recent Inkscape source change is a good example for showing some of the process of conversion from C to C++ of a GTK+ type. In doing some recent usability changes, I'd done a bit of a cleanup on 'C++ifying' the Inkscape SPCtrlLine type. Trying to keep our source revision history clear and useful, this one cleanup pass went in as a separate change (revision 11321). This also makes it easy to look at for guidance.

A good starting point is to look at the changes to the main header file itself: sp-ctrlline.h.

First is a simple change to a standard GTK+ macro definition. Yes, in general macros are evil, but the few macros listed at the start of the header are following GTK+ conventions.

21    #define SP_TYPE_CTRLLINE (sp_ctrlline_get_type ())
   23 #define SP_TYPE_CTRLLINE (SPCtrlLine::getType())

• The "SP" prefixing is legacy naming that we will ignore for now.
• In general this seems like a minor change, with only subtle formatting differences, but there is more to it than that.
• Instead of invoking a single function with a long name, it now invokes a static method on a class.
• The method being called is now merely "getType()" (and thus is template-friendly).

One important point to keep in mind is that in C++, a struct is just a class that defaults to public:. So once we're in C++-land, just think of "struct" as a rough synonym for "class".

Then the main change in the header involves moving a set of simple C functions to instead be class methods:

33  GType sp_ctrlline_get_type (void);
34 
35  void sp_ctrlline_set_rgba32 (SPCtrlLine *cl, guint32 rgba);
36  void sp_ctrlline_set_coords (SPCtrlLine *cl, gdouble x0, gdouble y0, gdouble x1, gdouble y1);
37  void sp_ctrlline_set_coords (SPCtrlLine *cl, const Geom::Point start, const Geom::Point end);

• Since sp_ctrlline_get_type() does not have a pointer to an instance, this will be a static method
• Since the others start with SPCtrlLine *cl instance pointers, these will become normal methods.
• The prefix "sp_ctrlline_" dissappears as a natural part of moving into a class.
• The explicit instance pointers (SPCtrlLine *cl) dissappear and are replaced by the implicit "this" pointer of C++ member functions (aka "methods").
• To avoid making unnecessary copies of the start and end parameters on sp_ctrlline_set_coords, we change it to pass constant references instead.
• Since C++ references are easiest to understand when read left-to-right, we move the 'const' to be just before the & of the reference.

28    static GType getType();
30    void setRgba32(guint32 rgba);
32    void setCoords(gdouble x0, gdouble y0, gdouble x1, gdouble y1);
34    void setCoords(Geom::Point const &start, Geom::Point const &end);

Moving on now to the sp-strlline.cpp file, there are a few things to note. One is switching from static methods to using an unnamed (or anonymous) namespace. That could have allowed us to drop the "sp_ctrlline_" prefix, but that step was skipped for the moment. We do, however, want to fix casts as we go, such as

49        (GClassInitFunc) sp_ctrlline_class_init, 
   51     reinterpret_cast<GClassInitFunc>(sp_ctrlline_class_init),

Inside of the class_init function around lines 63-72/66-72 there is a simplification due to inheritance. There is no need to create object_class and item_class pointers from the passed in SOCtrlLineClass *klass pointer. The members of the parent types are visible, so we can just use klass directly, such as for

klass->destroy = sp_ctrlline_destroy;

Another handy aspect to turning stand-alone C functions in to C++ methods is that we get compile-type checks and safety and can drop run-time checks, such as at the beginning of the new SPCtrlLine::setRgba32() method:

154    g_return_if_fail (cl != NULL);
155    g_return_if_fail (SP_IS_CTRLLINE (cl));

The checks at lines 171-172 are similarly dropped.

Once we get to the body of the method, there are a few interesting points to be seen:

157        if (rgba != cl->rgba) {
158            SPCanvasItem *item;
159            cl->rgba = rgba;
160            item = SP_CANVAS_ITEM (cl);
161            item->canvas->requestRedraw((int)item->x1, (int)item->y1, (int)item->x2, (int)item->y2);
    155    if (rgba != this->rgba) {
    156        this->rgba = rgba;
    157        canvas->requestRedraw(x1, y1, x2, y2);

• At new line 155 since a parameter has the same name as a member, we use "this->" to be able to access the member.
• There is no need for the casting macro SP_CANVAS_ITEM from line 160, since a subclass has all the superclass accessible.
• Since canvas, x1, y1, x2 and y2 are all members and we are now a member function, use of cl-> and item-> can be dropped.
• Since canvas is a member and we are in a member function, we can use it directly in new line 157.
• C-style casts, and casting in general, are enemies. By dropping the casts to (int), we let the code get simpler, gain the ability to leverage from overloading, and get errors more visible.

Moving on down into gradient-drag.cpp, there is a very important shift in though/approach for pointers. Looking at line 1579/1578 we see a difference in type:

1579         SPCanvasItem *line = sp_canvas_item_new(sp_desktop_controls(this->desktop),
1580                                                                  SP_TYPE_CTRLLINE, NULL);
     1578    SPCtrlLine *line = SP_CTRLLINE(sp_canvas_item_new(sp_desktop_controls(this->desktop), SP_TYPE_CTRLLINE, NULL));

Instead of holding a pointer to the more generic parent class SPCanvasItem, we hold and use a more specific pointer to the sublcass SPCtrlLine.

With GTK+ in C, holding the more generic type is common, and results in, among other things, excessive use of the type check and type casting macros (such as SP_CTRLLINE()). Aside from any performance slowdown they introduce, they hide things, block overriding, and sacrifice compile-time safety for run-time checks. It is far better to have incorrect code that will result in the compiler rejecting it upfront rather than code that will fail at runtime (but only when a user trips over the specific code path in question).

Similar fixes can be seen in the changes to line-geometry.cpp and elsewhere. In pen-context.h, seltrans.h, text-context.h, and node.h the type of the pertinent members have also been changed from the parent class SPCanvasItem to the more specific subclass SPCtrlLine.

In closing, reviewing the entire change with thoughts as to why different things were done can be quite useful. At some point soon I'll be following up with some more examples, along with some summaries of key points to follow and keep in mind. Additionally, this change did not really touch on any conversion from plain GTK+ over to Gtkmm (the C++ wrapper library for GKT+). Subsequent entries will also touch on those.

Read more!

Back on Track

After being bogged down with 'real life', I've finally managed to get things moving bak on track... so time to get back to the blogging. A lot has gone on, and is getting ready to happen. Conferences conferences conferences and more conferences, hardware, Inkscape hacking, and more...

We have a lot planned, and maybe something for most anyone. Inkscape has picked up a few more active contributors, and I've gotten progress on a few 'interesting' tweaks. Some seem just for fun, but others have good practical application. We're also trying to get together some more organized meetings, online and in person, so that will be good. Also look for more on the front to help promote Inkscape.

Much went on at this past linux.conf.au, with great people helping out and some really outstanding presentations going on. Bruce Perens had some very important things to say, and it looks to be very helpful. And I even had my talk on logo design for developers make it up online. (There are more going up over time, and the mirrors should be getting ogg versions too.)

Posts will show up highlighting things from linux.conf.au and SCALE10x shortly. There will even be a few photos here and there. Most importantly, though, is that things should get more and more active here, and posts should be quite regular now.

Read more!

Inkscape Text Outlines

An Inkscape user mentioned trying to follow this Illustrator-based tutorial on outlined lettering, but said he was having some problems. To get the user going, I pointed out Troy Sobotka's tutorial on text styling. It gets a bit more complicated, but does present several nice features that got the user going even better.

However... I thought that the basic techniques used by Illustrator should work fine with Inkscape, so I pulled things up to take a pass at following it. It turns out I was right, and it wasn't hard at all. In fact, it turns out to be doable with fewer steps. So here is a basic summary of the changes in approach needed to achieve the copy-n-past over text effects explained there.

Start by reading the tutorial on "Lettering: Multiple Outline SFX". It seems pretty straightforward, right? Since adding a thick stroke often doesn't work the way one might want it to, I was quite familiar with the approach of pasting a copy over a thickened version.

1. Create the letters you want and get thing tuned as positioned as desired. This might be just plain text, text with some manual kerning applied, or outlines one draws or modifies.

2. Group them, apply a stroke, and set the desired thickness. Depending on the size of your text, you'll need different thicknesses. (If you look closely, especially at the hole in the 'A', you can see how this version is thicker than the original)

3. Duplicate the text and set the fill white and turn off the stroke. This is the part where it varies a bit from Illustrator. In Inkscape, all you need to do is "Duplicate" the grouped paths/object using Ctrl-D (That will combine the separate copy and then paste-in-front that were called for in the Illustrator tutorial).

Moving on, one can also follow the other techniques there. Using the simpler 'duplicate' saves a tiny bit of time, but the general principals are solid and the skills transfer easily from Illustrator to Inkscape once the specific keystrokes are not hunted for.

Read more!

Inkscape Does Support CMYK

While some are mislead by the fact that Inkscape does not (and probably should not) support raw or "generic" CMYK, it does in fact support working with true CMYK for print support. The key factor is that Inkscape only supports real CMYK work, and not "pretend CMYK." In and of itself "CMYK color" does not mean anything specific. It turns out that "RGB color" is also meaningless as far as specifying an actual color goes, but the variances are usually not as strong. To get accurate RGB color, one needs to specify *which* RGB to use. SMTP television values, Adobe RGB, Wide Gamut RGB, sRGB, etc. For experience on the Internet, people usually don't realize that there is an implied colorspace of "sRGB" used for tools, browsers, etc.

In a similar manner, Inkscape needs to be given a *specific* CMYK colorspace to work in. In fact, Inkscape (and SVG itself) can support a document with several different colorspaces at once, including mixing multiple different CMYK colorspaces alongside RGB colorspaces. This could be useful for cases such as when a graphic designer is creating artwork for some brochure that will be printed with cutaways and different paper types. Or it could apply to a case where different printers are used for different parts of a job. (Figure 1 shows what appears to be the same colors)

However an fairly common use case is where one might create a document to be printed mainly in CMYK, but with one or more spot colors, such as Pantone, Toyo, HKS, etc. colors. In this case, some elements of the artwork can be marked with a specific target CMYK profile, while the elements to be done in a spot color can be specified with a named color profile supporting the type of spot color (for SVG 1.2) or perhaps even with simple sRGB equivalents. Then when things go to a service bureau to be run the CMYK elements can go to a four-color print and the spot colors can go to custom plates per ink. (Figure 2 shows that the colors are actually different)

So how does only get to "real CMYK" in Inkscape? It's actually fairly simple. First at least one CMYK profile needs to be added to the document being worked on. That can be accessed in the GUI through the "Color Management" tab on the document properties dialog. Once at least one profile has been added, the color pickers in the Fill & Stroke dialog can be used to pick colors in that colorspace via specifying the ICC profile. In the past one needed to use the CMS color picker, but with Inkscape 0.48 the other color pickers such as the "CMYK" one will attempt to preserve values. (Figure 3 shows that the exact same CMYK numbers were used)

The main problem left is that even though true CMYK values are stored in the saved SVG value, using those values is now a bottleneck. Printing directly from Inkscape will flatten things to sRGB, and even PDF export will not yet preserve the CMYK values However, other software can read and use those values. Recent versions of Scribus will read in and preserve ICC colors including CMYK, and will happily save high-quality print-ready PDF output. (Figure 4 reveals the difference in RGB and visible colors that result from using two different CMYK profiles)

Read more!

"CMYK" is Meaningless

For anyone working with print there is one key principal to keep in mind: "CMYK numbers" are meaningless. Far too often artists are lured into "working in CMYK" without actually understanding what it means, and fall into the trap of believing their work is more precise when the exact opposite is true. Saying "50% Cyan" does not actually specify any color, and will most likely result in many different colors being produced. The subtle yet critical difference between "untagged CMYK" vs. "unspecified CMYK" is the bottom line that will mean the difference between success and failure.

CMYK is a type of colorspace, but in and of itself does not actually specify anything. It just tells how one can define a specific colorspace. To actually make sense a specific device (either real or theoretical) needs to be targeted. Once the specifics are involved, however, working in a specific CMYK is a very helpful thing. It is good to try to not get caught up in distraction of focusing on the "how" of things and instead look to the "why" of doing things.

In this case, the distracting "how" is people "working in CMYK" while the "why" they should be focusing on is reliably creating and controlling color. Instead of an artist getting caught up in saying "I need to get exactly a 50% saturation of cyan ink onto the printing plate at this point", they need to shift to say "I need to get this point of the final print output to be exactly this shade of color." That is not to say that an artist should never be concerned about CMYK numbers and plate separations, but rather they need to keep in mind that the ink details are merely a means in reaching the ends of the final print. (There is one main exception to the focus on raw CMYK, but I'll cover that later)

So although 'raw CMYK' numbers might be meaningless and produce randomly shifting results in completely unpredictable ways, CMYK values in a specific context normally give very precise and controlled output. Be wary of anyone asking for or providing "generic CMYK". However, specifics such as "SWOP v2 CMYK" will allow for fairly exact control and results. If someone says "CMYK", the response should be "which CMYK?"

What does this all mean in practice? If one is producing artwork that will go to print, getting specifics nailed down is critical. When working with a good print house, they will provide either specific profiles for the output that will be run, or will say which industry standard profiles they will work from. The artist provides content targeting the specific CMYK profile and then the printed results comes back with the exact appearance that was intended. The print house gets this generally specified input and then does a specific conversion from what the artist supplied to the measured control needed for the specific press and the actual paper with that days inks and the current temperature, humidity, etc.

When such a good workflow is used one can get reprints run at any time later on and the output will match what was printed the past week, month or even year. Thus there is no need for the time nor the expense of multiple tweak-and-reprint runs to end up with acceptable results.

On the other hand, if a small shop is used that employs no color management in their own workflow, the burden falls squarely on the artist/customer to come up with ways to get consistent and desired output. Sometimes the print shop will provide some target profile, but make no guarantees as what the resulting run will look like.

This is the point where most will just think they're working directly with raw CMYK and just need to tweak things over and over until they are close enough. That's actually not what they should be doing. The critical need here is to understand that they are not working in "generic CMYK", but that they are working to a very specific CMYK. They really are working in "CMYK for fliers printed at the corner press". Sometimes that color will be consistent over time, but more often even that will vary from week to week or from day to day. If the artist was smart, he would have created his own profile for the local print shop and will work in an industry standard CMYK and convert to the specific local shop CMYK for delivery to them. He also should have done some simple calibrated output (perhaps in the margins of his run) so that if (or more likely when) the local print shop gives different colors for the same numbers he can call them on it and get things corrected.

For a shop with a good relationship, the artist can use his own management and tracking to get the print shop to correct their output. Some small shops might not even be employing much in the realm of color control but can happily match output to a reference proof they get handed along with the files for the job to be run that day.

Finally in the case were the local print shop will give varying results and no help for color matching we reach the situation I mentioned where actually sending raw CMYK values is desired. However the reason for sending out a file with raw CMYK that is intended to go exactly to the end plates is in creating a test target output for measurement so that the artist can create his own target CMYK profile. The artist can send over a raw file to get a test output print, and then measure that test print. He then converts the real job files to using that locally created profile and sends the adjusted art files over to be printed. The net result is better output with lower costs due to avoiding reprints, etc. (so "raw CMYK values" should really only be used for printing test targets)

This last case helps illustrate the difference between "untagged CMYK" and "unspecified CMYK". The artists sends over art files that are not tagged with any embedded ICC profiles. However these are not raw nor "unspecified" CMYK values at all. Rather they are CMYK numbers in the specific profile that the artist himself has created to describe the characteristics of the local print shop. Although the files are not literally tagged with the profile, they have been created with an explicit ICC CMYK profile specified in the artists workflow.

And the bottom line? Be specific and you will save both time and money. And end up with happier clients.

Read more!

Backlogs and Real Life

The last three months have been a bit crazy, with far too much "real life" hitting us upside the head. Things have finally settled in a bit so that I'll be able to get my head above water and surface again. Aside from diving head first at the new day job and surviving the holidays, much had happened in the tech world.

I still haven't had time to finish my writeup of SVG Open (partly since I accepted the new day job while I was attending it up in Mountain View). Then there was the Google Summer of Code Mentors' summit. Great things happened there. Then I had to prep for our visit to New Zealand as co-organizer for a Libre Graphics Day miniconf and as a speaker at the main linux.conf.au. Then we had SCALE8x come 'round where I presented yet another talk and then also run the Inkscape booth on the show floor. Toss in getting a new tech (adaptive UI) going, starting a new project with other CREATE guys, and doing battle across the board to help get proper CMYK support out for end users everywhere.

Whew!

On top of all that was work for Inkscape and trying to get new features solid for the next release, 0.48. Thankfully I was able to squeeze the time in to finish up the basic support and UI for per-document color/swatch palettes. This allows for basic colors to be stored as a set in a given document, but also for gradients to be included in that. One big thing that inclusion accomplishes is breaking down the artificial barriers software engineers have imposed on artists for far too long. Assets had been artificially separated by their *implementation*, without regard for how artists actually are used to working. This also enabled many workflow enhancements including making art recoloring easier, indicating which swatches are in use on the selected object, etc.

Work on the new input devices dialog also came through. Aside from more end users getting their hands on tablets and such, we had a push in that the ugly outdated GTK+ dialog is being removed. And just in the nick of time we had Krzysztof step up and investigate some of the win32 tablet bugs and get some insight on the problem with Aiptek and others showing up with broken names. I was able to help refine the fixups there wile getting them set to be reimplemented in the new dialog.

And then there is the basic work on adaptive UI. This is a very promising area, and is just beginning to show the tip of the iceberg. I'm implementing internals based in part on Michael Terry's work with INGIMP he has presented at LGM. Though 0.48 will only expose a tiny bit of what can go on, the support in Inkscape will give it some very useful functionality in even the near term. We're looking at only giving 0.48 a few set layout modes, but with some handy logic behind the scenes to assist users getting what they need without having to think as much.

Unfortunately, though, we were unable to find time to work in support for Wii remotes, joysticks, and the SpaceNavigator someone at LCA lent me. We are on track to get more in, and 0.49 might even see some of that. Some of this (like using guitar game controllers) might sound a bit silly. However there are some very interesting ways these can be worked in and give Inkscape some nice functionality for average users. And, of course, more hardware toys always makes the geeks happier.

Read more!

Inkscape should NOT "support CMYK"!

Recently Felipe "JucaBlues" and I were hashing out some next steps for development, when I realized that Inkscape should NOT "support CMYK." Given that the Brazilian user community has really been pushing progress on the adoption of Open Source, including the use of Inkscape in print work, this might seem a bit surprising. However as we have been moving forward, implementing things, and trying to really support more and more professional use of Inkscape, the problem has become a bit clearer. What it seems to come down to is that we need to be sure to not get caught up in the low-level "how" of implementation of "four color CMYK" and instead change to focus on the higher-level "why" of "supporting prepress work." To get good, reliable, professional results in all forms of image work is a good thing, and people being able to get work done, and well, is key.

People who don't work towards print output are not often as familiar with CMYK and a CMYK workflow. What people are familiar with, at least when it comes to computer imagery, is RGB. GIMP, for example, has worked in RGB for the longest time (though it is now getting updated with new internals that will make working for print output much nicer). RGB images are split into three components: Red, Green, and Blue. Colors might be chosen with different modes (such as HSL), but are generally are stored in RGB. For photographs, web work, etc., RGB image work can be quite sufficient, and sometimes even preferable. There are also subtle variations such as sRGB, wide gamut RGB, Adobe RGB, etc. that can be used for specific needs.

Whereas RGB is creating colors by mixing three light primaries in additive color, CMYK is used with mixing four ink primaries in subtractive color. In general this is done by inverting the three RGB primary colors into inks and then adding a fourth ink that is plain black. This helps with getting true black, avoiding oversaturate paper, and other factors. Print artist often like working directly in CMYK so they can control sharpness of text, overprint of color, etc. However, the first big trap is that there is no such thing as "the CMYK colorspace." CMYK numbers/values are actually dependent on a specific device, and even two printers of the same make and model usually will give different results for the same input numbers. Given that an artist will choose to work in CMYK in order to more precisely control the output of a job, it is critical that color management is involved in the CMYK workflow to target specific jobs. Working on a job to be printed in a glossy magazine can be very different than one to be printed in a local newspaper.

SVG has been able to support CMYK via ICC profiles, and Inkscape has supported that in rough form since 0.46. Felipe and I have improved the interface for this more in 0.47, but there is still more to go. We also have been working with Scribus to help ensure color-managed SVG files become well supported. Some recent work for SVG 1.2 has added device-cmyk, but it turns out that this is for workflows that are not color-managed, and thus not really what end users need.

The other significant complication with a focus on "CMYK work" is that many professional jobs that are to go to print are not really "four color" at all. They might have four-color printing as part of the job, but then spot colors come in and easily expand to five-color, six-color and more. A company, for example, will often have a precise color they use for their logo, and this will be printed on its own plate in a pass of just that specific ink. UV coating, embossing and other effects might require their own color or 'channel'. Anyone who has ever heard "Pantone" mentioned has probably bumped up against this "not-just-four-colors" problem. And in addition to spot colors, modern printers have been expanded to use six or more colors, not just four, in order to get better results.

What that means is that to properly support end users needing to work on art that is going to be printed, Inkscape will need to support far more than only four colors. And more than just CMYK is a given (that spot color issue again). Artist will need to easily pick a target CMKY ICC profile for all jobs, have multi-color support preserved, handle spot colors and custom palettes, etc. So when it comes time to implement features, thinking only of CMYK will most likely lead to solutions that hurt, rather than help. So remember, think "professional prepress work" and not "CMYK work".

(Images
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Original apple image by Jan Mehlich)

Read more!

Libre Graphics Day Call for Papers

linux.conf.au 2010 is taking place in Wellington, New Zealand this year. It's a wonderful conference, with quite a lot going on. I was lucky enough to have a talk accepted this past conference, and it was a great experience. For next year's conference Donna Benjamin and I proposed putting on a mini version of the Libre Graphics Meeting for people who have not been fortunate to make one. It had been accepted, and we're in the final half of the CFP before it closes on Friday 25th September and we have to decide what to go with. Again, there is just one week left!

So, the mini Libre Graphics Day is on January 18th, and is planning to bring together programmers, artists, designers and just those interested in using graphics programs all together. If you are planning to attend linux.conf.au and you might have something to say or show, please consider submitting a talk or such. This does not have to be just about Inkscape, since GIMP, Scribus, Krita and many others have all been involved in LGM.

Read more!

Libre Graphics Day at LCA 2010

Man, the past few weeks have been quite busy, including some sad family events. However, there is one item I need to get out there.

The news is that the LCA 2010 miniconf proposal of a "Libre Graphics Day" I submitted has been accepted! There still is a lot to do, but since the time is short we do need to be moving quickly.

I'm going to be coordinating this "mini" version of LGM with the help of Donna Benjamin and Tina Cruz. A more formal announcement along with a CFP will be up shortly. In the mean time you can ping us on identi.ca or Twitter with ideas and suggestions:
Twitter: @joncruz, @kattekrab, @sendchocolate
identi.ca: @joncruz, @kattekrab, @sendchocolate
(here's a hint. @sendchocolate is far more organized than I)

Read more!

Much to do, but color is on the march

"Real life" has again been conspiring to keep me distracted. Of course that really is the norm rather than the exception; we need to be able to complete despite distrations, not wait until distractions are done. However that is a topic for another time.

The main thing I wanted to address was in relation to color. Especially at and since the last LGM there has been a lot going on in regards to color and open source. As a last-minute fill-in I did a shorted presentation of my talk on why color management is needed. Ginger Coons made a presentation that included an artists'/designer's approach to needing better color standards, and GIMP and Scribus were among the others to touch on color, standards, etc.

Since then the collaboration with software developers and designers has made some significant progress. The most important is in establishing working relationships with various vendors in many countries. Things are not quite ready for formal announcements, but many companies involved in color, printing, inks, paints, etc. have been talking with open source developers and advocates. Now we haven't gotten say the 500 pound gorilla on board (yet), but those leading the charge have been making some very solid contacts and commitments.

Of the companies out there, I do want to make note of New-Zealand-based color vendor Resene. They've been extremely committed and helpful. For a bit more, you can check out the note in this rant by Christoph Schäfer. And, of course, if anyone would like to help in this area, or knows someone or something, feel free to track down Christoph and talk.

Read more!

On Conficker and Zombie Education

So, T was talking with me just the other day about Conficker worm, and had a bit of a question. She'd finished listening to Steve Gibson's excellent Security Now podcast on the worm (episode 193), and was wondering about the checking of random domains. The question was basically how that could help infect machines.

The answer is that Conficker is not using those domains for infecting new machines, but rather for the zombie machines that are already infected to go and wait for updates. Other standard means are leveraged to infect new boxes and bring them into the botnet, and to do DOS attacks and such. Once I mentioned "zombie" as a term, she said "Yes, I get that. So you basically have the evil horde wandering to random intersections waiting to answer calls as they pass phone booths". Her question had been trying to figure out what the purpose of that would be, if it were not to infect new machines.

"Simple", I answered. "To get updates". That, of course, begs the question as to what exactly one would need to update a zombie in regards to. Well... using the analogy it turns out that the answer was very simple. Aside from the basic cat-and-mouse aspect of trying to hide from the zombie hunters that T. already knew, a big reason to update your zombies would be... to teach them to turn doorknobs!

In classic zombie movies, the heroes always end up huddled together inside a room/house/cabin/pub where the closed doors cause the feeble minded attackers to fumble uselessly against the panels of the door. Teach them to quickly open such obstacles and suddenly the horde is swarming right in to attack your PC and eat its brains. ♪ ♫

Read more!

Intuos4 Unboxing

Yes, that is the pretty new toy. After a bit of delay with things such as work, family, supporting friends, etc. I've finally gotten a chance to get up the pictures I took of my Intuos4 unboxing. As you can see, Wacom has stepped things up on their packaging, and seem to have done a nice job on the look of both the tablet and the box it comes in. The front of the package is quite simple, merely showing the product. You know their name, you know what a tablet is. If they need to tell you more, then this product is not really for you. Oh, and they also show down in the bottom left corner which of the sizes this tablet is. I like their subtle nudge that they have four of these, with two larger than the one I got.

The back of the box is pretty and informative (I have a larger pic for this one). They call out all the main features, including all the ooohs and aaahs that they should evoke. One main point of interest for the international (aka non-US) crowd is down at the very center bottom. It states "MOUSE INCLUDED", since I've read that the overseas version has to be purchased separately. Also they note that the tablet is shown actual size, so it is very helpful for a potential customer browsing in the store.

The front and back are part of a cover that slips down over the actual box. Once that is removed we see the box itself. It says "intuos4" in nice friendly letters on the cover. By this point I can see that Wacom was definitely taking lessons from Apple on their packaging. (I should also probably point out that I am not very practiced in photography, so the flash tended to wash things out and reflect a bit. Given that the battery on my camera was busy dying, I decided not to try to set up something more complex).

Lifting up the first flap of the box reveals "Where it all begins" in several languages. Again, friendly and welcoming. Also they have directions printed on the inside of that top flap. The three steps seem to be

1. put in the disc
2. install the software
3. connect the tablet

They realize that nobody really reads the directions, so they need to get things going as simply as possible.

Lifting up the second set of flaps reveals the tablet itself resting comfortably in it's nice protective foam sleeve. Like the rest of the packaging, this is a very pretty black (my flash did not do it justice). Also at this point I was struck by how light and efficient the packaging was. It definitely conveyed at least the feel of being more eco-conscious.

Sliding the tablet itself over a bit reveals more of the plastic it was sitting on, along with the stylus just below. All the rest is still hidden... probably to impress you more with the two parts you really care about.

Finally the view we have been waiting for. The tablet and stylus removed from their protective wrappings to bask in all their glory. The flash picks out the different textures, but in person all the parts are just about the same shade of black. The left edge is a high-gloss translucent finish, whereas the rest of the frame is a matte finish with a nice feel to it. Quite comfortable to rest one's hand or arm on. You can also see that the eraser end of the stylus is quite different.

I set my Intuos3 stylus down for a side-by-side comparison. The front looks just about the same, but the back is shorter and the eraser is definitely more "nubby." The Intuos4 stylus also had a lighter feel to it.

This next shot really shows off the glossy side with all the buttons. Under normal lighting the buttons and touch wheel do appear to be almost the same black as the glossy hard plastic. The way the buttons are all on one side now are quite evident, along with their placement to facilitate easy single-hand operation. Here you can see the "wacom" at the bottom, which hits where the tablet starts to curve down. There is a corresponding logo on the top, upside down, for when the tablet is used in left-handed mode.

Lifting out the black plastic tray reveals the packing of the additional bits. To the left is the nice, long USB cable. In the middle is the very Apple-ish box with the driver CD and such. On the right is the revamped stylus holder. It has secrets. We'll see more on that next.

Here is a shot with the stylus holder opened to reveal its trove of goodies. The top comes off with a quick quarter-turn to reveal a foam bed with ten nibs and a changing tool in the middle. This seems like it will make things much more convenient.

Under the box with the CD is hidden the nice goodie (at least for those in the US)... the new mouse. As with the other pretty parts, it's in a nice protective cover so that you will be the first one to get to scratch it up.

There's the new mouse. One negative is that the two buttons on the side are now gone. However, it has some secrets to make up for that. More later on that. One thing to note is that this shot does give a good idea of the actual colors of the different pieces (the flash didn't wash it out too much).

Here we have it all together. The flash is really washing out the smooth blackness of the normal appearance. And the mouse definitely is not blue nor gray; just two textures of a nice black.

For comparison I set the Intuos3 mouse and pen next to the Intuos4. The new mouse is definitely more rounded, and the styling on the stylus holder is even nicer. It is also clear that the Intuos4 mouse is smaller. I'm not sure how it will work for people with larger hands, but it fits mine quite well.

Another angle on the accessories.

Comparing the Intuos4 medium to my Intuos3 6x8, the evolution of the tablet is easy to see. The newer area has a widescreen aspect ratio, to match modern displays. There is also a bit less tablet above and below the active area.

And switching them to give a better idea of lighting, etc. The matte edges of the Intuos4 really contrast with the glossy finish on all of the Intuos3.

From the left sides of the tablets. (trying to give a fair impression of their shape, etc)

From the right sides of the tablets.

And looking at the new mouse and stylus on top of the old tablet.

Even the bottom of the tablet is pretty and well designed. One thing to note here is that there is a slider on the left edge of the bottom.

That slider is used to expose and cover the USB connectors on the side. When one switches between right and left handed use, the slider will expose the connector away from the user and cover the other connector to protect it and keep it from becoming gunked up.

In my initial comparison to the Intuos3 a few points stood out

• The feel of the surface and nibs struck me as much more paper-like. This should make the artists out there much happier.
• The two touch strips were replaced by the single touch wheel. However the use of that is much more natural, and the addition of the mode toggle in the center makes for nice potential.
• The mouse has a z-axis!!! This is probably the top feature for mouse/puck use. Before this, one would have to move their hand aligned to the tablet itself, regardless of the angle of the mouse, in order to move straight. With the Intuos4 the mouse reports the "twist" of the angle it is on, and the drivers compensate for this to make it move like any normal mouse, regardless of the orientation of the tablet.
• There are OLED displays next to each of the programmable buttons. The stock software can make them switch per app (which is perfect for making the tablet suddenly say your daughter's name and freak her out)

I will have to revisit with some details on actual use later. However it seems to work well with OS X, Inkscape and decent with Windows. I did have a problem with the drivers triggering a sleep problem on a Windows XP laptop, but that might be due to XP in general. I was not able to test under Linux since the wacom drivers only now are supporting it in the dev versions, and I was not quite ready to try poking those in (need to update to Jaunty among other things).

Read more!

What's on My Bookshelf

What's on my bookshelf? That is usually a good question, especially when it comes to software developers and people starting out... but my current answer is "nothing". Of course, before people get the impression that I hate books, or can't read, or such, I should probably clarify things. A little while back we had a bit of a problem with our house. Luckily no people were harmed... but this is what our shelves ended up looking like.

That's right, we had a wee bit of a problem with a house fire. As I mentioned, all people were OK, but the contents were totaled... including the few software books I owned. Oh, and our inkjet printer that was halfway across the house didn't fare too well either. (I never knew they made printers out of spaghetti).

However, in talking with some potential Google Summer of Code students over at Cal State LA the subject came up. It is a good one, and very helpful even to programmers who have been out of school for a while. First off, I should point out that I am not one who buys nor reads many technical books. It started off originally from not having much money, so books were a luxury (well, technical ones... books just for reading are a necessity). By the time I could buy more, I didn't really want to since books on programming tend to be out of date so quickly nowadays. And for the most part, I could get detailed and more specific information from the Internet.

The following books, though, should be read by anyone working on software:

"The Mythical Man-Month" - Frederick P. Brooks Jr. (anniversary edition)
ISBN 0-201-83595-9
The granddaddy of them all. Although first published in 1975 it is still very applicable today. The abstract concepts were found and present well and hold up more than a quarter century later. Be sure to track down the anniversary edition with "No Silver Bullet" in it. It also helps that this is a fairly thin book, so one can actually read it. (Admit it, not many of you pour through gigantic tomes. or at least not to the detail to which they deserve)

"Code Complete" - Steve McConnell
ISBN 978-1556154843 First edition (1993)
ISBN 978-0735619678 Second edition (June 2004)
Big fat textbook on software coding. This one is huge, but well worth the read. Also it has already been distilled down to the essentials, so don't skim through it. Definitely one to be taken a chapter at a time. My personal feeling is that this very savvy person set out to write the definitive textbook on software construction and nailed it. This one also is chock full of studies, statistics and citations.

"Agile Software Development with Scrum" - Ken Schwaber, Mike Beedle
ISBN 978-0-735-61993-7
This, I think, is a number one "must read", second only to The Mythical Man-Month (and in slight contrast to Code Complete, which is a "must slog through"). The key here is that it explains why the software industry has gotten its process almost completely wrong. Waterfall is broken and can't work, etc. It also points out how to make a software development process that actually works. I've been on teams that have brought this into companies both large and small, and it works. Very well. Also it is a very thin book, so all should be able to read it. However, if some of you don't want to actually track down and read a book made of actual paper, the first chapter is available online as "Get Ready for Scrum". (Just be sure to read all 8 pages, since the online article lists it as 7. Don't miss that last page)

"Extreme Programming Explained: Embrace Change" - Kent Beck
For those who know of extreme programming, there is a tendency to either hate it or love it (if you hate it, then you don't "get" it). However, I am surprised at how many people I meet nowadays who aren't familiar with it. (I guess they don't get the joke of Microsoft renaming Windows 2000++ to be "XP" either). Anyway, this is a very good book and even manages to weave in citations of both anthropological studies of the 60s and Spinal Tap. When understood and put into practice correctly, I believe that XP practices (Beck's, not Microsoft's) lead to very high productivity. However it is easy to get them wrong, and I believe that even the book "Extreme Programming Implemented" in the same series misses the mark on some things, including pair programming. Again, this is a relatively thin, so no excuses for not reading it.

"Rapid Development" - Steve McConnell
Another good tome by Steve McConnell. Whereas Code Complete focuses on actually writing code, this one focuses on managing a software project. Quite handy, but again one to take a single chapter at a time.

"Peopleware: Productive Projects and Teams" - Demarco & Lister
ISBN 0-932633-43-9
This is a bit of an older book, but very handy for team leads, managers, etc. Also is a thin book, so no excuse...

Read more!