- Inkscape Devel - Inkscape Mailman

Font weight and style variants
by Denis Jacquerye 27 Mar '06

27 Mar '06

Inkscape is not handling style variants in any flexible way. Right now it can only handle what style_name_compare() recognizes, everything that does not correspond to that is mixed up. Right now only Regular, Roman, Normal, Plain, Medium, Book, Italic, Oblique, Slanted, Bold, and Caps are understood. Fonts that have Light, Thin, ExtraLight (or its variants), UltraLight, Hair, Demi, Demi-Bold, Semi-Bold (etc.), UltraBold, Black, Heavy, Fat and UltraBlack are not handled properly. These could be added as valid style but that's just part of the problem. Some fonts have non standard style like Contour, Sketch or Bubbly. The font dialog should allow the user to select between the CSS weights of a typeface without having to select the styles. libnrtype/nr-type-pos-def.[cpp|h] seems to have the proper structure for multiple weights. I opened a bug report https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1448618&group_… and made some sample fonts if you want to test multiple weights and styles http://home.sus.mcgill.ca/~moyogo/fonts/test/ Denis Moyogo Jaquerye

1 0

Re: [Inkscape-devel] Xarification
by Tobias Jakobs 26 Mar '06

26 Mar '06

> On 3/23/06, MenTaLguY <mental@...3...> wrote: > > - Xara is considerably faster > Xara's renderer is fast, but Cairo with OpenGL is even faster. > But if Cairo gets Xara renderer, it will be just as fast. > Carl Worth (Cairo) talked a lot with the Xara programmers at the LGM. And as far as I know the plan was to make Xara's renderer GPL and then write an Caito backend. > Anyway, so far it's premature, since Xara's renderer is the part which > is not opensourced yet (it remains a binary lib in their source > tarball). > An other reason to use Cairo is, we will get PDF and PS export for free. Tobias __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

3 3

Nice Tutorial in Linux Format
by John Taber 26 Mar '06

26 Mar '06

