Moved from Google Code issue #569.

Add support for rounded corners in XY scatter plots with a stepped interpolation mode. This would make it also possible to implement graphs like this:

.

CPTTextLayer can have a maximum size but it doesn't show ellipses when the text is truncated. At least for NSAttributedString this is easy to add by using

NSStringDrawingUsesLineFragmentOrigin | NSStringDrawingTruncatesLastVisibleLine

in NSAttributedString<CPTPlatformSpecificAttributedStringExtensions> (use -drawWithRect:options: instead of -drawInRect:).

Moved from Google Code issue #20.

A templating component should be added that allows someone to completely define the look of a graph (not its data). This would probably take the form of a loadable bundle, which contains a property list describing the graph, and any media that is needed (eg background images). A user should be able to generate such a bundle with a single call to the CPTGraph class, and generate a new graph from such a bundle with an initializer of CPTGraph (factory method).

The CPTTheme class partially addresses this, although at the moment all stylizing is done in code. This class should be extended to support persisting themes to property list files and bundles.

CPTTheme needs to be able to handle property lists. This need not be so complex. The properties could literally be the properties on the layer classes themselves. The only tricky bit will be how to convert, say, a property list string, into a CPTColor. Perhaps just a simple list/set of keys can be stored that delineate properties for which a conversion should be performed.

Add support for stacked scatter plots and bar charts. There should be a way to group plots together and "stack" the plots in the group by adding the provided data value to the total values of the plots below it in the stack before drawing the point.

Example:

Moved from Google Code issue #613.

Add accessibility support to Core Plot on both Mac and iOS.

References:

Mac: https://developer.apple.com/library/mac/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXIntro/OSXAXintro.html

iOS: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html

Moved from Google Code issue #564.

Add support for arc graphs. This graph type is extremely beautiful and something to add a special touch to your application, but a bit diffiult to understand. They show relationships between different points on a date series or similar. Example:

http://www.bewitched.com/song.html

Moved from Google Code issue #560.

Add support for stream graphs. One way could be like stacking curved scatter plots like this:

Another very nice example is:

With curved rectangle like appearance plus overlapping parts.

Comment by: mike.lischke

The second example is rather a sankey graph not a stream graph, I'd say.

Moved from Google Code issue #144.

Plots should support receiving date data as NSDate objects instead of numbers. Axes should support setting plot ranges and tick locations as dates rather than numbers.

This would eliminate the conversion step in client code and simplify creating plots of time-series data which is a common use case.

Moved from Google Code issue #279.

The current implementation for applying fills to regions of scatter plots is limited: You can apply two separate fills, for two different base values. This allows you to have a fill above, and a fill below a scatter plot, for example. But if you want to have a different fill for when the plot goes below an axis, for example, you can't do that. You end up having to split the scatter plot into two separate plots.

It would be good if there was a system for filling regions of scatter plots that was flexible, and could handle all cases. Here is one suggestion:

Introduce a CPTRegionFill class:

@interface CPTRegionFill : NSObject 
    @property CPTFill *fill;
    @property NSDecimal baseDecimal;
    @property CPTRegion region;
@end

CPTRegion is an enum:

typedef enum {
    CPTRegionNone = 0,
    CPTRegionAbove,
    CPTRegionBelow,
    CPTRegionAboveAndBelow
} CPTRegion;

Scatter plot would need methods to add and remove the region fills:

@interface CPTScatterPlot
    -(void)addRegionFill:(CPTRegionFill *)fill;
    -(void)removeRegionFill:(CPTRegionFill *)fill;
@end

Drawing the regions would not be quite as easy as now. Some means of only drawing fill on the appropriate side of the scatter plot would be needed. In effect the intersection of two areas would need to be found. One masks the other. It may be possible to do this with Quartz 2D calls.

After installing Xcode 5.1 beta 4, I get the following compile error:

CPTGraph.m:683:1: Ivar 'legend' which backs the property is not referenced in this property's accessor

Which refers to:

