Next message: Tony Cook: "Re: Ellipses & Antialiasing"
2008/4/17, Tony Cook <email@example.com>:
> On Wed, Apr 16, 2008 at 12:11:53PM +0200, Bruno Czekay wrote:
> > 1. At the moment, Imager does not support drawing ellipses (or arcs of
> > elliptical shape). Is this feature somewhere near on the TODO list?
> AFAIK it
> > depends on some new C function in the underlying library.
> This is the first time I recall anyone asking for it.
To be honest, I ask because some time ago I was involved into creating some
image-for-PDF-generator and I've sticked to Imager (which still seems very
good decision for me!). Now the customer wants to use some SVG implants,
which in turn means having possibility to draw an ellipse (just in case)...
A complete ellipse, with the axes of symmetry parallel to the X and Y
> axes is pretty simple to support.
> Complexities include:
> a) when drawing a pie segment, are the angles specified the real
> angles (since the scaling changes the angles if you just use sin() and
> cos() directly) or the angle before scaling? I can see cases where
> both are useful.
This is right. However, as the basic function should drive ellipse (or
ellipses arc), calculating right angles should bother the function that
creates piecharts, not ellipses. So I suppose "an angle" should mean "an
angle of the ellipse", not "an angle of the skewed circle".
b) can you control the angles of the axes of symmetry? (the axes would
> remain at right angles to each other) Does this change the effect of
> the d1 and d2 parameters?
I assume the right angle (pi/2) between axes. Fancies can be obtained using
Matrix2d->shear (correct me if I'm wrong).
I've added this to the TODO list.
I've been thinking about using Bresenhams algorithm - for lines, arcs,
circles and ellipses. However, I wouldn't like to mess with your plans
regarding the code. If I could be useful, I'll ask my boss if I could spend
some "official time" with it.
> 2. In the POD for Imager::Draw one can read "box, arc, do not support
> > antialiasing yet", however there are calls to functions like i_circle_aa
> > i_arc_aa. I tried an arc with aa => 1 and it works fine (hovewer it is
> > filled, as the POD says).
> You're right. Anti-aliased arc() fills were added in 0.46. I've
> corrected the BUGS section for the next release.
I suppose it would be also nice to have a possibility to draw an empty
(transparent) circle/arc/line/box/polygon of a given thickness.
Thank you for your support
Best Regards, Bruno