9:09 a.m.
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 -----
9:46 a.m.
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
10:06 a.m.
On 4/14/06, ted@...11... <ted@...11...> wrote:
I've got one I'd like to see:
http://gould.cx/ted/blog/Google_SoC_2
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
11:22 p.m.
bulia byak wrote:
On 4/14/06, ted@...11... <ted@...11...> wrote:
> I've got one I'd like to see:
>
> http://gould.cx/ted/blog/Google_SoC_2
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.
12:57 a.m.
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
1:03 a.m.
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
1:12 a.m.
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
2:07 a.m.
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
2:18 a.m.
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
5:11 a.m.
New subject: color changing
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.
7:02 a.m.
New subject: color changing
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
7:13 a.m.
New subject: color changing
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
8:37 a.m.
New subject: color changing
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.
2:03 a.m.
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.
2:12 a.m.
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
6:16 a.m.
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
8:39 a.m.
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.
5:42 a.m.
New subject: [Fwd: Invitation to Participate in Summer of Code 2006]
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/
7:46 a.m.
New subject: [Fwd: Invitation to Participate in Summer of Code 2006]
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
7:49 a.m.
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
1:15 a.m.
> 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.
10:39 a.m.
New subject: [Fwd: Invitation to Participate in Summer of Code 2006]
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
12:09 a.m.
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:
http://gould.cx/ted/blog/Google_SoC_2
^^^
"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&...
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/
2:38 a.m.
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
6:01 a.m.
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 :)
--
Alan
6:10 a.m.
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_Code
> 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.
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
6:18 a.m.
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
6:27 a.m.
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
6:12 a.m.
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
9:51 p.m.
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/
11:06 p.m.
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
8:39 a.m.
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.
9:30 a.m.
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.
10:45 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:19 a.m.
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.
12:30 a.m.
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
2:31 a.m.
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(a)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/
2:36 a.m.
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 :)
> [1] http://home.gna.org/colorscheme/
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
8:33 a.m.
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(a)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
4:45 a.m.
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.
12:49 a.m.
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/
12:51 a.m.
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.
--
Alan
1:03 a.m.
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
1:51 a.m.
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/
2:18 a.m.
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
9:50 a.m.
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.
4:49 a.m.
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.
9:53 a.m.
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
4:55 a.m.
New subject: PDF output
bulia byak wrote:
- 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)
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
3:11 a.m.
New subject: PDF output
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
3:54 a.m.
New subject: PDF output
On Sat, Apr 15, 2006 at 09:55:13PM +0200, Ulf Erikson wrote:
bulia byak wrote:
>- 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)
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
10:55 a.m.
New subject: PDF output
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:
> >- 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)
>
> 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.
--
Alan
6:59 a.m.
New subject: vectorsection vs native PDF?
# 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
--
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
7:29 a.m.
New subject: vectorsection vs native PDF?
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
7:43 a.m.
New subject: vectorsection vs native PDF?
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
8:09 a.m.
New subject: Repeatable crash on Mac 10.4.6, latest SVN
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
8:16 a.m.
New subject: Repeatable crash on Mac 10.4.6, latest SVN
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
8:42 a.m.
New subject: Repeatable crash on Mac 10.4.6, latest SVN
On 4/26/06, Andrew Wilson <awilson@...1237...> wrote:
Repeatable crash error:
1. start inkscape
2. select rectangle tool
3. draw 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.
5. 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
9:59 a.m.
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
11:15 a.m.
On 4/14/06, John Taber <jtaber@...480...> wrote:
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!
Ishmal just committed odg export :)
2) 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.
3) more potrace development (convert right from scanner or digital
camera card / gphoto / digikam)
Hmm, why should we care about the user's harware?
4) 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
4:55 p.m.
New subject: Fixes Not Features [Fwd: Invitation to Participate in Summer of Code 2006]
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
9:55 p.m.
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
11:27 p.m.
bulia byak wrote:
> 3) 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.
12:47 a.m.
Nicu Buculei wrote:
bulia byak wrote:
>
>> 3) 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
7:45 a.m.
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
7:39 p.m.
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 !
6178
days inactive
6194
days old
inkscape-devel@lists.inkscape.org
66 comments
22 participants
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