March 2004 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] problems with win32 (German)
by bulia byak 11 Mar '04

11 Mar '04

>but the rect is shown as it is (with no fill) Thanks, it is also caused by the same bug where , is used instead of . in numbers. We're working on that. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] problems with win32 (German)
by bulia byak 11 Mar '04

11 Mar '04

>I tried to attach a the file, >but it doesn't give me any button to do that. >I will attach the picture to this e-mail. Rect1 is still holduing the mouse >button (you dont see the cursor on the screenshot). Rect2 is after release >the button. Thanks, but we're more interested in the resulting SVG file, not the screenshots. Also please attach your preferences file ($HOME\Inkscape\preferences.xml), it may be useful for debugging. _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] "problem with gradients" (Bug 850924)
by bulia byak 11 Mar '04

11 Mar '04

>So, if it's a problem in Nautilus, then there really isn't anything we >can do. Shall I document the workaround and close the bug? Properly, this should have been investigated... But with the bug being scarce for info (no sample) and with Lauris' opinion, I'd vote for closing it. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

patch comments
by bulia byak 11 Mar '04

11 Mar '04

1. This bit must come _before_ any drawing in GDK_MOTION_NOTIFY: if ( event_context->within_tolerance && ( abs( (gint) event->motion.x - event_context->xp ) < event_context->tolerance ) && ( abs( (gint) event->motion.y - event_context->yp ) < event_context->tolerance ) ) { break; // do not drag if we're within tolerance from origin } // Once the user has moved farther than tolerance from the original location // (indicating they intend to draw, not click), then always process the // motion notify coordinates as given (no snapping back to origin) event_context->within_tolerance = false; Its purpose is to do nothing if the mouse hasn't trespassed tolerance limit from the origin. However in arc-context (and probably elsewhere) you have sp_arc_drag() before it, which kinda defeats its purpose. 2. event_context->xp and xy should be reset to 0 in GDK_BUTTON_RELEASE, just in case. 3. Like I said, tolerance can be a local variable, i.e. instead of event_context->tolerance = prefs_get_int_attribute_limited ("options.dragtolerance", "value", 0, 0, 100); you can have guint tolerance = prefs_get_int_attribute_limited ("options.dragtolerance", "value", 0, 0, 100); and remove it from SPEventContext. 4. Cosmetics: please fix indentation (I don't care tabs or spaces, but the nesting structure must be indented properly), AUTHORS should remain alphabetical, and remove the "hello" :) Other than that, good work! Now what remains is the cosmetic/behavior of spinbuttons (focus, keys, font size - as in rect) and, most importantly, spinbuttons' event handlers and listeners to track selection. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: Spoonshapes - win32
by bulia byak 11 Mar '04

11 Mar '04

>I cannot make them appear regularly. Sometimes I can get two in >successsion. >Other times 15 or 20 normal ones might intervene. Noticed that as well. Please file a bug with your a screenshot. _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: [Inkscape-devel] "problem with gradients" (Bug 850924)
by bulia byak 10 Mar '04

10 Mar '04

>Summary: problem with gradients >Bug ID: 850924 I can't verify, but this bug is closed in sodi: http://sourceforge.net/tracker/index.php?func=detail&aid=782800&group_id=40… _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: offset & simplify
by bulia byak 10 Mar '04

10 Mar '04

>to false). apparently illustrator does exactly the >same kind of errors in its offsets, so i suppose they >have taken the same method. You used a constant value in the call to Coalesce in sp-offset. I changed that to: SPItem *item = &(shape->item); NR::Rect bbox = sp_item_bbox_desktop (item); gdouble size = L2(bbox.dimensions()); gdouble exp = NR::expansion(NR::Matrix(item->transform)); if (exp != 0) size /= exp; orig->Coalesce (size * 0.001); I.e. I coalesce by the 0.001 of the item's size (divided by transform, because offset works with the original untransformed path). And it now works perfectly for most sizes! Only in the smallest size, at 256x zoom, there are noticeable distortions resembling pixelation, apparently because of a lack of precision somewhere causing nodes to "snap to grid". However, this is a much smaller annoyance than before. The version with my change is committed. Another change I did was reducing the minimum allowed radius from 0.25 to 0.01: if (fabs (offset->rad) < 0.01) offset->rad = (offset->rad < 0) ? -0.01 : 0.01; because with 0.25, there was a noticeable "jump" around 0 for small objects. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: offset & simplify
by bulia byak 10 Mar '04