-(CPTLegend *)legend
{
    return (CPTLegend *)self.legendAnnotation.contentLayer;
}

Moved from Google Code issue #394.

Add support for radar charts.

http://en.wikipedia.org/wiki/Radar_chart

When creating a y-axis on the right side of the plot the title's offset has to be calculated differently than the label offset in case the (major) ticks have the direction CPTSignNone. This is quite confusing.

The reason for this behavior is that the axis title has in contrast to the axis labels no own direction but the direction of the major ticks is used. In case of CPTSignNone for the ticks the API has to make a decision in which direction the title is to be placed: it chooses the negative direction (which is OK for all axes on the left or bottom side of a graph but not for an axis on the right side).

A workaround is to assign a negative title offset. But this is strange as the label offset is positive in case the labels have a positive direction.

Therefore, I suggest to add for the axis title a direction, too.

Regards,
Hartwig

Moved from Google Code issue #179.

Add the option to fill the area between two scatter plot lines instead of a fixed base value.

Comment by: mike.lischke

A stream graph could be used which comes with a configurable number of data lines and then it should be simple to fill the space between them. The new stream graph/plot can be made configurable to allow the same interpolation types as normal scatter plots. In fact the XY scatter plot should just be extended to support multiple data lines and the fill feature can be added then easily. This way it also would support stream graphs (with the curved interpolation).

Comment by: Ned1988

Hi, I think you are trying to implement something like this:

How I solved this issue:

1. You need coordinates for top and bottom lines
2. Sort top values by the ascending
3. Sort bottom values by the descending
4. Combine sorted top and bottom values to one array
5. Apply fill color to plot

To say long story short, you need closed plot path.

Moved from Google Code issue #614.

(see file attachment on the linked Google Code issue)

I'm working on small a Mac app. I wanted to be able to use my trackpad to zoom in and out of graphs, as well as to pan around without having to click down. So, here's a patch to do that.

An unintentional-but-nice side effect is that mice with scroll wheels will also be able to pan on the Y axis now (and the X axis, if the hardware supports that).

There's also a property to enable/disable allowPinchScaling, to closer mimic the interface of CPTGraphHostingView on iOS.

Moved from Google Code issue #551.

Moved from Google Code issue #584.

Fix various rendering performance issues. Both reports below apply to iPad 3.

1. The performance should be equal... Well in the landscape mode the performance of the graph rendering is considerably lower than in the portrait mode. If the graph is displayed fullscreen, the difference is huge!
2. Install the CPTTestApp-iPad on a physical device running iOS7. Try to pinch or move the upper scatter graph. The responsiveness of the graph is very bad, also the CPU is getting nearly to 100%.

Moved from Google Code issue #259.

Many Mac apps use an area selection rectangle, sometimes with marching ants, to select a region of a plot for zooming and other applications. It would be good if it were possible to "turn on" and position a selection rect layer inside a graph. It would only exist within the bounds of the plot area, and could be positioned in either plot area view coordinates, or in plotting coordinates.

The DropPlot example app implements a selection rectangle in client code; this could be used as a model for bringing the feature into Core Plot itself.

Moved from Google Code issue #572.

I am developing an iOS application that uses a scatter plot to plot some data points along with a trend line. I would like the user to be able to select not only the data points, but the line itself. That is, I would like to be notified when a touch down occurs within, say, 10 points of the line on either side. Here is a picture illustrating the feature.

There exists a - (void)scatterPlot:plotSymbolWasSelectedAtRecordIndex:, but the corresponding deselect delegate method is not exist.

Use case: I want to show a data label when clicking on plot symbol, then dismiss it when clicking on empty plot area. Currently it’s hard to use Core Plot to achieve this.

I’ve wrote a prototype patch for my own use: https://github.com/xhacker/core-plot-0/commit/eadf250d7a88c1199f0d45ddcaad92027de5509f
If you think it’s useful, I will complete it and open a pull request.

Moved from Google Code issue #601.

