ARC support for ellipse draw

[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