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