Code Wide Open

Inkscape Text Outlines

2011-03-27T01:53:00.000-07:00

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.

Inkscape Does Support CMYK

2010-10-06T00:15:00.000-07:00

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)

"CMYK" is Meaningless

2010-09-20T20:48:00.000-07:00

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.

Backlogs and Real Life

2010-03-16T18:17:00.000-07:00

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.

Inkscape should NOT "support CMYK"!

2009-12-17T21:25:00.000-08:00

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)

Libre Graphics Day Call for Papers

2009-09-18T17:26:00.000-07:00

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.

Libre Graphics Day at LCA 2010

2009-08-08T12:15:00.000-07:00

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)

Much to do, but color is on the march

2009-07-31T22:59:00.000-07:00

"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.

On Conficker and Zombie Education

2009-06-03T06:45:00.000-07:00

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. ♪ ♫

Intuos4 Unboxing

2009-04-30T21:04:00.000-07:00

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

put in the disc
install the software
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).

What's on My Bookshelf

2009-04-10T23:37:00.000-07:00

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...

Swatches Moving In

2009-03-23T01:57:00.000-07:00

It's been a while since I first started on swatches work for Inkscape. Much of the time has been taken in preparing the code internals, and some with coordinating with others on new standards and formats. I've also had other things going for bugs fixing, needing to fix icon regression, etc. However the first cut of functionality has gone in. The new menu on the popup for swatches now has add and edit if you are on the "Auto" swatch set for the current document.

One of the nice uses that works now is that if you drag a "solid color" (implemented behind the scenes as a SVG 1.1 compliant single-stop gradient) on to multiple objects you can then edit that source gradient to change all objects with that color automatically. After I fix some bugs elsewhere in the code I'll be revisiting this and extending it with linked colors to automatically keep and update tints, tones and shades. (The people who know what those things are will be quite happy, and the others will like it once they see it in action)

While I was cleaning things up, I did manage to get initial support for more than just simple color in also. So custom per-document palettes can contain both solid colors and gradients too. The previews and even the drag-n-drop color patch should show gradients nicely. Behind the scenes I've been moving functionality into some common shared classes, including drag-n-drop and exporting that will support Open SwatchBook. I'm still roughing out the format so that it will be based on using the new color format worked out in CREATE, but with more than just simple solid colors. The code could also be reused in applications like Scribus.

While I was in there, it was easy to implement another feature request to highlight selected color in the palette. For the moment I did just simple square and diamond markers to note selected fill and stroke respectively. I'm pretty sure that visually this is... sub-optimal, and will need reworking. But at least it gets the code functional and the feature usable. Suggestions on how to make it look in the long run are very welcome.

There are a few things that still need implementing, including updating the swatch down in the palette when the color/gradient is edited and also misc problems when working with multiple documents. External saving and loading of these swatch sets also needs to be put it, along with some management for updating and reloading.

I'm tossing it out for some initial feedback and requests. More work is ongoing, but I do need to get those pesky icon issues finalized and fixes put back in. Well... I probably should get some sleep... but drop notes with what to do to improve it (again, once I get some existing bugs elsewhere fixed to keep Inkscape moving to a 0.47 release).

Color talk at linux.conf.au

2009-02-24T01:13:00.000-08:00

I just got word today that the videos from linux.conf.au 2009 started showing up online, and mine was among the first set. The video is up in ogg, and should be nice and open, so grab it and check it out if you might have an interest. There's no interpretive dance, but there is juggling. The target for the talk was fairly broad, so as to be helpful to as large a group as possible.

Unfortunately, the other Inkscape presentations have not gone up yet, so we have to wait a little longer for the complete experience. Andy did a nice LPE talk, and Donna had a good intro class. I think the main problem with the latter was that there were more interested people than space for hands-on in the talk. Then again, that's usually a good problem to have, since it shows good interest.

You can download the video for "Why Color Management matters to Open Source and to You". I did get them a copy of the slides (which include full notes), ~~but those don't seem to be online quite yet~~ and are now up. The abstract for the talk has been online, so that's a handy summary to check and see if the video might be of interest.

Once more finish getting posted, I'll try to get a summary of some of the more interesting and/or useful up. Then again, they are good resource and are worth checking out overall.

SCALE and GNOME and Tux and cakes

2009-02-23T00:51:00.000-08:00

Just got back from a busy weekend at SCALE 7X. There was quite a lot to take in, and despite the downturn in the economy (or perhaps because of it) there seemed to be even more going on this year. With all the changes in situations, I was the only person representing Inkscape this year, so camped out with the GNOME guys. Ted was there, but literally next door manning the Canonical booth. He came in last-minute to give an Ubuntu talk, and was very busy. I'll do some follow-ups with details, but had to at least get a quick note up, along with some info on that visitor to our booth there...

We whipped up this little cupcake guy to hang out in the booth and perhaps get a little more interest from people walking by. Unfortunately the table was so full of good monitors that he kinda had to hang out back a bit. He did garner a bit of interest, then and the end of day one he met his fate :-) . There was some good GNOME traffic and interest, but Inkscape managed to get quite a bit going on there too. It also probably helped that right next to our setup was the other booth running World of Goo.