Scrolling a plot space causes the axis to relabel and the alternating band fills to be drawn in different intervals. Provide an option to anchor the band fills so they do not jump around when scrolling.

See http://stackoverflow.com/questions/19513258/core-plot-alternatingbandfills-jumps-when-scrolling-horizontally for more info.

Moved from Google Code issue #590.

Currently, when you enable user interaction on a plotspace, core-plot automatically supports scrolling a scatterplot within its global ranges. This is done by dragging with the mouse.

To make use of other mouse and trackpad input (like swipe gestures, mouse wheel) this handling should be extended. Properly handling that is not as trivial as it seems, but I have done this for a class already and would like to share that code here, so it becomes easier to implement it in core-plot. Note that only vertical scrolling is handled in my example code.

For another control in my application (OSX) I implemented scrolling myself for all possible devices (trackpad + mouse, including high precision mouse pos, swipe, scroll wheel etc.). You might be interested in how I did it to derive a solution for core-plot. Implemention handles vertical scrolling only at the moment, but it should be easy to add the horizontal case:

- (void)scrollWheel: (NSEvent *)event
{
    switch (event.phase) {
        case NSEventPhaseBegan: // Trackpad with no momentum scrolling. Fingers moved on trackpad.
            offsetAccumulator = scrollOffset;
            // Fall through.
        case NSEventPhaseChanged:
            if (offsetAccumulator >= 0) {
                offsetAccumulator += event.scrollingDeltaY / 5;
            } else {
                offsetAccumulator += event.scrollingDeltaY / 2.0 * exp(offsetAccumulator / 75.0);
            }
            [self setScrollOffset: offsetAccumulator];
            break;

        case NSEventPhaseEnded:
            if (scrollOffset < 0) {
                [self.animator setScrollOffset: 0];
            }
            offsetAccumulator = scrollOffset;
            break;

        case NSEventPhaseNone:
            if (event.momentumPhase == NSEventPhaseNone)
            {
                // Mouse wheel.
                if ([event hasPreciseScrollingDeltas]) {
                    offsetAccumulator += event.scrollingDeltaY;
                    if (offsetAccumulator < 0) {
                        offsetAccumulator = 0;
                    }
                    [self setScrollOffset: offsetAccumulator];

                } else {
                    offsetAccumulator += 10 * event.scrollingDeltaY;
                    if (offsetAccumulator < 0) {
                        offsetAccumulator = 0;
                    }
                    [self.animator setScrollOffset: offsetAccumulator];
                }
            }

            break;
    }

    switch (event.momentumPhase) {
        case NSEventPhaseBegan: // Trackpad with momentum scrolling. User just lifted fingers.
            ignoreMomentumChange = NO;
            offsetAccumulator = scrollOffset;
            break;

        case NSEventPhaseChanged:
            if (!ignoreMomentumChange) {
                if (offsetAccumulator >= -50) {
                    offsetAccumulator += event.scrollingDeltaY / 5;
                    [self setScrollOffset: offsetAccumulator];
                } else {
                    // If we scrolled beyond the acceptable bound ignore any further
                    // (automatically generated) change events and animate back to 0 position.
                    ignoreMomentumChange = YES;
                    offsetAccumulator = 0;
                    [self.animator setScrollOffset: offsetAccumulator];
                }
            }
            break;

        case NSEventPhaseEnded:
            break;
    }
}

scrollOffset is the current offset (0...+infinite) while the offsetAccumulator is a temporary offset used during an ongoing scroll operation to get the animations smooth. Additionally I create an animation for scrollOffset:

- (id)animationForKey: (NSString *)key
{
    if ([key isEqualToString: @"scrollOffset"]) {
        CABasicAnimation *animation = [CABasicAnimation animation];
        animation.timingFunction = [CAMediaTimingFunction functionWithName: kCAMediaTimingFunctionEaseOut];
        animation.speed = 1;
        return animation;
    } else {
        return [super animationForKey:key];
    }
}

Especially with momentum scrolling this enhancements becomes essential. It's really hard to do momentum scrolling by mouse dragging.

