NFG

Thank you, the selection box reset button is a cumbersome (I was hoping for a modifier key) but effective way to do what I wanted. Un- and re-selecting the object reverts to the previous behaviour, which is excellent. As for the rotation... I'm baffled by this. Once an object is rotated, how can I adjust its size relative to the page with a new height/width value?

DA 1.5.0.15 Forgive me if this has been brought up before, I couldn't find anything in the forums and the Windows beta help is broken. When rotating an object, the height and width appear to be linked to the original orientation, not the new one. For example, a horizontal rectangle that's 50 wide and 10 tall will still be 10 tall when it's rotated 90 degrees. It's now 50 tall and 10 wide, but AD still shows the original height and width. This is weird, is it expected behaviour? Bonus question! After rotating the same rectangle to, say, 30 degrees, attempts to change the size via the handles will change the height or width relative to the new orientation. Moving the handles left or right in every other app I've ever used causes the object to expand or shrink relative to the page. AD changes the size relative to the object's orientation. For example, changing the height of the rectangle will change the height at the new 30-degree angle, not vertically against the page orientation. The newly resized rectangle still has perfectly square corners, where with other apps it would effectively be skewed. Now, I -like- this, but I can foresee instances where I'd want it to behave more traditionally. How can I do this?

It seems to be fixed now. I haven't tested them all but the important one - ^shift-V - is working fine. Yay!

You're not listening. I don't care about lines vs curves, I care about paths. The discussion started over AD's calling something a curve when it's normally called a path. We got sidetracked into zero-handle infinitely bendy non-radii curves masquerading as lines, but that's not why I'm here. I only pointed out the difference between back-end purity and user expectation. EDIT: yeah OK, I may have started this by insisting that straight lines aren't curves. As far as I care though, if a path segment ain't bent, it's a line. But again, the original point is that they should be called paths, which can contain curves or lines or non-curved curves or wtf ever. Paths.

Back in 1987 I was using a package that had a separate key for each node. As you draw, you press one for LINE segment, another for a CURVE segment. There's no reason for one segment to be a zero-handle (or infiinite radius, or however you wrap your head around it) curve, it can simply be a line connecting two points. I'd wager most users view it exactly this way. What happens in the background matters little to the users who see CURVE and wonder why their all-lines creation has curves in it. So basically: maybe AD has infinite radius curves, and maybe it uses lines. They're all still paths. =P

I think my only problem with your definition is that a bezier path with no curve handles is a straight line. A zero-radius, zero-bend line is not a curve by anyone's definition. Mathematically it might be a bezier curve with zero control points, but still in this case a bezier curve (straight or not) is a subset of the whole path. And in this case too, each 'curve' is the segment between two points, not the whole path. Wikipedia, the infallible source of neverwrong information, sayeth: "Paths", as they are commonly referred to in image manipulation programs,[note 1] are combinations of linked Bézier curves. If we were to vote, I'd say they should be called paths. ^_^ I'm not going to touch the 'polygon' issue, haha.

I have to believe you've got that backwards. A path is not defined as something that is straight or curved, a straight path or a curved path are subsets of the superset 'path'. Like AdamStanislav I don't really have an interest in starting a war over it, and I'm happy to be found wrong on the matter (or eve to let it drop) but the idea of paths, curves and lines is sort of well defined. 'line' is ambiguous, it can be straight or curved, but a path is defined as both, curve is defined only as something that bends.

To be clear, I'm not saying grouping is bad! I'm saying grouping as a workaround to a problem other apps have gracefully solved is bad. I use grouping all the time, it's a necessary feature. A minute or two your way, vs no time at all mine. Your way requires careful pre-planning and constant grouping and ungrouping of objects not being actively worked on is a cumbersome solution. It's extra steps too every time I want to go insert or copy a piece from these other objects. It's work I don't have to do with another app, something that, TBH, I assumed was standard. Aha, that's very useful indeed. I need to find this 'paste behind' function. Thanks for the tip! As for user-defined... I can't think of any so I'm asking you guys - under what circumstances does the layer order matter, except visually?