OpenSUSE was just behind and around the corner from us. Aside from other things, they were notable for two main points of interest to Inkscapers. The first item was Joe Brockmeier's keynote on Sunday. I think the main takeaway there is that the main problems for FOSS projects are no longer technical (our stuff is solid and works well enough), but rather is in getting the word out about the project. The second reason of note is the openSUSE Build Service. It's part of the infrastructure they are building out, but all are welcome to use it, and it builds for all "major" distros. Additionally the architect who talked with me said that it could build Win32 targets (though no Mac as of yet). That struck me as potentially helpful to take the load off of our current overloaded guy.

Well... that's probably all I can pull together without a bit more rest and tought. So in the meantime I can say.... om nom nom nom!

Linux conf au one

2009-01-31T17:12:00.000-08:00

Well, here it is. Another conference has come to a close, and it is time again to try to make sense of all the amazing things that were seen and discussed. Overall LCA was a great meet-up, although there was one big negative: there were so many good sessions to hit that it was impossible to not run into at least some scheduling conflicts. Of course the good news there is that the volunteers are working to get slides and video up for as many of the sessions that they were cleared to. One things are up, I'm sure I'll find even more to ponder.

Probably the first thing to hit is the topic I came down to speak on: Color Management. My presentation went pretty well, and I had a few people talk to me about it later (and that was despite being scheduled right next door to the Linux powered clarinet playing robot). Additionally Carl Worth introduced me to someone who has started poking around in Cairo, seeing about hooking in color management. We also got a chance to go over what's needed to get things hooked into Cairo and get some nice CMYK PDF output. The next step is to collect up some representative use cases so we can figure out exactly what the API changes will have to be supported. I'm going to be pestering the Scribus guys to see what they know of, but if anyone out there has any experience or needs of going to print, send off an email or comment so that we can be sure to cover things well.

Next up is extended input. I attended a talk by Peter Hutterer (of MPX) that went over a bit of the state of things and then the new changes that have been going in. Over the course of the conference I had ended up chatting with him a few times, and verified that I am on track with where I'm working on taking the new extended input support (good support will need to leverage D-Bus and HAL). He also had poked around for a couple of weeks with Wii remotes, but had since moved on. That actually was a fairly common story, and it seems that it's up to me to address the GUI and application levels.

And to keep things short for now, there's one last point I want to cover: technical drawing. Of people I talked to who were not using Inkscape or not using as much as they could, the most common question seemed to be with technical drawing. We could probably pick up a good usability boost and garner another user segment if we just tune up things to make technical drawing and diagramming better. Most of what we need to do is probably already well known to us. However, we could benefit from a quick review and a little refocusing. I think one person's question really summed up the viewpoint we need to use when looking into this: “So, will Inkscape let me finally move off of Xfig now?” The people we could help with that are probably using Xfig or Dia (or nothing yet) for simple charts, diagramming, home layout and the like. Perhaps focusing down on some casual use-cases like that will help us sight some low-laying fruit and get a jump up in this area.

As usual, I'll send out more info as I digest things and get them settled out in my head. In the mean time, feel free to ask about any specifics you might care about. Perhaps Peter or Andy or some of the other Inkscapers who were there might chime in also.

Bdale Makes the Cut

2009-01-23T13:54:00.000-08:00

This year's linux.conf.au charity auction was going to help the "Save the Tasmanian devil" organization. Things started to get crazier and crazier, with strange attempts to get Linus to do something resulted in a change of the mascot for one release from Tux to Tuz.

