SVG Chicken and the CMYK Egg

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

Read more!

Inkscape 'shell' patch

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.

Read more!

SVG Open Summary

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.

Read more!

At SVG Open

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.

Read more!

Wacom villain found and fixed!!!

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.

Read more!

Standardization is a Bad Goal...

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

Read more!

The vertical block is finally gone

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.

Read more!

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

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.

Read more!

Smaller Extension Preferences

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.

Read more!

Next eraser toggle

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.

Read more!

Adding another little feature

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.

Read more!

First phase of tool committed

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.

Read more!

Freedom from size tyranny

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.

Read more!

LugRadio Live is on

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

Read more!

What's This?

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.

Read more!

Inkscape at LugRadio Live USA 2008

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!

Read more!

Summer of Code 2008

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

Read more!

Tablet Test Area

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.

Read more!

New Tablet Config

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

Read more!

What is a 'Swatch'?

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.

Read more!

Enhancing tablet support

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.

Read more!

Color Palette tweaks for Inkscape 0.46

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.

Read more!

Hello World

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

Read more!