Jump to content
You must now use your email address to sign in [click for more info] ×

Inexact description


Recommended Posts

I have noticed that when I open/import an SVG image, in the layers list, where it lists all the objects, it says (Curve) to the right of polygon objects. This, while not a major issue, is inexact. A polygon is not a curve. A polygon is a geometric figure completely defined by a set of points connected by straight lines.

 

Adam

 

post-32179-0-61842300-1469845713_thumb.png

Link to comment
Share on other sites

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.  =)

Link to comment
Share on other sites

A straight line is a special kind of curve, in the same way as a square is a special kind of rectangle. In my view, using the term 'path' instead of 'curve' is less than ideal since a curve has a weight or width but a path doesn't.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

A straight line is a special kind of curve

 

Well, English isn’t my native tongue. But in my own language I was always taught there were straight lines and there were curved lines. So, a curve is a special kind of line, but a line, let alone a straight line, is not a special kind of curve.

 

Anyway, as I said, this is not a major issue to me, so I have no interest in getting into a debate here.

Link to comment
Share on other sites

A straight line is a special kind of curve, in the same way as a square is a special kind of rectangle. In my view, using the term 'path' instead of 'curve' is less than ideal since a curve has a weight or width but a path doesn't.

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.

Link to comment
Share on other sites

A straight line is a special kind of curve...

 

 

Correct.

 

Affinity, like all other mainstream drawing programs, creates Bezier curves. All Bezier curves are mathematical curves, be they straight or not. A series of connected Bezier curves is what drawing programs generically (and the SVG format specifically) refer to as "paths."

 

A cubic Bezier curve takes as variables four coordinate pairs. Two mark the start and end of the curve. The other two influence its curvature as it is plotted from start to end. A curvature of zero is still a curvature. Just think of it as a curvature with an infinite radius, if you must. Consider: Even a "straight" Bezier curve may have one or both of its middle two coordinate pairs (so-called "handles") extended. And that affects the curve, even if it is "straight." That's why, for example, it can be used to affect the distribution of interpolated Blend steps along that "straight" line.

 

"Polygon" has its own programmatic meaning in SVG, distinct from "Path". Path objects and Polygon objects in SVG take different parameters. So I don't want Affinity calling a path (connected series of Bezier curves) a "polygon" just because it happens to be polygonal in shape--especially one imported from an SVG file. Doing so would suggest that Affinity is respecting the parameters of an SVG Polygon object, which it does not.

 

Affinity is not a specifically SVG-oriented editor. Inkscape is. In fact, Inkscape provides an XML Editor palette. (SVG is a subset of XML.) If you:

 

1. Launch Inkscape and open a new document

2. Use Inkscape's Polygon Tool to draw a Polygon

 

...then as long as you are in Inkscape, that native object acts like a special Polygon object; one which takes radius and number of sides as its parameters, just as one defines a Polygon in SVG code. But if you:

 

3. Select the Polygon object

4. Open the XML Editor

 

...you will see the object listed in the XML not as a Polygon, but as an SVG Path, because that is how it is going to be written if you Save As any of the several SVG formats other than the Inkscape-native InkscapeSVG format. So if you do both:

 

5. Save the file as Plain SVG

5. Save the file as Inkscape SVG

 

...and then re-open the files in Inkscape, you will find that the path in the Plain SVG file is just a path, but only the one in the Inkscape SVG retains the native Inkscape-specific Polygon parameters still intact and adjustable.

 

Both of those files can be opened in Affinity as well. Doing so, you will find that both of them bring in a simple path; neither will have the Polygon adjustable parameters, because those parameters were native to Inkscape.

 

Affinity also, of course, provides its own native Polygon Tool, which also provides live editable parameters, including (among other things) number of sides, but otherwise somewhat different from those in Inkscape's native Polygon objects. And Affinity does, indeed, label objects created with its Polygon Tool "Polygon". So I wouldn't want an ordinary path to also be labeled a "Polygon" in Affinity, because, just as in Inkscape and in SVG language, a Polygon and a path are different constructs in Affinity.

 

