Flot 0.8.0 used the default font size, typically derived from the
placeholder, as the basis for the default lineHeight. This produced
incorrect results when a font.size was provided explicitly, and it
differed from the placeholder’s CSS size.
Fixed by waiting to default lineHeight until the actual font size has
been resolved. Fixes#1131.
Flot 0.8 added logic to account for the size of axis tick labels and add
padding around the edges of the plot, to prevent long labels from
sticking out. But it padded both sides equally, which is incorrect if
the right/top side has no last axis label.
Fixed by allocating padding per-side, and checking whether the last
label would be shown before padding the top or right. Fixes#1048.
The fix for #1056 caused a regression where grid lines were drawn for
the innermost axes on both sides instead of just the first axis.
Fixed by properly distinguishing the first axis in each direction from
the innermost one on each side. Fixes#1075.
The autoscale check was too broad; it included the case where autoscale
was undefined. This resulted in axes not expanding correctly when
coordinates at the end of a series had null x or y values. Fixed by
narrowing the check to !== false; resolves#1095.
This is up to 2x faster and appears to work around issues in Chrome's
canvas implementation that sometimes result in bars not being filled.
Resolves#915.
Throwing an exception was overkill for such a limited-use option; we
should reserve those, and the file-size bytes they consume, for serious
cases only.
Support for right-aligned bars was never added to the hover or highlight
code; only the actual bar drawing. We need to replicate that in the
other two places as well.
Resolves#1093.
Since a plot may be redrawn after removing ticks or hiding the axis,
the tick text should always be removed before determining if there are
ticks to draw.
An axis is innermost when it's first among those not just in its
direction, but also on its side, i.e. left/right, of the plot. So the
inArray check should be against the samePosition list, not all.
Resolves#1056.
Resolves#1032. Previously it was impossible to draw the same text,
with the same style, in two different locations, because the second
would end up using the first's cache entry, which only ended up moving
the element to a new position.
Now each cache entry holds a list of positions at which the text
appears, creating clones of the original element for each position
beyond the first.
Flot 0.7 calculated x-axis label dimensions by assigning each label a
fixed width, then measuring the height as determined by the browser. A
side-effect of this technique is that x-axis label divs received a fixed
width. The rewrite of the text system in 0.8 accidentally removed this
feature; this patch restores it.
(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#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.
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.
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.
David Schnur
Anthony Ryan
Benjamin Gram
Luis Silva
Craig Oldford
Thodoris Greasidis
Eric Byers
Mark Côté
goorpy