Original author: dsim...@gmail.com (July 14, 2009 12:26:32)
If I create links out of the x-axis label, they are unclickable because the
span of the other labels around it are "over" it. I'll try to create a
patch to correct it as soon as possible.
Original issue: http://code.google.com/p/flot/issues/detail?id=191
From dsim...@gmail.com on July 14, 2009 13:40:05
Created a patch for it. Tested against examples and it's working.
From olau%iol...@gtempaccount.com on August 06, 2009 12:35:20
I don't think your solution is general enough. Even if it works in the examples,
other people might be relying on the current constant. We either need a completely
different approach or some kind of heuristic.
Just to make sure you're aware of it: you can always fix it for your own graphs by
setting xaxis.labelWidth in the options.
From jmulder on August 28, 2009 23:19:25
As part of implementing Flot in our work I had the need to solve this problem as
well. I solved it by writing an algorithm that does the following:
1. Render all labels off screen
2. Find the widest label for consistency sake
3. Store width of widest label
4. Calculate maximum number of labels based on plot width and label width
5. Determine the Nth label of the collection that has to be shown to achieve an
evenly distributed list of labels along the axis
6. Loop through the labels and clear the determined labels
7. Finally, always check and possibly clear the last label of an X axis (to
prevent it from overflowing the entire canvas)
I am planning to look at my current code more closely and also do some extensive
testing before I'd like to contribute a patch to this issue. I expect to do this
somewhere early next week (august 31st).
PS. This is part of several enhancements I made to Flot's code base which I'd like to
offer (for example configurable label alignment and week based x-axes).
From jmulder on August 31, 2009 15:10:51
Attached is the first version of the patch
(flot-label-alignment-and-distribution.patch) that does the above. It also introduces
the ability to align the labels relative to their ticks (left, center or right).
These two functionalities can be separated, if you'd like, but they live intertwined
in our build right now and were both needed to achieve the intended result
A summary of the changes and rationale:
Introduction of configuration option titled 'cssSuffix' per axis
I added this to allow for per axis CSS styling and to easily find() specific labels.
This CSS class is added after the global 'tickLabel' class used on all labels.
Reordering of HTML structure of labels
To ensure correct calculations for label widths independant of CSS styling applied to
it I had to use a seperate container to enclose the labels. The container is
positioned, whereas the child contains the 'tickLabel' CSS class.
Copy axis options to axis variable in Plot.processData()
Many of the functions in Plot that deal with axes are written in a way that they do
not need to know the type of axis they are dealing with. Continuing this design I
felt it was necessary to copy the axis options for each axis when processing the data.
However, this is directly related to issue #193 (
http://code.google.com/p/flot/issues/detail?id=193 ). I think it would be better to
finalize this approach and use that solve my original problem.
Off-screen rendering of x-axes in Plot.measureLabels()
Simply used to find the largest label on an x-axis. This code could solve issue #211
( http://code.google.com/p/flot/issues/detail?id=211 ) but doesn't right now, as I'm
unsure whether the proposed solution is the correct one.
Usage of outerWidth() and outerHeight() to measure labels
This is a result of change 1 and 2.
Changes in Plot.addLabels() are a result of all of the above.
cleanLastLabel() in Plot.addLabels() is a separate routine to check whether the
last label is overflowing the plot area.
Plot.distributeLabels() is the function that ensures labels on an x-axis do not
overlap by clearing the tick of a label. I still render the HTML for styling
possibilities (e.g. a small tick).
There's still room for improvement, but I tried to keep my design decisions in line
with the current design direction of the code. Comments and criticism are welcome!
What is left is extensive testing with multiple axes and use cases. For what it's
worth: doesn't look like it breaks any of the provided examples.
From olau%iol...@gtempaccount.com on October 07, 2009 15:37:13
I skimmed the patch, it looks fine. I have two reservations though:
1) The "cssSuffix", can't we just autogenerate it? Do we really need to expose it as
2) Did you test how fast the measuring step is? I originally did something like this
when I started the project, but at that time it was really slow. I need reasonable
reassurance that it is not taking disproportional amounts of time with a slow machine.
From pug...@gmail.com on October 13, 2009 18:07:50
Works well for me so far. Thanks, this really helped clear up annoying display issues.
You mention that:
"7. Finally, always check and possibly clear the last label of an X axis (to prevent it from overflowing the entire
Could you instead make this a configuration option? It looks very odd to have a conspicuous blank at the end
of my x-axis. Right now I've commented out the check, and it looks much better. I don't mind the slight
overflow as I have all my graphs contained in another div with ample padding.
From jmulder on October 22, 2009 08:52:41
@ole, yes, the cssSuffix should be generated. Reason I didn't is for impact sake. I
looked into doing this initially but found I wanted to do some more refactoring to
really make this worthwhile. There was this other issue and patch that required the
naming of axis (instead of relying on the property name).
I haven't done any speed testing. I agree this needs to be done before this
functionality can be integrated into the plugin. I suggest we keep this patch here
and I try to improve it over the weeks.
@pugioX, yes, that should have been made an option in the first place. Thanks!
From olau%iol...@gtempaccount.com on October 22, 2009 12:16:30
By the way, issue #64 is related to the problem of the outermost ticks.
From pug...@gmail.com on November 18, 2011 05:14:48
Has anything been done to further the integration of this patch?
I just tried to upgrade to the latest Flot version and, once again, my x-axis labels overlapped each other greatly.
Are we still waiting on a speed test to apply this?
From jmulder on November 18, 2011 08:18:53
Sorry, since then I have moved onto other things and no longer work on our Flot implementation. I have talked to others within the company, except they are looking into moving to other libraries.