As the crowd grew more frenetic, someone jumped in with a demand for Bdale's beard. Despite starting the whole thing off with a beautiful print of his wife's award winning photograph, he began to reconsider under the pressure. Arjen Lentz (who at the conference promoted http://bluehackers.org/) stepped up and offered the hair on his head if Bdale went through with it. Bdale did say if over $10,000 was donated then he would (although I'm not sure if he believed it was possible; I was very pessimistic on that myself). Matching challenges were also tossed out and taken up, and the final result was a total somewhere in the ballpark of $40,000 (au) being raised.

So come Friday around lunch, a huge spectacle unfolded as Bdale, Linus and Arjen prepared for their ordeal. Arjen went first, to allow for a little practice before the more difficult (and anticipated) task of Bdale's.

The event went off well, with much amusement, live tweeting, and even local television coverage. Once Linus had completed his arduous task with clippers (having foregone the hedge clippers he was first looking at) there was just a bit left for an actual razor. Being the wise man that he is, Bdale decided that he himself would do that close work. However, in the pause before that I caught a great shot that to me conveyed his great temperament and sense of humor about the whole thing, as he endured the temporary pain and embarrassment in order to be able to do his part in helping preserve one of God's great creatures here on earth.

Greetings from Tas and Tuz

2009-01-19T13:59:00.000-08:00

Greetings from Tasmania!

Just dropping a quick note while I'm sitting here waiting for day 2 of the linux.conf.au miniconfs to kick off.

I'm just hanging out, and spent time already with my new friend Tuz. He helped me get the artwork for my slides tweaked up, and has taken over my room.

Things are going good here so far, and lot's of great people. I'll have more details come up, but in the meantime will try to get bits up on identica and twitter.

SVG Chicken and the CMYK Egg

2008-11-25T01:06:00.000-08:00

For some time now SVG has suffered from a fair bit of chicken-and-egg problem when it comes to CMYK. Not much of the software out there handling SVG supports CMYK because not too many people use SVG for CMYK work. And not too many people use SVG for CMYK work because not much software supports it. Unfortunately this cycle has persisted for quite some time.

CMYK for vector work mainly matters to a segment of the users out there who are preparing artwork for printing. Some doing print work might find wide gamut RGB to be a better solution (photographic work, for example), since it is rare that an artist is actually working in the exact CMYK output colorspace for the specific printer that will be used for the final output. But still there are those who find the lack of CMYK as a blocking issue. There is also a factor that the types of artwork that can benefit more from working directly in CMYK are more the non-photographic types that are less appropriate to work on in GIMP or Photoshop.

Since the beginning, Inkscape has allowed users to select colors using CMYK values, but those were not truly selecting CMYK. Instead it would use a simplistic approach to split RGB into some sort of CMYK numbers (but not profile-matched accurate ones), and then convert the user's selection back into RGB numbers for storage in the SVG. So although there was a CMYK color picker, Inkscape did not really "handle CMYK."

Starting with version 0.46, however, work has started that will begin to break the negative cycle of lack of CMYK support both in Inkscape and in other software. Leveraging the icc-color support in the SVG 1.1 spec, it is possible to use a CMYK color profile to store and work with proper CMYK values. Although no UI was added to allow a simple means to reference an ICC profile, once a SVG file that contains a reference to an ICC profile is opened, a new "CMS" color picker is enabled that can be used to choose colors using accurate values in proper CMYK.

What this does is allow for initial work with proper CMYK to be started. Users who are aware can start creating files with CMYK values with just a little manual tweaking. More importantly, however, is that people working on other programs can now start getting CMYK SVG files that are standard-compliant and thus can start adding support on their side. One such project is Scribus, who's developers have been coordinating with the Inkscape team, and who are looking at supporting such ICC profile SVG files in their next version.

That still leaves Inkscape with several areas to work on, but these are mainly independent now that the core work is in, and can be attacked independently of each other:

Add a basic UI for linking to ICC Profile files.
Integrate ICC profile support into the existing color selectors, including out-of-gamut selection warning.
Scan existing codebase for areas that limit themselves to RGB or RGBA values and thus can strip out full icc colors.
Improved style and/or CSS support to manage paint types, palettes, etc.
Basic support for "registration" color/style.
Coordinate with Cairo team on extending API beyond RGB
CMYK PDF export

Inkscape 'shell' patch

2008-09-13T23:14:00.000-07:00

I'm not sure why, but you can now launch Inkscape in a mode with a simple interactive shell. Someone submitted a patch a few weeks back that presented a "server" mode so they could run multiple Inkscape commands without actually relaunching the application.

I wasn't sure myself of where this would be most useful, but a few of our guys said it could help in some cases. I finally had time to clean up the bits of the implementation (though there still might be some lingering Windows issues) and get it submitted. There's a warning that pops up when exiting, but otherwise it seems ready to start using. We probably need to give a little thought to tweaks like the character or string for the prompt, etc. A bit more refinement is probably good.

It takes the same command format as the command-line interface that has been in Inkscape for some time. We might need to add a bit more, but finding out how people use it and what they run up against will probably shake all that out.

SVG Open Summary

2008-08-31T01:08:00.000-07:00

I just got back from SVG Open 2008, and wanted to give some quick highlights. If, of course, there are points that anyone would like more detail on, please feel free to ask. Overall I think it was a very good event, and I'm excited about the momentum with SVG.

One of the first points is regarding SVG and comics. John Bintz had asked me to see if there was any interest. Before the first day was out, at least three different people had come up to me and mentioned them in one way or another, with at least one person telling how such an interest is what drew them into SVG to begin with. So I would take that as a big "yes".

Probably the most encouraging aspect was the renewed activity I'd seen regarding the W3C efforts. SVG 1.2 Tiny looks on track to being finalized soon, with an upcoming Test Fest in Canada as one of the final steps. Both the SVG Working Group and the newer SVG Interest Group show a focus and strong activity.

Even though Inkscape has not even specifically addressed 1.2, they are still very interested in including Inkscape in the testing and report. Among other things that could help us see some opportunities on where to improve next. It definitely could help with establishing more communication, and could help raise Inkscape's profile. So if there is anyone around the area in Canada in September who could show up for that, please let us know. And if we don't have anyone local who can make it, they still were interested in us running the tests and getting the results over to them.

That brings me up to the SVG Interest Group itself. If anyone is "interested" in SVG, then they should look at the info and charter and see if they should join (I've already submitted the request for myself). Aside from the IG itself, they're hoping to have community resources and activity grow out of some of the IG's efforts. So participating with those efforts and growing community would be great.

The working group mailing lists have been revamped, and I believe they are now open for the public to join. Doing so to help track what's going on was strongly encouraged. The implementers' mailing list is probably going to be renewed also, so people might want to watch for it too.

About SVG itself, many different uses are out there and touched on. Two big areas of activity are in mobile phones and Mapping/GIS. Sometimes use of SVG is not apparent, so it's hard to say all the places it might be. Another place shown was television related program guides and control. One company showed their SVG interface for fabrication machines, and even took a few hours to come up with a Lego Mindstorms driver so they could demo a mini version of monitoring and control.

One presentation I found insightful was how one of the experiments in the LHC was using SVG for visualization of results and detection passes. There are even parts online for it, including a live XSLT result sample.

Work on SVG Print and SVG Layout are two areas we should keep our eye on, as those are addressing quite a lot that we want to work on supporting. Also when I asked about <multiImage> support (a key feature that would help UI artists) and described the use cases, others pointed out a facility in CSS3 might solve the problem in a more general way, and that I should definitely follow up on that.

Another stand-out presentation was Zack Rusin's one on KDE. He went over history and development, and then showed several demos of the latest KDE where most everything is done via SVG. The night before he had mentioned to me that many of the KDE artists used Inkscape and loved it.

That's all for the moment. I'll probably point out a few things in detail later on, and one at a time. But until then feel free to ask for more details on anything there.

At SVG Open

2008-08-28T02:13:00.000-07:00

Just a quick post about SVG Open.

I managed to get through my keynote and my CMS presentation without too much blowing up. The main problem was that despite the fact that I practiced timing earlier, once I was giving the talks the parts covered by slides took up all my time, and I didn't get to switch to the live demo bits I had prepared.

I'll have to take the time afterwards to write all up, but there has been a lot of good things going on. One thing I was asked about by Inkscapers was any interest in doing comics. By the end of the first day at least three different people had come up to me to mention Inkscape with comics. There is also some good work on accessibility that we'll need to look at integrating sooner if possible. Oh, and there was early mention of non-affine transforms and a few other nice things.

One of the things on the W3C front is the fact that they are winding up finalization of SVGT 1.2 and are about to hit a testing phase. The SVG Working Group is going to be running an implementors test thingie (my technical term) soon in Canada I was asked if Inkscape might have anyone local who could participate. Or if at the least we might run through the SVG 1.2 Test Suite and submit the results.

Wacom villain found and fixed!!!

2008-08-25T16:20:00.000-07:00

After many months of toil and frustration, I finally tracked down the root of my problems with the Wacom tablet on Ubuntu. It was quite frustrating, since the tablet worked fine if I ran from a live CD, but failed once I installed to the hard drive. Everything else worked but the tablet. So I suffered and found work-arounds.

After compiling and installing new Wacom drivers yet again and another round of fruitless poking, I stumbled across a reference to a similar sounding problem. There was a post by some end user that was completely non-technical and involved talking about his admin and things that he had done when I hit a mention of the culprit...

It was the dreaded, the insidious, the crafty...

Mouse-Emu!!!!!

It turns out that the mouseemu software normally used to make a touchpad on a laptop more friendly had turned evil in this case. It perhaps was handling the touchpad fine, but it also got greedy and grabbed the external Wacom itself. The simple fix was to just go into Synaptic and remove mouseemu there. Voila! Happy-happy Wacom time!!!!

So if a tablet is showing up properly in the low-level view, but stops responding... it might be the tricky mouseemu.

Standardization is a Bad Goal...

2008-07-21T00:50:00.000-07:00

Recently I've hit upon how to express something that I've learned and worked with over many years: standardization is a bad goal. I know that standardization is something that management, both in software development and out, loves to focus on and push. However, I've often seen it cause more harm than good. There is a much better way to phrase the goal, with "standardization" taking it's proper, subservient role.

The key here is the one word - "goal". Standards themselves are not inherently negative. It is when perspective is lost and they become the goal itself instead of simply a means to a goal that the damage is done. A perfect example of this is military underwear.

For example, in the Eighties, the US Army had come to a realization that much of its purchasing standardization had come to be getting in the way of achieving the mission, and made efforts to reform it. Standard issue underwear were just one example. In order to try to gain consistent quality, specifications for requirements of underwear had been made. Pages upon pages of military specs covered them (tens or hundreds of pages, or perhaps more). However instead of the desired effect of quality and efficiency, over the years these military underwear specs had ended up locking things in to the state of the art from decades long past, pushing up prices and limiting supply. The process was redone with a simple focus on the actual goals and not only did the quality of the 'equipment' supplied to the troops go up, but the price came down.

When it comes to software development, most often there is an unstated goal hiding behind the calls for standardization. The true goal is not really standardization at all, but instead I believe it is most often interoperability. When a piece of software has a "standard" interface to meet (e.g. RFC 821) the goal is that different pieces of software running on different types of computers altogether can talk to each other, aka "interoperate".

Another reason to standardize things in software development is to allow for people new to a project or team to get up to speed quicker and be able to contribute sooner. I would argue that this, too, falls under the more general goal of achieving interoperability, but on a personnel level.

Of course one of the more recognized problems "standardizing" things causes is in limiting the effectiveness of developers. But there is another often overlooked issue: monoculture (and specifically software monoculture). If all developers are on a single version of a single operating system, then chances of code problems going undetected increases. Even moving to a new version of the same operating system can expose latent bugs. Time and again I've seen the quality of a project go up with an increase in variety of developer platforms and tools employed.

Monoculture often infects software development in the name of standardization. When a build system needs to pull code from several sub-projects and put them together, all of the sub-projects need to be able to play nice with the build system. Often management might try to guarantee this by declaring a requirement that all developers "standardize" on a single programming language and a single IDE tool on a single OS platform. Yes, this will reduce problems with setting up the builds, but at what cost? This approach can definitely be called the tail wagging the dog.

The focus needs to shift off of standardization and move to interoperability instead. One should leave the choice of language up to what is most appropriate for the project, based on common factors including target platform, delivery, maintenance, etc. The tool should be left to what allows individual developers to be most productive on whichever projects they get assigned to and may be different from developer to developer (and of course may change even during the course of a single project). Finally, a build system should be chosen to get projects built and delivered as needed. In all of this the requirement for interoperability needs to be explicitly stated and stressed.

A good example is with Java development. There are several choices used for development tools, with IntelliJ IDEA, Eclipse, Emacs and NetBeans among the more common. There are also many OS's that are used as developer platforms, with Linux, Windows and OS X among the more common of these. Despite being very different tools, all of these allow a developer to program in Java. Also most support the common build systems of Ant and of GNU Make in addition to their proprietary project format (and where the tools don't, Ant or Make can be made to support them).

So instead of battling over the various trade-offs of *.ipr files versus .project files, the "build people" and the "engineering people" of a group can standardize on either GNU Make or Ant. Then the requirement for developers would merely be that their workflow was compatible with the project build system and leave the choice of specific tool and/or tools up to the needs of individual developers. Even source control can be mix-n-match. Inkscape's official source repository uses Subversion, but some developers use other interoperable (there's that word again) tools such as SVK, git and others.