Moved from Google Code issue #567.

Add support for word cloud diagrams. This is rather a special plot type that doesn't draw any lines but instead shows labels with keywords. Each label is sized depending on a data value. All labels are laid out so that they stay close together similar to a cloud or ellipsis.

Plots should support categorical data. This occurs frequently in statistics where data points are grouped into non-numeric categories (yes/no, male/female, low/medium/high, etc.)

Categories should be strings (NSString or NSAttributedString). The category name will be used as the corresponding tick label on the axis and optionally as the data label. This would be useful for pie charts.

Moved from Google Code issue #406.

Graphs on OS X should support tooltips over various graph elements such as axes, plots, and legends. The existing annotation infrastructure can be used to display the tooltip. This enhancement requires only a way to associate the tooltip content with various graph elements and handle the mouse tracking to show and position the correct tooltip.

Moved from Google Code issue #561.

Add support for chord graphs which offer a great way to visual relationships. An example is on this page:

http://thesocietypages.org/graphicsociology/tag/visualization-code/

(scroll down a bit)

Moved from Google Code issue #103.

Reported by [email protected]

People with very large data sets could benefit from a point culling algorithm. The algorithm, which would be turned on via a CPTScatterPlot property, could work like this:

The deviation from linearity is accumulated from one point to the next, until it crosses some threshold, at which point a new point is drawn. Intermediate points, which do not deviate much from linearity are not drawn. This algorithm would ensure important points, such as extrema, would be drawn, while points that do not contribute much to the shape of the curve would be skipped.

Another algorithm to do this would be to check the distance from an intermediate point from the line joining points either side. If it falls within a tolerance, it is skipped. The end point would then move to the next point, and the same test -- spanning a larger range -- would be carried out. The tolerance could be set by the user, or perhaps derived from the native view coordinate system (e.g., a one pixel tolerance, or two pixel tolerance, etc).

Comment by: barrywark

This issue is a significant rabbit hole of literature spanning many disciplines. Until someone proposes a published procedure and justifies its use, I'm wary of implementing an ad-hoc solution (thought they sound good).

Comment by: [email protected]

I am inclined to say that as long as the algorithm is published in our docs, people can make up their own mind.

It should definitely not be turned on by default, but in many cases, people may be happy to give up a little accuracy for performance.

There was a question from Jonathan 'Wolf' Rentzch at NSConference about exactly this: 'Suppose I have 2.5 million points, is there anything in Core Plot to help'. I told him to cull his data, but we could help by providing a basic option, and anyone that needs more can always do it themselves.

In my view, a simple algorithm like I am proposing is better in many cases than an extremely advanced one. At least you can grasp it, and predict when it might not be appropriate or might fail.

Comment by: bfulgham

I'm doing exactly this, and have just been thinking about this problem. I think Drew's suggestion is good, because it's easy to understand and implement. Hand waving about complexity and lack of perfection just mean the feature will never be implemented.

In another project, I ended up computing the plot position of each point based on the current viewing resolution. Once the display extents have been computed, it's not too computationally intensive to determine what the x,y coordinates (in screen pixels) will be, and just toss out anything that matches the last plotted point.

Perhaps an approach like this might work.

Comment by: drewmccormack

I think you can even go a bit further: throw out any point that doesn't deviate from linearity by more than x number of pixels.

If you're interested, why not take this on yourself. Just dig into the CPTScatterPlot class, and introduce a point culling option.

Comment by: mike.lischke

This task has been sleeping for quite some time, but let me add my thoughts here. Why do we need any point culling algorithm at all? We want to draw only as many points as needed for a graph. But calculating a downsampled set of points from something large like those 2.5 million points can be time consuming as well, since you have to do it whenever the plotrange changes.

