March 2006 - Inkscape Devel - Inkscape Mailman

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