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.

Created a patch for it. Tested against examples and it's working.

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.

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).

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 (flot-graph.png).

A summary of the changes and rationale:

1. 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.

2. 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.

3. 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.

4. 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.

5. Usage of outerWidth() and outerHeight() to measure labels This is a result of change 1 and 2.

6. Changes in Plot.addLabels() are a result of all of the above.

7. cleanLastLabel() in Plot.addLabels() is a separate routine to check whether the last label is overflowing the plot area.

8. 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.

Hi!

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 an option?

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.

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 canvas)"

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.

@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!

By the way, issue #64 is related to the problem of the outermost ticks.

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?

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.

Comment deleted

Is this a duplicate of issue #85?