But the solution can be much simpler: you cannot draw more points than you have pixels in either dimension. Let's consider an XY graph. coreplot asks for the number of x values and then queries the datasource for the y value of each x value. Depending on the plotrange and size of the graph many x points (data points!) may fall on the same x pixel coordinate. So all you would need is to avoid querying the y value for the same x value more than once. That's also kind of a subsampling and by picking randomly any y value (most of the time the first one) for an x value you might of course miss extrem values. But that makes the algorithm extremely fast, on the other hand.

A modification can be applied to improve the y value selection, by sacrifying some speed, by asking the datasource for a "y representation" for a given x data range (which later is applied to a single x pixel coordinate). The datasource can then decide what to (return the first value, the average, the largest value, whatever). The datasource can optimize speed by caching the computed value.

Moved from Google Code issue #595.

Add support for box plots. See http://en.wikipedia.org/wiki/Box_plot for examples.

Moved from Google Code issue #68

Add an option to separate plot lines and fills into different layers. Along with the graph layer ordering, this will allow effects like having the plot lines on top of the axes while keeping the fills below the axes.

Moved from Google Code issue #534.

Add support for bubble charts. These are like scatter plots, but the size of the plot symbols represent a third data value. It could probably be implemented as a subclass of CPTScatterPlot.

Aug 10, 2013 comment #1 mike.lischke

Note that there are different types of bubble charts. One is similar like a tree chart. The bubbles are not drawn along a horizontal axis but grouped in a given outer area (which can again be a circle like in this example or a rectangle).

Moved from Google Code issue #5.

Annotations should be able to draw a pointing line or arrow between a given point and the annotation content layer. This would allow annotations to be used to call out specific data points. It would also add the ability for plot data labels to move away from the data point to eliminate overlapping labels while still connecting the label to the data point.

Moved from Google Code issue #525.

CPTImage does not support strecthable images and I believe it would be a big plus if it did. Currently, CPTImage resizes images completely, not allowing the user to keep parts of an image untouched (i.e., corners). Even when a CPTImage object is created through a stretchable UIImage, it still is no use.

Adding support for stretchable images would be greatly appreciated.

Comment by: [email protected]

I haven't tested it, but CPTImage in the release-2.0 branch may now support this (iOS only). Use +imageWithNativeImage: or -initWithNativeImage: to create the CPTImage from a stretchable UIImage. We still need to add support on OS X and extend the CPTImage API similar to the UIImage syntax so that support for stretchable images is explicit and cross-platform.

Moved from Google Code issue #611.

Enable the ability to add gesture recognizers to any CPTLayer based object to increase the degree of interactivity with Core Plot objects.

in the documentation I am instructed to install the static library by copying the folder corePlotHeaders... where can i find that?

Moved from Google Code issue #568.

Add support for tree graphs. This type of graph is a relative to bubble graphs that size rectangles depending on a data value. Additionally these rectangles are automatically clustered so that no free space remains between them. One example is here:

http://flowingdata.com/2010/11/03/review-atlas-of-science-visualizing-what-we-know/

A very cool application is SequoiaView developed by the University Eindhoven in 2002 which shows disk content (files) in a tree chart:

http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview/

Moved from Google Code issue #335.

If a legend has many entries, it can be so large that the legend gets cut off and some entries are not visible. Add options to the legend to set the maximum size and allow it to scroll if the number of entries requires more space than available in the maximum size.