Since Affinity is ostensibly to be a "professional" level drawing program, I'd personally prefer the program label its native objects what they, in fact, are. That is less ambiguous than the confusion caused by "too friendly" terminology in other programs. I wouldn't have any big problem with Affinity generically calling the imported polygon-shaped path a "Path" instead of a "(Curve)" but that would be rather redundant, since it does name the object "path xxx". "(Curve)" tells you what it is: a [series of one or more] Bezier curve(s).

 

JET

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

...​a Bezier path with no curve handles is a straight line.

 

 

A straight Bezier curve still has handles. They are simply coincident with the start and end coordinate pairs. "Straight line" is the "inexact" term. "Curve" is the accurate mathematical term for what a Bezier curve expression describes.

 

 

A zero-radius, zero-bend line is not a curve by anyone's definition.

 

 

I didn't say zero radius, I said infinite radius. And I said think of it that way if you must because there is no radius involved in the Bezier curve formula. The "anyone" you're overlooking is a mathematician speaking in the context of a Bezier curve (and other formulae). Or me. I'm no mathematician, but I still know this, as do a lot of other illustrators.

 

Wikipedia, the infallible source...

 

 

Okay. Also from Wikipedia:​

 

"...a curve is a generalization of a line in that curvature is not necessarily zero." (Emphasis mine.)

 

If we were to vote, I'd say they should be called paths.

 

 

And Affinity is doing that. But it is also providing its technically correct native object type in parenthesis Example:

 

path4136 (Curve)

 

I consider that quite admirable and befitting an ostensibly "professional" software. Would that other drawing programs making that same claim were as careful with terminology.

 

Suppose, just on a whim, that Affinity (being a professional level program) were to eventually add its own JavaScript object model, so that we users so incline could add powerful new functionality of our own design to the program (as Illustrator users do today, and as Draw users do also, but with VBA). Trust me, those of us so inclined would be very happy to find that the object names in the scripting model actually agreed with those used in the general interface.

 

JET

Link to comment
Share on other sites

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

Link to comment
Share on other sites

NFG, you're not listening. Again: Bezier curves do not have a radius variable.

 

Various programs do all kinds of things in their interfaces and their terminology to "insulate" beginners from the "anguish" of understanding what they're actually doing. It often leads to more confusion downstream. (Spend some time in the Adobe Illustrator forum and you'll see endless examples.)

 

Again: Serif has stated from the very start that this program is intended to be a serious vector drawing program for professional illustrators, not yet another cheezy, feature-cluttered program for hobbyists who won't read instructions. Take a look at professional software in other disciplines (CAD/CAE programs, for example). The last thing you want them to be is sloppy with terminology.

 

Here's an example of what I'm talking about when I raise this "professional" vs. "consumerish" point:

 

When I first laid hands on the beta, one of the first things I looked for was the "missing" fields or dialog by which to scale an object by percentage, disproportionately; something necessary for mechanically-correct axonometric drawing. I hate to admit it, but over the decades, I'd become so acclimated to the endlessly gratuitous, overly explicit separate command or dialog or button or fields for every little detail in mainstream general-purpose drawing programs, that I actually thought they'd left out such a fundamental capability.

 

Until, of course, I realized that they'd made the value fields able to take simple math operators. So you don't need separate %Height and %Width fields in a modal dialog, like Illustrator. You just type a multiplication symbol and a value in the H or W fields in the tidy, space-efficient Transform palette.

 

Moreover, unlike Illustrator, you can key both multiplication/division and addition/subtraction math operators into the value fields in one move. (Ex: you can key "15/16-.25" and the field will evaluate it.) FreeHand could do this over two decades ago. Illustrator only recently gained the ability to evaluate a single math operator in some of its value fields with no control over the accuracy of its infernal rounding.

 

(Keying parenthesis into the fields will cause the program to crash--something I need to remember to report.)

 

