'Re: GSoC 2009 proposal, looking for mentor'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: koffice-devel
Subject: Re: GSoC 2009 proposal, looking for mentor
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2009-02-27 0:51:28
Message-ID: 478b087a0902261651j2cab13e8se03114a64abe0521 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On Fri, Feb 27, 2009 at 12:23 AM, Andrew Dorrell
<andrew.dorrell@gmail.com>wrote:

> LukasT.dev@gmail.com wrote:
> >> I'd like to put in a vote for the diffusion curves.  That stuff is very
> >> cool and looks very powerful for content creation.  Also it is nice and
> >> modular (self contained project).  But I would contact the authors first
> >> to clarrify their position WRT intellectual property.  I.e. Have they,
> >> or are they planning to patent this work and how will they view a GPLv3
> >> release of their work.
> >>
> > I already mailed long time ago with one of the authors of curves and the
> > author showed some joy over the fact, that somebody wants to implement in
> > open-source project. No problems with patent I think.
> >
>
> That's fantastic to know.  BTW I think it could fit in both karbon14 and
> krita but in krita it would be used as a kind of brush so that, when you
> had finished using the tool it rendered to pixels and that was that.  In
> karbon14 it makes sense to retain the curve definition and re-generate
> as required - retaining full scalability.
>
> I must get to know these apps a little better!
>

Well the main reason against doing it in Karbon is, that  it can't be saved
to standard vector graphics formats. So it would have to be a non-standard
extension which other apps like inkscape can't open.
Of course you could rasterize it to an image.

Even in Krita you could retain the curve definition. Like we currently do
with shape layers the curve data could be stored and the gradient be
regenerated when needed.

[Attachment #5 (text/html)]

<div class="gmail_quote">On Fri, Feb 27, 2009 at 12:23 AM, Andrew Dorrell &lt;<a href="mailto:andrew.dorrell@gmail.com">andrew.dorrell@gmail.com</a>&gt; \
wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d"><a \
href="mailto:LukasT.dev@gmail.com">LukasT.dev@gmail.com</a> wrote: </div><div \
class="Ih2E3d">&gt;&gt; I&#39;d like to put in a vote for the diffusion curves. That stuff is \
very &gt;&gt; cool and looks very powerful for content creation. Also it is nice and 
&gt;&gt; modular (self contained project). But I would contact the authors first 
&gt;&gt; to clarrify their position WRT intellectual property. I.e. Have they, 
&gt;&gt; or are they planning to patent this work and how will they view a GPLv3 
&gt;&gt; release of their work. 
&gt;&gt; 
&gt; I already mailed long time ago with one of the authors of curves and the 
&gt; author showed some joy over the fact, that somebody wants to implement in 
&gt; open-source project. No problems with patent I think. 
&gt; 
 
</div>That&#39;s fantastic to know. BTW I think it could fit in both karbon14 and 
krita but in krita it would be used as a kind of brush so that, when you 
had finished using the tool it rendered to pixels and that was that. In 
karbon14 it makes sense to retain the curve definition and re-generate 
as required - retaining full scalability. 
 
I must get to know these apps a little better! </blockquote></div> Well the main reason \
against doing it in Karbon is, that it can&#39;t be saved to standard vector graphics formats. \
So it would have to be a non-standard extension which other apps like inkscape can&#39;t \
open. Of course you could rasterize it to an image. Even in Krita you could retain \
the curve definition. Like we currently do with shape layers the curve data could be stored and \
the gradient be regenerated when needed.

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread] 