Similar comparisons can be made for C and C++, and with Inkscape we see quite a bit of it. Emacs, vi, VisualStudio, Anjuta, Eclipse, Kdevelop, vim, gvim and more have all been seen in use by different contributors. Developers don't don't have to use a standard IDE, but they do use interoperable IDEs and workflows.

To sum up, don't be foolish; clarify your actual goals. As Emerson said, "A foolish consistency is the hobgoblin of little minds."

The vertical block is finally gone

2008-06-19T01:12:00.001-07:00

It's finally gone!!!

The main tools toolbar has been forced into a stock GtkToolbar. Now that it is no longer a limiting factor, Inkscape is much more usable on screens 1024x768 or smaller. Any tools that don't show up in what space the toolbar does get just end up under the popup menu at the bottom.

On the setup I'd been checking size on previously this now shrinks the minimum size down to 535x469 (and on my Eee PC that hight is down to 460... very usable there).

Also in all the cleanup I was able to get in some needed fixes to floating out the toolbars.

Previously I'd whittled things down from 652x735 to 600x583. So it's over 36% shorter than before.

Overlaying this new size on top of the previous comparison really shows the difference.

I avoided some of the work of changing legacy code over by wrapping things in a simple Gtk::Action subclass (yay C++) so was able to get things functional much sooner than I'd hoped. Now it's time to add a few more things... especially since the cleanup I did manage to do put things in place to have string-based UI.

