Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Drawing Graphs on Your Browser?

Cliff posted about 11 years ago | from the harvard's-got-nothing-on-these dept.

Graphics 201

Pieroxy queries: "I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...) for a web-based enterprise application. As we need some interactivity, the GIF image generated on the server-side is not an option. Here is the list of technologies I can think of: Flash is probably over kill and a closed technology. Java is very flexible but slow (to start and run). SVG (discussed here) still requires a plugin. VML is supported only on IE5+, but it is natively supported. Which one of these technologies is the more flexible and interactive? Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Do you need all chart types, or just one? (4, Insightful)

TC (WC) (459050) | about 11 years ago | (#6497456)

If you can get away with just bar charts, take several gifs/jpegs/pngs that are just single colour pixels and have your server-side program fiddle with the heights and widths to draw your bar chart without having the server generate an actual image file.

Re:Do you need all chart types, or just one? (0)

Anonymous Coward | about 11 years ago | (#6497516)

Informative, or just plain illiterate?

Different graph types are mentioned in the bloody post, you cave monkey.

Re:Do you need all chart types, or just one? (0)

Anonymous Coward | about 11 years ago | (#6498282)

Let's re-read the very first sentence of the request, shall we?

I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...)

Yep, sounds like bar charts alone will do the trick for this guy. Also, those single-color gifs are very interactive. Way to hustle for that first post though!!

Re:Do you need all chart types, or just one? (1)

Tablizer (95088) | about 11 years ago | (#6501027)

Also, those single-color gifs are very interactive.

Who says they have to be a single color? Use color X for bar A, color Y for bar B, etc.

IE5...not quite (5, Insightful)

X-wes (629917) | about 11 years ago | (#6497470)

Internet Explorer 5 and above are very widely-used. However, they are still flawed browsers and, due to the announcement that these browsers will no longer be updated as standalone applications, many people may switch to another browser. Also, those using a Unix-based platform (read: GNU/Linux) no longer have any viable way of using Internet Explorer. If it is not easy to change back and forth, the already limited audience VML will reach even less as time goes on.

As an opinion only, if SVG is an option, it may be best in the long run. Assuming it is not easy to acrobatically jump from one option to the next (if that was possible, you could serve VML to IE 5.5+ and SVG to Mozilla, and some raster format for any other browsers), SVG holds the best promise. SVG is already supported as a plug-in (much like flash). It is about to be tested as a native part of the Mozilla browser. Over time, compatibility will actually improve--not something Java or VML can say easily. Also, as compatibility improves, simple scripting can make the charts interactive or real-time (or other neat fancy stuff).

Re:IE5...not quite (2, Insightful)

Anonymous Coward | about 11 years ago | (#6497520)

IE5+ has too limited an audience to bother with, but Mozilla with SVG is worth the effort?!

You sir, are incapable of consistant thought.

You monkey.

Re:IE5...not quite (-1, Flamebait)

Anonymous Coward | about 11 years ago | (#6497888)

NO! You sir are not only a monkey but a big assed babboon as well!

p.s: Leave "man's best friend" in your bedroom, I do not wanna see it!

Re:IE5...not quite (2, Insightful)

syrinx (106469) | about 11 years ago | (#6498356)

IE5+ has too limited an audience to bother with, but Mozilla with SVG is worth the effort?!

You sir, are incapable of consistant thought.

And you seem to be incapable of any thought at all.

Maybe you need this spoon fed to you.

VML = only on IE5+

SVG = on any browser with a plugin.

Let's try that one again, just in case your brain hasn't quite wrapped itself around it.

VML = not everyone.

SVG = everyone.

Get it yet?

And I'd call *you* a monkey now, but that'd be an insult to many intelligent monkeys out there.

Re:IE5...not quite (-1, Flamebait)

Anonymous Coward | about 11 years ago | (#6499436)

There are indeed many intellident monkies out there, sadly you are not one of them.

I'll make this as simple as I can for your simeon brain.

The poster claimed that VML had too small an audience to bother with, and then went off on one about Mozilla.

The original post also said that plug-ins were inconvenient.

I'd call you illiterate, but you obviously can't read enough for it to be worth my while.

You monkey.

Re:IE5...not quite (2, Insightful)

aridhol (112307) | about 11 years ago | (#6499817)

The original post also said that plug-ins were inconvenient.
However, the article mentioned Flash and Java, both of which require plugins.

Re:IE5...not quite (0)

Anonymous Coward | about 11 years ago | (#6500230)

It also basically discarded both of them. Will you please learn to read you wadge of dirty, monkey sputum.

Re:IE5...not quite (1)

Lordrashmi (167121) | about 11 years ago | (#6500398)

SVG is in no way "everyone". It runs poorly in IE, and very poorly in netscape. They are just now starting to get SVG working at all in Mozilla, and I doubt it supports a lot of advanced scripting.

I hate applets, but if you need alot of client side interactivity, I would say Java is the way to go.

Re:IE5...not quite (3)

rmohr02 (208447) | about 11 years ago | (#6497774)

I would simply go with SVG. The first time I saw an SVG graphic on a webpage I was asked to download a viewer, and 30 seconds later I saw the image. That's not a real inconvenience.

Agony of Expectation (2, Insightful)

4of12 (97621) | about 11 years ago | (#6500044)

SVG to Mozilla

A solid reliable freely-redistributable implementation of SVG, and in Mozilla, would be one of the finest things, IMNHO.

A really good SVG implementation could make give web documents the elevated precision of presentation, akin to PDF, but in a W3C standard.

With extensions such as MathML and dynamic SVG, the format could form the basis of not just web documents, but paper documents (eg, stuff that currently is done in Word, Quark, Framemaker, TeX), as well as dynamic presentations (eg, Powerpoint) and, simple interactive applications that are currently done in text boxes in JavaScript.

Once a freely-available SVG renderer is available, then editing and composition tools for SVG documents should really take off. BTW, I don't count Adobe's SVG viewer because it is restricted to only a handful of platforms and no source is provided.

From what little I understand, the Mozilla SVG effort has been a one man show and entangled in licensing clauses.

It would be really nice if this were all cleared up and a big push into SVG by the Mozilla team were made.

SVG demo page -- including charts (2, Informative)

XaXXon (202882) | about 11 years ago | (#6500079)

Here's a link to an adobe site with SVG demos. If you look 4 down from the top, you'll find an interactive chart demo. []

I think this may be a good example of what you're looking for.

In terms of support, if you plan on having this application around for a while, SVG is only going to get more popular.

Re:IE5...not quite (1)

EdMack (626543) | about 11 years ago | (#6501433)

I don't see how flash is overkill.. yes it is proprietory, but you can always make the swf using php like so: php3 Anyway, here's a simple graphing example I did the other week in Flash: s.swf

I can answer the last two (3, Informative)

Kris_J (10111) | about 11 years ago | (#6497476)

Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?
1) Require, no. Use for added functionality (interactive vs non-interactive) yes.
2) No. If it doesn't work on (at least) Netscape/Mozilla then you're excluding too many people (unless you know something about your target audience that I don't).

Surely you can do something with DHTML/Javascript to dynamically resize bar charts...

Re:I can answer the last two (-1, Troll)

Anonymous Coward | about 11 years ago | (#6497557)

>> Surely you can do something with DHTML/Javascript to dynamically resize bar charts.

Not in Netscape and Mozilla. You see, they are a big pile of poo and wouldn't know what to do with a piece of JavaScript if it came with an instruction manual.

Re:I can answer the last two (1)

stoborrobots (577882) | about 11 years ago | (#6497637)

Interesting idea...

Especially since Netscape *invented* JavaScript...

Just because other systems now include a similar language (with another name!!!) doesn't mean that Netscape does not understand it.

Re:I can answer the last two (0)

Anonymous Coward | about 11 years ago | (#6498101)

Invented it or not, theirs is still a crappy implementation.

That's not an 'idea' it's a 'fact of life'.


Important Phrase - Enterprise Application (1)

borkus (179118) | about 11 years ago | (#6498937)

By "enterprise application", I take it this is an application with a large number of users (10,00+), but still internal to your company.

I'd agree with the above post for an external website. About the only two plug-ins that you can reasonably count on people having are Flash and Acrobat Reader. And IE 5+ would limit you to about 90% of the browsing public - you don't want to turn away 10% of your potential customer base.

However, if the application is internal to your company, requiring a plug-in is very reasonable. You do need to make sure you have an easy way to distribute the plug-in and that you have your support people ready when you implement your app. In fact, part of your app should be detecting if someone has the plugin then directing them to the correct page to install it. A plug-in based system linke SVG or Flash is a little easier to install than a Java Runtime Environment. However if you plan on creating more web applications, you may find yourself needing a standard JRE eventually.

I wouldn't limit myself to IE - a better standard would be the W3C's recommendations [] or you could check out the Web Standards Project [] . If you must use IE, I strongly recommend IE 6. Again, you may need to upgrade some people's browsers; you just need to include that in your implementation.

ImageMagick (1)

darkov (261309) | about 11 years ago | (#6497485)

Use ImageMagick ( and do it all server side and save your self a lot of user dissatisfaction. The chances of finding a format that everyone will see is pretty much nil. Just send them GIFs or JPEGs from the server.

Re:ImageMagick (1)

Sesse (5616) | about 11 years ago | (#6497636)

Or perhaps PNGs? :-) /* Steinar */

Re:ImageMagick (0)

Anonymous Coward | about 11 years ago | (#6497842)

Well, since the GIF patent has need to promote PNG's anymore....

Re:ImageMagick (1)

Sesse (5616) | about 11 years ago | (#6498895)

Well, PNGs still are technically far superior to GIFs, you know... No need to support a five year old legacy format anymore; everybody supports (non-transparent) PNGs nowadays. (Graphs rarely need transparency :-) )

Re:ImageMagick (1)

AssFace (118098) | about 11 years ago | (#6497791)

he says that he needs interactivity and therefore that won't work

Re:ImageMagick (1)

darkov (261309) | about 11 years ago | (#6497856)

Yes, I did notice that after I posted, but if he doesn't want to use Flash he'll have limited support, unless he insists that everybody install SVG.

He didn't actually say what sort of interactivity he wanted, but if it's anything more complex than that can be delivered using JavaScript, then he'll most probably be going back to a server for data, which makes his requirement for no server-side a bit meaningless.

JPGraph and PHP (5, Informative)

FruitCak (56337) | about 11 years ago | (#6497492)

I've recently had to do something very similar, well okay almost identical. Interactive graphs of various types and of various data sets from a Web Based interface.

We have larges amounts of data which is very hard to interperate by a human in something like a spreadsheet. The only really feasable way to do it was graphs. Of course with the amount of data we had transmitting it to the client to do client side rendering (ie Java) is also out of the question.

In the end we settled on JPGraph [] with an interactive interface built using PHP. So a wizard style interface to choose the type of graph, what data to graph, how to group the data, and finally the outputted graph with the option to change all the settings.

With good indexed data making PHP generated graphs with JPGraph interactive is quite painless and very powerful.

Just one suggestion, make sure you have a way for people to save the settings of the graphs they make so they can pull em later, keeps the PHBs happy :)

Client-side or server-side interactivity? (2, Interesting)

stoborrobots (577882) | about 11 years ago | (#6497500)

Do you need client-side interactivity (vis-a-vis an applet), or do you need a "dynamic image" (as used by most sharemarket websites [] , for example)?

For serverside interactivity, a generated image (PNG,JPG,GIF) is more than suitable...

You can even make it an imagemap, if you need image-based feedback...

Just a thought...

Re:Client-side or server-side interactivity? (2, Interesting)

Froggie (1154) | about 11 years ago | (#6497798)

On a slightly off-topic note, has anyone found a decent server-side graph generator? GD seems to be a bit pants, and almost none of them understand antialising...

One option might be to find a server-side SVG renderer. Assuming you believe SVG will become an implemented standard (practically speaking, that means something that IE will eventually support) you could generate graphs in SVG, server-side render them for the time being, and have a relatively easy way of stepping forward to a SVG + JavaScript/DOM page in the future.

Otherwise, if you want really clever ways of altering the graph's values or view that work today, you're going to have to use either Flash or Java.

Why not an imagemap? (2, Insightful)

DrSkwid (118965) | about 11 years ago | (#6497504)

As we need some interactivity, the GIF image generated on the server-side is not an option.

Surely an image with an onClick and some Javascript will do what you ask of it?

Re:Why not an imagemap? (0)

Anonymous Coward | about 11 years ago | (#6497668)

Huh? How on earth do you propose manipulating a bitmap image with "some Javascript"? He's talking about altering the proportions in pie charts and stuff.

Re:Why not an imagemap? (2, Interesting)

Froggie (1154) | about 11 years ago | (#6497778)

How on earth do you propose manipulating a bitmap image with "some Javascript"?

By fetching another image when a change is requested, perhaps? This is easy enough to do without a page reload.

Re:Why not an imagemap? (2, Insightful)

gazbo (517111) | about 11 years ago | (#6497831)


Sir, you surely jest. Have you even considered the latency issues of a dynamic interface that requires an HTTP request every time something needs to be redrawn? Even on a gigabit network, with less than 6' of cable physically separating your client from the server it would be intolerable.

You may as well say that Javascript should never be used as it can't do anything that can't be accomplished server-side.

Re:Why not an imagemap? (1)

Froggie (1154) | about 11 years ago | (#6497954)

You seem to have a very low opinion of my intelligence. Perhaps instead you should have thought about what I was suggesting before replying. I'm not suggesting that you redraw the image on the server with every mouse movement, which seems to be what you're thinking of.

Javascript can't alter images, but it can make it moderately simple to e.g. pick a zoom area (downbutton marks a point, dragging draws a box in another layer so that the user can see what they're doing, upbutton sends the request with the co-ordinates gleaned). The responsive graphical part of this is client-side, and the relatively infrequent graph redraw is server-side.

I'm sure, with a little imagination, you could come up with a range of operations that you could perform in a similar manner - possibly even as far as e.g. changing bar sizes, if you were prepared to put the time into writing the Javascript. Although in my experience more than a minimum amount of JS brings enormous cross-browser maintenance and browser crashiness problems...

There are also more basic applications of the same idea, where you use an image which you occasionally reload and a set of form elements that change the graph parameters. So, when someone changes the graph from a bar to a line, only the image, and not the whole page, is redrawn. If you look around enough share-price-graphing websites, you should find a few examples of this.

Re:Why not an imagemap? (1)

gazbo (517111) | about 11 years ago | (#6498027)

OK, a hybrid solution may be acceptable depending on exactly what he wants (as in a visual clue, such as rubber-banding, drawn by Javascript, then the finished operation rendered by the server) but I think that it would be tricky to generalise this to all of the possible operations he may want.

For example, you are basically limited to drawing a rectangle. You could specialise this to only allowing a horizontal line, or a vertical line, but ultimately that's all you can get without running back into the very problem he's trying to solve.

OK, I'll apologise for being harsh (well, 99% of my slashdot contributions are trolls, and it's hard to flick out of character) but one of the common problems with "ask Slashdot" questions is that unless it is highly technical to start with, everyone is willing to chime in with irrelevant, dumb and downright wrong answers. And the entry bar doesn't get much lower than talking about web pages (read some of the "helpful" comments in this story about useful server-side graph utilities, for example) so I figured you'd just not thought it through.

So there we go: an official gazpology - cherish it, for it is a rare and wonderous thing indeed.

Re:Why not an imagemap? (1)

Froggie (1154) | about 11 years ago | (#6500535)

Wow, apologies on Slashdot. The end of the world is nigh. ;-)

Re:Why not an imagemap? (1)

Pieroxy (222434) | about 11 years ago | (#6501351)

The idea is that the more interactive the better. GIF/PNG generation on the server side is not that interactive, that's why we were looking at other possibilities.

Premptive Strike at anti-IE zealots (-1, Flamebait)

Anonymous Coward | about 11 years ago | (#6497507)

Fact : IE probably has got enough of an install base.

You could support Opera and Mozilla and Netscape and Safari, giving you about 5% market coverage and a painful case of lowest common denominator, or just plump for IE and be done with it.

Fact : If the other browsers don't support VML, then that is not Microsofts' fault or problem - this is a W3C supported specification.

Go on, flame away, you'll just be wrong is all.

begin flame bait
In fact, I doubt many of you future flamers will actually get this far into the post, you'll have just read the subject and reacted like the predictable monkies you are.
end flame bait

Re:Premptive Strike at IE zealots (0)

Anonymous Coward | about 11 years ago | (#6497518)

well in my experience i can create great interactive STANDARDS COMPLIANT sites that work completly in Opera, Mozilla and Safari, then have to go bugger it up to get it working in IE

Re:Premptive Strike at IE zealots (-1, Troll)

Anonymous Coward | about 11 years ago | (#6497529)

SVG is STANDARDS COMPLIANT (as you put it), due to it being a standard.

In my experience, Opera is a necessary evil on Linux, simply because IE isn't available.

As the grandparent pointed out, you are most certainly a reactionary monkey.

Hijack Excel (0)

floydigus (415917) | about 11 years ago | (#6497542)

This may not be ideal for you, and its a bit of a kludge, but others might find it interesting...
It's relatively trivial to use VBA to get Excel to generate a nifty graph. Now use the 'save as html' format and it will save a nifty gif of the graph. I have written a wrapper for this process which means I can pass in a dataset and end up with a reference to the graph file.

Re:Hijack Excel (0)

PhlegmMaster (596165) | about 11 years ago | (#6497574)

That not only requires a nice big plugin download (that bitch ain't small), but it's also ActiveX and IE only.

Re:Hijack Excel (1)

floydigus (415917) | about 11 years ago | (#6497593)

Without trying to sound rude: Bollocks. Try reading the posts before replying to them.

Re:Hijack Excel (1)

PhlegmMaster (596165) | about 11 years ago | (#6497703)

I did, but I just realised that you meant save as html (which is different from save as web page).

Re:Hijack Excel (0)

Anonymous Coward | about 11 years ago | (#6499696)

This won't work if the data is live -- Excel is a big pig singlethreaded process that doesn't run well on the web server.

And even though you aren't talking specifically about the "web components" -- steer away from them too. They suck.

dumb question (0)

Anonymous Coward | about 11 years ago | (#6497545)

Is IE5+ a wide enough target for an enterprise application?"

sorry for trolling, but that sounds like a dumb question.
no matter how much this site hate micro$oft, we still have to accept the fact that window$ still dominate the market.
at least 8 out of 10 of my randomly picked friends are using windows.

Re:dumb question (0)

Anonymous Coward | about 11 years ago | (#6497548)

Well done you, for being correct.

Alas, I expect some flamage to follow.

Probably along the lines of "IE isn't standards complient, blah blah blah" completely ignoring the fact that it is the VML part that fails to work in their browser of choice, and this is a W3C defined standard not a MS one.

Re:dumb question (1)

erinacht (592019) | about 11 years ago | (#6498259)

dumb is the wrong disability - blind (having no vision) is probably a better.
The thing about WEB STANDARDS is that the latest MS browser is really rather compliant - after all Microsoft are a major player in the creation of these standards.
Coding web pages for standards compliance INCLUDES Internet Explorer which will render reliably and faster when in standard compliant mode.
Quirks mode is used for junk HTML markup to make sure that badly written web pages will still work, but this mode may well be dropped some future Microsoft World Wide Web Reader Application.

The point of the standards is nothing to do with market share, linux, mac or anything else, it's about making sure that the pages produced will work today with the minimum of effort on the part of the author AND that these pages will continue to work into the future WITHOUT changes.
Do you get it?? It doesn't matter which browser you use - you'll use a different one in the future.

Re:dumb question (0)

Anonymous Coward | about 11 years ago | (#6499489)

>> It doesn't matter which browser you use - you'll use a different one in the future.

Not if you use IE, and avoid taking stupid pills.

Re:dumb question (0)

Anonymous Coward | about 11 years ago | (#6501212)

IE isn't standards complient, blah blah blah

Neither is your writing.

Re:dumb question (1)

Phillup (317168) | about 11 years ago | (#6500555)

Well... Windows may still dominate "the market"... but, an "enterprise" and a "market" are totally different beasts.

I'm currently working on an "enterprise application" and the target browser is Mozilla 1.2 .


Because with three flavors of Win95... and Win98... and WinMe... and W2k... and Win eXPerimental... and let's not forget the many versions of MacOS running all over the place...

Well... Mozilla was the only browser that would run (consistently enough) on them all.

And... it doesn't insist that we upgrade our operating system and upgrade our applications to work on the upgraded operating system... just to run a newer browser.

Oh yeah... the "enterprise" is a school district where we insist on:

1) A high return of investment for our software... just as our hardware. Constantly "upgrading" reduces ROI.

2) Teaching computers... not "Windows"

And don't kid yourself that this is happening just in schools. Many businessess consider IT to be a cost factor and are not convinced that the cash register will count money any better if they upgrade to the latest OS.

With many versions of Windows in your business... IE becomes less of an option because of MS "integration". What business wants is a browser that works... on *ALL* of its computers!

P.S. The application is for administrative & teacher use. But, we can't afford computers for the sole use of the teacher... we can't "standardize" the platform. That *would* change the equation.

So, the teachers use what is in the classroom... and that means we have to reach a very wide audience... and that means IE, for all of its "market share" is not an option.

SVG + alternatives (1)

khanyisa (595216) | about 11 years ago | (#6497577)

Facing the same question, we are taking a route where people can have either SVG (if they have a plugin) or a standard image format. Then server side we render the chart onto the required format. SVG is really nice - compact (if compressed), simple, scalable, ability to have dynamic interaction etc. but PNG etc are good to have as fallbacks...

If it's meant to be this interactive.. (4, Insightful)

lpontiac (173839) | about 11 years ago | (#6497578)

.. and that interactivity is hard to achieve in a web browser, maybe this application doesn't belong in a web browser. Just a hunch.

Re:If it's meant to be this interactive.. (1)

stoborrobots (577882) | about 11 years ago | (#6497648)

Agreed... It is not useful to webify every single application...

Some apps are just better off as applications than webapps.

Consider whether the webapp route is really worthwhile in this case. If it is, then you may have to sacrifice interactivity (a little). If it isn't, then use a conventional application, and deploy it...

Just my $0.02

What SPARKLING *insight* (0)

Anonymous Coward | about 11 years ago | (#6500650)

slashdot is pathetic... rules by 12 years olds with a grudge.

Re:If it's meant to be this interactive.. (1)

Pieroxy (222434) | about 11 years ago | (#6501397)

It does exist and is achievable in a web browser. The question is more about "What's the state of the art today ?", or "What's the best alternative for our App ?"

How closed is SWF really? (3, Informative)

Burb (620144) | about 11 years ago | (#6497599)

The SWF format is pretty open, as these things go. The FLA format used by flash is proprietary, but SWF documented and that's the bit that actually get's published on the page.

The MING library can generate SWF from PHP et. al.

Flash isn't as bad as it used to be (3, Insightful)

Andy_R (114137) | about 11 years ago | (#6497600)

I've been pleasantly surprised by Flash MX, actionscript is a fully featured programming language that runs across all the platforms Flash is ported to. You can pass variables from your html page, so your graphing application should be writable as 1 single 'movie' that accepts data, rather than writing a new one every time you need to draw a graph.

The only problem is that the tutorials and manuals are aimed purely at designers, not at programmers, so the concept of a variable is given a 20 page explanation whereas the syntax of the more complex commands is glossed over in a 'do this and it works, you probably don't need to mess with it' manner.

Re:Flash isn't as bad as it used to be (1)

AssFace (118098) | about 11 years ago | (#6497808)

Flash has been able to do that for a few versions now.

Flash is moving more and more towards what Shockwave used to be.
Flash doesn't support OpenGL or anything the way Shockwave does, but it is a very good tool for certain things - making dynamic/interactive graphs is certainly one of the things that it is good for.

Have you considered TABLE (2, Informative)

Burb (620144) | about 11 years ago | (#6497605)

For simple histograms, you can go quite a long way with TABLE TD and TR, and a few 1x1 coloured GIF files stretched to suit. Primitive perhaps but very portable to most browsers. OK, lynx users will get cross ... maybe generate ASCII art for them

Re:Have you considered TABLE (1)

Pieroxy (222434) | about 11 years ago | (#6501422)

Do I need to mention that Lynx is not our target ? ;-)

Histograms works the way you describe, that is true, but other things needs to cooperate on the same graph as well...

Point taken: DHTML might be a reasonnable fallback.

Java might be faster than you think (3, Informative)

dhk42 (586518) | about 11 years ago | (#6497667)

If you want the interactivity, you should at least try an optimized pared down applet. It's true that most applets are slow, but it is frequently also true that they are written badly and/or contain heaps of additional libraries that they need to download. Use as much of java's built-in code as you can with the possible exception of the GUI library.

Look at lightweight graphical libraries like lwvcl (commercial) [] or thinlet (LGPL) [] for the controls. The zaval people [] even have a charting library for their lwvcl system. (I have never used the lwvcl library, it just looks cool - try their online demo [] . Thinlet packs amazing capabilities into a very small package.)

If you need to display 15 graphs at a time with limited interaction, then this may not be the way to go, but if you need to display one at a time with very rich interaction, this might be the ticket.


Java (1)

Admiral Burrito (11807) | about 11 years ago | (#6497690)

Java is very flexible but slow (to start and run).

A while back I created a small Java applet that did some minor client-side image mangling. There was a delay of a fraction of a second bringing up the image. Not "slow" by any means. Most of that delay was probably the time it took to download the image from the server.

The real problem is that you have to stick to what is available to the 1.1 runtime. Yes, that's "1.1" from the previous century, because that's what most Windows users have.

We use Corda (5, Informative)

pbulteel73 (559845) | about 11 years ago | (#6497768)

Most of these posts suggested image formats... I have a suggestion for an application if you want charts.

Corda [] might do what you need. It will output the images in Flash, JPG, PNG, GIF, SVG and others. I believe it uses XML files to generate the graphs. I'm sure I'm missing a lot of the other things that it can do, but it's worth taking a look. Oh, and unfortunately it's not free, but it might be worth it if it does what you need.

Note: I do not work for this company. I have seen the results of using their product. We use it where I work and everyone seems to like what it can do.

Expensive (1)

Futurepower(R) (558542) | about 11 years ago | (#6497804)

Yes, but it costs thousands of dollars!!!

Re:Expensive (1)

Zardoz44 (687730) | about 11 years ago | (#6497993)

I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...) for a web-based enterprise application.

Thousands of dollars is par for the course when talking about enterprise applications. There was never any mention of cost limitations in the original article.

Re:We use Corda (1)

pmz (462998) | about 11 years ago | (#6500183)

Corda might do what you need. It will output the images in Flash, JPG, PNG, GIF, SVG and others. I believe it uses XML files to generate the graphs.

With that many buzzwords, you can't go wrong! (everyone cheers) COR-DA! COR-DA! COR-DA! YAAAAYYYYY!

GD::Graph is quite popular, fast, and easy. (1, Interesting)

Anonymous Coward | about 11 years ago | (#6497794)

In perl.
Blazing fast with mod_perl.
Very easy to learn.
More info here [] .

Oops, forgot to mention... (0)

Anonymous Coward | about 11 years ago | (#6497821)

You can dynamically call it with javascript.
You can use an image map and some javascript.
You can put results in a frame or an iframe if you don't want the entire page to reload.

I wouldn't write the whole thing in javascript alone -- why reinvent the wheel?

Javascript (3, Interesting)

Basje (26968) | about 11 years ago | (#6497795)

I once wrote a piece of javascript that would do this client side. It was for a corporate intranet, so I knew which version of which browser was going to be used.

The idea was simple: I created a table with every cell one pixel large, and set the colors accordingly to the input for the frame. It started out as a simple line graph, but in the end it could do bar and pies too.

This should be doable crossbrowser now that JS has stabilized enough between IE and Moz. If implemented right, it can really do with much lower bandwidth than pictures (which was the main requirement then): the .js file can be cached, so only the data has to be sent, measuring a large multicolor pie graph in bytes rather Kbytes.

Same problem (4, Insightful)

gazbo (517111) | about 11 years ago | (#6497814)

We're doing a similar type of thing, but not specifically graphs - arbitrary vector graphics are required, and client side is most definitely required. The route I went with was VML.

There were a few options that I rejected:

  • Flash - probably extremely good at this sort of thing, as vector graphics and user interaction are its big target. However, we have no in-house expertise, and the end-users will all be professionals who may very well not have Flash installed (and furthermore, their firewall may not even give them HTTP access to download it)
  • SVG - Great! It's W3C approved, as opposed to the officially deprecated VML! Whoop-de-fucking-doo. When our clients complain that our application doesn't work, I'll point them to the W3C spec and have the warm glow of righteousness as all of the lawyers' letters demanding refunds come in.
  • Java - Well, it can handle drawing and events just fine, we have in-house expertise, but the whole point we're doing this through the browser is to avoid having to write an application from scratch in the first place. Now calling it an "applet" and changing main() to start() doesn't alter the fact that IMO writing user interfaces in Java sucks my grandma's clit.
So, VML. We have the luxury of knowing that the standard desktop is Windows running IE. I suspect that at least 95% of your target desktops (you did say enterprise, right?) will be IE too. Furthermore, if they're running Windows then you know that even if they are running, say Mozilla, that they have IE to hand.

At the risk of posting flamebait, do you really have to worry about the possibility of end users running a non-MS operating system? Almost certainly not. Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.

Unless, of course, you do wish to use Flash and have the expertise - although I still think you'll run into issues of people not having installed the plugin.

Re:Same problem (2, Insightful)

bill_mcgonigle (4333) | about 11 years ago | (#6500042)

Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.

FYI, IE for Mac is a discontinued product.

There's really little point in writing a Windows-only web site. I mean, if you're not going to be multi-platform, why hobble yourself with the web in the first place? A real Win32 app will be much easier for everybody.

That he wants a web-based product is a good hint he wants multi-platform.

To add some signal to the noise, I'm facing the same issue, and generating Flash from Perl is the approach I'm planning to investigate first.

Re:Same problem (1)

gazbo (517111) | about 11 years ago | (#6500193)

Ah, yes. Forgot about Mac/IE.

And there is sense in writing web apps for specific environments. First, if you're providing it as a service for hundreds or thousands of people, then you have the ultimate thin client - zero rollout, just a URL. Also, no need to worry about server security or reconfiguring firewalls, as everything runs on Apache and port 80. Also, as with a similar project I'm doing, if you're mostly interested in showing a load of data, then a web browser is an ideal platform to do it in; HTML talking to your choice of mod_perl, mod_php, whatever is a really, really easy way of coding an attractive, multiuser interface to data.

The cross-platform nature is just a neat bonus.

How about HTML and CSS? (2, Informative)

DeadSea (69598) | about 11 years ago | (#6497815)

Here's a mockup of a bargraph for a web site statistics package that I'm working on: []

It is done using only HTML with CSS. There was some reason that the bars come down from the top rather than up from the bottom, but I don't remember what it is right now...

Re:How about HTML and CSS? (1)

gazbo (517111) | about 11 years ago | (#6497846)

OK, fine. And if you changed the height attribute using JS then I'm sure it would all work just nicely.

Now write the equivalent for a line graph or a pie-chart and I'll give you a cookie ;-)

Re:How about HTML and CSS? (2, Interesting)

DeadSea (69598) | about 11 years ago | (#6497884)

Pie chart would be hard. I'll bet you could do a line graph. I'm thinking that you could generate a large table with javascript. You could set each each of the cells to be 1px by 1px. Then turn on the backgrounds of the ones in the line. It'd be a bit of a cludge, but it just might work. (Come to think of it, pie chart might work like this too if you have enough time on your hands).

Re:How about HTML and CSS? (3, Interesting)

gazbo (517111) | about 11 years ago | (#6497938)

Cute idea - time to dig up the rasterizing algorithm and port it to JS. Yeah, in principle it would work (might possibly be a problem trying to persuade the browser that no, really, I honestly do want these TDs and TRs all to be on adjacent pixels.

I wonder how quickly a browser could re-flow a document that included an 800X600 cell table...My guess is "painfully", but it's almost worth writing the concept code to find out - time to write some PHP (I'm buggered if I'm going to write it by hand)

Re:How about HTML and CSS? (1)

TheShadow (76709) | about 11 years ago | (#6498438)

Well, everyone has those 3.2Ghz Hyperthreaded processors now so it shouldn't be a big deal.

Is PDF even viable? (1)

jolshefsky (560014) | about 11 years ago | (#6497881)

Here's a couple ill-thought-out ideas:

In considering possible solutions, I would take a crack at PDF. I've never done PostScript programming, but as I understand it, you can create vectors, arcs, and splines pretty well. Actually, since I don't have a good graph-generating package myself, I may just look into this ... hmm.

For my own use I would also look into CAD software formats ... what was it, DXF? I gather that's pretty simple for vector stuff, but it's not readily supported in browsers.

"Enterprise" (1)

Muggins the Mad (27719) | about 11 years ago | (#6497892)

I think it depends what you mean by "Enterprise application".

If you mean this is for a company intranet or something where you can control the browser they're using, then having to install a plugin for SVG or Flash wouldn't seem to be a problem. Neither would dictating IE5+, although you might find that limits the companies options later.

If you mean it to be "professional looking" for as many customers as you can, then obviously going IE only is about as short sighted as you can get (remember Mac users are about to be excluded) leaving you with probably 10-20% unable to use your application. Requiring a plugin might be a hassle but if it works on everyones browser choices then maybe that's still ok.

But I don't understand why Java is the wrong answer here? Most people have it, it really isn't slow to start and run unless you're doing something boneheaded with it like sending many megabytes of libraries you don't need.

You can even do some surprisingly powerful things with Javascript, although coding them to work in buggy browsers (all of them, especially IE) can be a real pain.

- Muggins the Mad

Accept: image/foobar (1)

42forty-two42 (532340) | about 11 years ago | (#6497912)

Why not check the HTTP Accept header? If SVG's in there, use it. If VML's in there, use it. Etc.

ThreeDGraphics (1)

Zardoz44 (687730) | about 11 years ago | (#6497966)

Since this hasn't been mentioned yet, you may want to look into these guys:
Three D Graphics [] .
As with many things, it all depends on what you need and how you use it. You can definitely get interactive web-based charts generated on the server side using their PGSDK, but it may be a more comprehensive (i.e., expensive) solution than you need. They support just about any chart type, including OpenGL rendered 3-Dimensional bars, complete with texturing, etc... Overkill for most, but it gives you an idea of what's possible. Plus they run on all platforms.

(I don't work for them, but I have used their products)

Why not... (1)

kashmirzoso (592597) | about 11 years ago | (#6497969)

If you can control the browser to be IE5+ and don't mind using a plugin, you could..... write a .NET control using the System.Drawing namespace. Very easy to use. I have done something similar where I generate .png files on the fly based on user input and a resulting DataSet. p.s. I will preceed to duck now, trying to avoid the flying tomatoes.

Ploticus (2, Informative)

jedimaster101 (199049) | about 11 years ago | (#6498047)

I rarely comment, but I can't help it here. I work for Wal-Mart, and I'm on a team that needed to be able to graph a system's performance (CPU/mem/network/disk usage, et cetera). Similar situation to what you're in, I think. I'm not sure what they were using beforehand, but everybody, managers included, is extremely happy that they've switched to Ploticus. They rave about how fast it generates a graph. It's very, very flexible. And it's open source; I noticed a subtle bug, and a few days after notifying the author he gave me a fix.

We have the raw data points coming in from a server-side scripting language (proprietary, unfortunately). These points are passed to a Perl script which parses the data and stores it in a format Ploticus can recognize. It also generates the configuration file used by Ploticus.

I'd really highly recommend Ploticus. No plugins needed. Once you figure it out, it's a dream.

use flash (1)

sarabob (544622) | about 11 years ago | (#6498067)

Use flash - I don't know how you can dismiss it as overkill when you consider using java.

If you just need the basics, you can use ming to generate the graphics, and most of the vector drawing programs will save as .swf

You get cross platform support (pc, mac, linux, IE, opera, moz) and no plugin download for >80% of your audience. ECMAscript-like actionscript for interactivity, and a whole shedload of developers to help you when you get stuck.

OK, so it's not quite OSS, but you *can* get the source, generate your own swfs using OSS etc.

Someday the net will get over those flash intros and see flash for what it is - a compact, cross platform plugin

Server side java. (1)

(H)elix1 (231155) | about 11 years ago | (#6498185)

Argh - way to many 'but java applets suck' posts already. They do. Wrong tool for the job. Just about any servlet textbook will give an example where an image was created on the server side, set the appropriate response type, and stream it back to the user. As long as you are creating the image on the fly, there is nothing stopping you from also creating an image map/html that gives you user interactivity. Odds are post/re-paint will be enough. Take a look at or most interactive maps that push you a gif for an example.

Reliance on the client will lead to nothing but heartache IMHO.

IE5? I'd say so (1)

PhilHibbs (4537) | about 11 years ago | (#6498190)

Is IE5+ a wide enough target for an enterprise application?
Google sees very little else. []

damn lies... (1)

erinacht (592019) | about 11 years ago | (#6498468)

Beware of statistics... This google graph is very good and someone else has quoted 5% of world wide web viewers are not IE
The internet statistics site [] estimates 605.60 million online so a litte itsy bitsy (statistically) 5% of that works out at 30.28 million NOT USING IE!

Anyway - besides the point really - it's an enterprise application - how many people (not percent) in the OP's organisation are using IE vs others - if that number is high enough, then go for IE, but make sure you generate standards compliant markup so the enterprises choice of browser is not down to bad coding, but down to features, ease of use, familiarity and other good reasons like that.

Consider Java *and* SVG (1)

Boiotos (139179) | about 11 years ago | (#6498203)

Don't forget that the Batik [] SVG toolkit includes a Java Graphics2D class that outputs to SVG. This means roughly that any class that draws stuff to the screen can be quickly tweaked to draw the same stuff to SVG. If you find a pleasing Java graphing package whose source is open, you could use it to make SVG graphs on the server. (I assume when you claim that java is slow, you are referring to client startup or something.) Just remember to gzip the output stream because svgz documents are about 20-30% the size of their svg equivalent.

Finally, it should be noted that the upcoming Adobe SVG Viewer 6 (available now in beta [] plays nice with Mozilla / Netscape 7. (Although a win32 binary only is provided, the team at Adobe stated that they are building for Linux and OS X, too.) Assuming ASV6 will be out by the time your project is done, platform breadth isn't a problem for you.

Hmmm... (1)

Tyrdium (670229) | about 11 years ago | (#6498636)

Would Flash work for something like that? I'm not sure how the speed compares to Java, though...

Anybody ever hear of Graphics Server? (1)

RolandGunslinger (597069) | about 11 years ago | (#6498677)

I rolled by own active-x dll using Graphics Server 6 to produce jpegs, the image map, and all the supporting html. Upside, Graphics Server is a very robust graphing tool; downside, still has some issues with concurrency. Plus; no client side components needed.

I would use java (1)

hswerdfe (569925) | about 11 years ago | (#6499140)

first the word "ENTERPISE" is a pet peeve of mine.
exactly what does it mean?
as far as I can tell, its supposed to mean high end software with every feature possible and a much lower than average bug count.

but that dosen't tell you if ie5 is a large enough target market, and itdoesn't tell you if a plugin is acceptable to use.

If you have 100% control over the machines you will be installing on then yes ie5 is an aceptable taget.

it is always acceptable to expepect the user to intall a
plugin if
1. your software is a useful AND
2. your software will be used many many times.
don't expect a user to install some fucking plugin to visit your site once.

as for the technical aspect.
I would use java, based completely on the fact that I know how to use java.
there would be a huge learning curve for me to use flash, or SVG....but I'm not the issue.

go to the guy who is going to do the coding and ask him what technology they know best.

then use it.

You've been FUDed (1)

aminorex (141494) | about 11 years ago | (#6499563)

Take a look at, or
Tell me again that Java applets are too slow.
Try to reimplement those applets in Flash, then tell me

Macromedia Flash (1)

nsebban (513339) | about 11 years ago | (#6500489)

Flash is a good way to do that.

- It usually generates small .swf files (as long as your scenes are clean)
- It's scriptable so that you can generate dynamic charts without a big effort.
- Everybody's got a flash plugin, as it exists for nearly every OS.

And as the Flash community is really huge on the web, you will easyly find many resources and tutorials about building that kind of animations.

Java not so good (1)

Stormalong (36874) | about 11 years ago | (#6500647)

I had to deal with this for the web GUI for one of our products. The solution has gone through a few revisions. The graphs consisted of two pie charts and a bar chart.

Version 1: images generated on the server (perl script using GD). This worked well, but I came to dislike how it had to download a new image every time you refreshed the page. Some of our customers were on pretty slow links. Also, we wanted the next version to work on Windows (v1 was on linux), and the perl/GD thing was going to be a pain. Our product is a web cache, so obviously I'm a bandwidth conservationist, and the bandwidth needed to download the images over and over offended me. :)

Version 2: images generated on the client using a java applet ( was only $50 or so). Nice, because the images are generated client-side, but the applet took awhile to download on slow links, and the startup time is BRUTAL. I came to hate this solution.

Version 2.1: pie charts done with Flash, bar charts done with DHTML/javascript. This has been working great! Flash starts up instantly, and almost everyone already has it. The numbers for the graphs are just included in the HTML code, and Flash/javascript uses those numbers to generate graphs. There are 2 numbers for each pie chart, and 60 numbers for the bar graph. Being text, they take up very little bandwidth.


joeldg (518249) | about 11 years ago | (#6500666)

DHTML and CSS are probably your best option. you can specify exact screen coordinates which DHTML and place pixels. All the display crunching is done on client side and the layout is done on your side. I have used this same thing for doing placements on a map of the world.


josepha48 (13953) | about 11 years ago | (#6500832)

Yes, listen to this post. DHTML is very powerful and many people don't use it. With DHTML you can support Opera 6+, Konqueror3+ (maybe earlier versions?), IE4+ and NS6.1+ with very little difficulties. Using the div tag you can do wonders.

EG: create a style sheet that creates a div with a border. Change the height on this and add in absolute positioning and you now have a bar graph. Data could be sent to the client in a a set of JavaScript arrays (one for X, one for Y or 2 d array). Create a few functions for A controlling layout and B controlling size and tada you have pretty client side graphs and charts without a plugin. Will work pretty nicely on above mentioned browsers too.

ColdFusion (1)

Tablizer (95088) | about 11 years ago | (#6501130)

I would note that ColdFusion has tags that draw various graphs. True, there are probably some open-source equivalents, but if you already are using CF, then give it a try. Like everything else, CF makes it pretty easy to get started[1]. (I found some of them buggy, but maybe they have since been fixed.) I believe is generates the graphs on the server, and then just sends a GIF to the browser.

[1] Fast learning/starting and long-term productivity are not necessarily related, I would note. CF is pretty easy to learn, but it is somewhat hard to build certain types of frameworks with IMO.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>