If it's touching an object, moving it up or down should move it relative to the ones it touches. If it doesn't, who cares? It'll have no visible effect, some other rules should apply. Probably in this case it'll move in the logical layer sequence. I've never experimented with it because, honestly, who cares? It only matters when they overlap, and if they overlap they should move above or below each other with the command. Doesn't that just make sense? Simple logic: If two objects touch, layer move is relative to touching objects. If not, relative to total layer order. That saves the user all the work, and all the thinking.

I think the distinction is that one object can have disconnected paths. If they run the same direction, one is essentially doing nothing. If it's reversed, as you say, it has an effect. Nah, it's busywork for the user. It basically requires me to do a series of steps every time because the program's authors didn't do it for me. I sometimes create dozens of variations of an idea on a single page. Asking me to go and group 300 items in logical little bundles for the convenience of saving 300 MOVE DOWN commands when I accidentally move to the TOP is ... Well I'd be somewhat unimpressed. See the attached image. Each skull is made of 30-40 components. If I'm working on any one of them, I shouldn't have to be aware of the other 500 objects/layers, I should only have to worry about the ones in front of me.

When I load your file and export it to PDF, I get the message "Nothing will be rasterized" and no warning.

Sorry, it was my error. That triangle should have been at the top. I corrected it later. That it moves below the layer immediately below it is surprising to no one. =)

Mark: Isn't this a terminology issue? In my experience, 'path' is any series of two or more vector points, be they curves (bezier) or lines. A 'curve' is generally understood to be a bezier path. Calling something with only straight lines and points a 'curve' is incorrect. =)

That's also why I asked, at one point, if this was what's happening if the object was first moved to the top of the stack. I wasn't sure that I'd left it in the right place when I saved the file (I have now updated the file so anyone playing with it will have it at the top). Thing is, never mind the behaviour I'm used to, I can't imagine for the life of me why anyone would want the object to move one step at a time, slipping between items not close to the current object. In my example file if I'm working with the triangle and I want to move it down a layer... I mean, I'm repeating myself here, but if there are only two objects in view and I move one that's on top of the other DOWN, under what circumstances would I want nothing to happen? And then continue to do nothing twelve more times? From a logic standpoint, sure. "It's on level 27, DOWN moves it to 26". That's programmer logic. The user sees it on top of an object, moves it down, and ... Well, you see where I'm going, and I'm repeating myself, I'm sorry. I used to be involved in software development, I see both sides. But here, now, I'm a user. ^_^ As for reverse path! I've never used an application where, if you draw a path, draw another one inside it and reverse the direction, it fails to remove the part contained by the second path. If it's the same object with a second reversed path, it cuts a hole. However, this exact same effect is achieved by making two objects and using one to cut or remove chunks from the second. The end result is the same: a donut of sorts. Whether you mentally visualize this by considering the inside path reversed or not is up to you. <shrug> Not really my problem with the app in any case. =)

It seems that AD uses 'curve' where other apps would use 'path'. It's not correct, IMO.

As discussed in more detail in this post. Short version: I was complaining that moving an object DOWN did not immediately move it to a position lower than the object it was currently blocking. Instead, it required the action to be taken many times, as it moved successively lower past objects that were perhaps not even on-screen at the time. This is contrary to Inkscape, for example, where objects will drop in level so that they'll move in relation to things that immediately below them. ie: it's taking their position context into account. Here's an example document: http://oz.nfgworld.com/AD-test.afdesign In this example, the green triangle on the top level will require -thirteen- moves to place it below the black square. During the discussion linked above it was determined that this doesn't happen on the Mac version, and it moves based on the context as expected. EDIT: Further discussion has confirmed the Mac version behaves the same way. Basically, the strict adherence to the layer structure makes the user's job more tedious, and other apps have a better solution. ^_^

1. Aha, so Window bug, I guess! 2. Ah of course, I was looking at the layer palette. Flicking it to Winding (non-zero) filled the item in solid, which... doesn't help me. =) As an aside, I can't find a 'reverse path' option, which is usually how you use one path to carve a chunk out of the middle of another path.

1. So in your Mac version, raising the triangle to the top and dropping it one level puts it below the black rectangle? 2. Purple curves... If there's a 'Fill Mode' option I can't find it. =/

Just moving 'Back One'. It doesn't move below the black rectangle until it's shuffled through a bunch of irrelevant layers. If I saved it wrong, you may need to move it to TOP first, but it certainly takes 13 steps from there.