Eee PCs and Tablets and remote X11! Oh, My!

2008-06-07T00:05:00.000-07:00

One thing that has slowed down some of my Inkscape development has been that Hardy is not happy with my tablet on the laptop I usually use. It worked fine when I booted up from CD, but fails once I install and run from hard drive. I had been waiting to see if the last few rounds of beta updates would fix it, or if I could give any helpful testing feedback. Alas, it was not to be. So on OS X there is no extended input from my tablet working for X11 apps, and on Ubuntu the tablet doesn't even work as a plain mouse. That, of course, means I can't work on things like pressure sensitive behavior, extended device configuration, etc.

However... this week I thought of something. The tablet is USB after all, and I do have a second little computer with USB, so perhaps that could be used to help some how. I did a quick search on the Eee PC's filesystem and found it had wacom drivers already. A few quick minutes hacking away on xorg.conf files and it actually worked! The tiny computer was running happily with my tablet.

Of course, I then hit the big problem that it *is* a tiny computer, and I don't have a workflow to get custom things compiled and installed yet (keeping it stock for now). But then the UNIX world came to save me with remote X11! Just toss in ssh and a little X11 forwarding and voila! the Eee PC is displaying the application and running keyboard, mouse, and tablet input, while the program itself is actually running on a different computer.

I had done a few test runs with ssh to my laptop from the Eee PC in the past, so I tried again. Well, the connection and all worked, but the version of GTK+ on there did not have extended input support compiled in. So even though the X11 front end running supports it, the application didn't listen to the X11 server. Off to another computer then! Tried it with ssh to run the app from an Ubuntu 7.10 box and it worked!!!

