RGraph is a JavaScript charts library based on HTML5 SVG and canvas. RGraph is mature (over 15 years old) and has a wealth of features making it an ideal choice to show charts on your website.

More »

 

Get the latest version of RGraph (version 6.17) from the download page. There's also older versions available, minified files and links to cdnjs.com hosted libraries.

More »

 

RGraph can be used for free under the GPL or if that doesn't suit your situation there's an inexpensive (£99) commercial license available.

More »

Hi Richard,

I'm posting this because I've stumbled a bit over inconsistencies between the capitalization of the labelsInBar options, both between the different options and what the API docs say, here:

https://www.rgraph.net/canvas/hbar.html#labels-and-text-properties

Sometimes it's "InBar" and sometimes "Inbar", and they are not interchangeable.

For example, the API doc above says "labelsInBar", but it is actually (and the description says) "labelsInbar". The descriptions of the various other InBar options flip/flop between these two spellings. Color and Bold are also listed incorrectly in the API. Here's code that works for me:

//labelsInBar
labelsInbar: true,
labelsInBarOffsetx: 3,
labelsInbarColor: 'white',
labelsInbarBold: true

Desired behavior: For the spelling/case to be consistent for all the "InBar" options ("InBar" probably more appropriate than "Inbar") and described correctly and consistently in all of the docs. I don't know if other options have this issue, I don't recall encountering any.

You can probably fix this issue by disregarding casing for these options going forward to maintain backwards compatibility, and picking one as the official "correct" version for documentation ("InBar" please).

Thanks for letting me know about this. I'll get them changed but to maintain consistency I'll rename it to:

labelsInbar*

This raises a question though - are the capitals really necessary...? I'll have to think some more on this and experiment with both.

Cheers.

Capitals...I like camelCase, it makes things more readable, especially for documentation, but for actual use it would probably be better to just be agnostic about it and flatten everything before processing. Resulting in:

labelsinbar = labelsInBar = LABELSINBAR = LaBeLsInBaR

I can't think of a reason to not accept every variation. If you did then inconsistencies in the API docs wouldn't matter.

Precisely my thinking and I think that I may have some code to it without any disruption. I'll add it to 6.16 though as it's too late for 6.15.

Cheers.

I've just added version 6.15 onto the website and the Activity meter has the ability to accept the configuration names in any case you desire - so give this a try and see how it works out for you. All being well I'll add this to the rest of the libraries for the next release.

Ok, I've added the relevant changes to the library files and you can get them from GitHub here if you so choose (they'll be a part of v6.16 but that won't be released for a few months yet):

All of the library files (click on a library file and then on the RAW link to get the code easily):

https://github.com/heyesr/rgraph/tree/main/libraries

The HBar library file:

https://raw.githubusercontent.com/heyesr/rgraph/main/libraries/RGraph.hbar.js


And here's an example:

new RGraph.HBar({
    id: 'cvs',
    data: [8,6,7,9,8,5,4],
    options: {
        backgroundgridhlines: false,
        BACKGROUNDGRIDBORDER: false,
        Xaxis: false,
        YAxis: false,
        yAxiSlAbElS: RGraph.DAYS_LONG,
        LABELSABOVE: true,
        LABELSABOVEUNITSPOST: '%',
        textsize: 18
    }
}).draw();

Cheers.