Running AD 1.5.0.7: None of the ctrl-shift shortcuts work. Or at least, none that I've tried. I can't move objects to front or back, or paste styles using the keyboard. Works fine by selecting these commands via the menus using the mouse. Actually, ^shift-S works to save the document, but that's the only one so far that works. EDIT: wrong forum, sorry. I can't delete or move it myself. =(

I think JimmyJack makes it more clear? Here's an example document. When you try to select the red rectangle, you can click through the purple object that has been cut, but not the whole one. http://oz.nfgworld.com/AD-test-2.afdesign (20kB) As for the layer thing, here's another sample AD document. In Inkscape, if you select the green triangle and move it down one level, it moves below the black rectangle immediately. In AD it first moves down past all the rainbow circles. Now I could move it to the bottom but this sort of avoids the problem, it's quite easy to imagine a document where this behaviour isn't good either. Basically, Inkscape considers the object's position and context, which is desirable behaviour IMO. http://oz.nfgworld.com/AD-test.afdesign(18kB) http://oz.nfgworld.com/AD-test.svg(5kB) ^ there's an SVG to load into inkscape if you so desire. They're the same content.

Hey! Stop derailing my thread! ;) I dunno, maybe I'm not reading you right, but you're not describing anything that I don't think I can already accomplish with groups and standard vector item stacking heirarchy. Not to say that you're wrong, but rearranging the vertical order of items, grouping them, and etc is... standard stuff. But this selecting-clear-space-only-if-object-is-closed is damnably weird. It's not at all consistent with the obvious care and attention heaped upon the rest of the app. As for moving things up or down, inkscape has a definite edge to user friendliness here. When I want to move an object below the one it's currently obstructing, it's unfriendly to ask me to do it 30 times because there are 29 objects somewhere else in the design. Having it drop all layers required to clear the one I'm obviously trying to avoid... I just don't see a good reason to want to have nothing happen 29 times. When would this behaviour be desired? Anyway, to be clear, I really like AD. I don't think I've come anywhere near scratching the surface of what it'll do, but I plan to buy it. This is good stuff and I want to encourage its development.

That's the part that makes no sense. If I cut it, it works. If it's two items grouped, it works. The way it's handled now seems entirely arbitrary, more of a "we've always done it this way" sort of thing, instead of something that makes sense. (I don't wanna sound like I'm harping on this particular issue, but it's really sort of a big one.)

Well, to be clear, I never use layers in vector art. I've never really needed to, since the objects are layered already. So yeah, not really sure if that applies or if I'm misunderstanding your point. ...or are you suggesting every object has its own layer? That's interesting, and certainly a little different than what I'm used to. I did notice that moving an object up or down causes it to cycle through -every- layer, where inkscape will move an object below only the ones that it's actually next to. So it won't take 10 steps to go beneath the item you see if the other 9 items aren't located near the selected one. Ahem, moving on. ^_^ Not being able to click an empty space to select the object under the mouse really seems more like fundamental logic error, more than new software weirdism. If I can click the clear space outside an object, I should be able to click the empty space inside it. -- Where did all my tool palettes go? They're all gone but the colour select box. I can't figure out how to bring them back again. <panics> EDIT: Found them. They'd slid around and were stacked on top of each other for some reason.

Hey guys, thanks for the answers. Yes, alt-clicking allows me to select the thing behind the thing. This is sort of weird to me, and I say that as a guy who's been working with vectors since like 1986. If an item is like a donut, hollow in the middle, then I'm very much accustomed to it not having any presence where it's not visible. In this respect AD seems to treat it like a raster with a 0% alpha component: it's there but you can't see it. Every other app I've used treats the parts where there's no object as not being part of the object. But with the alt-thing I think I can handle it. Thumbs up! As for #5, it's related to the alt-clicking thing. Basically, if I click where there's no object, I do not expect to grab that object. If I've previously selected it and click off the object (but still within the bounding box) I do not expect to grab that object. Blah blah 30 years of mucking with vectors, it's weird behaviour. (OMG I'm so old). The blur thing: I haven't actually FOUND it yet, was the issue. I figured it must exist because SVG images imported into AD handled the blur just fine. =)