Of course I still want to use the laptop, so I ended up using ssh there too. So the development (Emacs), compiling and running is all done on a Linux box in another room, but my editor/IDE is displayed here on the laptop and the app I'm building and running is displaying on the Eee PC. Kinda kludgey, but it works.

And then finally the size of the Eee PC in relation to the tablet is something I find quite amusing. The poor little PC is basically dwarfed by the Wacom. Literally it is only as big as the active area on the tablet itself.

What makes it even sadder is that the Eee PC is pretty good for travel and presentations, so I'll now be stuck with toting around the ridiculous pair.

Smaller Extension Preferences

2008-05-24T07:08:00.001-07:00

Alexandre asked this week if it would be possible to use combo boxes instead of radio buttons in the preferences UI for extension dialogs. Aside from that being a good suggestion for UI improvement, there were a few good factors in its favor. First of all, things have been cleanly abstracted enough so that hooking in such a change would not be much work (thanks, Ted). So a good UI benefit with minimal coding effort is generally a good thing. Second is that I've done things like this before, and have been thinking about general ways to improve the dynamic UI like this. So I've already had my mind wrapped around the problem. That's always a big hurdle to starting a coding project, even one as small as this. And finally, this just happens to line up exactly with my plans for world domination via XForms implementation. Moving forward on world domination is good, so it became a requirement for me to code it on up. :-) Here it is: On this one dialog the vertical size shrank about 30%, which seems quite helpful. I think the Eee PC users will gain some benefit here too. The other dialog I tried it on changed from 700 pixels tall to only 530, saving about 25%. More important than the percentage, though, is that this case will help those running at 1024x768 (aka LCD monitor users and such).

The C++ part of implementation was not too much at all, and seems rather trivial to me (maybe around 75 lines of code). Using the change, however, is very simple. Just add appearance="minimal" to an existing optiongroup in a .inx file and it will switch over to the combo instead of radio buttons. That's the beauty of XForms... it's mainly a way to use existing technology to gain strong benefits. And on the subject of XForms, I find Micah Dubinko's "O'Reilly XForms Essentials" a very good book on XForms specifically and on lightweight UI design in general.

Next eraser toggle

2008-05-11T23:59:00.000-07:00

I'd forgotten to point out that the mode toggle for the eraser tool showed up in SVN, along with the main eraser mode that it enables: When that mode is enabled (which should be the default) the eraser tool acts more like a vector eraser than a raster eraser:

As you can see, it allows someone to zig-zag around and delete objects very selectively. The functional details need to be tuned up a bit, as it doesn't behave well with clicks as opposed to drags. However, it should be enough to see what the feel is and how it's different from the other mode. Now all I have to do is get my tablet happy with Hardy and I can get those details like width, etc., nailed down.

Adding another little feature

2008-05-10T02:08:00.000-07:00

So here I go, finally adding a little feature that's been kicking around for some time now. The first half of it is done, but it's the half that notices changes and reloads that still needs to be worked on. Oh, and then there is also the half of trying to figure out what to invoke, and the half of needing to deal with embedded images... Well... it's a start. Feedback on that bug would help get more things going.

First phase of tool committed

2008-04-26T02:17:00.000-07:00

Here it is... The first part of the code for my new "eraser tool" for Inkscape is in trunk now. I've been working on the use cases probably more than the code even. However this is now a starting point for people to look at and start complaining. :-) This first part only adds in the functionality to cut away parts of objects you have selected. It won't do anything if you don't have something selected, and it won't do anything if the first mode is selected (the sub-toolbar has toggles for the two modes). However it does commit all the infrastructure changes including the new icons, new drawing context, verbs, switching, etc. I had been wanting to get that in first to shake down bugs in that support work. Moving forward I'll implement the "touch-delete" mode, and support for working when no selection is made. Probably a few more enhancements will come in as people try it out and give some feedback. I'm most excited about the pending "touch-delete", since it has a feel that strikes me as very "vector" and can differentiate the usage from raster drawing packages.

Freedom from size tyranny

2008-04-25T01:25:00.000-07:00

