Ensure that axis lines align with their ticks.

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.
Avoid an unnecessary intermediate variable.
Fix highlight and unhighlight inconsistency.

The unhighlight method retrieved the point differently from highlight,
and incorrectly.  It now matches the behavior of highlight.
Short-circuit when removing all highlights.

There's no need to continue in the function when all highlights are
being cleared.
Temporary patch for font-size parsing issue.

This partially addresses #991, but a more complete solution, or better
documentation, is still necessary.
Replace the stylesheet hack with inline styles.

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.
A better fix for the font-size 'smaller' problem.

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.
Move time-specific options into the time plugin.
Fix incorrect default for xaxes/yaxes tickColor.

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.
Give the example placeholder its own line-height.

This way it doesn't inherit from something further up, whose line-height
may be more or less than we expect.
Added lineHeight to the font-spec object.

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.
Tiny optimization; don't set info.y twice.
Round text coordinates consistently.

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.
Set the text baseline only once.

The setting is the same for everything, so there's no reason to re-set
it every time.
Pre-compute coordinates for each line of text.

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.
Use actual line height for canvas text rendering.
Switch back to 'middle' baseline rendering.

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.
Always recalculate tickDecimals and tickSize.

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.
Updated credits for #987, #861, and #1000.
Re-interpret zoom range to be an absolute range

Re-interpret zoom range to be an absolute range instead of the range of
possible widths.