Ok good, I will investigate how it can be done within plugin or script.
Unfortunatelly I'm on trip until next Friday, so this will wait some
time until I come home.
Cheers,
Mirza
On 14. ruj. 2010., at 22:03, Sven Neumann wrote:
> On Mon, 2010-09-13 at 22:19 +0200, Mirza wrote:
>
>> Please
On Mon, 2010-09-13 at 22:19 +0200, Mirza wrote:
> Please consider optimization with merged paths as this is crucial to
> smooth rendering on current GIMP's architecture.
Such "optimizations" don't belong into the core. We already provide the
infrastructure for scripts and plug-ins to hook into
Thank you Sven.
Actually I didn't wasted my time more on this so far, beacause I'm
able to continue my work with painting textures where I jammed last
week.
I know that I just scratched the surface in this short time and in
order to do more solid solution I need to learn more and to look for
On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote:
> Hi all,
>
> I came up with solution to import and merge Blender's SVG file as path
> into GIMP.
> This is just quick and dirty solution which I hacked this afternoon.
> But it works very well.
> I opened bug report yesterday concerning GI
There is no doubt about XOR drawing. It should be fixed asap so GIMP
development can continue more clearly.
But, if you merge some complex path and there is no way to unmerge, it
is useless to keep collinear lines.
This is just optimization from which users can benefit to import more
complex
On Mon, Sep 13, 2010 at 11:05 AM, yahvuu wrote:
> On 13.09.2010 11:47, Alexia Death wrote:
>> No. Just... no. XOR needs to die. Badly.
>
> just curious: what coloring options exist to enshure sufficient background
> contrast
> when drawing non-XORed/anti-aliased?
One good way of doing it is draw
On 13.09.2010 11:47, Alexia Death wrote:
> No. Just... no. XOR needs to die. Badly.
just curious: what coloring options exist to enshure sufficient background
contrast
when drawing non-XORed/anti-aliased?
thx,
yahvuu
___
Gimp-developer mailing list
Gi
2010/9/13 Mirza :
> Then test should be extended to look
> for collinear lines.
> But principle should be the same, which means that collinear lines will be
> removed from flattened path.
> Mirza.
No. Just... no. XOR needs to die. Badly.
--
--Alexia
Then test should be extended to look
for collinear lines.
But principle should be the same, which means that collinear lines
will be removed from flattened path.
Mirza.
On 13. ruj. 2010., at 10:42, Łukasz Czerwiński pl> wrote:
Hello,
The same as Tobias, I'm not in the topic of paths, so
Hello,
The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but
you wrote that you add each path (x1, x2, y1, y2) to the hash table and look
for duplicates. And what if only a part of a path overlaps? Consider paths:
(2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be
On 09/13/10 05:47, saulgo...@flashingtwelve.brickfilms.com wrote:
> Quoting Mirza Husadzic:
>
>> Hi all,
>>
>> I came up with solution to import and merge Blender's SVG file as path into
>> GIMP.
>> :
>> :
>> I was quite depressed yesterday, but in the middle of night I got an idea
>> :-)
>> "If GI
Quoting Mirza Husadzic :
> Hi all,
>
> I came up with solution to import and merge Blender's SVG file as path into
> GIMP.
> :
> :
> I was quite depressed yesterday, but in the middle of night I got an idea
> :-)
> "If GIMP cannot draw overlapped lines, then why should draw them
> *overlapped* aft
Am Sonntag, 12. September 2010 schrub Mirza Husadzic:
[...]
> The algorithm:
>
> As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is
> constructed and pushed into hash table.
> If key is uniuqe then line in stroke is valid.
> If key is duplicated, then line is rejected and
> Fixed in GIT. We miscounted the numbers in the "points" string when it
> had additional whitespace at the end, resulting in a rejection of the
> data, since an uneven count means invalid data.
Thank you Simon. That was fast.
I tested it, it works.
But, there is another problem with not displayin
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
> > Can you please open a bug-report and attach the most simple test case
> > that you can come up with? We need a small .svg file that illustrates
> > the problem. I am pretty sure that the problem can easily be fixed then.
>
> Here it is: https
> The grammar parsed by GeglPath is dynamically extendable to also
> incorporate for instance spiro curves http://libspiro.sourceforge.net/
> or other non bezier curves.
I'm looking forward to see it in action.
Mirza
___
Gimp-developer mailing list
Gimp
> Can you please open a bug-report and attach the most simple test case
> that you can come up with? We need a small .svg file that illustrates
> the problem. I am pretty sure that the problem can easily be fixed then.
Here it is: https://bugzilla.gnome.org/show_bug.cgi?id=629318
Mirza
___
On Thu, 2010-09-09 at 12:13 +0200, Mirza Husadzic wrote:
> The problem is manifested when I imported SVG file (the mesh UV Layout
> generated by Blender 2.53) into GIMP, in order to be able
> to paint textures by keeping guide-lines with paths.
>
> The paths are not imported/merged properly where
On Fri, Sep 10, 2010 at 7:57 AM, Mirza Husadzic
wrote:
> I'm afraid that path rendering in GIMP requires a major change.
> Why not take this step further and make it more flexible and easier to
> maintain for future development?
Depending in any way on librsvg would in my opinion not be a move in
> To provide path coordinates flattened
> (with all transformations applied) it would have to compute the
> transformations itself. So it is not obviously clear, that librsvg *has*
> the data readily available for the use in the GIMP.
It can provide transformation matrix which keeps rotation
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
> > Using which rsvg function calls exactly?
>
> I checked the 'librsvg' and yes, there is no API exposed to satisfy this.
> Maybe the 'librsvg' can be subtly redesigned to expose this API? ;-)
I did not look at the librsvg internals, but interpret
> Using which rsvg function calls exactly?
I checked the 'librsvg' and yes, there is no API exposed to satisfy this.
Maybe the 'librsvg' can be subtly redesigned to expose this API? ;-)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.ED
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
> I think that better solution is that 'librsvg' do the parsing job and that
> GIMP can fetch points from the lib to render.
Using which rsvg function calls exactly?
Bye,
Simon
--
si...@budig.de http://simon.bud
Hello,
> This was imported perfectly for me, if it still fails to you, maybe
> you should filla bug report (Try validation your svg first using the
> svg validator - http://validator.w3.org/ ).
But not worked for me when whole document is imported.
I checked the document and it passed SVG 1.1. va
Hello,
On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic wrote:
\> The paths are not imported/merged properly where SVG image is generated
> correctly (probably by 'librsvg'?).
GIMP imports path itself using it's own functions - the reason is that
it can only handle bezier/polygonal strokes (so othe
> Why is GIMP so slow at rendering paths?
I noticed that just last week. I was trying to use a path a a guide
to paint and gimp was virtually unusable with the path displayed.
This was on XP and 2.6.10
I worked around the issue by stroking the path on a new layer that I
used as a guide.
-Rob A
26 matches
Mail list logo