Inkscape now has tweaked toolbar size preferences. Why is this? Well the main thing is that it makes the UI more usable on Ubuntu again. There have been some ongoing issues with size, many of which are due to the use of custom toolbars from before GTK+ had stock ones. A while back I added some options to use 'secondary toolbar' size for the main tools on the left (and the top bar also), but for some users that did not help. Between Inkscape 0.46 being released and me recently getting a laptop with a very small screen (thanks Dice and LugRadio Live), I've been getting more done on that front. After seeing more bug report activity on it, especially from people running on fixed 1024x768 monitors, I tracked down a bit more. The main issue is that while Inkscape is properly respecting the user's GTK+ theme for sizes of icons, the people setting those themes up for Ubuntu, among others, had chosen to set the two toolbar icons sizes to the same. So switching from using the primary size to the secondary size did nothing to help, as it just switched from 24x24 to 24x24. So on the one hand the theme designers are imposing their idea of how things will be pretty, but on the other we were facing imposing our idea on what would make things more functional. Either way seems bad. So after splitting this specific issue to its own bug (#221676), I settled in and added enough preferences so that now the end user can decide what they want to do, and on a per-platform basis. The change reduced the minimum size from the old 652x735 to now be 600x583, just over a 20% reduction in vertical size required. The big gain there is that it should no longer be pushing things for Ubuntu users on lower-res LCD monitors. Additionally now when I flip over from OS X to Linux, I'll be able to keep the smaller icons showing up that make my workflow go faster. Of course that does tend to mess with the crispness of some of the icons... but if people care about that they can just set the sizes back. In the long run we have plans to address that, but for now at least the work-arounds should be sufficient.

LugRadio Live is on

2008-04-13T00:07:00.000-07:00

LugRadio Live USA has opened, and the first day is done. All the prep didn't come of quite as we wanted, but things still worked out well. Inkscape got a nice placement near the front, right next to OpenSuSE (who has really nice Banshee shirts). The event is shaping up to be very good, and had many different people come by the booth. Early on Stuart Langridge stopped and gave hearty thanks to all you who make Inkscape possible. He'd picked it up and whipped up a graphic and banner for the event (blogged under "Coming to America" at the LugRadio Live blog). Overall things are better than I'd expected. Though the attendance might be smaller that some shows, the people attending seem very savvy. Then again, we also have a lot more people basically coming by to say Inkscape rocks. There were a few people teaching or knowing of people teaching it, and looking for more materials. A there were few people from different projects I got to talk to, including Behdad of Cairo. Several people had things we might want to look at adding or enhancing. Hopefully we'll get the details coming from them. For example, Miguel de Icaza came by with a few things he got from recently seeing some artists in action, and it struck me as possibly something to tie in with animation and possibly the script Ed Halley was recently doing. I've been taking notes, and will get some details out to the mailing list this coming week. More later...

What's This?

2008-04-10T00:20:00.000-07:00

Interesting... so what's this that is showing up in my tools bar on the left, making Inkscape suck up even more vertical space? Interesting... could it be something I'm coding, but haven't quite finished due to prep for LugRadio Live USA? Could be.

Inkscape at LugRadio Live USA 2008

2008-03-26T21:52:00.000-07:00

Hi, Just spreading the word that Inkscape will be exhibiting at LugRadio Live USA 2008. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

LugRadio Live USA 2008 brings San Francisco the unique atmosphere of LugRadio Live UK, an event that has developed a strong reputation for providing a range of topics about free software, Open Source, digital rights, technology and more, a compelling list of speakers, exhibitors and birds of a feather sessions, and wrapping it all in a unique, fun, loose, social and inclusive event, which is often described as combining the atmosphere of a rock concert and a computer conference. LugRadio Live USA 2008 brings this unique atmosphere to the USA, with around 30 speakers, over 20 exhibitors, an eclectic range of BOF sessions, and plenty of additional sessions such as our debate discussion panel, a showcase of five minute talks, tech demos, and of course a live recording of LugRadio in front of an audience.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Any and all are welcome to come by and visit, hang out, talk about whatever. It's also a very user-centric conference with registration only running $10. We also need any volunteers to come by and help man the booth. Even being able to commit a few hours would be a great help to the Inkscape project. Additionally we have a minor need for equipment for the booth... it's a small, informal show but we can still do with a few things like monitors or projectors (if anyone lives in the area that would be handy). If anyone can volunteer, please let me know so that I can get them a list of all our people to get signed up. Thanks, and hope to see people there!

Summer of Code 2008

2008-03-25T18:24:00.000-07:00

The time has come again for another Google Summer of Code. Inkscape is participating again. However OpenICC is also returning. The more people applying, the more slots will show up. If anyone is interested they can see a bit more on Kai-Uwe's blog

Tablet Test Area

2008-03-21T23:07:00.000-07:00

I've gotten a bit more committed to SVN for the new input devices dialog. It does tracking of buttons and axes now, with different graphics to show ones that have been seen, ones that have not, and ones that are currently active. There are two main benefits right off the bat (aside from the gratuitous "oooh, pretty lights" factor). First is that it allows a simple way to determine what inputs any given device really has, as opposed to what is reported to GTK+. For example, my tablet's pen says it can handle 7 macros, but it only has 3 buttons. And I've seen that although the driver reports six axes, I only get data on five (aka there is one 'dead' input axis). The second main functionality is to allow a user to see which physical parts of his devices are hooked up to what. For example, an Intuos3 tablet has buttons and touch strips on the tablet itself, but it may not be immediately obvious how those are configured. Under Linux, I see those strips as the x-tilt and y-tilt axes. Also using the visual feedback it is easy to see which buttons have which numbers. Then below I'm using progress bars to show the current values of the axes, so it's easy to get an idea of how those values range on different physical changes. I still need to add some visual feedback for those that have no bounds, but those are usually the ones mapped to x and y, so are already being used for positioning. Now the next thing is to get some feedback on how this works for other people. That will also help for the "Configuration" tab which will allow setting of things such as screen versus window mode, button actions, etc. Those may change with the user's current task, but the hardware usually will stay in one (or a very few) combination.

New Tablet Config

2008-03-13T00:58:00.000-07:00

I've got the initial cut of the new replacement for GTK+'s extended devices input config done.
The old dialog has been around for quite some time, and is really good for a low-level view of things. However, the needs of users have moved more and more into the high-level artist-centric viewpoint. This is a bit nice for me as a software engineer, but definitely is not as nice for my artist side. X? 1? 6? Which do I need? What do they mean? Also "pad"? Why is part of my tablet showing up just like my tip of my pen does? And for that matter, why does my eraser show up as something separate from the front of the same pen?
The work on a replacement has progressed to a point where something is visible and initially functional. One minor point is that the dialog is now dockable... but that's a minor item. The first functional point of note is a separation of hardware from configuration. The more common case will be that a user has a single tablet, but a few different ways of working with it. The next point is the Test Area. I've found that it is a bit hard to tell what's going on with tablet config. Currently the area should switch to indicate the device currently active on the tablet. Additionally it will dump events to stdout. This will allow for checking things like button numbers, axis values, etc.
This is in the current sources now, but needs USE_NEW_INPUT_DEVICES defined in verbs.cpp to turn it on (hint: this is for those of you able to build). So the next thing is to get some user feedback to see if it reports events correctly, detects actual devices, etc. So have at it and have fun. :-)

