turiya / ovt Goto Github PK

Placement depends on the cairo stroke_extents and fill_extents to bound the
objects being placed. This is slow and a bit error-prone.

The hangup is that I don't know the extents of text primitives without
cairo. Perhaps this will be a special case, but I should be able to remove
the dependency for other primitives.

The current exceptions were written without much consideration. They don't
provide much useful information and some are probably unnecessary.

When ticks or data scaling are determined from the data, prefer round
numbers near the real bounds rather than the real bounds themselves. This
should be easier to interpret.

Labels should be centered at the point given to the `Label constructor.
With regard to ticks, they appear just to the right of center.

These functions perform different kinds of bounding operations. Determine
exactly where each is used and consider whether both are necessary. Current
usage seems confusing and inconsistent.

The text formatting for labels is hardcoded. Intelligently decide how much
precision to use based on the values being shown.

All current OVT code resides in the single file prototype.ml. Split it in
to more manageable modules.

The proposal called for these and Yaron has since mentioned them. Get to!

Attributes like color and line thickness pertain to both primitives and
datasets. Some attributes are meaningful only for a subset of primitives
while others may apply to all. Some may have reasonable defaults. It will
be necessary to discriminate between a value specified by the user and a
default value. It would be nice for attributes to be as uniform as possible
across primitives and datasets. It would be nice to be able to add
attributes easily.

Endpoints are drawn as circles over the rectangle of the interval itself.
For  open intervals, this causes visible overlap in the open circle.

The OVT build process would likely be more robust if it could use ocaml
findlib to build with cairo-ocaml. Investigate adding the necessary support
to cairo-ocaml.

Building cairo-ocaml from cvs fails. To fix it, swap the order of includes
in src/ml_cairo_bigarr.c so that ml_cairo.h comes before caml/bigarray.h.
This fix should be submitted to cairo-ocaml.

The error:
{{{
make[1]: Entering directory `/home/yminsky/src/cairo-ocaml/src'
ocamlc.opt -ccopt "-g -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/libpng12  " ml_cairo_bigarr.c
ml_cairo_bigarr.c:13: warning: 'struct caml_bigarray' declared inside
parameter list
ml_cairo_bigarr.c:13: warning: its scope is only this definition or
declaration, which is probably not what you want
ml_cairo_bigarr.c: In function 'ml_bigarray_byte_size':
ml_cairo_bigarr.c:18: warning: implicit declaration of function 'Bigarray_val'
ml_cairo_bigarr.c:18: warning: passing argument 1 of 'bigarray_byte_size'
makes pointer from integer without a cast
ml_cairo_bigarr.c: In function 'ml_bigarray_kind_float':
ml_cairo_bigarr.c:24: warning: initialization makes pointer from integer
without a cast
ml_cairo_bigarr.c:26: error: dereferencing pointer to incomplete type
ml_cairo_bigarr.c:26: error: 'BIGARRAY_KIND_MASK' undeclared (first use in
this function)
ml_cairo_bigarr.c:26: error: (Each undeclared identifier is reported only once
ml_cairo_bigarr.c:26: error: for each function it appears in.)
ml_cairo_bigarr.c:28: error: 'BIGARRAY_FLOAT32' undeclared (first use in
this function)
ml_cairo_bigarr.c:29: error: 'BIGARRAY_FLOAT64' undeclared (first use in
this function)
ml_cairo_bigarr.c:30: error: 'BIGARRAY_COMPLEX32' undeclared (first use in
this function)
ml_cairo_bigarr.c:31: error: 'BIGARRAY_COMPLEX64' undeclared (first use in
this function)
ml_cairo_bigarr.c:36: warning: control reaches end of non-void function
ml_cairo_bigarr.c: In function 'ml_cairo_image_surface_create_for_data':
ml_cairo_bigarr.c:42: warning: implicit declaration of function
'Data_bigarray_val'
ml_cairo_bigarr.c:46: warning: passing argument 1 of
'cairo_image_surface_create_for_data' makes pointer from integer without a cast
make[1]: *** [ml_cairo_bigarr.o] Error 2
make[1]: Leaving directory `/home/yminsky/src/cairo-ocaml/src'
make: *** [all] Error 2
}}}

Allow the user to specify a label for each axis and place it appropriately.

The color should be used for plotting the data itself and should also
appear in the legend.

Placement eventually gets turned in to simple scene nodes, so make this
explicit by using a separate type for structures with placement
information. Polymorphic variants might be useful here.

Labels are currently placed at the upper right of a box bounding the
labelled object. Allow labels to be placed in some relatively flexible way.
It would be reasonable to start with Left of/Right of/Above/Below.

gallery.py checks for changes from the baseline by comparing image data,
not file data. This is necessary as Cairo writes timestamps to PNGs. If the
image data has not changed, gallery.py should not update the baseline as
this will cause needless commits.

Plotting 100k points is slow. Figure out how slow and see what improvements
are possible.

In addition to ticks, frame should support a grid decorator.

Time series and bar charts won't work well with the current tick labeling
scheme. Support labels which do not come directly from the tick's offset value.