fyi: This month's Linux Format magazine has a really nice tutorial on Inkscape shapes (becoming a regular feature like their great Gimp tutorial series). Maybe it's just a copy of the existing shapes tutorial (didn't have my laptop with me to compare), but if not, I wonder if there's a way to get permission to put links on the website to the actual articles like this? It's often frustrating to search for documentation and find articles that are months, even years old locked away in subscription only files. Maybe there's a better way to have a linkage between commercial publishers (or even bloggers, the line is blurring) and free software in order to get more how-tos and documentation (some sites do variations on this) One way is to give special promotion on the website to mags that promote the existing tutorials as articles or maybe so many months after publication have excuarticles that become open and part of the software's tutorial or website - this provides magazines with steady stream of great articles, first to market advantage, and exposure on software websites, authors become regular celebrated columnists and even fabulously wealthy on the speaker circuit, and Inkscape and it's users get more freely available docs, everyone wins.

2 1

Inkscape Development
by Dale Harvey 26 Mar '06

26 Mar '06

Hey After a rather long break, I have started again at trying to do some development with inkscape, I was wondering if there was a few quick questions I could ask. debug statements - Im currently trying to get the hang of the code by basically going through and adding debug statements to try and follow the program flow, however g_warning (and g_print/printf/g_debug etc) messages are not being sent to stdout when they are called, I only recieve them after inkscape has been closed, a grep on "g_set_print_handler" gives me nothing back and its supposed to default to stdout, Im assuming the command line interface is interfering in some way but having problems finding how, and how to fix it. complication - compiling the application takes a little more time than is really usable to be developing with, my machine isnt great, 1.6Ghz, 512Ram, but I expect im not compiling it in the right way for development, i tried turning off optimisation with export CXXFLAGS='-g -O0 -Wall' export CFLAGS='-g -O0 -Wall' and trying to use ccache export CXX='ccache g++' the optimization does not seem to have affected much, and using the CXX flag gives me configure errors about not being able to find libraries that are installed. it takes me around 4 minutes to do a make / make install, im not really sure if this is an acceptable / usual time for recompiling. inkboard - after having to give up last time, im going to try finding the bug on my platform with inkboard that I mentioned in http://sourceforge.net/mailarchive/forum.php?thread_id=9660890&forum_id=360… when I left last time, I could invite another user to join an inkboard session, which worked perfectly, however I could not recieve connections, either from another instance of inkscape, or another user. I was wondering if anyone who is working with inkboard had anytime on or after sunday ( any time suitable, I will be making myself permanently free from then on) would be able to join me in the inkscape jabber room, as the problem is quite hard to debug with a single session, that doesnt work. Thanks Dale

3 3

article on Inkscape
by Alexandre Prokoudine 26 Mar '06

26 Mar '06

Hi, Both offline and online versions of popular russian computers magazin "Computerra" now feature a review of Inkscape written by Sergey Tokarev: http://www.computerra.ru/online/files/259519/ It looks like he did his best to present most actual and precise information, but unfortunately in some areas he failed (e.g. he stated that Inkscape's developers are already working on support for CMYK and CIE LAB colorspaces :)). However, Inkscape is rated as best vector graphics editor for Linux that, in case of merging codebase with Xara, will have all chances to be the best free vector graphics editor on all platforms. Btw, he also wrote that the same guy who introduced support for tablets is working on vector brushes now. Is that true? Alexandre

2 3

Xarification
by MenTaLguY 24 Mar '06

24 Mar '06

I've been thinking about our Cairoification plans today, and I think we might be much better off incorporating Xara's rendering engine instead. Two main reasons: - Xara provides a lot of stuff that we would otherwise have to write ourselves atop Cairo (e.g. gaussian blur) - Xara is considerably faster I don't want to simply borrow code from Xara, though -- ideally, I'd like to componentize the relevent portions of Xara so that both projects could use and jointly maintain them, as a sort of "common pot". Xara would benefit from this, since (in the long term) to fully implement the SVG specification we'd need to contribute additional capabilities which Xara Extreme could then exploit. To make the task managable, we'd want to approach this on a bottom-up basis: begin with the lowest-level components (e.g. the rasterizer), and work our way up to ultimately componentizing and incorporating the retained-mode graphics layer. The eventual goal would be to replace both livarot and NRArena with components shared with Xara. I'm going to start seriously looking into the technical aspects of this once I'm done with the current spate of layers work (probably post-0.44/0.45). -mental

3 7

Fwd: Re: [cairo] filters/image processing
by MenTaLguY 24 Mar '06

24 Mar '06

-------- Original Message -------- Subject: Re: [cairo] filters/image processing Date: Fri, 24 Mar 2006 08:31:17 -0800 From: Carl Worth <cworth@...573...> To: MenTaLguY <mental@...3...> On Fri, 24 Mar 2006 10:23:31 -0500, MenTaLguY wrote: > > We've been discussing "Cairoification" in Inkscape recently again, Sounds like fun! > If we adopt Cairo, should we expect to always have to implement > things like e.g. gaussian blur ourselves using intermediate image > surfaces, or will Cairo eventually provide image processing > operations like that in ways which can be accelerated in hardware? We already have an API for specifying that a given filter should be applied to a pattern, (cairo_pattern_set_filter), but the current selection of filters is fairly limited here. So I see two things that need to be done: 1) We need to add more filter types. Gaussian blur is an obvious first one that needs to be added, and something I've been giving some thought to lately. One trick with this is that it requires at least one parameter, so the current cairo_filter_t enum is not going to be sufficient. Oh, look, there is even a CAIRO_FILTER_GAUSSIAN there already. I'm not sure if that does anything useful or not yet. 2) We need to add support for filtering the implicit masks that cairo generates. This is the right place to put a filter for doing something like a drop shadow or for applying what Xara calls "feathering" to a filled shape. There's still a mask pattern involved here, but the user doesn't get to see it since it is implicitly created by cairo. So I think all we need here is a simple new API: cairo_public void cairo_set_mask_filter (cairo_t *cr, cairo_filter_t filter); (Modulo the same enum limitations we discussed above.) So this filter would be applied to the implicit masks created by cairo_stroke, _fill, _show_text, and _show_glyphs. It would not apply to cairo_mask where the user has a pointer to a pattern already and can call cairo_pattern_set_filter. As for what filter types to add, I think that "can be accelerated in hardware" is a pretty good criterion for inclusion in cairo. I think we've got Gaussian blur stuff just sitting there waiting in some existing backends already. As for a bunch of the other SVG filter types, I'm less confident that we'll see a lot of hardware support for them. I don't think it makes sense to complicate the cairo API for these if they're all going to end up in software anyway. (Though, if someone can convince programmable GPUs to do these, then there's a different question to be asked---so let me know if you know someone that has figured that out.) -Carl

1 0

Check up time
by Mike Hearn 24 Mar '06

24 Mar '06

Hey guys, I thought I'd pop in and see how you were getting on with autopackage. Are there any issues I need to be aware of? Are you happy campers? Are there any features you'd really like to have? I'm asking so I can get a better idea of where we should be going in future. Here is the current roadmap as relevant to Inkscape: * Get 1.2 released. This brings: * Better C++ support, that is, a build of the correct ABI will always be installed for the user. This resolves various obscure problems related to bugs in GCC and will allow for usage of gtkspell (finally!) * Better compression -> smaller Inkscape downloads * Better uninstall support, can now check for RPM/debs of Inkscape already being installed and (when safe) remove them. * New binreloc system. If it works out then this will make it totally transparent and the prefix location code could be dropped. * Further out, automatic online updates and maybe support for abstracting the Python unicode ABI so the python plugins support could be safely enabled. Any other features you guys want? thanks -mike

1 0

Educational contact(s)
by Jon A. Cruz 24 Mar '06

24 Mar '06

Hi, Just trying to track down what kind of interest there is for being point contact for .edu kind of people. So, who's interested? I can think of a few levels of involvement. There's working with people trying to develop open source based curriculum, and then also working with educators themselves. Also, both of those might be further broken down by various age groups, technical programs, etc. (I have various interests in this myself, but wanted to be sure to find out who all is also interested)

3 2

Libre Graphics Meeting - A Recap
by PLinnell 24 Mar '06

24 Mar '06

Hi all, For those who were not able to attend and/or also wondering about the quietness on IRC or the ML over the weekend, below is far from complete summary of the Libre Graphics Meeting held this past weekend in Lyon, France. First, this was the first ever meet of all the Scribus devels in the same place with the exception of Franz who could not attend. This meeting came about from the generous offer of Dave Neary from the GIMP team to bring in other graphics app developers such as Inkscape and it soon snowballed into a larger meet. Dave and the local Linux LUG group did a fantastic job organzing everything and a great time was had by all. One of the first presentations was by Øyvind Kolås aka pippin from the GIMP team demoing working code using GEGL,babl and gggl , the next generation of image libraries for the GIMP and other applications. Most impressive is the way Øyvind used oxide and bauxite, which are built from these components. For end users, GEGL, babl and gggl are a means to break the current limits in GIMP with 16bit and larger bit depths available, along with the ability to support other color spaces like CieLAB and CMYK. When can we see this in cvs ? The GIMP devs I spoke with said as soon as 2.4 is released. Next up was Marti Maria from littlecms and now HP. He gave an excellent presentation connecting how we see as humans with the nature of digital color in computing. Suffice to say, Scribus is as good as any at demonstrating littlecms' capabilities. Little known is indeed littlecms is used in the color management firmware in a number of high end HP specialty printers. We're hoping we can have that presentation on the docs site as a primer for beginning with color management. Gerald Friedland gave a demo of SIOX or Simple Interactive Object Extraction, which is in the current development version of GIMP. Simply put, SIOX is a clever new way of selecting objects in an image in a way which otherwise takes many manual steps. If you have a chance to get the latest GIMP beta, it is worth it just to see this in action. Who says open source folks do not innovate ? Cedric Gemy, better know for his new book on GIMP 2.2 in French 'Gimp 2 efficace' gave a demo of Tuxpaint in French. If you can read French, his new book is probably the most comprehensive book on GIMP 2.2.x Jon Phillips from Inkscape gave a talk on Create and how open source graphics applications are working to share things like brushes, color swatches and other image oriented media. Xara has been open sourced - a very bold move for a commercial graphics application company. Xara is an illustration application which has tremendous rendering speed on the canvas among other assets. One of the principal reasons for open sourcing the "crown jewels" as they put it, is to port Xara to Linux and MacOSX. It was obvious from the interaction with other teams and developers that not only the Xara folks were very much welcome there, but also they have taken the open source development model to heart. The Blender folks had a number of small talks and demos, but owning to other meetings none of us had much time to participate. One of the best parts of this meet was the time spent outside of the presentations to be able to meet and interact with other teams. Examples: Marti Maria from Littlecms gave us some hints on making Scribus more robust when handling corrupted icc profiles. We also had the chance to meet Carl Worth who developed Cairo. Sunday afternoon was a chance to meet with the Inkscape team and we looked over our mutual future plans. Jon Cruz from Inkscape showed off a drag and drop debugging tool, which should help us with Scribus to make drag and drop work easier with a more diverse group of applications. Similarly, we outlined how Scribus uses Ghostscript to import EPS and PS files with high fidelity. Adding this to Inkscape should be feasible without a major rewrite of Inkscape. The collaboration between Inkscape and Scribus teams has been good and should be even better in the future now we have met face to face. More to come later on. If there was one area lacking was simply time to meet and exchange with everyone there. We had less time to meet with some of the GIMP team than hoped, but we did have some informal one to one chats and we are much more attuned to future plans and wishlists. The GIMP team has been often unfairly criticized, in my opinion, for perceived shortcomings and unwillingness to address long standing feature requests. To the contrary, my sense is they are very well aware of these requests, but they are a small team indeed, not much larger than Scribus. That said, what I saw and heard gives me confidence that the GIMP will see major additions to its feature list in the future. The plans they outlines for future versions are ambitious. Other folks there included one of the Krita developers and folks from the Tango Project. One great surprise was to meet Nicholas Spalinger and Victor Gaultney, creator of the award winning typeface Gentium, which has been re-released under their newly written Open Font License. A few of us over a dinner had a chance to learn a great deal about Gentium, typography and future plans for enhancements and additions. The Open Font License has been carefully researched and written to maintain both openess and type creators desire for artistic integrity. This license avoids the kind of ambiguity discussed a few months ago on the list here about font embedding and the GPL. Summing up, the meet exceeded everyone's expectations I suspect. The atmosphere was fun, collegial and less a show and tell, than a chance for lots of face to exchanges. Attendance was roughly double the number anticipated. The simple fact this kind of event took place is a testament to the capabilities and maturity of open source graphics applications. Five years ago when Scribus was launched, one could hardly imagine an event like this. Already, it was decided amongst the teams to meet again next year and work is underway already on a venue. Discussion and plans will take place on the Create list on freedesktop. I'm sure I missed some important bits, but maybe we will see you there next year... Peter

3 2

Re: Live Effects Discussion
by Ricard Marxer Piñón 23 Mar '06

23 Mar '06

Hi there, I was at the LGM this weekend and one of the Inkscape developpers pointed me out to this list in order to discuss one of the concepts I talked him about: vector graphics shaders (as in 3D graphics shaders) It's an idea I have been thinking about and working on for a while. Today I had a look at the archives of the mailing-list and I just found the thread on Live Effects Discussion. Which seems to be exactly what I was looking for. I think my point of view is not that different from yours but maybe there are some new ideas. I basically try to recycle the work done on the 3D shader field to what could be the 2D shader field. >From my point of view we should define some perceptual data that should be accessible to a shader programmer and some principle drawing functions that he should be able to use. I haven't worked on it a lot yet but some of these ideas are: data accessible from a path: - point (given the % of the arclength) - tangent and / or normal (given the % of the arclength) - curvature (given the % of the arclength) (this could be given by the modulus of the tangent) (so it could be avoided) - color (given the % of the arclength) - stroke weigth (given the % of the arclength) I guess the only thing hard to do here is the reparametrization for the beziers or other curves in order to make this a function of the % of the arclength. But I think that this is something that would make this shaders powerful, since the shader shouldn't bother to know if the path is made of curves, beziers or whatever he only needs what's perceptually important about the vector graphic. What do you think? anyway here I post a little experiment with some experiments in vector graphics renderers that I made (feedback is greatly appreciated!!!!): http://www.caligraft.com -- ricard http://www.ricardmarxer.com

2 1

WEBFORM Professor switches OS X machines with Ubuntu machines
by Ryan B 23 Mar '06

23 Mar '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Ryan B email: giantmechanicalsquare@...400... submitted the following: This professor started teaching Inkscape instead of Illustrator and Scribus instead of Quark. I\'ve opened a discussion about it here: http://giantmechanicalsquare.blogspot.com/ and here is the article: http://business.newsforge.com/article.pl?sid=06/03/09/2238246&from=rss Thanks!

1 0

WEBFORM Professor switches OS X machines with Ubuntu machines
by Ryan B 23 Mar '06

23 Mar '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Ryan B email: giantmechanicalsquare@...400... submitted the following: This professor started teaching Inkscape instead of Illustrator and Scribus instead of Quark. I\'ve opened a discussion about it here: http://giantmechanicalsquare.blogspot.com/ and here is the article: http://giantmechanicalsquare.blogspot.com/ Thanks!

1 0

Font issues
by Jon A. Cruz 23 Mar '06

23 Mar '06

I was taking a peek at bug 1456620, and hit an interesting problem. There might be many other problems overlapping, but the name of one has issues right off the bat. One font name is 'Magnump.i.', but gets truncated at the first period. Does anyone have insight on this?

1 0

Live Effects Discussion
by Ted Gould 22 Mar '06

22 Mar '06

Hey all, Sorry, I've been effectively offline for over a week, so I'm catching up. I feel like I'm spamming the mailing lists :) Anyway, Aaron, I noticed that you made a branch for live effects. I've thought I little about this -- I was thinking perhaps we can all have a big friendly discussion about some of the ideas/features that would be required. (if there are any Xara developers on the list we'd love your comments on what worked and what didn't) If nothing else, so we don't overlap on any work. Here are some thoughts that I've had, feel free to destroy at will :) - Live Effects need to work with opening and saving a file, so they need to be stored somewhere. I was thinking we could add a "<inkscape:live-effect>" node in the defs section to define each live effect and read them when the file is opened. - Live Effects should be triggered when the original objects are edited, so we need to mark who those are. Probably by node ID. - If one of those nodes is deleted in the process of running the effect, then it should be stored in the live-effect node so that when re-running the effect it can be placed back on the canvas temporarily. - We need to keep track of the objects that are created by the effect, so we can delete them before rerunning the effect. I think this could also be accomplished through a node ID. - If any of the objects created by the live-effect are modified (ie moved) the live-effect is broken. I'm not sure if there should be some warning, or atleast a status bar message for this. I think it is simply to difficult to track the changes. - We need a way for the effects themselves to mark which nodes they created or deleted in their execution. I'm thinking that we can just add a inkscape namespace attribute for the nodes. When we reparse the file, we'll look for those. Then, in the inx file, we can mark whether an effect is "live effects aware" to keep the basic case simple. We may be able to accomplish this through comparing the before and after documents, but that seems likely to cause error (perhaps Mental has some ideas on this?) - I think that live effects should work for output and input extensions too. That way you could have an SVG document that you're working on constantly update the Postscript output copy that you want to have. Of course, this might be slow, but people will find it useful when they have 64-core computers :) - To make the performance reasonable, I think that we'll need to keep parsed copies of the scripts cached. I think I know how to do this with the python libraries. There is already the load/unload mechanism in the extensions to facilitate this. After I finish the extensions dialog, I'll start working on this. (unless someone really knows how to do it, I'd be happy to let someone who knows what they're doing go ahead :) Those are the things that I can think of right now. Comments and ideas are welcome! --Ted