10 Mar '04

>the offset quality is dependent on the simplification >quality, especially the "correct" version. for the >time being, i leave the bad version (selected by >setting the global use_slow_but_correct_offset_method >to false). apparently illustrator does exactly the >same kind of errors in its offsets, so i suppose they >have taken the same method. its advantage is that it's >faster, and easier to recombine in curves. but i still >haven't found a nice way to have a treshhold that >depend on the "detail" size (like for the "good" >version), so the simplification can eat some details. >as far as simplification is concerned, it's probably >wiser to leave someone else come up with a good >algorithm (and to not default to Coalesce(), which is >sometimes too strong). I tried use_slow_but_correct_offset_method = true, which gave good results indeed, but froze and crashed soon :( So I guess we should leave it at false for now. As for the current method, again, if it gives correct results for large objects, what prevents you from "tricking" it so it believes all objects are large enough for the artifacts to never appear? >also, when you say >"simplification", i assume you mean (a bit) >"smoothing". Yes, that's what is often needed in design, and what most people expect when they do "simplify": reduce the number of nodes making the path smoother. >The simplify() functions don't do >smoothing at all; they were intended to remove very >small segments in the path description, that's all. So I guess it's useful for doing simplification as part of the offset, but not usable for standalone Simplify command. >i can't remember what the defaults were for >yesterday's sp_selected_simplify(), but i don't think >i have done major changes to the behavior of simplify. >it's probably just the difference between >justCoalesce=true and justCoalesce=false Yes! options.simplifyjustcoalesce was 1 by default, now I changed it to 0 and it works very well again! With the starting threshold of 0.003 * size, it gives a very smooth transition from the original shape to the degenrate two-node path, preserving the original outline as good as it can on every step. Thanks, and please do not change the algorithm used by the standalone Simplify anymore! :) (you can of course tweak the algo used by offset, to fix the distortions, if this is possible at all) _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar � get it now! http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/

1 0

"problem with gradients" (Bug 850924)
by Bryce Harrington 10 Mar '04

10 Mar '04

Summary: problem with gradients Bug ID: 850924 ------------------------------------------------------------------------ If you use gradients in Sodipodi and then stretch the icon of the saved file in Nautilus, you'll notice, that the gradients are absolutly screwed up! Just try it yourself, draw a rect, give it a gradient fill, save it as svg or sodi-svg and do "Stretch Icon" with Nautilus... I assume there's something wrong with de definition of the gradients in the xml David ------------------------------------------------------------------------ Can anyone verify that this is a problem with how gradients are being stored in the SVG, or could it be a Nautilus problem? Bryce

1 0

offset & simplify
by bulia byak 10 Mar '04

10 Mar '04

Hi Fred, Your latest changes in the offset code are very promising. The offset behavior is now much better, it's almost perfect for most "normal" sizes and only breaks for really small objects. So I'm closing the "splotch" bug as no longer relevant, and to the "offset distortions" bug I attach a new sample file, sloam.svg, with three object sizes (one perfect, one slightly broken, one broken). As for Simplify, the best result I've seen from it was yesterday. Today (as of this writing) it behaves much worse: does not change anything until very high thresholds, and then suddenly distorts the shape beyond recognition. The nature of these distortions is similar to those in the broken (smallest) shape in sloam.svg. Obviously this is because offset uses the simplify command too. The behavior I want to see from Simplify is this: preserve the general outline of the path; allow to remove a varying number of nodes by varying the threshold; avoid distortions; behave consistenly and predictably for all threshold values. Yesterday's version was very close to that. Ca we return to it please? _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0