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.
On 13. ruj. 2010., at 10:42, Łukasz Czerwiński <lc277...@students.mimuw.edu.
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 a path (1,2,1,2), won't it?
2010/9/12 Mirza Husadzic <mirza.husad...@gmail.com>
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 GIMP's invalid path-line
Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364
(dating form 2001) I realized that
things will change really slow:-).
I was quite depressed yesterday, but in the middle of night I got an
"If GIMP cannot draw overlapped lines, then why should draw them
*overlapped* after all!?"
If duplicates are removed, then XOR drawing will not affect path.
As a side effect, there will be approx. half of lines less to draw
(in case of connected polygons a.k.a mesh) so this is a very good
for poor gdk-powered line drawing in GIMP.
Here is a SVG file for testing:
Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop:
Here is a patch:
btw. I used slower variant 'g_hash_table_find' instead of
'g_hash_table_lookup'. I know that this is a flaw. I will try
to fix it.
And yes, rendering of this kind of optimized path is much better
than without optimization.
I'm able to work and paint (realtime) over this path. I'm very
The code affects processing only if paths are merged while importing
(checked "Merge imported path").
I'm not sure that I placed code at right place.
I'm not sure how it will affect importing of other entities from SVG
file (curves, ellipses etc.).
But, I'm pretty sure that this is a good way in direction of merging
It is useless if they are not flattened into only one path, without
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 current stroke ends
(begin of a new stroke).
This method can be applied even if paths are merged from GUI. I will
further test this approach
with other shapes from SVG (cubic bezier, ellipse etc).
If they are flattened on lines, at this stage, maybe this may work
with them too.
But, I'm not sure about this. I didn't tested it.
I would like to hear you opinions.
Gimp-developer mailing list
Gimp-developer mailing list