5 10

NEW: better statusbar tips for multiple objects in selection
by bulia byak 22 Mar '06

22 Mar '06

For multiple selected objects, the statusbar now reports their types. For example, if 5 groups are selected, it displays 5 objects of type Group in layer LayerName. instead of just "5 objects selected" as before. If there are up to 3 types in the selection, they will be listed, for example: 5 objects of types Group, Path, Rectangle in layer LayerName. The order of the list will correspond to the order in which the objects were added to selection. If there are 4 or more types in selection, only the number of types is reported, for example: 5 objects of 4 types in layer LayerName. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 10

Objects not plugins
by Martin Owens 22 Mar '06

22 Mar '06

I was thinking of a way to manage my barcode plugin and was thinking that the way plugins currently run (i.e single process modifies document) is not how a barcode should be managed. it should be some kind of object plugin which allows you to modify the code and see the update in the bars, having the svg on the page will be a must, it would just have hooks so that if the plugin is there you can edit the object with some gui or what ever is required. Best Regards, Martin Owens -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

icon/swatch sizes
by bulia byak 22 Mar '06

22 Mar '06

Jon, Now I figured out why you're so reluctant to just make the swatches smaller as I proposed: because you used the GTK standard icon sizes for swatch sizes. I don't think this makes a lot of sense, honestly. A swatch is not an icon at all. However, I'll leave this up to you, but in any case I just want to reiterate the need for adding one or two smaller sizes that GTK does not have. You can even make them dependent on the existing sizes, for example by making them 75% and 50% of Gtk::ICON_SIZE_MENU. But we _really_ need them, both for icons and for swatches. The current "small" size of the swatches is NOT small by any stretch of the imagination. By the way, selecting the Huge size of the swatches in the bottom panel crashes Inkscape. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 4

