Re: Shouldn't Cairo use/offer degrees rather than radians?

Hi David.

I understand that this is kind of a clash of philosophies here, and the
mathematician in me very much sympathize with you in the sense, that
exact representations are helpful and important.

But the computer scientist in me thinks, that sometimes "good enough" is
good enough...

David Kastrup ([email protected]) wrote:
> It does change it because 180.0 has an exact representation with lots of
> trailing zeros in any floating point format in active use.  rational
> multiples of pi do not have an exaxt representation in any floating
> point format in active use.
> 
> > Obviously using integer degrees is too limiting for a library like
> > cairo, so we're always dealing with floats. And then there is no point
> > to offering degrees.
> 
> The point is that exact multiples of right angles are representable.
> The point is that _every_ _single_ use of cairo_rotate with a
> non-arbitrary angle in the Cairo codebase itself has to factor in M_PI
> in some manner.  The point is that
> 
> cairo_rotate
> 
> is unable to produce the transform matrix
> 
> [ 0 1 0
>  -1 0 0 ]
> 
> with any argument you give it.

Lets see:

#include "math.h"
#include "stdio.h"
#include <cairo/cairo.h>
#include <cairo/cairo-pdf.h>

int
main ()
{
  cairo_surface_t *surf;
  cairo_t *cr;

  surf = cairo_pdf_surface_create ("bla.pdf", 100, 200);

  cr = cairo_create (surf);
  cairo_translate (cr, 50, 100);
  cairo_rotate (cr, M_PI / 2);

  cairo_move_to (cr, 30, -30);
  cairo_line_to (cr,  0, 30);
  cairo_line_to (cr, -30, -30);
  cairo_close_path (cr);

  cairo_stroke (cr);

  cairo_show_page (cr);
  cairo_destroy (cr);
  cairo_surface_destroy (surf);

  return 0;
}


and lets decompress the resulting PDF:

[...]
3 0 obj<< /Length 138>>stream

q
   0 0 0 RG  /a0 gs  2 w  0 J  0 j  [] 0 d  10 M
   q
      0 -1 -1 0 0 200 cm  130 -80 m  100 -20 l  70 -80 l  h  130 -80 m S
   Q
Q

endstream
endobj
[...]

Oh, look. It is a perfect 90° transformation matrix! Surprise  :)

My point is, that the precision is high enough for all practical
purposes and that adding a lot of complexity to the cairo code to ensure
that some special angles are guaranteed to end up in some special
transformation matrices isn't really worth it and just adds headache to
maintaining the code.

(Btw. the SVG example looks a bit more crude:
"transform="matrix(0.000000000000000061,1,-1,0.000000000000000061,50,100)",
but I'd like to argue that cairo really should put out the numbers with
less precision here.)

> >> So why not provide degrees (and use them internally) for Cairo?

Because to my knowledge cairo doesn't store angles internally, it
alwasy uses transformation matrices...

Bye,
        Simon
-- 
              [email protected]              http://simon.budig.de/
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo