- Inkscape Devel - Inkscape Mailman

RE: bug 848692
by bulia byak 10 Apr '04

10 Apr '04

> > 1) by starting from a non-rounded rect and dragging only one handle >down. > > The other handle stays in the corner (does not move) but, since having >one > > of the radii equal to 0 and other not makes little sense, Inkscape >responds > > by producing strictly rounded corners. > >point is, it does not! When you have a portrait rect, they are not >strictly circular corners. Well, they _start_ circular, they only stop being circular if you move too far. > > > The difference is that with 1), the circularity is preserved when you >resize > > the rect, while with 2) it is not. I agree that this is inconsistent and > > inconvenient, and I will try changing Ctrl-drag so it produces the same > > result as 1), with one of the handles in the corner. This way you can >drag a > > handle on any side with Ctrl and get auto-circular corners preserved in > > scaling. Is this what you're after? > >So yeah, that'd be a solution. but if you do so instead of stopping that >handle when the top and bottom curves meet it should be possible >starting out dragging the handle to the right, and not to the bottom >only, because that way you can get the same result, as if you had the >rect rotated by 90�. Hope this makes a little sense to you, what I'm >saying. I oughta watch more movies in English, maybe, but probably it's >just hard to explain :( It stops now with Ctrl, and it will still stop with Ctrl when I change that. The change will only affect how the circular corners are represented (with one handle at the corner, instead of both being at the same distance from it), but the stop when the roundings (with or without handle) meet on the shorter side should remain as is. I may not be able to work on this right now, so please file a RFE with the summary from our emails. _________________________________________________________________ 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…

1 0

RE: bug 848692
by bulia byak 10 Apr '04

10 Apr '04

>My point is: if you create a landscape rectangle, you can only move the >node down until the curves on the left and the right size meet. This way >you end up having a rect with two arcs attached to it. >Now take a portrait rect and do the same. you end up with an elipese, >because the node does not respect the curves meeting at the top and the >bottom and hence don't stop at that point. >This is inconsitent. Drag it with Ctrl, then it will stop as soon as the handles on any of the sides meet, and you will get strictly circular corners. >It also doesn't allow me to create a portrait rect with arcs attached to >the top and the bottom, because I don't know, where to stop moving the >node. Dragging with Ctrl takes care of that. >If anybody should want to have different radii, he should move the >second node aswell. That is what it is for imho. I.e. you propose that normal dragging should behave as Ctrl-dragging now? Why? >But moving only the single node should do the same as having both nodes >moved with ctrl pressed. Then how do I get the current behavior if I want it? >The difference gotta be though that when >rescaling the rect, the corners stay circular. OK, I think I understand what you want. There are currently two ways to get strictly circular corners: 1) by starting from a non-rounded rect and dragging only one handle down. The other handle stays in the corner (does not move) but, since having one of the radii equal to 0 and other not makes little sense, Inkscape responds by producing strictly rounded corners. 2) By dragging any handle with Ctrl. This way both handles are moved and are at the same distance from the corner. The difference is that with 1), the circularity is preserved when you resize the rect, while with 2) it is not. I agree that this is inconsistent and inconvenient, and I will try changing Ctrl-drag so it produces the same result as 1), with one of the handles in the corner. This way you can drag a handle on any side with Ctrl and get auto-circular corners preserved in scaling. Is this what you're after? _________________________________________________________________ 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: bug 932629
by bulia byak 10 Apr '04

10 Apr '04

>932254 died a horrible death, with a very ugly fix >(adding the miterlimit to the bounding box in the >nr-arena-shape update function). My gut feeling is that the renderer must not have any preconditioned bounding box; it must _return_ one, not take. But this may be too difficult to implement. For now, adding the miterlimit length to the bbox sounds OK to me. So the wrong cut problem is now gone, but the stroke-miterlimit value is still calculated wrong. According to spec, the value of sqrt(2) must correspond to the miter/bevel transition at the angle of 90 degrees, while now it happens at 45 degrees. We must conform to what the spec says to be compliant: http://www.w3.org/TR/SVG11/painting.html#StrokeProperties >932251 i cannot >produce either, but i had the exact same problem a >while ago. it should have been fixed. if you can >provide me a svg of the problem to debug... I attached a sample svg to the bug. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

RE: bug 932629
by bulia byak 10 Apr '04

10 Apr '04

>i cannot reproduce this bug. are there any settings >that must differ from the stock ones to get the bug? >also, since the scaling is proportional to the canvas >size, is there a specific canvas size to use? It depends on zoom, not canvas size. Anyway, I attached a new file to the bug where you only need to select the object and do outset of any size at any zoom, and it crashes. >btw 932640 and 932631 were apparently the result of an >intersector bug. i had to change a bit the code, but >my memory is quite fuzzy as to how it exactly >proceeds; i hope the changes didn't create new bugs... I hope too :) These two bugs are closed, thanks. What about 932254 and 932251? _________________________________________________________________ Tax headache? MSN Money provides relief with tax tips, tools, IRS forms and more! http://moneycentral.msn.com/tax/workshop/welcome.asp

1 0

misc
by bulia byak 10 Apr '04

10 Apr '04

Fred, your latest changes broke win32 compilation: display/nr-arena-item.cpp: In function `unsigned int nr_arena_item_invoke_render(NRArenaItem*, NRRectL*, NRPixBlock*, unsigned int)': display/nr-arena-item.cpp:383: error: `gettimeofday' undeclared (first use this function) display/nr-arena-item.cpp:383: error: (Each undeclared identifier is reported only once for each function it appears in.) I noticed you added a new option, arenatilescachesize. Can you elaborate on what effect it has, and what are the recommended values? If it's supposed to be user-editable, please add it to http://inkscape.org/cgi-bin/wiki.pl?PreferencesDialog with a label, acceptable range of values, and a tooltip which explains what this option does and how. When we finally create a preferences dialog that page will be used as the base. Also, there are quite a bunch of new bugs in the tracker that you may be interested in (dashed strokes, offsets, miters, etc.) _________________________________________________________________ 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…

4 3

RE: [Inkscape-devel] item opacity not drawn correctly
by bulia byak 10 Apr '04

10 Apr '04

>When you have an object, with pretty thick an outline and change it's >opacity, in the item properties, you will notice, that not the opacity >of the object is decreased, but the opacity of the stroke and the fill >seperately. You notice this, because you see the fill behind the stroke. >If you group some objects and change the opacity of the whole group, >things work fine. >Should I file a bug? Yes please. _________________________________________________________________ Add photos to your messages 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

item opacity not drawn correctly
by David Christian Berg 10 Apr '04

10 Apr '04

When you have an object, with pretty thick an outline and change it's opacity, in the item properties, you will notice, that not the opacity of the object is decreased, but the opacity of the stroke and the fill seperately. You notice this, because you see the fill behind the stroke. If you group some objects and change the opacity of the whole group, things work fine. Should I file a bug? David

1 0

0.38 Release Status
by Bryce Harrington 10 Apr '04

10 Apr '04

Here's the status of packages for the 0.38 release: * (DONE) Signed tarball * (DONE) Debian packages (i386 & PPC) * (DONE) Two RPM-based distros * Win32 EXE's As soon as someone has binaries for the Win32 version, we can go ahead with the official announcement. Bryce

2 2

redering of icons
by David Christian Berg 10 Apr '04

10 Apr '04

Now this I don't get, there's a problem rendering the icons in the icon.svg, for use on the buttons. They are displayed correctly in the document itself, though. as it seems, there are gradients, that are messed up upon rendering for the display, or something like that. david

1 0

IMPORTANT: release tagging
by MenTaLguY 10 Apr '04

10 Apr '04

NOTE: anyone who currently has a checked-out copy of RELEASE_0_38_0, the tags in your working copy are most likely hosed; please check out a fresh copy! Since we need to do a point release, I went to check out the 0.38 release branch, only to discover that there wasn't one -- and RELEASE_0_38_0 was a branch tag itself. That's a problem, because I can't just check out RELEASE_0_38_0, commit the point fixes, and tag RELEASE_0_38_1 -- it would have moved the head of the branch and the next person to check out RELEASE_0_38_0 would have gotten something other than our 0.38(.0) release... In future, PLEASE do this: RELEASE_0_X_BRANCH - a branch for the 0.X.Y releases RELEASE_0_X_Y - a regular tag for the That way, if we need to do a point release, we can just check out RELEASE_0_X_BRANCH, commit the fixes, and tag RELEASE_0_X_Y; no muss, no fuss. As noted at the top of the email I have moved and rebranched the existing 0.38 tag accordingly. RELEASE_0_38_0 is now a regular tag, and RELEASE_0_38_BRANCH is now the branch tag. -mental

4 5