round corners won't be resized on resizing a object
by Frank Wunderlich 21 Mar '06

21 Mar '06

Hi, i try to explain the behavior: i have 2 rects: 1 rect with round corners and 1 rect with normal corners inside the first one if i group this 2 shapes and try to make this group smaller, the shape is correctly resized (both rects), but not the corners of the round rect. the radius of the corners must be also adjusted... Greetings Frank

2 1

Clip path and mask UI patch - need guidance
by Joshua A. Andler 21 Mar '06

21 Mar '06

Knutux has made excellent progress with the clipPath/Mask UI patch (nice couple options in prefs to make it more robust too). However, there are two issues left that are related, but we couldn't figure out the best solution. Note that this is in comparison to both Xara & Illustrator as reference. 1) In Inkscape, currently you can not edit a clippath on canvas (presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem. 2) In Xara or Illustrator when you clip objects, they're "grouped" together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc. The more complicated of the two issues would be number 2. We kicked around a couple ideas, but neither seemed like the optimal solution so I figure I would ask for advice here. The ideas were having the clipping object in defs be a clone of a "normal" object on canvas. That original object can then be grouped and the clone/clippath would follow a move of the original, and it would theoretically also take care of the editing aspect too. And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas. Again, that object could then be grouped and would take care of the editing aspect too. To me, neither method seems clean and each would potentially introduce it's own set of issues. Bulia or Mental, do you have any suggestions? -Josh

