(Realted to flot issue #1031: https://github.com/flot/flot/issues/1031)
Currently, if the user declares a custom color palette with less than 5 colors (say, n), $.extend(true, options, opts) only modifies the first n colors of the default palette and leaves the last 5-n in place. When the number of series is >n, colors are used that are not part of user-defined palette, contrary to description of colors array in API.
This line overrides the extended colors array and replaces it with exactly the user-defined colors array, when present. Afterwards, the user color palette is respected by the auto tinting/shading system for when there are more series than colors.
Resolves#1016. Initialization consists of adding the tickGenerator and
tickFormatter functions to each axis. This should happen exactly once
per plot, but since the code was previously using the processDatapoints
hook, it was called once per series. When no series were present, it
ran zero times, triggering an exception when we later checked for the
existence of the functions.
Binding to the processOptions hook ensures that the axes are always
modified once, regardless of how many series there are. The axes are
already initialized by the point the hook runs, so this change shouldn't
cause any problems.
Resolves#1000. In Flot 0.7 we only calculated tickDecimals and
tickSize once, when creating the tickGenerator for the first time. This
meant that calls to setupGrid failed to recalculate the values, as
reported in #860. #861 fixed the problem by moving calculation into
tickGenerator, but this turned out to cause a new problem, since the
function doesn't run when an explicit ticks array is provided.
This commit solves both by always recalculating the values outside of
the tickGenerator function. As far as I can tell the only reason it
wasn't done this way from the beginning was to avoid unnecessary work in
the case where tickGenerator is already provided in the options. But
the extra work is negligible, and it's actually more consistent for the
properties to always be set.
Ole's original implementation used 'middle', which I switched away from.
After a great deal of testing it turns out that 'middle' does in fact
provide the most consistent results, so we're switching back to it.
The values don't change, so there's no reason to repeat those
calculations on every redraw. The resulting code is not just faster,
but also smaller and simpler, and we no longer need to store halign in
the text info object.
The core implementation used parseInt, which was originally to catch
text values, but really only stayed due to its side-effect of flooring
the values. The canvas implementation has never rounded coordinates.
This led to various one-pixel rendering glitches between the two
implementations. I've fixed the problem by consistently rounding
coordinates to the nearest whole number.
Line height is a core font property - it can be specified as part of the
unified 'font' definition - and we therefore need to give users access
to it when they're manually defining the font.
The way in which xaxes/yaxes inherit options from xaxis/yaxis resulted
in a minor bug, where tickColor defaulted to the xaxis/yaxis color
instead of the color for its axis. Fixed by applying the default before
extending the per-axis options, resolving #984.
There's still some questionable behavior here; this section should be
revisited for 0.9, especially with an eye towards removing some of the
code that only exists for backwards-compatibility.
This resolves#991, replacing the earlier temporary patch. It takes
advantage of the fact that line-height can take the form of a unit-less
integer, in which case it mirrors the font-size, even when it is
something abstract, like 'smaller'. We can then read the dummy
element's height to learn the effective font-size.
The purpose of the stylesheet hack was to provide a default without
having to use inline styles on containers. We can do this much more
neatly by instead just giving the inline styles to a parent container,
leaving users free to customize the children.
Add an extra pixel to ensure that the lines cleanly join both top and
bottom ticks. Also apply the sub-pixel offset only in the necessary
direction, so the lines don't start a pixel off from where they should.
The axis color now controls the color of the axis line, instead of its
ticks and labels, while the tickColor controls the tick color. This
makes a little more sense and provides the minor feature of being able
to change the axis line color separately from that of its ticks. Pull
request #917 ought to be easier to merge now, too.
Plugins are re-initialized with each re-plot (which may not be the right
thing to do, but that's how it works for now). The previous approach of
saving references to the original Canvas functions therefore broke,
since the second time around we'd get a reference to our new function.
Instead we hold those references as globals within the plugin, and only
set them once.
This whole idea of replacing prototype functions is, now that I step
back and look at it, really awful. This needs to be changed ASAP to
something less ridiculous.
This allows us to reuse the canvas elements without having to retain the
rest of the Canvas object, which should really be reset when the plot is
reconstructed. It's also a little simpler, and the Canvas constructor
just feels like the right place for this code.
David Schnur
Nicolas Morel
goorpy
Brian Peiris
Lee Willis
Daniel Shapiro
vird