Is that "less immediately intuitive" for a hobbyist or a child than providing explicit separate scale-by-percentage fields? Yes. But it's also faster, less cluttered, and more efficient (i.e., elegant) for someone making a living, once he endures the few seconds of "anguish" of realizing it's there.

 

And see? Just think: You've already survived the "anguish" of coming to realize that every path segment in a Bezier drawing program is technically a curve, before the first version has even gone up for sale. ;-)

 

So no, I don't want the labeling of Curve objects to be changed to "Polygon" just because the path happens to be polygonal in shape, and I don't want it to be labeled a "Line" just because the curve happens to be straight. It is what it is: it's a native Curve object. And it already names the specific object "path", so why aren't you happy with that?

 

The tern "Polygon" is already taken (appropriately) for an Affinity-specific construct. I don't care to see the term "Line" used unless and until a "Line" becomes a similarly special-case native object type with its own special parameters (as it is in some other programs).

 

This thing still has a long way to go toward becoming sufficiently full-featured to be commensurate with the claimed "professional- level" intent. Every effort to integrate functionality and avoid ambiguous terminology needs to be jealously guarded in order for functional elegance to survive. Otherwise, it just becomes another "me, too" consumerish piece of drawing software.

 

JET

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Staff

Hello guys,

 

The naming is intentional and won't change - if your object is of type "Polygon" (i.e.. a procedurally generated polygon shape) - then it will say "Polygon".

 

Once something is "Convert to Curves" (or just drawn using the pen tool) - it will say "Curves" - because inside, they are Bezier curves (even if they contain straight line segments).

 

This is the only time I've seen this naming question raised in over two years - so given all the other things which need fixing we won't be making changes in this area.

 

Thanks,

 

Andy.

Link to comment
Share on other sites

Except it doesn’t. It says curve.

 

A polygon drawn with the Polygon Tool shows as '(Polygon)' on the Layers panel. A trapezoid shows as '(Trapezoid)' and a cat shows as '(Cat)'. As Andy has said, these show as '(Curves)'* once converted to curves.

 

A polygon drawn with the Pen Tool in 'Straight Line' mode is immediately (i.e. without any conversion steps) listed a curve, as I would expect.

 

________

*Actually just '(Curve)' if it's a single curve such as a star or a trapezoid.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

A polygon drawn with the Pen Tool in 'Straight Line' mode is immediately (i.e. without any conversion steps) listed a curve, as I would expect.

 

And some programs provide a separate Line Tool and differentiate a "Line" as a dedicated native shape primitive with its own unique parameters (length and angle). I prefer Affinity's treatment for this of providing the "line mode" for its Pen Tool, rather than cluttering the interface with another unnecessary tool icon. This, combined with Affinity's stricter preservation of the rotated bounding box measures, fulfills most uses for a separate Line Tool; that's the kind of elegant feature integration I like to see in a serious drawing program. So I wouldn't want the native object designation to try to decide for me which ordinary path(s) to label as "Lines", either.

 

As I said from the start, I wouldn't have any heartburn over "Path", but I also have no problem with the more technically-accurate "Curve"; they are, in fact, Bezier curves.

 

But it would be nice to see length and area for any path, as other programs provide (Canvas, for one example).

 

(How I long for another program to centralize its interface on the omnipresent Object Inspector (like Freehand) instead of these "control bars" across the top of the main drawing window, which so often seem "schizophrenic" as if struggling with whether they are a tools option bar or an object attributes bar.) 

 

JET

Link to comment
Share on other sites

A polygon drawn with the Polygon Tool shows as '(Polygon)' on the Layers panel.

 

That has no relevance for this. This thread is about a polygon in an SVG file opened in AD, a file which has a polygon (actually many of them) drawn using the SVG polygon element, which, as its official definition says, “defines a closed shape consisting of a set of connected straight line segments.” When opened in AD, all those polygons show as curves, not as polygons, as clearly illustrated in the enclosed screen cap.

 

