x-axis label boxes has fixed widths that may overlap

[GoogleCodeExporter]

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 reported on code.google.com by dsim...@gmail.com on 14 Jul 2009 at 12:26

[GoogleCodeExporter]

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

Original comment by dsim...@gmail.com on 14 Jul 2009 at 1:40

Attachments:

• issue_191.diff

[GoogleCodeExporter]

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.

Original comment by olau%iol...@gtempaccount.com on 6 Aug 2009 at 12:35

• Changed title: x-axis label boxes has fixed widths that may overlap
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

Original comment by jmulder on 28 Aug 2009 at 11:19

[GoogleCodeExporter]

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.

Original comment by jmulder on 31 Aug 2009 at 3:10

Attachments:

• flot-label-alignment-and-distribution.patch
• flot-graph.png

[GoogleCodeExporter]

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.

Original comment by olau%iol...@gtempaccount.com on 7 Oct 2009 at 3:37

[GoogleCodeExporter]

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.

Original comment by pug...@gmail.com on 13 Oct 2009 at 6:07

[GoogleCodeExporter]

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

Original comment by jmulder on 22 Oct 2009 at 8:52

[GoogleCodeExporter]

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

Original comment by olau%iol...@gtempaccount.com on 22 Oct 2009 at 12:16

[GoogleCodeExporter]

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?

Original comment by pug...@gmail.com on 18 Nov 2011 at 5:14

[GoogleCodeExporter]

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.

Original comment by jmulder on 18 Nov 2011 at 8:18

[GoogleCodeExporter]

Original comment by dnsch...@gmail.com on 8 May 2012 at 8:10

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Is this a duplicate of issue #85?

Original comment by mikez...@gmail.com on 24 Oct 2012 at 9:02