[Fwd: Invitation to Participate in Summer of Code 2006]
Hi All,
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Bryce
----- Forwarded message from Leslie Hawthorn <lhawthorn@...819...> -----
Date: Fri, 14 Apr 2006 12:43:36 -0700 From: Leslie Hawthorn <lhawthorn@...819...> To: bryce@...961... Reply-To: lhawthorn@...819... Subject: Invitation to Participate in Summer of Code 2006
Hello Bryce, *ahem* Sorry about that - we'd like to invite Inkscape to sign up! Google is launching the Summer of Code program again this year and we would like to invite Inkscape to sign up to participate. You can peruse our [1]Mentor FAQ and [2]Terms of Service on the [3]Summer of Code site for more information on this year's instance of the program. If you would like to participate in Summer of Code 2006, please email back with your [4]Google Account information and we will use this information to create the first administrator account on the SoC site for Inkscape and send you instructions for accessing and updating the site. We look forward to working with you again during this year's Summer of Code! Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc.
References
1. http://code.google.com/soc/mentorfaq.html 2. http://code.google.com/soc/tos.html 3. http://code.google.com/soc/ 4. https://www.google.com/accounts/ManageAccount
----- End forwarded message -----
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
I've got one I'd like to see:
http://gould.cx/ted/blog/Google_SoC_2
--Ted
On 4/14/06, ted@...11... <ted@...11...> wrote:
I've got one I'd like to see:
That is interesting, but can you provide a few examples of the specific effects you'd like to see?
I'm asking because all effects I can think of are either (1) to be implemented as SVG filters, which would apply equally to both embedded bitmaps and vector objects - for example, blur and its derivatives (shadows etc.); or (2) should really be internal Inkscape commands, also applicable equally to both bitmaps and vectors - for example, brightness/contrast, color adjustments, etc.
Doing these things via bitmaps may be acceptable as temporary workarounds (one of which I myself use, see doc/inkscape-shadow.README), but in the long run we should really concentrate on doing things the Right Way, which means the Vector Way. I know that, for example, Xara can use Photoshop plugins to process bitmaps, and it's good for eyecandy, but it never appealed to me because of its lack of genericity and overall clumsiness.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 4/14/06, ted@...11... <ted@...11...> wrote:
I've got one I'd like to see:
That is interesting, but can you provide a few examples of the specific effects you'd like to see?
If I understand correctly Ted's proposal, is not about effects on or as bitmaps, but simple editing: brightness, contrast, maybe crop.
I'm asking because all effects I can think of are either (1) to be implemented as SVG filters, which would apply equally to both embedded bitmaps and vector objects - for example, blur and its derivatives (shadows etc.); or (2) should really be internal Inkscape commands, also applicable equally to both bitmaps and vectors - for example, brightness/contrast, color adjustments, etc.
Doing these things via bitmaps may be acceptable as temporary workarounds (one of which I myself use, see doc/inkscape-shadow.README), but in the long run we should really concentrate on doing things the Right Way, which means the Vector Way. I know that, for example, Xara can use Photoshop plugins to process bitmaps, and it's good for eyecandy, but it never appealed to me because of its lack of genericity and overall clumsiness.
I agree, is awful to create effects as bitmaps and force embedding those bitmaps in the SVG file.
On 4/15/06, Nicu Buculei <nicu@...398...> wrote:
That is interesting, but can you provide a few examples of the specific effects you'd like to see?
If I understand correctly Ted's proposal, is not about effects on or as bitmaps, but simple editing: brightness, contrast, maybe crop.
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 4/15/06, Nicu Buculei <nicu@...398...> wrote:
That is interesting, but can you provide a few examples of the specific effects you'd like to see?
If I understand correctly Ted's proposal, is not about effects on or as bitmaps, but simple editing: brightness, contrast, maybe crop.
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
could that be done with icc profiles?
Aaron Spike
On 4/15/06, Aaron Spike <aaron@...749...> wrote:
could that be done with icc profiles?
I'd rather not do it this way. It might be possible to some extent, but the profiles have an entirely different purpose. It would be an extremely ugly and fragile hack.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Apr 15, 2006, at 9:12 AM, bulia byak wrote:
On 4/15/06, Aaron Spike <aaron@...749...> wrote:
could that be done with icc profiles?
I'd rather not do it this way. It might be possible to some extent, but the profiles have an entirely different purpose. It would be an extremely ugly and fragile hack.
Actually... if done properly it might not be that much of a hack. Section 6 of the tutorial, "On-the-fly profiles", covers what might be a useful mechanism. http://www.littlecms.com/tutorial.txt
On 4/15/06, Jon A. Cruz <jon@...18...> wrote:
Actually... if done properly it might not be that much of a hack. Section 6 of the tutorial, "On-the-fly profiles", covers what might be a useful mechanism. http://www.littlecms.com/tutorial.txt
"When all you have is a hammer, each problem looks like a nail..."
Jon, I'm not interested in color _correction_ here. I just want to do arbitrary wild things, such as select a complex drawing and desaturate it, or shift its hue from green to purple, or decrease contrast. See? I don't want no "profiles" (even temporary), I just want a simple and straightforward and permanent color change.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Apr 15, 2006, at 10:18 AM, bulia byak wrote:
Jon, I'm not interested in color _correction_ here. I just want to do arbitrary wild things, such as select a complex drawing and desaturate it, or shift its hue from green to purple, or decrease contrast. See? I don't want no "profiles" (even temporary), I just want a simple and straightforward and permanent color change.
But that's what is done.
LittleCMS lets you do much of that color changing, and if the source and destination buffer types are the same, you can even do it in-place.
In fact, that's exactly how I'm using it in sp-image.cpp
guchar* currLine = px; for ( int y = 0; y < imageheight; y++ ) { // Since the types are the same size, we can do the transformation in-place cmsDoTransform( transf, currLine, currLine, imagewidth ); currLine += rowstride; }
In your case "shift its hue from green to purple" could be seen as just a 'profile' describing the color operation you want. *If* a 'temporary profile' matches the concept of what you need to do, and *if* the coding is straightforward, then you see that actually changing a buffer permanently is quite simple and straightforward.
Also... if you only want to change a given RGB color, then you just use that as a tiny "buffer" and change a single color. I've done that in code also.
However... if you need to change the actual source values of fills and gradients and such of items, then using LittleCMS is the best solution if those happen to have icc-color() set on them (which is getting added now). So for that point, the question is whether or not you need to change the paint specifications on the SVG items themselves, rather than only tweaking placed bitmap images. If it's the former, then I think you'd *have* to use LittleCMS to do those changes, otherwise you'll have to recreate the entire sourcebase for dealing with colorspaces other than sRGB.
Just ponder what "desaturate" might mean for an SVG drawing targeting a specific CMYK printer.
On 4/15/06, Jon A. Cruz <jon@...18...> wrote:
LittleCMS lets you do much of that color changing, and if the source and destination buffer types are the same, you can even do it in-place.
But I'm not working on buffers - unless my selection happens to include a bitmap. Most of the time I need to transform single color points (fills, gradient stops etc).
cmsDoTransform( transf, currLine, currLine, imagewidth );
And even apart from that, I know the formulas I need, they are pretty simple. Why would I want the trouble of creating a profile that implements these formulas and then apply the profile, if I can just apply the formulas directly?
Also... if you only want to change a given RGB color, then you just use that as a tiny "buffer" and change a single color. I've done that in code also.
Why on Earth?
However... if you need to change the actual source values of fills and gradients and such of items, then using LittleCMS is the best solution if those happen to have icc-color() set on them (which is getting added now).
Why is this a best solution? I work in sRGB. I convert one sRGB color to another. I don't want to even think about any kinds of profiles applied on top of my drawing. Let them do their job (prepare my image for printing), and please let me do mine (be creative with colors). I don't see why these two areas need to ever touch each other.
So for that point, the question is whether or not you need to change the paint specifications on the SVG items themselves, rather than only tweaking placed bitmap images.
Of course what I need is universal vector color adjuster, as I explained in that thread. I'm not interested in bitmap-only tweaks.
If it's the former, then I think you'd *have* to use LittleCMS to do those changes, otherwise you'll have to recreate the entire sourcebase for dealing with colorspaces other than sRGB.
I still don't see why. Just as we don't need no CMS for adjusting the HSL of a single object in Fill&Stroke now, we won't need it for my adjuster either. The only difference between them is that one affects single object and the other multiple objects!
Just ponder what "desaturate" might mean for an SVG drawing targeting a specific CMYK printer.
I must admit I don't understand this kind of reasoning. "Desaturate" has a perfectly intuitive meaning for everyone, and I don't see how the fact that I'm going to print it on some kind of printer might ever affect that meaning. Desaturate is a _creative_ thing, see? I don't want no stinkin' CMYK interfering with my creative choices. If that particular printer can't print my design adequately, it's a problem with the printer, not with my image.
Of course I'm exaggerating a bit for the sake of argument. But you get the idea. I don't like the sound of a narrow-purpose, hardware-tied code, with its CMYKish mindset, encroaching onto the land of pure vector creativity. If SVG forces this kind of issues on us (instead of letting the operating system do all of this CMYK stuff at low level), let's use littleCMS, but only when we must.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 4/16/06, wrote:
Of course I'm exaggerating a bit for the sake of argument. But you get the idea. I don't like the sound of a narrow-purpose, hardware-tied code, with its CMYKish mindset, encroaching onto the land of pure vector creativity. If SVG forces this kind of issues on us (instead of letting the operating system do all of this CMYK stuff at low level), let's use littleCMS, but only when we must.
Additionally, I suggest having a look at VIGRA [1] for processing images
[1] http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
Alexandre
On Apr 15, 2006, at 3:02 PM, bulia byak wrote:
I must admit I don't understand this kind of reasoning. "Desaturate" has a perfectly intuitive meaning for everyone, and I don't see how the fact that I'm going to print it on some kind of printer might ever affect that meaning. Desaturate is a _creative_ thing, see? I don't want no stinkin' CMYK interfering with my creative choices. If that particular printer can't print my design adequately, it's a problem with the printer, not with my image.
No...
It's *very* much a problem with your image (counting a *.svg file as 'your image'). And it doesn't have to be CMYK output either, that's just the first example that comes to mind that people for professional reasons (aka in their day-to-day work) need.
I'll follow up with more details shortly, but it's *very* much an appropriate thing. As I mentioned, unless the code in Inkscape for tweaking colors takes more that just sRGB fallback values into account, it's going to be outdated when it first goes in.
The point is.. before 0.44 is out we'll have gradients and such switch from "fill: #ff00ff" to "fill: #ff00ff icc-color(target, 0.5, 0.0, 0.3, 1.0)" Ideally in that situation we'd do the main work in the more capable colorspace covered in the specified icc profile, and just update the sRGB fallback values as a side effect, not as the main driver.
That's the very minimum we'll need to support. We can go *way* above that and stay with SVG 1.1 even. And if we support some SVG 1.2 features (as is planned... and as ksvg happens to support at the moment), then we can do even more.
*However* before we chase rabbits and such, I'll need to get together detailed information, questions, and a few answers. Then I'll toss those out in a new thread.
On Apr 15, 2006, at 9:03 AM, Aaron Spike wrote:
bulia byak wrote:
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
could that be done with icc profiles?
Actually... that might be an interesting way to do it. Some of Little CMS's functions could be used to calculate and apply that.
On 4/15/06, Jon A. Cruz <jon@...18...> wrote:
Actually... that might be an interesting way to do it. Some of Little CMS's functions could be used to calculate and apply that.
Not via ICC profiles please! This has NOTHING to do with color profiles. It's a purely creative thing, e.g. "color me pink". Functions from littleCMS perhaps could be used if littleCMS can do HSL and not only CMYK, but even in that case I'd feel much safer writing the actual formulas myself - they are very simple.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 4/15/06, Aaron Spike wrote:
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
could that be done with icc profiles?
That should not be done with ICC profiles, ever. Sorry.
Alexandre
On Apr 15, 2006, at 2:16 PM, Alexandre Prokoudine wrote:
On 4/15/06, Aaron Spike wrote:
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
could that be done with icc profiles?
That should not be done with ICC profiles, ever. Sorry.
Perhaps not with "ICC Profiles" per se, but with CMS and Little CMS calls it should. In fact, I'm starting to see that there's no simple alternative that doesn't include lcms calls.
Am Samstag, den 15.04.2006, 11:57 -0400 schrieb bulia byak:
On 4/15/06, Nicu Buculei <nicu@...398...> wrote:
That is interesting, but can you provide a few examples of the specific effects you'd like to see?
If I understand correctly Ted's proposal, is not about effects on or as bitmaps, but simple editing: brightness, contrast, maybe crop.
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
You are right, it's really important to have as much as possible in vector. But there are a lot of things you still need for direkt manipulating bitmaps. Off cause I'm not interested in making Inkscap an bitmap editor, that's Gimps job. So what I'd like to see is an SOC project for implementing a verse plugin you will be able to edit your bitmaps in Gimp and see changes in real time in Inkscape. The nice think is, that there is all ready a Verse Gimp Plug-In (To edit textures e.g. in Blender.) and just the Inkscape part is missing.
Tobias
Some links: [1] http://wiki.blender.org/bin/view.pl//VerseIntegrationToBlender [2] http://verse.blender.org [3] http://purple.blender.org [4] http://www.uni-verse.org [5] http://www.quelsolaar.com [6] http://www.blender.org/modules/verse/
On Sat, 2006-04-15 at 11:57 -0400, bulia byak wrote:
We already have generic "crop" (clipping) which applies equally to bitmaps or vectors. Similarly, we must have a generic brightness/contrast/color adjuster which will work the same on ALL objects, including bitmaps. I have detailed plans on how to do it, so this may be another SOC project with me as a mentor.
It's worth noting that brightness, contrast, desaturation, and hue shifting (among many, many other things) can all be done via SVG filters.
See feColorMatrix and feComponentTransfer in particular.
-mental
On 4/15/06, MenTaLguY <mental@...3...> wrote:
It's worth noting that brightness, contrast, desaturation, and hue shifting (among many, many other things) can all be done via SVG filters.
Yes, and our Color Adjuster should provide the option of doing this via these filters (i.e. nondestructively) after we support the filters. But of course the simple direct color-changing functionality must be there as well.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
I'm asking because all effects I can think of are either (1) to be implemented as SVG filters, which would apply equally to both embedded bitmaps and vector objects - for example, blur and its derivatives (shadows etc.); or (2) should really be internal Inkscape commands, also applicable equally to both bitmaps and vectors - for example, brightness/contrast, color adjustments, etc.
Doing these things via bitmaps may be acceptable as temporary workarounds (one of which I myself use, see doc/inkscape-shadow.README), but in the long run we should really concentrate on doing things the Right Way, which means the Vector Way. I know that, for example, Xara can use Photoshop plugins to process bitmaps, and it's good for eyecandy, but it never appealed to me because of its lack of genericity and overall clumsiness.
I agree, is awful to create effects as bitmaps and force embedding those bitmaps in the SVG file.
I think it's not necessaty to embed the bitmap for generating the effect, we just need to save the parameter used for the creation of the effect into the svg file, to replicate them at rendering time.
On Fri, 2006-04-14 at 22:06 -0300, bulia byak wrote:
I'm asking because all effects I can think of are either (1) to be implemented as SVG filters, which would apply equally to both embedded bitmaps and vector objects - for example, blur and its derivatives (shadows etc.); or (2) should really be internal Inkscape commands, also applicable equally to both bitmaps and vectors - for example, brightness/contrast, color adjustments, etc.
Doing these things via bitmaps may be acceptable as temporary workarounds (one of which I myself use, see doc/inkscape-shadow.README), but in the long run we should really concentrate on doing things the Right Way, which means the Vector Way. I know that, for example, Xara can use Photoshop plugins to process bitmaps, and it's good for eyecandy, but it never appealed to me because of its lack of genericity and overall clumsiness.
Well, again, I think we're thinking of different things :)
I was thinking operations on bitmaps specifically. So, for some reason you have to import a bitmap into Inkscape (you've only got the data that way) and you want to perform some sort of operation on it. Yes, you could go into the GIMP and transform it, but for simple things it seems you shouldn't have to. That's all I'm thinking about, nothing more, nothing less. Sure, we should probably provide a way to change vectored objects into bitmaps and perform the same operations, but I wasn't targeting that with this proposal.
As for a list of operations, I was thinking all of them: ;)
http://www.imagemagick.org/Magick++/Image.html#Image%20Manipulation% 20Methods
--Ted
On Fri, 14 Apr 2006 ted@...11... wrote:
Date: Fri, 14 Apr 2006 19:46:35 -0500 (EST) From: ted@...11... To: Bryce Harrington <bryce@...961...> Cc: inkscape-devel@...6... Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
I've got one I'd like to see:
^^^ "Summer of Code: Adding bitmap capabilities to Inkscape" (using imagemagick)
See also the various requests for GIMP integration and Filters
sort of like this request but there are others too http://sourceforge.net/tracker/index.php?func=detail&aid=1457179&gro...
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Thanks everyone for such quick brainstorming! :-)
I've captured the suggestions so far on this page:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code
Please remember that these are going to really just be "seeds" to spark interest in a student, so it's not necessary to get too deep into them yet. We'll have plenty of time once the proposals start coming in to do fine tuning and ensure things go in the right directions.
Keep the ideas coming!
Bryce
On Sat, 15 Apr 2006, Bryce Harrington wrote:
Date: Sat, 15 Apr 2006 10:38:38 -0700 From: Bryce Harrington <bryce@...961...> To: ted@...11... Cc: inkscape-devel@...6... Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Thanks everyone for such quick brainstorming! :-)
I've captured the suggestions so far on this page:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code
Please remember that these are going to really just be "seeds" to spark interest in a student, so it's not necessary to get too deep into them yet. We'll have plenty of time once the proposals start coming in to do fine tuning and ensure things go in the right directions.
Keep the ideas coming!
I close serveral requests for Guides at non 90 degree angles, because what those cases really need is a perspective grid. There may be room to implement a variety of grid functionality, such as a Hex Grid and a Perspective grid.
Trawling through the various requests should turn up some tasks of the right size for the summer of code. There will always be more file formats people would like to see supported and they make for fairly well contained projects which can be achieved in paralell to Inkscape.
I wish I were a student again so I could enter the Summer of Code :( I'd settle for having a job which allowed me to work on Gnome though :)
On Sat, Apr 15, 2006 at 10:01:33PM +0100, Alan Horkan wrote:
On Sat, 15 Apr 2006, Bryce Harrington wrote:
I've captured the suggestions so far on this page:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_CodeKeep the ideas coming!
I close serveral requests for Guides at non 90 degree angles, because what those cases really need is a perspective grid. There may be room to implement a variety of grid functionality, such as a Hex Grid and a Perspective grid.
Oh yeah, Nathan had put some thought into that too, years ago. That's a good suggestion.
Trawling through the various requests should turn up some tasks of the right size for the summer of code. There will always be more file formats people would like to see supported and they make for fairly well contained projects which can be achieved in paralell to Inkscape.
Yup. We had a file format converter for one of last year's projects. It's definitely true there's no end of these needed. I suspect that creating a good, usable converter is more than a summer's worth of effort, and unfortunately they don't seem to be things that others would pick up and continue work on, so we might want to think about how we would narrow the scope of the project to something that's doable but still produces useful results. For example, sometimes just nutting out the original format (esp. proprietary formats) can be a project in and of itself.
Anyway, both ideas are added. :-)
Bryce
On 4/16/06, Bryce Harrington wrote:
Yup. We had a file format converter for one of last year's projects. It's definitely true there's no end of these needed. I suspect that creating a good, usable converter is more than a summer's worth of effort, and unfortunately they don't seem to be things that others would pick up and continue work on, so we might want to think about how we would narrow the scope of the project to something that's doable but still produces useful results. For example, sometimes just nutting out the original format (esp. proprietary formats) can be a project in and of itself.
By the way, there was some discussion at LGM on reusing Scribus's EPS import lib in Inkscape. Could that possibly be a SoC project?
Alexandre
On Sun, Apr 16, 2006 at 01:18:38AM +0400, Alexandre Prokoudine wrote:
On 4/16/06, Bryce Harrington wrote:
Yup. We had a file format converter for one of last year's projects. It's definitely true there's no end of these needed. I suspect that creating a good, usable converter is more than a summer's worth of effort, and unfortunately they don't seem to be things that others would pick up and continue work on, so we might want to think about how we would narrow the scope of the project to something that's doable but still produces useful results. For example, sometimes just nutting out the original format (esp. proprietary formats) can be a project in and of itself.
By the way, there was some discussion at LGM on reusing Scribus's EPS import lib in Inkscape. Could that possibly be a SoC project?
Yep, this'd be a great project. We'd need to touch base with Scribus again on this, but it'd be a wonderful feature.
I wonder if it'd be feasible/appropriate to make that lib work with UberConverter?
Bryce
On 4/16/06, Alan Horkan wrote:
I close serveral requests for Guides at non 90 degree angles, because what those cases really need is a perspective grid. There may be room to implement a variety of grid functionality, such as a Hex Grid and a Perspective grid.
I don't see how grids can be related to guides, but as of current SVN anyone can draw a line and snap objects to it. No guides required.
Alexandre
On 15 Apr 2006, at 19:38 , Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Thanks everyone for such quick brainstorming! :-)
I've captured the suggestions so far on this page:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code
[...]
Keep the ideas coming!
Hi all,
this was a long discussion to follow! here are things I would very much like to see, as a user. I do not know to which extent they could be SoC projects.
Improving "Inkscape I/O": this is in fact several "small" (or not) things. First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again. I don't know if it is easy or even possible but embedding fonts into the document would be great too. I was perfectly happy with the link behavior but got to work with people who didn't understand it... and I changed my mind ;-) This would call for a way to edit embedded bitmaps but this was already mentioned (Verse plugin to link to Gimp or direct editing). In parallel a rework of the import/export/save as dialogs could be achieved with: - link or embed in import (if possible with bitmap _and_ vector, so that it's possible to link to SVG files too, click on the linked file and have it open in a new instance of inkscape) - restrict to selection or to any part of the drawing in export with bitmap _and_ vector. For vector this look like just clipping the SVG to the selection and export it so it seems straightforward now that clipping exists. then all non conserving vector file formats (EPS, POV, TEX etc.) could be moved to the export dialog - the save as dialog keeps only inkjar/zip, inkscape svg and inkscape svgz (and plain svg and compressed plain svgz?)
Improving the color panel: This would require to fix some UI things: - "small" size does not look like small when first opening inkscape, you have to switch to an other size and then witch back to small to have them small - the rolling menu on the right of the panel is small when first opening inkscape but as soon as something is changed inside it, it becomes larger. while becoming larger it eats a lot of space so it might not be the best choice for a menu. right click? there was some discussion about it earlier on the mailing list. - add the possibility to resize the panel and/or have it to the right of the desktop Then adding some functionality: - save the state of the panel (size, position, size of the color swatches, which palette was selected) on a per document basis - add a way to build some custom palettes, which would be stored as a (xml?) file. The intend of this is to have to possibility to post them somewhere on the web site and exchange color palettes between users. So this requires also a simple interface to add a downloaded palette to the menu (like a Add palette... menu item). [Side note: this could be extended to effects too, when there will be too many of them to include them all in the menu and this would add a nice community aspect to the website ;-)] - add a style palette, renewed on a per document basis where the user can store fill, stroke and font properties of objects in the drawing by dragging and dropping them on the panel. It would also be nice to have the possibility to exchange those and to import styles from another document into a new one. I think there is a large potential for those in a company or any communication agency which works with some specific templates (in terms of colors, fonts...) for each product. - maybe add a "current styles" palette which is dynamically filled with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
Improving the Text Tool: I use text and flowed text a lot and these are things that could be improved IMHO: - flowed text does not respect the default style of the text tool - when flowing a text which already contains line breaks, the line breaks are not conserved and are converted to spaces. It would be better to conserve them. - when the style selected in the the Text and Font dialog is applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them. A general way to address this would be to rework the Text and Font dialog (and I think it was planned anyway): - It could include some kind of "story editor" a la Scribus instead of the Text tab. Then text editing and formatting could be done there avoiding the style erase mentioned above. - I don't know a font manager on linux but I guess there should be at least one. It would be nice to have some font collections before the font family selector, in order to narrow the search. I have over 300 fonts on my system (and I guess this is not much compared to some graphic designer) and it is already difficult to find the one I want in the Text and Font dialog. BTW: the Font family list is not searchable with the keyboard while every other GTK list I have seen is.
These are my 2 cents. Thank you for reading all this ;-)
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
- add a way to build some custom palettes, which would be stored as a
(xml?) file. The intend of this is to have to possibility to post them somewhere on the web site and exchange color palettes between users. So this requires also a simple interface to add a downloaded palette to the menu (like a Add palette... menu item).
You can do this right now: - the color palettes are defined in a simple text file, the same format used also by GIMP (very important!). the structure is so simple, that making a program to edit them is trivial; - you can already post those files (*.gpl) on a website, all an user needs to do is to download the file in ~/inkscape/palettes/ and restart Inkscape
On Tue, 18 Apr 2006, jiho wrote:
On 15 Apr 2006, at 19:38 , Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Projects really need to be self contained tasks (both in time it would take to implment them and development scope) which can easily be carried out in parallel as much as possible and not be any great dissappointment if things dont work out.
Hi all,
Improving "Inkscape I/O": this is in fact several "small" (or not) things.
First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again.
I'm sure someone will disagree and have some good technical reasons for it but Inkscape SVG is different by necessity from Plain SVG and maybe more consideration should be given to this idea.
The inkjar format is intended to be largely compatible with OpenDocument to take advantage of existing tools. Dont understimate the network effects of the OpenDocument standard. There is some question of how much of OpenDocument to use but I think it should be possible to unzip an inkjar and have a working SVG. Perhaps careful use of xlinks will allow the incompatible bits to be put elsewhere in the archive, allowing the SVG to be relatively clean and have everything degrade gracefully as needed.
I guess the developers will feel this out as they go and strike the right balance but I do not see how it could be a Summer of Code project.
don't know if it is easy or even possible but embedding fonts into the document would be great too.
SVG Fonts will in effect give you this. The font licensing issues are sticky but that is a user problem more than an implementation issue. If the developers have a clear idea of what is wanted this would probably make a good project (in my humble opinion).
Improving the Text Tool:
Improving the color panel:
Not sure if the collection of smaller issues you mention can be made into a single workable project.
- maybe add a "current styles" palette which is dynamically filled
with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
Something like this to managed Predefined Styles (i.e. <defs>) will be needed eventually. (Incidentally how do we unabbreviate <defs> to Defines without making it any less confusing to users when they encounter this implementation detail?)
On second thoughts (having read other replies) I think a standalone palette editor (implemented in python maybe?) could be an excellent complementary project to Inkscape. I recall a mail to this list about a very advanced colour editor tool. Last year there was a clipart browser was developed complementary to the Openclipart project. Having smaller specialised tools orbiting inkscape alleviates the pressure to do absolutely everything inside Inkscape.
These are my 2 cents. Thank you for reading all this ;-)
With all these great suggestions I hope this year of Summer of Code will be even better for Inkscape. Hopefully inkscape will get a similar allocation of funds despite the added interest in competition.
On Apr 18, 2006, at 5:51 AM, jiho wrote:
Improving "Inkscape I/O": this is in fact several "small" (or not) things. First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again. I don't know if it is easy or even possible but embedding fonts into the document would be great too. I was perfectly happy with the link behavior but got to work with people who didn't understand it... and I changed my mind ;-) This would call for a way to edit embedded bitmaps but this was already mentioned (Verse plugin to link to Gimp or direct editing). In parallel a rework of the import/ export/save as dialogs could be achieved with:
- link or embed in import (if possible with bitmap _and_ vector, so
that it's possible to link to SVG files too, click on the linked file and have it open in a new instance of inkscape)
- restrict to selection or to any part of the drawing in export
with bitmap _and_ vector. For vector this look like just clipping the SVG to the selection and export it so it seems straightforward now that clipping exists. then all non conserving vector file formats (EPS, POV, TEX etc.) could be moved to the export dialog
- the save as dialog keeps only inkjar/zip, inkscape svg and
inkscape svgz (and plain svg and compressed plain svgz?)
There's one main caveat I would point out in regards to save-all-in- one behavior. The main argument in favor of it is "Users have complained when they move their SVG file around and the images break"
However, I'd break it down to be "Users are expecting A and instead getting B" those users complain "Users are expecting B and are getting B" those users are silent as things work the way they expect them to.
So... if we switch our behavior from B to A, then those first users will be quiet, but the second group will start to complain.
The solution here is probably not to just toss things one way or the other, but instead to manage user expectations. Some base UI and workflow tweaks to make it clear to users what exactly is going on. And the way things are looking to me, a subtle overall approach might be best
Improving the color panel: This would require to fix some UI things:
- "small" size does not look like small when first opening
inkscape, you have to switch to an other size and then witch back to small to have them small
- the rolling menu on the right of the panel is small when first
opening inkscape but as soon as something is changed inside it, it becomes larger. while becoming larger it eats a lot of space so it might not be the best choice for a menu. right click? there was some discussion about it earlier on the mailing list.
These have been addressed in SVN already.
- add the possibility to resize the panel and/or have it to the
right of the desktop Then adding some functionality:
- save the state of the panel (size, position, size of the color
swatches, which palette was selected) on a per document basis
- add a way to build some custom palettes, which would be stored as
a (xml?) file. The intend of this is to have to possibility to post them somewhere on the web site and exchange color palettes between users. So this requires also a simple interface to add a downloaded palette to the menu (like a Add palette... menu item). [Side note: this could be extended to effects too, when there will be too many of them to include them all in the menu and this would add a nice community aspect to the website ;-)]
- add a style palette, renewed on a per document basis where the
user can store fill, stroke and font properties of objects in the drawing by dragging and dropping them on the panel. It would also be nice to have the possibility to exchange those and to import styles from another document into a new one. I think there is a large potential for those in a company or any communication agency which works with some specific templates (in terms of colors, fonts...) for each product.
- maybe add a "current styles" palette which is dynamically filled
with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
All planned and very doable. To get the last few we'll need good non- RGB color support and a few other things in, but this might be a good SoC project.
Improving the Text Tool: I use text and flowed text a lot and these are things that could be improved IMHO:
- flowed text does not respect the default style of the text tool
- when flowing a text which already contains line breaks, the line
breaks are not conserved and are converted to spaces. It would be better to conserve them.
- when the style selected in the the Text and Font dialog is
applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them. A general way to address this would be to rework the Text and Font dialog (and I think it was planned anyway):
- It could include some kind of "story editor" a la Scribus instead
of the Text tab. Then text editing and formatting could be done there avoiding the style erase mentioned above.
- I don't know a font manager on linux but I guess there should be
at least one. It would be nice to have some font collections before the font family selector, in order to narrow the search. I have over 300 fonts on my system (and I guess this is not much compared to some graphic designer) and it is already difficult to find the one I want in the Text and Font dialog. BTW: the Font family list is not searchable with the keyboard while every other GTK list I have seen is.
Much of that seems to be a good-sized chunk that would work for SoC. Some of the style re-work could be cross-leveraged with the palette stuff. And actually, the palette classes themselves are not tied to colors, and are intended to be used for styles, patterns, layers, etc.
thanks to everybody for the interest in my suggestions. here are my answers, suggestion by suggestion.
Improving "Inkscape I/O":
On 19 Apr 2006, at 02:30 , Jon A. Cruz wrote:
this is in fact several "small" (or not) things. First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again. [...]
There's one main caveat I would point out in regards to save-all-in- one behavior. The main argument in favor of it is "Users have complained when they move their SVG file around and the images break"
However, I'd break it down to be "Users are expecting A and instead getting B" those users complain "Users are expecting B and are getting B" those users are silent as things work the way they expect them to.
So... if we switch our behavior from B to A, then those first users will be quiet, but the second group will start to complain.
my opinion is that users in group 1 and 2 are not the same. basically: - the new comer/unexperienced user expects everything to be embedded and things to work even if he moves things around. this is why I thought that the default should be a self contained file format. - the more experienced user might like the flexibility and smaller disk usage provided by the link behavior. he will be able to save his work as inkscape svg and to click a "link" button in the import dialog. IMHO the problem is not which behavior is the best because they have different intent but which should be the default. and I think that save-all-in-one should be, hence my suggestion. I thought that the two attempts to implement this behavior were pretty advanced and that technical issues (which I am not able to judge) were sorted out. From Alan answer:
From: Alan Horkan <horkana@...44...> The inkjar format is intended to be largely compatible with OpenDocument to take advantage of existing tools. Dont understimate the network effects of the OpenDocument standard. There is some question of how much of OpenDocument to use but I think it should be possible to unzip an inkjar and have a working SVG. Perhaps careful use of xlinks will allow the incompatible bits to be put elsewhere in the archive, allowing the SVG to be relatively clean and have everything degrade gracefully as needed.
I guess the developers will feel this out as they go and strike the right balance but I do not see how it could be a Summer of Code project.
it seems that this still needs some work and some delicate decisions from adequate people (which I am obviously not) so indeed this might not be suited for the SoC.
The solution here is probably not to just toss things one way or the other, but instead to manage user expectations. Some base UI and workflow tweaks to make it clear to users what exactly is going on. And the way things are looking to me, a subtle overall approach might be best
subtle, delicate... all this seems to be complicated! anyway, I like current behavior, it is just more complicated to explain to other people in my lab in order to spread Inkscape a bit more widely.
From: Alan Horkan <horkana@...44...>
don't know if it is easy or even possible but embedding fonts into the document would be great too.
SVG Fonts will in effect give you this. The font licensing issues are sticky but that is a user problem more than an implementation issue. If the developers have a clear idea of what is wanted this would probably make a good project (in my humble opinion).
I recently ran into some font issues, hence my suggestion. it would be great it this is possible.
Improving the color panel: This would require to fix some UI things:
- "small" size does not look like small when first opening
inkscape, you have to switch to an other size and then witch back to small to have them small
- the rolling menu on the right of the panel is small when first
opening inkscape but as soon as something is changed inside it, it becomes larger. while becoming larger it eats a lot of space so it might not be the best choice for a menu. right click? there was some discussion about it earlier on the mailing list.
These have been addressed in SVN already.
cool!
From: Alan Horkan <horkana@...44...> Projects really need to be self contained tasks (both in time it would take to implment them and development scope) which can easily be carried out in parallel as much as possible and not be any great dissappointment if things dont work out.
[...]
Not sure if the collection of smaller issues you mention can be made into a single workable project.
it was intended as some preliminary work for the rest to be doable... but it appears that the problems vanished :-)
- add the possibility to resize the panel and/or have it to the
right of the desktop Then adding some functionality: [some new palletes suggested]
All planned and very doable. To get the last few we'll need good non-RGB color support and a few other things in, but this might be a good SoC project.
From: Alan Horkan <horkana@...44...> On second thoughts (having read other replies) I think a standalone palette editor (implemented in python maybe?) could be an excellent complementary project to Inkscape. I recall a mail to this list about a very advanced colour editor tool. Last year there was a clipart browser was developed complementary to the Openclipart project. Having smaller specialised tools orbiting inkscape alleviates the pressure to do absolutely everything inside Inkscape.
Given Nicu's answer:
From: Nicu Buculei <nicu@...398...> You can do this right now:
- the color palettes are defined in a simple text file, the same
format used also by GIMP (very important!). the structure is so simple, that making a program to edit them is trivial;
- you can already post those files (*.gpl) on a website, all an
user needs to do is to download the file in ~/inkscape/palettes/ and restart Inkscape
I tried to generate some new palettes with the Gimp and it is fairly easy. Nevertheless, colors still cannot be moved around. The answer to this is probably, as Alan mentioned, some third party color management software. It would benefit Inkscape as well as Gimp and unify the appearance of color management between the two. But I guess I am dreaming of a very large project that will probably be out of the scope of the SoC once more ;-)
Improving the Text Tool: I use text and flowed text a lot and these are things that could be improved IMHO:
- flowed text does not respect the default style of the text tool
- when flowing a text which already contains line breaks, the line
breaks are not conserved and are converted to spaces. It would be better to conserve them.
- when the style selected in the the Text and Font dialog is
applied it erases any other style applied to some part of the text (like italics on some words, bold on others...), it would also be better to keep them. A general way to address this would be to rework the Text and Font dialog (and I think it was planned anyway):
- It could include some kind of "story editor" a la Scribus
instead of the Text tab. Then text editing and formatting could be done there avoiding the style erase mentioned above.
- I don't know a font manager on linux but I guess there should be
at least one. It would be nice to have some font collections before the font family selector, in order to narrow the search. I have over 300 fonts on my system (and I guess this is not much compared to some graphic designer) and it is already difficult to find the one I want in the Text and Font dialog. BTW: the Font family list is not searchable with the keyboard while every other GTK list I have seen is.
Much of that seems to be a good-sized chunk that would work for SoC. Some of the style re-work could be cross-leveraged with the palette stuff. And actually, the palette classes themselves are not tied to colors, and are intended to be used for styles, patterns, layers, etc.
OK, I got at least one right then ;-)
thank you again for all the suggestions and what will likely become an even greater software.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
Begin forwarded message:
From: Alan Horkan <horkana@...44...> Date: 19 April 2006 01:39:19 CEDT Cc: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On Tue, 18 Apr 2006, jiho wrote:
On 15 Apr 2006, at 19:38 , Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Projects really need to be self contained tasks (both in time it would take to implment them and development scope) which can easily be carried out in parallel as much as possible and not be any great dissappointment if things dont work out.
Hi all,
Improving "Inkscape I/O": this is in fact several "small" (or not) things.
First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again.
I'm sure someone will disagree and have some good technical reasons for it but Inkscape SVG is different by necessity from Plain SVG and maybe more consideration should be given to this idea.
The inkjar format is intended to be largely compatible with OpenDocument to take advantage of existing tools. Dont understimate the network effects of the OpenDocument standard. There is some question of how much of OpenDocument to use but I think it should be possible to unzip an inkjar and have a working SVG. Perhaps careful use of xlinks will allow the incompatible bits to be put elsewhere in the archive, allowing the SVG to be relatively clean and have everything degrade gracefully as needed.
I guess the developers will feel this out as they go and strike the right balance but I do not see how it could be a Summer of Code project.
Improving the Text Tool:
Improving the color panel:
Not sure if the collection of smaller issues you mention can be made into a single workable project.
- maybe add a "current styles" palette which is dynamically filled
with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
Something like this to managed Predefined Styles (i.e. <defs>) will be needed eventually. (Incidentally how do we unabbreviate <defs> to Defines without making it any less confusing to users when they encounter this implementation detail?)
On second thoughts (having read other replies) I think a standalone palette editor (implemented in python maybe?) could be an excellent complementary project to Inkscape. I recall a mail to this list about a very advanced colour editor tool. Last year there was a clipart browser was developed complementary to the Openclipart project. Having smaller specialised tools orbiting inkscape alleviates the pressure to do absolutely everything inside Inkscape.
These are my 2 cents. Thank you for reading all this ;-)
With all these great suggestions I hope this year of Summer of Code will be even better for Inkscape. Hopefully inkscape will get a similar allocation of funds despite the added interest in competition.
-- Alan H.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Begin forwarded message:
From: Alan Horkan <horkana@...44...> Date: 19 April 2006 01:39:19 CEDT Cc: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On Tue, 18 Apr 2006, jiho wrote:
On 15 Apr 2006, at 19:38 , Bryce Harrington wrote:
On Fri, Apr 14, 2006 at 07:46:35PM -0500, ted@...11... wrote:
On Fri, 14 Apr 2006, Bryce Harrington wrote:
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Projects really need to be self contained tasks (both in time it would take to implment them and development scope) which can easily be carried out in parallel as much as possible and not be any great dissappointment if things dont work out.
Hi all,
Improving "Inkscape I/O": this is in fact several "small" (or not) things.
First would be to finalize the inkjar/zip file formats and use this by default so that inkscape new comers are not bothered with the red cross again.
I'm sure someone will disagree and have some good technical reasons for it but Inkscape SVG is different by necessity from Plain SVG and maybe more consideration should be given to this idea.
The inkjar format is intended to be largely compatible with OpenDocument to take advantage of existing tools. Dont understimate the network effects of the OpenDocument standard. There is some question of how much of OpenDocument to use but I think it should be possible to unzip an inkjar and have a working SVG. Perhaps careful use of xlinks will allow the incompatible bits to be put elsewhere in the archive, allowing the SVG to be relatively clean and have everything degrade gracefully as needed.
I guess the developers will feel this out as they go and strike the right balance but I do not see how it could be a Summer of Code project.
don't know if it is easy or even possible but embedding fonts into the document would be great too.
SVG Fonts will in effect give you this. The font licensing issues are sticky but that is a user problem more than an implementation issue. If the developers have a clear idea of what is wanted this would probably make a good project (in my humble opinion).
Improving the Text Tool:
Improving the color panel:
Not sure if the collection of smaller issues you mention can be made into a single workable project.
- maybe add a "current styles" palette which is dynamically filled
with all styles of objects in the document. OmniGraffle does this and I find this occasionally useful. But it might be memory/CPU hungry.
Something like this to managed Predefined Styles (i.e. <defs>) will be needed eventually. (Incidentally how do we unabbreviate <defs> to Defines without making it any less confusing to users when they encounter this implementation detail?)
On second thoughts (having read other replies) I think a standalone palette editor (implemented in python maybe?) could be an excellent complementary project to Inkscape. I recall a mail to this list about a very advanced colour editor tool. Last year there was a clipart browser was developed complementary to the Openclipart project. Having smaller specialised tools orbiting inkscape alleviates the pressure to do absolutely everything inside Inkscape.
These are my 2 cents. Thank you for reading all this ;-)
With all these great suggestions I hope this year of Summer of Code will be even better for Inkscape. Hopefully inkscape will get a similar allocation of funds despite the added interest in competition.
-- Alan H.
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Begin forwarded message:
From: Nicu Buculei <nicu@...398...> Date: 18 April 2006 16:06:10 CEDT To: List Devel Inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
jiho wrote:
- add a way to build some custom palettes, which would be stored
as a (xml?) file. The intend of this is to have to possibility to post them somewhere on the web site and exchange color palettes between users. So this requires also a simple interface to add a downloaded palette to the menu (like a Add palette... menu item).
You can do this right now:
- the color palettes are defined in a simple text file, the same
format used also by GIMP (very important!). the structure is so simple, that making a program to edit them is trivial;
- you can already post those files (*.gpl) on a website, all an
user needs to do is to download the file in ~/inkscape/palettes/ and restart Inkscape
-- nicu
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, 19 Apr 2006, jiho wrote:
I tried to generate some new palettes with the Gimp and it is fairly easy. Nevertheless, colors still cannot be moved around. The answer to this is probably, as Alan mentioned, some third party color management software. It would benefit Inkscape as well as Gimp and
Or you could open the GPL file in any good spreadsheet. The palette file it is a list of Tab Seperated Values (TSV).
-- Alan H.
On 4/19/06, Alan Horkan wrote:
Or you could open the GPL file in any good spreadsheet. The palette file it is a list of Tab Seperated Values (TSV).
Yeah, really! Why on Earth using excellent GNOME Colorscheme [1] and the like, if we have all power of Gnumeric in our hands? :-D
[1] http://home.gna.org/colorscheme/
Alexandre
On Wed, 19 Apr 2006, Alexandre Prokoudine wrote:
Date: Wed, 19 Apr 2006 19:30:31 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devs ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On 4/19/06, Alan Horkan wrote:
Or you could open the GPL file in any good spreadsheet. The palette file it is a list of Tab Seperated Values (TSV).
Yeah, really! Why on Earth using excellent GNOME Colorscheme [1] and the like, if we have all power of Gnumeric in our hands? :-D
Forget that, why not use the full power of Emacs instead!
But seriously what kind of application calls itself a Gnome application and then has a "Favorites" menu. :(
(If he didn't want to use the label bookmarks then palette might have been a more appropriate choice. Anything to avoid having to have different spellings for American and English.)
Good idea though, I'm glad someone gave it a try so there isn't much point suggesting someone do it again as a Summer of Cod project unless someone has some great ideas about how it might be made into an optional plugin for those who want every palette editing feature imaginable.
Does it export GPL palette files? Read the page, it does, nevermind. Be cool if it could also export the XML palettes used by OpenOffice.
Seems like a project that Create or Openoffice or Inkscape could promote as a complementary tool.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 4/19/06, Alan Horkan wrote:
But seriously what kind of application calls itself a Gnome application and then has a "Favorites" menu. :(
(If he didn't want to use the label bookmarks then palette might have been a more appropriate choice. Anything to avoid having to have different spellings for American and English.)
For heaven's sake, there are en_US/en_GB locales and gettext :)
Good idea though, I'm glad someone gave it a try so there isn't much point suggesting someone do it again as a Summer of Cod project unless someone has some great ideas about how it might be made into an optional plugin for those who want every palette editing feature imaginable.
IIRC, Jon Cruz worked with its developers to make drag'n'drop between Colorscheme and Inkscape possible.
Seems like a project that Create or Openoffice or Inkscape could promote as a complementary tool.
Sure :)
Alexandre
On Wed, 19 Apr 2006, Alexandre Prokoudine wrote:
Date: Wed, 19 Apr 2006 21:36:08 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devs ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [Fwd: Invitation to Participate in Summer of Code 2006]
On 4/19/06, Alan Horkan wrote:
But seriously what kind of application calls itself a Gnome application and then has a "Favorites" menu. :(
(If he didn't want to use the label bookmarks then palette might have been a more appropriate choice. Anything to avoid having to have different spellings for American and English.)
For heaven's sake, there are en_US/en_GB locales and gettext :)
Evil, an abomination. Or at the very least a shocking waste of time. If developers were just a little more careful about their word choice the differences should be kept to a minimum. I dont mind colour/color but the excessive use of -ize and casual use of "bogus" slang does stick out as sloppy work. Given the number of people who end up using English as a second langauge or because no translations are available in their language it becomes even more important that the English used in software is as clear and culturally unambigious as possible. it is a langauge thing, either you understand how unpleasant it is to have a "foreign" language foisted on your or you dont.
To make matters worse my locale is usually set to en_IE which barring an act of gross stupidity is 100% the same as en_GB. Unfortunately the infrastructure such as it is will fall back and show American spellings (for en) rather then en_GB.
How did we get so far offtopic?
Good idea though, I'm glad someone gave it a try so there isn't much point suggesting someone do it again as a Summer of Cod project unless someone has some great ideas about how it might be made into an optional plugin for those who want every palette editing feature imaginable.
IIRC, Jon Cruz worked with its developers to make drag'n'drop between Colorscheme and Inkscape possible.
sweet.
Seems like a project that Create or Openoffice or Inkscape could promote as a complementary tool.
Sure :)
Sincerely
Alan Horkan
On Apr 19, 2006, at 10:31 AM, Alan Horkan wrote:
Seems like a project that Create or Openoffice or Inkscape could promote as a complementary tool.
I've been in contact with the main author, and have been looking at ways to interoperate.
One thing is a common format. The base .gpl palette files are one way, but not sufficient for our needs as ICC support goes in. Another is the need for a scheme within there, etc.
Also, nice drag-n-drop compatibility is another way to share.
Overall, I think that as soon as we get things with reasonable workflow, GNOME Colorscheme can pick up supporting them.
On 19 Apr 2006, at 17:19 , Alan Horkan wrote:
On Wed, 19 Apr 2006, jiho wrote:
I tried to generate some new palettes with the Gimp and it is fairly easy. Nevertheless, colors still cannot be moved around. The answer to this is probably, as Alan mentioned, some third party color management software. It would benefit Inkscape as well as Gimp and
Or you could open the GPL file in any good spreadsheet. The palette file it is a list of Tab Seperated Values (TSV).
Yes of course, I could also copy paste them directly in the text file to reorder them, but from a creative point of view it is probably easier and more appropriate to actually drag a square of color rather than a piece of text. Well then, this is probably just a question of easiness (some might call it eye candy interface) as the functionality is there but IMHO a good interface make people discover the functionality, otherwise most of them probably won't use it. In addition it might fit in your requirements for a SoC project: its development can be parallel to the rest and there is not too much disappointment if it fails (because the functionality is still there). these were just suggestions anyway. As I wrote earlier it seems that there is a lot of potential functionalities already inside Inkscape that are just not exposed through some interface... this should be a SoC project: "Exposing hidden functionalities in a leading vector editing software" ;-)
thanks for the reply.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On Wed, 19 Apr 2006, jiho wrote:
On 19 Apr 2006, at 17:19 , Alan Horkan wrote:
On Wed, 19 Apr 2006, jiho wrote:
I tried to generate some new palettes with the Gimp and it is fairly easy. Nevertheless, colors still cannot be moved around. The answer to this is probably, as Alan mentioned, some third party color management software. It would benefit Inkscape as well as Gimp and
Or you could open the GPL file in any good spreadsheet. The palette file it is a list of Tab Seperated Values (TSV).
Yes of course, I could also copy paste them directly in the text file to reorder them, but from a creative point of view it is probably easier and more appropriate to actually drag a square of color rather than a piece of text.
I was thinking in terms of a spreadsheet being very useful for sorting the list into a regular order. Sorry if i was pointing out the obvious.
On 4/19/06, jiho <jo.irisson@...400...> wrote:
my opinion is that users in group 1 and 2 are not the same. basically:
- the new comer/unexperienced user expects everything to be embedded
and things to work even if he moves things around. this is why I thought that the default should be a self contained file format.
My opinion is that a new default format is way too much of a change for this. What is needed is simply a checkbox "Embed into document" on Import dialog, on by default. That will provide the self-containedness for most novice users. Changing default from plain text SVG to some zipped non-standardized monster sounds like a bad idea.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 19 Apr 2006, at 18:03 , bulia byak wrote:
On 4/19/06, jiho <jo.irisson@...400...> wrote:
my opinion is that users in group 1 and 2 are not the same. basically:
- the new comer/unexperienced user expects everything to be embedded
and things to work even if he moves things around. this is why I thought that the default should be a self contained file format.
My opinion is that a new default format is way too much of a change for this. What is needed is simply a checkbox "Embed into document" on Import dialog, on by default. That will provide the self-containedness for most novice users. Changing default from plain text SVG to some zipped non-standardized monster sounds like a bad idea.
well I mentioned the self contained format because, from what I recall of past discussions on the subject, embedding bitmaps directly into a SVG file seemed to lead to very bad performance. If it is not the case, then of course keeping the default format a SVG file will be great. the discussion was "linked vs embeded": http://sourceforge.net/mailarchive/message.php?msg_id=14552578
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On 4/19/06, jiho <jo.irisson@...400...> wrote:
well I mentioned the self contained format because, from what I recall of past discussions on the subject, embedding bitmaps directly into a SVG file seemed to lead to very bad performance. If it is not the case, then of course keeping the default format a SVG file will be great. the discussion was "linked vs embeded": http://sourceforge.net/mailarchive/message.php?msg_id=14552578
I'm not aware of any performance problems. I routinely work with multi-megabyte SVGs with embedded bitmaps and they work acceptably. Anyone has a use case?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 4/19/06, jiho <jo.irisson@...400...> wrote:
well I mentioned the self contained format because, from what I recall of past discussions on the subject, embedding bitmaps directly into a SVG file seemed to lead to very bad performance. If it is not the case, then of course keeping the default format a SVG file will be great. the discussion was "linked vs embeded": http://sourceforge.net/mailarchive/message.php?msg_id=14552578
I'm not aware of any performance problems. I routinely work with multi-megabyte SVGs with embedded bitmaps and they work acceptably. Anyone has a use case?
Is there a tarball version that has any self contained/zipped bitmap collection code ? I'll be happy to test on Dapper. We use full page background pngs all the time without problems. But look forward to keeping the svg and png files married.
On Apr 19, 2006, at 9:03 AM, bulia byak wrote:
On 4/19/06, jiho <jo.irisson@...400...> wrote:
my opinion is that users in group 1 and 2 are not the same. basically:
- the new comer/unexperienced user expects everything to be embedded
and things to work even if he moves things around. this is why I thought that the default should be a self contained file format.
My opinion is that a new default format is way too much of a change for this. What is needed is simply a checkbox "Embed into document" on Import dialog, on by default. That will provide the self-containedness for most novice users. Changing default from plain text SVG to some zipped non-standardized monster sounds like a bad idea.
Yes. Too much.
I'd say that tuning up "embed" vs "link" in our ui, plus adding a few minor UI clues at the proper places would take care of most problems.
As we move forward, there are going to be more things that just base images to manage. ICC Profiles are another file asset that will need to be managed. And a few other things too. So just adding some UI tweaks and then some base checks (like the "quit without saving?" check done for modified docs) and we can have a very usable situation.
On 4/14/06, Bryce Harrington <bryce@...961...> wrote:
Hi All,
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
My proposals:
- Debug Inkscape's memory leaks and decrease memory usage by some nontrivial amount
- Implement SVG filters, at least blur (I can be a mentor on that)
- Implement http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
That's what first comes to mind.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
(I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
The PrintingConsensusPoll has not seen much progress the last half year.. (you've lost a few links there, btw. It's PDF_Bugs, PDF_Test_Cases, and PDF_Tools) On the mailing list, however, there seem to have been a silent agreement on using Cairo for PDF output when/if Inkscape starts use it for rendering. Is that what you search here?
I wrote my own PDF output for Inkscape few weeks ago. It doesn't even try to address all your requirements and is not based on Cairo. All I wanted was a PDF with colours, bounding box and transparency. And that is about all there is. I never got much further than strokes and fills. It wasn't needed for the drawings I wanted to convert anyway. There is no support for features such as text, patterns or embedded images..
If this still sounds interesting enough as a starting point I could mail it to you.
/Ulf
On Sat, 15 Apr 2006 21:55:13 +0200, Ulf Erikson <ulferikson@...400...> wrote:
I wrote my own PDF output for Inkscape few weeks ago. It doesn't even try to address all your requirements and is not based on Cairo. All I wanted was a PDF with colours, bounding box and transparency. And that is about all there is. I never got much further than strokes and fills. It wasn't needed for the drawings I wanted to convert anyway. There is no support for features such as text, patterns or embedded images..
If this still sounds interesting enough as a starting point I could mail it to you.
Sure, could you upload it to the patch tracker?
I was looking into PDF the other day. While cairo PDF is good enough (maybe even preferable) for a lot of purposes, with a "native" PDF export we could do a lot more to preserve SVG document structure in the PDF output.
-mental
On Sat, Apr 15, 2006 at 09:55:13PM +0200, Ulf Erikson wrote:
bulia byak wrote:
(I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
The PrintingConsensusPoll has not seen much progress the last half year.. (you've lost a few links there, btw. It's PDF_Bugs, PDF_Test_Cases, and PDF_Tools)
Yes, the condition for moving forward on it was to get 20 people to list themselves in the poll, but we only got 17. I think it was an interesting approach to solving the problem, but in practice it failed to get the level of participation expected.
I wrote my own PDF output for Inkscape few weeks ago. It doesn't even try to address all your requirements and is not based on Cairo. All I wanted was a PDF with colours, bounding box and transparency. And that is about all there is. I never got much further than strokes and fills. It wasn't needed for the drawings I wanted to convert anyway. There is no support for features such as text, patterns or embedded images..
If this still sounds interesting enough as a starting point I could mail it to you.
Would you have the interest in continuing on with development of it?
Bryce
On Sun, 30 Apr 2006, Bryce Harrington wrote:
Date: Sun, 30 Apr 2006 11:54:57 -0700 From: Bryce Harrington <bryce@...961...> To: Ulf Erikson <ulferikson@...400...> Cc: inkscape-devel@...6... Subject: Re: [Inkscape-devel] PDF output
On Sat, Apr 15, 2006 at 09:55:13PM +0200, Ulf Erikson wrote:
bulia byak wrote:
(I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
The PrintingConsensusPoll has not seen much progress the last half year.. (you've lost a few links there, btw. It's PDF_Bugs, PDF_Test_Cases, and PDF_Tools)
Yes, the condition for moving forward on it was to get 20 people to list themselves in the poll, but we only got 17. I think it was an interesting approach to solving the problem, but in practice it failed to get the level of participation expected.
It does go to show there is not as much interest in PDF as expected. The lack of a plan was I think the major stick point there was a lot of support otherwise. I do think there is a good chance Cairo and Poppler will improve and provide the PDF infrastucture we really want. This short term setback might work out for the best in the long run and avoid redundant work.
Perhaps the workarounds are good enough for the determined few.
From scribus we know there is an audience who do care very much about PDF
but I guess SVG is good enough for most inkscape users where the drawing is the desired end result.
# from bulia byak # on Friday 14 April 2006 05:53 pm:
- Implement
http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
bulia, can you explain why this needs to be native? Short of animation and the exact placement of things like transforms in the DOM (if pdf would even allow that) the Chromista hub should express enough of the SVG structure to round-trip PDF conversions as well as anything native.
If it gets implemented natively in inkscape, I would just use that as a hub attached to chromista to get things like xar -> pdf, but going through svg is going to be lossy from that perspective.
Thanks, Eric
On Wed, 26 Apr 2006 14:59:18 -0700, Eric Wilhelm <scratchcomputing@...1063....> wrote:
# from bulia byak # on Friday 14 April 2006 05:53 pm:
- Implement
http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
bulia, can you explain why this needs to be native?
One issue: if my understanding of Uberconverter is correct, it requires Perl, doesn't it?
We can't really make it a required component for Windows users in that case.
-mental
MenTaLguY wrote:
On Wed, 26 Apr 2006 14:59:18 -0700, Eric Wilhelm <scratchcomputing@...400...> wrote:
# from bulia byak # on Friday 14 April 2006 05:53 pm:
- Implement
http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know of UberConverter, but PDF is the most important interchange format so we should better support it natively)
bulia, can you explain why this needs to be native?
One issue: if my understanding of Uberconverter is correct, it requires Perl, doesn't it?
We can't really make it a required component for Windows users in that case.
We actually already provide perl in the win32 libs. :)
-Josh
Repeatable crash error:
1. start inkscape 2. select rectangle tool 3. draw a rectangle (F4)
rectangle is drawn with controls points, unselected
4. select edit-path-nodes tool (F2)
rectangle remains unselected. if you see black arrows round the shape then you did it wrong.
5. press delete button on keyboard [<-]
6. bye, bye...
Inkscape attempts to save the work file, but then hangs. Have to control-C to kill it from the command line, since I'm not running it as an .app
Joshua A. Andler wrote:
Andrew Wilson wrote:
Repeatable crash error:
Actually... it looks like all you need to do is open Inkscape, change to the node tool, hit Delete... Crash
For note, it also happens on Win32 & Linux as well.
-Josh
On 4/26/06, Andrew Wilson <awilson@...1237...> wrote:
Repeatable crash error:
start inkscapeselect rectangle tooldraw a rectangle (F4) rectangle is drawn with controls points, unselected
Actually the rect IS selected after these steps. Different tools use different ways to highlight selected objects, but it does not affect their selected status.
press delete button on keyboard [<-]
Thanks for the report, fixed. (It was a gotcha from adding the new node deletion algorithm by Aaron.)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Bryce Harrington wrote:
Hi All,
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
some ideas:
1) SVG support in OpenOffice (not exactly Inkscape development, but would allow Inkscape users to paste in art rather than having to export to png and really promote usuage of Inkscape). Not to mention eliminating all those duplicate svg/png image files!
2) If the "save linked images" issue hasn't been resolved yet and needs additional work
3) more potrace development (convert right from scanner or digital camera card / gphoto / digikam)
4) extending the online InkscapeSVG stuff - might be very cool for sharing sketches, etc
On 4/14/06, John Taber <jtaber@...480...> wrote:
- SVG support in OpenOffice (not exactly Inkscape development, but
would allow Inkscape users to paste in art rather than having to export to png and really promote usuage of Inkscape). Not to mention eliminating all those duplicate svg/png image files!
Ishmal just committed odg export :)
- If the "save linked images" issue hasn't been resolved yet and needs
additional work
Yes, but it's pretty simple to do, IMHO not enough for a whole SOC project.
- more potrace development (convert right from scanner or digital
camera card / gphoto / digikam)
Hmm, why should we care about the user's harware?
- extending the online InkscapeSVG stuff - might be very cool for
sharing sketches, etc
What if we build instead a public whiteboard server for Inkscape users, with a web site of its own, user galleries, interest groups, scheduled drawathons, connections to OCAL, etc.?
Admitted, for this to be possible, we really need to make whiteboard to work on Windows...
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
First I wanted to propose to ask for fixes not a feature because there are a few things that are unfinished. Give us not yet another one. But Bulia appears to have the same opinion:
bulia wrote
What if we build instead a public whiteboard server for Inkscape users, with a web site of its own, user galleries, interest groups, scheduled drawathons, connections to OCAL, etc.?
Admitted, for this to be possible, we really need to make whiteboard to work on Windows...
Exactly. So, I'm all for the latter as a project.
ralf
bulia byak wrote:
Admitted, for this to be possible, we really need to make whiteboard to work on Windows...
Mikael's stated that he's working on getting Loudmouth 1.2 to be "fully working and compilable" on Windows (see http://lists.imendio.com/pipermail/loudmouth/2006-April/001170.html). That may be completed faster than a port of the Inkboard code to a different client library...
- David
bulia byak wrote:
- more potrace development (convert right from scanner or digital
camera card / gphoto / digikam)
Hmm, why should we care about the user's harware?
Directly interacting with the hardware doe not sound very exciting or useful, but there was recent talk about integrating SIOX (simple interactive object extraction) with tracing - that could be a really cool project.
Nicu Buculei wrote:
bulia byak wrote:
- more potrace development (convert right from scanner or digital
camera card / gphoto / digikam)
Hmm, why should we care about the user's harware?
Directly interacting with the hardware doe not sound very exciting or useful, but there was recent talk about integrating SIOX (simple interactive object extraction) with tracing - that could be a really cool project.
Bob was so excited about this, we already have it in SVN. :)
-Josh
Bryce Harrington wrote:
Hi All,
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Bryce
(</me adds some fine machine oil to the email engine)
Hi folks
Would it be possible to use the SOC to talk to Toyo about their colour finder and whether they will release it and then working with incorporating that? I know the social negotiation of this has to happen before the code but a printer(the industry not the desktop) relevant collection of swatches would be very nice, for gimp and scribus as well. I think mrdocs from #scribus is aiming to get someone from HP to talk to Toyo. Just wondered if the SOC could help resource that work?
If this aspect is in hand then just consider this a bravo and thanks for all the fish.
Janet
Bryce Harrington wrote:
Hi All,
I've gone ahead and indicated our interest in participating in this year's Google Summer of Code.
Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better!
Bryce
Hi all,
One very interesting functionality would be the ability to connect to one external Database. This could be a very powerful tool. While this exist in word processing software for making address list, I never see it in drawing software
Let me explain in few examples the main idea :
- Simple document like birthday invitations one want to send to several friends : the database could hold all the address of your friends while the body of the document could be draw in inkscape. Special fields would then be replaced by inkscape at printing or preview time by the Database items. - Calendar could be automatically made from one template. - Idem for series of stickers.... - More complex could be building of one full catalog of items, where the pictures link, names and descriptions of items could be hold in the database. While Inkscape would hold the templates part. - It would also allow to separate the redaction part from the artistic part in making magazine or newspaper ...
Cedric
Hope my poor english was sufficient to explain the all !
participants (22)
-
unknown＠example.com -
Aaron Spike -
Alan Horkan -
Alexandre Prokoudine -
Andrew Wilson -
Bryce Harrington -
bulia byak -
CedSha -
David Yip -
Eric Wilhelm -
Janet Hawtin -
jiho -
John Taber -
Jon A. Cruz -
Joshua A. Andler -
Lorenzo Luengo -
MenTaLguY -
Nicu Buculei -
Ralf Stephan -
Ted Gould -
Tobias Jakobs -
Ulf Erikson