What is a 'Swatch'?

2008-03-04T23:05:00.000-08:00

What exactly is a swatch? That is a very simple question, but ask many different people and you'll get many different answers. When it it comes to computer graphics and programs, that ambiguity introduces many problems. What is worse is that most people are unaware of it. For most people familiar with graphics apps, this one is easy. Are these swatches? "Yes. Swatches are colors in my program." Sometimes they have a name. Sometimes they have RGB values. Sometimes they have CMYK values. But just simple colors. OK.
So for the next question... are these swatches? Interesting. Gradients... yes those could be swatches also. Hmmm... that starts to cause a problem, since many programs like to keep those separated.
Now here comes the fun... the common dictionary definition says that a swatch is sample strip cut from cloth. So we get more than a simple 'color'. And we've definitely left the land of simple 'color' and moved on well into materials.
Here is another set of cloth swatches. A set of simple pieces of cloth, but showing a fair bit of patterning.
And another set. More and more fun.
Often other materials can get collected up into swatch books. At least in the real world.

So... what does this all mean for us now? Basically that I am very unhappy with the artificial isolation and concepts being driven from the implementation side. Instead we need to start looking at things from the end-user side. Artists, cartoonists, graphic designers, etc. all have certain needs, and our software should learn their neeeds, instead of forcing the artists to learn the software's needs. I'm now adding a more artist-centric view into Inkscape's implementation of things. Hopefully we'll be able to get a common OpenSwatchbook format to allow these sets to be shared between applications, just as they can share .gpl color palette files now. As a first step I'm trying to collect up information on the use cases, shared needs, user interface ideas and such at the Swatch Book page on the Inkscape Wiki. If you happen to be an artist of any type, a doodler, a programmer, or even just someone with a few opinions we would like to hear from you. The more different types of users and others that we hear from, the better we can make things.

Enhancing tablet support

2008-02-26T00:25:00.000-08:00

For some time I have been wanting to help with tablet support in Inkscape. Things have finally come together enough for me to get started. We've had at least one RFE on this for a while (bug #171265) The first step of this is in, and now has a preference setting to enable switching the Inkscape tool as different devices are used on the tablet (pen tip, eraser, mouse, etc.) The implementation will probably need a bit of testing and refinement, but it should be ready for users to check out. The coding is not that difficult; most of the real effort is with figuring out the behavior that needs to happen. At the moment the tool switched to is always the same for the same tool, but very shortly it will remember the last tool used. In the long run I'll probably be replacing our use of GdkInputDialog to provide easier configuration. However, the main thing missing is how different tablet setups are configured. Multiple pens, multiple tablets, non-Wacom tablets, etc. That's where feedback from end-users and testers really comes in handy.

Color Palette tweaks for Inkscape 0.46

2008-02-23T13:59:00.001-08:00

Here's a little tweak I got in at the last minute for the next version of Inkscape. Bulia had been annoyed by a few aspects of the palette there at the bottom of the UI. After talking some things over with him this past week I realized that the first bit of his issues could be addressed by adding an option to change the color swatches from square to some user-specified shape instead. The popup menu that allows choosing size, etc. now has a submenu to go thinner or wider. Also he brought up some information on how the sizes ("tiny", "small", etc.) were being calculated, so I was able to fix a bug with that. (Prior to this things would behave as desired on my systems, but not for others if their current theme had different behavior). And then the final bit was to tune the code a bit so that when the palette fits on the UI all at once the space for the scrollbar would no longer be used. The end result is what you see here. You can now use a palette with over 400 colors and have it all visible at once. Of course, that does get a little hard to click on, so you can bring things up a little larger. This window is currently the narrowest that 0.46 goes on my system, and the palette is the Inkscape default one, which has around 431 swaches. It's interesting how just combining a few minor tweaks can result in nice bumps in options and usability.

Hello World

2008-02-23T13:53:00.000-08:00

After avoiding it for many years, I finally gave in and set up a blog. I'll mainly be focusing on issues related to Open Source software, and especially Inkscape (the main project I contribute to). More soon...