Moved from Google Code [issue #382](https://code.google.com/p/core-plot/issues/detail?id= 382).

Currently it's easily possible to have plot slice labels clash, rendering important parts of a pie chart useless. So it would be meaningful to add a collision detection to slice labels and move labels that overlap around, so that they stay readable. This might require to add a line from the labels to the slices to indicated their beloning.

A very similar problem is that labels can be cut off at the plot area boundaries. So by implementing that collision detection this case would be solved as well.

I'm fully aware that it is impossible to catch all possible cases, but for many it would be a very helpful solution.

Moved from Google Code issue #605.

Reported by graham.mueller315, Nov 4, 2013

Most touch/mouse events occur on the Up event, instead of the down (short of dragging). However, all of the delegate methods for the various graphs seem to be using the Down event.

This causes problems with graphs that are embedded in scrollable views, as you try to scroll and the events are unexpectedly fired.

Would you consider changing this behavior in the next version?

Thanks,
Graham

Nov 4, 2013 comment #1 graham.mueller315

This will additionally cause issue when "accidentally clicking" (i.e, user accidentally grabs one bar, and tries to drag away to prevent actually selecting it). The expected behavior in this case is that the event would not be fired at all (or at least not for that bar), but currently it would be fired immediately on the accidental tap-down.

Nov 14, 2013 comment #2 [email protected]

Should we change the behavior of the existing selection methods or add new ones with the new behavior to give the user a choice? If we change the existing behavior, that will need to go into the release 2.0 branch along with the other major changes in progress over there.

Nov 14, 2013 comment #3 graham.mueller315

I think that allowing the user to choose would make sense, but the default should be (in my opinion) on Up.

Based on that, I believe this will need to go into the 2.0 Branch. Is that nearing release, or is that likely not going to happen yet this year?

Nov 15, 2013 comment #4 [email protected]

We don't have a timeline for the 2.0 release yet. There are still some major architecture and performance changes that need to happen that are not ready to check in. The 2.0 branch is functional—I know some people are already using it.

Nov 15, 2013 comment #5 [email protected]

(No comment was entered for this change.)

Dec 12, 2013 comment #6 graham.mueller315

Hi Eric,

Here are two patches that should resolve this issue for the 2.0 release. I took two different approaches, let me know if either would work for you.

The first was using a boolean to determine when to fire the event. It didn't change the API at all, but adds a property to all of the items that handle events on the pointingDeviceUp/Down. If the boolean is set to false, it only fires on the down event, if set to true (the default), it will fire on the up event. This seems a little kludgy, so I came up with a second change, that fully preserves (though deprecating) backwards compatibility.

The second approach is to have all of those items that handle the pointingDeviceUp/Down events fire both events, depending on what the delegate wants. These methods all have a new API looks like, for example, -(void)axis:(CPTAxis *)axis labelTouchDown:(CPTAxisLabel *)label withEvent:(CPTNativeEvent *)event;.

This is nice because it allows the user to choose which events they want (it also enables them to respond to both.

Anyway, let me know what you think.

Graham

Dec 12, 2013 comment #7 [email protected]

Thanks. I will take a look at the patches this weekend.

Dec 13, 2013 comment #8 [email protected]

The boolean property makes for an awkward API. I prefer the solution that adds additional delegate methods. As you say, this gives the application a choice of which one to use.

Rather than deprecating and renaming all of the xxxWasSelected: methods, what if we instead add the "up" methods and leave the original methods as they are. We could call the "up" methods something like xxxWasReleased:. Since adding new APIs doesn't break old apps, this change wouldn't need to wait for the 2.0 release.

Dec 13, 2013 comment #9 graham.mueller315

If that's what you would prefer, it could certainly be done. However, to me "wasSelected" and "wasReleased" are not corresponding events.

Selection is really up/down agnostic, and seems like more of a "this item is now in focus" event.

The wasPressed/Released method would better indicate what is actually happen -- mouse/finger down/Up.

I realize you're suggesting this in favor of getting it into 1.x, but to me the breaking API change seems like a better fit, which would make it a better candidate for 2.0. That's just my opinion, though, so I can certainly modify my patch to make it fit your preference.

Dec 14, 2013 comment #10 [email protected]

I agree with the approach, I'm just looking for the right name for the event. Core Plot is platform agnostic; the names should make sense on both Mac and iOS. That's why we used "pointingDeviceXXX" for the CPTResponder events and "xxxWasSelected:" for the selection events.

However, none of this addresses the issue you raised in the initial issue report or the first comment. Rather than deprecate "xxxWasSelected:", why not use those to indicate when the down and up events occur on the same plot point? For example, if you touch a bar on a bar plot, slide your finger to a different bar, and then lift the finger, you'll get the down event for the first bar and the up event for the second bar, but not the selected event. If the up event occurs on the same bar as the down event, you'll get the selected event, too.

I'm not sure if this change in behavior will fix the issue when embedded in a scroll view or if more needs to be done to handle that case, too. The solution might be different on Mac and iOS.

Dec 14, 2013 comment #11 graham.mueller315

I know what you mean about choosing the right name. I recognize the cross platform aspect of the framework, and had actually looked at a couple of other libs that are as well when I decided on the touch name.

Check out LibGDX's (a gaming lib) InputProcessor class at http://libgdx.badlogicgames.com/nightlies/docs/api/ (sorry, I can't directly link to the class, JavaDocs kind of suck :/)

What you mention with touchUp/Down on different, non-matched points is actually an issue I had ran into when I was writing a Lua UI framework. It does actually get kind of tricky; what should the behavior be? If you started (down) on one, and ended (up) on another, are you actually trying to 'select' the latter, or are you canceling your selection of the first?

In that sense, rather than exposing either of those new events (up/down), maybe a change in the behavior of wasSelected would make sense -- it could only be fired when both up and down are triggered on the same point.

Regarding the scroll behavior, I believe this will work, though I guess I'm not 100% sure -- we put a separate work around in place to deal with it for this release, and I didn't try pulling it out to test. I'll give it a shot once we've decided on a strategy here, since presumably that's going to require some rework depending on the direction it goes.

Dec 15, 2013 comment #12 [email protected]

It does actually get kind of tricky; what should the behavior be? If you started (down) on one, and ended (up) on another, are you actually trying to 'select' the latter, or are you canceling your selection of the first?

That's why having both the up/down events and xxxWasSelected: would be useful. The application could choose which one is appropriate for what it is doing. xxxWasSelected: would only fire if the down and up events occur on the same data point.

I like your suggestion in comment #9 of using xxxWasPressed: for the down events and xxxWasReleased: for the up events.

Moved from Google Code issue #509.

Adding labels to axes is a complicated text layout problem because labels (numbers or texts) tend to overlap. There are several common strategies to solve this problem like line breaking inside labels and rotating labels. Also the padding of the chart should be automatically adjusted to make just enough room for the needed labels.

Moved from Google Code issue #559.

Add support for heatmaps. These graphs add another dimension by allowing coloring an area depending on a value. Colors could be specified either as a range or as a color ramp with a limited number where each color defines an area of input values.

Layout is a bit challenging because sometimes you want the colored areas to form a figure (like a block of n x m cells) and sometimes they can be like plot symbols in a scatter plot.

Moved from Google Code issue #563.

Add support for sunburst graphs. This type is very similar to pie/dognut charts but with stacking and incomplete rings.

Aug 10, 2013 comment #1 [email protected]

You can make that example plot with the existing pie chart, although it would require a separate plot for each ring and some work in the datasource to figure out where the blank pie slices should go.

Installed the docset from the last official release as per instructions (put in developer folder, and reload XCode). However, in the Documentation I can neither click on a item to display the documentation nor search for items within it.
I am using XCode 5.0.2.

A possible unrelated issues is that I have also tried building the documentation from the source, but it only ever creates a 7kb file that seems corrupted.

Moved from Google Code issue #86.

It should be possible to extend CPTPlotSpace so that it can be confined to a subregion of the whole CPTPlotArea. This would allow for 'paned' graphs.

The margin concept from CSS could be used. This could be a fixed distance, or a percentage (e.g., margin is 20% of plot area, or 20px).

If a chart has got a plot space with y-values with a lower limit of 0 and an upper limit value within [3, 5) no major tick except for zero is generated. If the upper limit is smaller than 3 or equal or larger than 5 at least another major tick is created.

This is caused by niceNum in combination with the algorithm in autoGenerateMajorTickLocations:minorTickLocations:.

A solution would be to let niceNum return something like floor(fractionPart) for fractionPart values within [3, 5). Actually, then the important part in niceNum could be simplified to

NSDecimal roundedFraction;

if ( CPTDecimalLessThan( fractionPart, CPTDecimalFromDouble(1.5) ) ) {
    roundedFraction = CPTDecimalFromInteger(1);
}
else if ( CPTDecimalLessThan( fractionPart, CPTDecimalFromDouble(3) ) ) {
    roundedFraction = CPTDecimalFromInteger(2);
}
else if ( CPTDecimalLessThan( fractionPart, CPTDecimalFromInteger(5) ) ) {
    NSDecimalRound(roundedFraction,roundedFraction,0,NSRoundDown);
}
else if ( CPTDecimalLessThan( fractionPart, CPTDecimalFromInteger(7) ) ) {
    roundedFraction = CPTDecimalFromInteger(5);
}
else {
    roundedFraction = CPTDecimalFromInteger(10);
}

Moved from Google Code issue #565.

Add support for sankey graphs. This type of graph is similar to flow diagrams and maybe can go as special styles into a single plot implmementation. Example:

http://www.fastcodesign.com/1664432/fineo-creates-tufte-worthy-diagrams-with-just-a-few-clicks

Moved from Google Code issue #536.

Add animation support to plots beyond what is possible with Core Animation. For example, adding points to a scatter plot could have the points fade in one by one or animate drawing the line connecting the data points. Bar plots could "grow", either one bar at a time or all together, reaching the final bar length together.

Moved from Google Code issue #562.

Add support for nightingale graphs. This type of plot is like pie chart but with stacking of values for each piece plus individual size of each piece. Example:

Bug description:
If the user zooms into a plot deep enough, the app hangs forever.

Versions:

• Source: commit 9a10b20, dated 2014-01-25T10:15:08-08:00
• Build: Xcode 5.0.2 on Mac OS X v10.9.1
• Run: iPhone 5 on iOS 7.0.4

Steps to reproduce:

1. Download latest version (https://github.com/core-plot/core-plot/archive/master.zip, commit 9a10b20, dated 2014-01-25T10:15:08-08:00).
2. Unzip and open core-plot-master/examples/CorePlotExamples.xcworkspace
3. In Xcode, choose target "Plot Gallery-iOS", "iOS Device".
4. Open Plot_Gallery_iOS.xcodeproj, go to Project Plot_Gallery_iOS → Build Settings → Code Sign Identity, modify as appropriate (to allow running on device).
5. Build and run on iPhone.
6. On the iPhone, in the Core Plot Gallery app, in the main menu, select Simple Scatter Plot.
7. In the plot's view, keep zooming in repeatedly by using the pinch-in gesture. Recommended to zoom towards the leftmost blue dot lying on the y-axis.
8. If you have zoomed in enough, the app hangs.

Debugging Info:
I found that the app got into an infinite loop in line 1052 of Source/Axes/CPTAxis.m, which is in -autoGenerateMajorTickLocations:minorTickLocations: of CPTAxis. At that time, initialIndex = 2147483647 and finalIndex = 2147483647. I think the problem here is that finalIndex is actually INT_MAX, so the variable i, being an int, can never go larger than it.

Additional Info:
This also happens in CorePlot Release 1.4 (https://github.com/core-plot/core-plot/releases/download/release_1.4/CorePlot_1.4.zip), using the binaries in CorePlot_1.4/Binaries/iOS.

Moved from Google Code issue #365.

Add support for pinch-zoom in pie charts.

Moved from Google Code issue #349.

One very helpful type of graph would be an intensity map. It would be great for plotting datasets such as those produced by a spectrogram.

Moved from Google Code issue #266.

Add data label alignment options to bar plots. The current label anchor is the center of the bar tip. Some possible options:

1. Align with the left or right side of the bar tip instead of the center.
2. Center the labels inside the bars.
3. Align with the bar base (left, right, or center) instead of the tip.

Moved from Google Code issue #566.

Add support for Venn diagrams. This type of plot show relationships between sets. A typical case is the additive/subtractive color diagram overlapping 3 circles (red, green, blue). A much nicer example is here: