ARC support for ellipse draw

[Tim Wessman]

I was thinking about this today. How would people feel about this?

Currently we have:
ARC(G, x, y, r, [[∠1, ∠2],[color]])

How would you feel about making it as such:
ARC(G, x, y, r|(r1,r2), [[∠1, ∠2],[color],[color]])

Basically, add in a second color for fill and border (like rect), but more importantly allow ellipse drawing if you give a pair of r values in a complex.

There isn't a way that I can see to support ellipses without either a) this described method or b) a separate command, without potentially introducing backwards compatibility issues.

Better suggestions?

[Han]

(02-26-2015 03:35 AM)Tim Wessman Wrote:  I was thinking about this today. How would people feel about this?

Currently we have:
ARC(G, x, y, r, [[∠1, ∠2],[color]])

How would you feel about making it as such:
ARC(G, x, y, r|(r1,r2), [[∠1, ∠2],[color],[color]])

Basically, add in a second color for fill and border (like rect), but more importantly allow ellipse drawing if you give a pair of r values in a complex.

There isn't a way that I can see to support ellipses without either a) this described method or b) a separate command, without potentially introducing backwards compatibility issues.

Better suggestions?

I would rather there be a new command than possibly break an existing command. EARC() (elliptic arc) perhaps? But if we are going to take that route, why not provide an arc command that builds an arc from b-splines?

[DrD]

The idea presented is similar to LINE() in that there would be a 'simple' and an 'advanced' form. I think it might be an advantage to keep just ONE command with a simple and an advanced form, rather than multiple commands. A problem with multiple commands performing similar tasks shows up when trying to quickly search for the needed command as one is building a program.

[Tim Wessman]

I don't see how the proposal could break the arc command. It just doesn't seem like adding a complete new pair of functions would be justified.

provide it a real, it interprets as a single radius. Provide two packaged into a complex, and it interprets as two real values.

???

[Han]

(02-26-2015 06:39 PM)Tim Wessman Wrote:  I don't see how the proposal could break the arc command. It just doesn't seem like adding a complete new pair of functions would be justified.

provide it a real, it interprets as a single radius. Provide two packaged into a complex, and it interprets as two real values.

???

No, I don't think it would break the ARC command nor cause backward compatibility issues. The reason I suggested a new command is because a complex number can be written as either a+b*i or (a,b), with the latter being fairly common (fewer keystrokes). In the past, we have seen far too many issues with commas (number separator vs digit separator or , vs ; for separators, etc). With a new command, you can specify whatever you want for the arguments (so as to avoid using a complex number). I don't know the inner workings of the parser, so perhaps a simple switch in object type would suffice to add this feature to the existing ARC command.

[StephenG1CMZ]

If there is any possibility that this could ever be extended into a third dimension, a list would allow {r,r} to eventually become {r,r,r}, whereas a complex number could not be extended.

[Tyann]

Pour moi une nouvelle instruction serai préférable.
Les instructions complexes sont difficiles à mémoriser et peuvent être sources d'erreurs.


For me a new instruction will be preferable.
Complex instructions are hard to remember and may be sources of error.

[Arno K]

Well, the idea of having more capability is cool, but the more there is provided, the more is to be remembered. Is the hardware strong enough to provide something similar to IntelliSense in visual studio, this would be a cool feature and very helpful.
Arno

[Martin Hepperle]

Tim,

in general I prefer to have a small number of commands. The compexity of parameter lists can be handled with the built-in help. I think it is easier to remember 20 clearly different commands than 40 slightly different commands.

If two commands basically do the same thing they should be given the same name and be intelligent enough to decode the parameter types (method overloading).
E.g. if only one radius value is given we would obtain a circle, if an array or list of two values is given we would see an ellipse.

I think the old graphics interfaces in languages like Borland Turbo Pascal or C (the famous BGI), MS Quick-C and such (even FORTRAN for the PC) are useful examples of having a small but powerfull set of graphics functions.
Also older graphics standars like CGI or GKS may be useful to get some ideas.

Combined with coordinate system transformations (translate, scale, rotate), one has a complete set of drawing functions. The description should also be extensible to the 3rd dimension, even if not implemented now.

Sometimes they have two sets of functions allowing to produce hollow shapes and filled shapes. Like DRAW_ARC and FILL_ARC. Sometimes both commands are merged and controlled via the argument list. I really would recommend to have a look at the old DOS languages.

The description of the parameters common to all shapes (arc, pie, rectangle, polygon, ...) should be the same in style and order:

• G - the GROB to draw on,
• +specific parameters depending on shape,
• outline - line style (none, solid, thickness, dotted...), color (tint, transparency, gradient),
• fill - style (hollow, filled, pattern), color (tint, transparency, gradient).
  

It should be made clear whether angles are true angles (in isotropiic or non-isotropic scaling modes) or relative. If I draw a elliptical arc from 45 to 90 degrees, will these angles be true in a 2:1 scaling?
Same for other rotational transforms.

Martin