5 19

Bug in the command line interface of Inkscape on Windows 32 platform ?
by Gilles Foucault 21 Mar '06

21 Mar '06

I run the Inkscape 0.43+devel, built Mar 20 2006 on Windows 32 platform I would like to export svg files via the command line interface of Inkscape : "C:\Program Files\Inkscape\inkscape.exe" --export-eps=out.eps in.svg But nothing happens, there is no error messages, and inkscape quit immediately. Could you help me with the command line usage in Win32 platform ? Thanks in advance, Best regards Gilles

2 1

LGM braindump
by Jon A. Cruz 21 Mar '06

21 Mar '06

Here's the first bit of braindump from LGM. (Please keep in mind that I typed this up while flying back to the States, and am not sure how jetlagged I was) -------------------------------- Overall, I think the whole get-together was an amazing success. Many different projects were represented, and a fair mix of end users and potential contributers were also in attendance. Although I would like to see more of the users and just curious there, enough were present to help give a good insight with fresh perspective. There were perhaps up to a couple hundred people in attendance, and it clearly seemed to be even a better turn out than Bryce or I had expected. We had four people with "Inkscape" on their badges, with a few extra people here and there like Cedric. The GIMP had a good presence, as did Scribus and even Xara. The atmosphere was one of the really good aspects of the whole meeting. Unlike many other conferences, this was not just a one-way dispersal of information. Though the presentations were similar, afterwards there was a lot of interaction between people with different groups, and even and users. Also, there seemed to not be any real conflicts or posturing, but rather a lot of genuine collaboration going on with win-win situations popping up all over. Probably the best illustration of this was with the SIOX presentation. Part of the presentation's purpose was to get the word out about the capabilities, and to try to spur more interest. That night one of the Blender guys got hooked, and by the next day had hacked together basic support for SIOX as a standard Blender effect. Each of the teams took advantage of the face-to-face time to have their own group meetings. For example, this was the first time that Craig had actually gotten to actually meet the other people on Scribus. But there was also a lot of communication with people of different groups, and most of the hitting dinner, etc, was completely inclusive. I know that some of the GIMP people expressed a little regret at not being able to get together with some of the non-GIMP people as much as they'd like, but this was only due to being able to get so much done in the various GIMP sit-downs going on. Even so, there was quite a lot that did get done, with various people in different groups each talking with others about all sorts of things. Xara had a booth outside the main amphitheater, and had three people showing what they've been doing. As you probably already know, they took the opportunity to release their source-code, and it seems like the delay 'till now was time well spent. I know that Carl Worth mentioned he downloaded it and not only did it build first try for him, but it actually ran too. The funny thing was that he didn't realize how much progress had been made since the initial demo, and that most of the tools are functional now. Their developers seemed like really good people, and very interested in the whole meeting and everything going on. I'd also met them on the bus from the airport the night before. So there was time spent talking with them on various Xara stuff, but then also a lot of time talking about all the other things going on, the stuff the other developers were talking about, and also some more questions on how best to fit in with the general open-source community. Charles from Xara made it down on Sunday, and after his presentation we had the opportunity to all sit down with him and discuss various Inkscape-Xara issues. The great news is that he honestly seems to "get it", and is working well to try to ensure the release of Xara has the best chance of being a win-win both for the business aspect and for the open-source community. By the end of things it was very clear that both Xara and Inkscape had their own focus, and each has their own reason for being around for quite some time. Probably the main issue for some will be the contributors agreement, however as everyone had time to drill down on things, and also others like Carl Worth from Cairo, it seemed to be a fair approach and my personal feeling is that it won't be a deal-killer for most. Speaking of Carl, he also had time to meet with Charles on his own, and they came away with quite a lot resolved, and a strong interest to see where things will go from here. Among other things, they were looking at various ways that Xara might get things to have Cairo to use their engine, so it will be *very* interesting to see how things progress in that area. One surprisingly inspiring presentation was Marti's talk on color management and littleCMS. Even though I'd been familiar with the concepts, and even had drilled down on littleCMS's API to figure out how to hook it into Inkscape, the talk suddenly made all the pieces fall into place. More importantly, it did so with several groups, and after the talk there was a lot started between us and Scribus in regards to managed color-flow, and we realized that together we actually almost at the point of having base things there and integrated. A lot of stuff they had been doing had gotten them close, and lot of the stuff I'd been doing had gotten us close. Then again, Marti confirmed that for basic support, only three functions of the littleCMS API are needed, so we might see that go in *very* soon. Additionally, we were able to use this to help hammer out with Scribus what direction they might want to take on SVG vs. EPS import, and whether things should be done in Inkscape or in Scribus, and to what degree. We probably ended up changing some minds and getting their focus back on enhancing SVG import, since we figured out some basic ways to support spot colors along with full ICC-profile targeted colors in SVG we will end up putting out. And, of course, Marti will be able to help advise us on the proper approach for a lot of the SVG/CSS color-profile details. One of the Inkscape-specific things that came up was someone from Slovenia being interested in animation support. We discussed quite a few things, including some general ideas of what Inkscape should and should not do in regards to UI and feature support for animation that Andy, Bryce, and I had just been tossing around the day before. This also leverages a bit more resources for enhancing the extensions mechanism, so look for new people to possibly show up soon. Speaking of extensions and plugins... there was a lot of general interest in this from many different people, with many different priorities. One of the more interesting exchanges on this was between myself and Craig from scribus. After some Scribus demos it had come up to me that what we were thinking of might be helpful for them also. Craig got really excited about the main idea of exposing a DOM for plugins, and some of the ways that they might go about doing that. Then we moved on to my ideas for abstracting UI for plugins by using XForms. He hadn't been aware of it before (and in fact was very light on XML background in general) but as I drilled in on more and more details he came to feel that it was a very good approach, and cold solve quite a few of the problems they are hitting up against right now, and even more in the future. He also mentioned this might be a concept to push over to the Xara guys (he'd been spending a fair bit of time with them also). One of the last things to go on was a CREATE BOF. It followed our Inkscape BOF, and ended up being very productive. We had lots of people from many projects, and got some good issues hammered out. Watch for more details on the CREATE mailing list, but a lot was about shared assets like palettes, brushes, etc., ways to share them, and how to make that work well (directories, daemons, things like font mangers, etc.) and not lagging. Another aspect was brought up from the drag-n-drop stuff I've been working on lately. Aside from knowing what to share, we also need to come up with how to put those things properly on the clipboard and for drag-n-drop. One point brought up was that it might be good to work details up and then leverage freedesktop.org to actually get MIME types registered. I'll follow up with more, like how Andy's demo went (great), Pippin's impressive stuff, and ReJon's great talk...