Why is it that every time someone reports some issue with the Beta on this forum, it is like having a tooth pulled? People start jumping at him, quoting all kinds of straw men, trying to prove him wrong. Why? We are volunteering our time and resources to Beta test a product someone else will make a ton of money on, yet we are treated as we were a stupid bunch of nincompoops.

 

Adam

Link to comment
Share on other sites

Why is it that every time someone reports some issue with the Beta on this forum, it is like having a tooth pulled? People start jumping at him, quoting all kinds of straw men, trying to prove him wrong. Why? We are volunteering our time and resources to Beta test a product someone else will make a ton of money on, yet we are treated as we were a stupid bunch of nincompoops.

 

I was merely responding to what you wrote in response to Andy Somerfield, where you seemed to be "jumping at" him. I am volunteering my time, just as you are. We are all exercising our right to express our opinions.

 

If you think that a polygon imported from an SVG file should come into AD as a procedurally generated polygon shape (with all that that implies in terms of its adjustability) then perhaps you should make a feature request. In the meantime, if AD imports a polygon as a bunch of connected straight lines, it seems perfectly reasonable to me that it should label the object as '(Curve)'.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

That has no relevance for this.

 

But it does. Affinity already has its own definition for a "Polygon". An Affinity-native Polygon object has parameters which an imported SVG polygon does not. For one example, its bounding box is offset so as to center the geometric center of the shape on the center of its bounding box. (So that if you later rotate, it, it rotates about its geometric center, which is usually what someone wants when rotating a triangle or a star about its "center.")

 

Affinity's SVG import filter simply does not translate an SVG polygon into an Affinity native Polygon, adding the extra functionality associated with a native Affinity Polygon object. It imports it as an ordinary path defined simply by its array of Nodes. I wouldn't want Affinity calling both an ordinary path and its own more functional native Polygon construct a "Polygon". That would just be confusion. The selected object should be labeled what it in fact is, in accordance with the object type definitions of the program.

 

This is no different in principle from, for example, importing into Corel Draw an Adobe Illustrator file containing what Illustrator terms a "Symbol" or a "Brush" or a "LivePaint Group" as ordinary paths, because Draw's application-specific native constructs are not the same as Illustrator's application-specific native constructs. Corel Draw has no idea what a "LivePaint Group" is.

 

Anytime you import into any application a native file from another application (even when it's called "opening" rather than "importing"), everything is still getting translated into the native constructs of the importing program. This quite often requires "dumbing down" the incoming objects to their more basic underlying constructs. In this case, Affinity is not "dumbing down" anything by interpreting an SVG polygon into an Affinity-native ordinary path. But it's also not "smarting up" the incoming SVG polygon to what "Polygon" means in Affinity, which is what it would have to do to avoid inconsistency.

 

So suppose Affinity did assign the object type of "Polygon" to an imported SVG polygon. Suppose you then bent one of its segments. Would you expect Affinity to automatically rename the object "Path" or "Curve" because it now violates the geometric and SVG definition of "polygon"?

 

If one expects Affinity to label as "Polygon" an ordinary path which it interprets from an SVG polygon object, then one should also expect Affinity to do the same with any ordinary closed path drawn with Affinity's Pen which happens to consist of all straight segments. But again, that would be folly, because a Polygon object in Affinity has special meaning and additional functionality.

 

Even Inkscape, which is expressly SVG-centric (SVG is its "native" file format), has its own native meaning for "polygon" because, like Affinity, it provides more functionality for objects of that type than SVG code supports. Inkscape (quite reasonably) combines stars and polygons in a single tool. For example:

 

Use Inkscape's Star Tool to draw a path with 5 corners. Click the Polygon icon in the options bar. Save this as any of Inkscape's various SVG flavors (InkscapeSVG, PlainSVG, OptimizedSVG). Open the resulting SVG files in a text editor. You'll find that none of the resulting objects are coded as SVG polygons. Even using InkscapeSVG format, the path is defined as a star, not a polygon, and even then is contained in the Inkscape-specific sodipodi XML. In the other SVG formats, it is coded as an SVG path object.

 

JET

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.