1 0

extension attributes documentation
by MenTaLguY 21 Mar '06

21 Mar '06

Hi all, In an effort to get the ball rolling for documenting Inkscape's extension attributes, I've populated a wiki entry with them here: http://wiki.inkscape.org/wiki/index.php/ExtensionAttributes I'd encourage volunteers to have a look and add documentation (just a brief description to start with) for any attributes that interest them. -mental

2 1

Clip path and mask UI patch - committed
by bulia byak 20 Mar '06

20 Mar '06

I have committed Andrius' patch and a couple of fixes of my own. So, clipping and masking are almost usable now. Use and abuse them, and report the results. So far the UI is limited to 4 command in the Object menu. Of course there are lots of issues, this is to be expected; note that while we appreciate your suggestions for how to make the UI better, for now my personal priority is to iron out all the basic behavior and rendering issues, so that at least the UI that we have works flawlessly. Several immediate issues are: - After you moved the clipped/masked object, unclipping/unmasking gives a wrong transform to the clippath/mask. - Mask display is buggy. If you don't see the masked object, try zooming in or out. - Upon unclpping/unmasking, the selection must hold the clipped object and the clippath/mask. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 2

Xara source released
by Joshua A. Andler 19 Mar '06

19 Mar '06

Subject line says it all... http://www.xaraxtreme.org/developers/sourcecode.html Thanks for the heads up John :) -Josh

6 6