Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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?"

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.

I've been using TWiki [twiki.org] for collaboration notes, and one of its features is a plugin for charting [twiki.org]. It manages to draw jpegs and pngs using the perl GD module [cshl.org] and the gd library [boutell.com].

Of course, you'd need to write your own server side to generate the chart you want, but these tools put you easily along that path.

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

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, Po

This tells me SVG is *slow*.
Check out the CML2SVG demo on a PC in the 1GHz range.
Yikes. I've seen faster simple wireframe spins on a 286.
(Yeah, I understand how much more is going on under the hood, but this is still painfully slow.)

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

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

Use ImageMagick (http://www.imagemagick.org/) 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.

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

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.

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 [aditus.nu] 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:)

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/D

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.

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 ver

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

Anyways, I'll try to explain the problematic of the web-based applications: No deployment.

Cost of developping an HTML page running on Linux/Mac/Windows/IE/NS/Opera: 1 dayCost of developping a proprietary app running on all that (only showing the page in question, with let's say a little form): 2 weeks

Anyways, I'll try to explain the problematic of the web-based applications: No deployment.

If you're an enterprise, you already have a remote deployment solution (Ghost images, Ghost packages, Microsoft's SMS packages) or you should do - how do you deploy fresh installations and updates to local applications like your office suite, web browser, email program etc?

"OpenSWF.org is the source for information on the Flash File Format. Here you will find file format specifications, sample code, links to 3rd party tools and more.

SWF is the file format used by Macromedia Flash to deliver graphics, animation and sound over the Internet. Almost 95% of web users can view SWF content without having to install a new plug-in, and over 300 million people have downloaded the Flash player. Macromedia published the specifications for SWF in April 1998. This site has re

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.

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

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) [zaval.org] or
thinlet (LGPL) [mycgiserver.com] for the controls. The zaval people [zaval.org] even have a charting library for their lwvcl system. (I have never used the lwvcl library, it just looks cool - try their online demo [zaval.org]. 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 Applets are not slow per se, but the Java plugin is a pain to start. On a laptop a little busy, it can take somewhere around 10 seconds...

Plus, the first time I clicked on the links, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one gets a dead-lock with the GUI thread, we're also dead.

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.

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

Corda [corda.com] 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.

See, I went to the link and it demonstrate exactly what we are trying to avoid. The live deom "2000 Presidential Election Results":

Every single time you click anything, the screen reloads and it takes 3-4 seconds to get the new graph. The user experience behind this kind of figures is really bad, as I don't keep in my mind an idea of a nice graph even though the graph was nicely drawn, beautifully anti-aliased. But barely usable.

Try out VML if you're not concerned by IE5 only limitations, and experience t

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.

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.

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 Flas

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;

The filename of Flash Player 1-5 was "swflash.ocx". Flash Player 6 was renamed to simply "flash.ocx" because Windows XP's file protection prevented the bundled Flash Player 5 swflash.dll from being overwritten by the Flash Player 6 downloaded from Macromedia.

Yeah, someone else already pointed out that flash was bundled. As you may have guessed, the overriding reason was that we have no Flash experience (Also a PHP coder whose environment is a text editor).

As for W3C ratification, I think you're being optimistic. Yes, it's nice to future proof things. However, SVG has been around for a couple of years, and is still not natively supported by IE. VML, however, is, and has been for some time. Even if (when) IE starts supporting SVG, there will be a significant

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

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)

I actually gave it a try... 'twas too long this idea was in my head, so I tried it....

My PC is approx. 1GHz.

320x20 (yes, 320x20 not 320x200) pixels takes approx 1 minute to be built through DHTML. (Using a table and a TD for every cell). Giving that 320x5 takes 4 seconds, it is not linear and we can deduce that a 320x200 matrix would be built in a couple of days.

...and throw in a rasterizing algorithm on top of it as well and we're in for some serious fun.

Well, I'm glad you tried it out as otherwise I'd have been compelled to write the code myself. But your results do confirm my suspicions of the people who claimed that they'd done this before. I can only assume that they meant the idea had occurred to them before, but wanted to sound "cool" by claiming they'd implemented it. Whatever.

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.

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 ar

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 notif

Interactivity on the client side is necessary for smoothness of the display.

Deciding that I want to add a specific data set to my graph or that I want to see a histogram instead of a line plot has another dimension when you can actually do it instantly. The server-side roudtrip add an unnecessary perceived heavyweightness (should I say bloatiness) to the web app, even though architecturally, moving things to the client side is probably heavier.

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 mapquest.com or most interactive maps that p

Don't forget that the Batik [apache.org] 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 si

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 aplugin if1. your softw

Plus, the first time I clicked on it, it froze my browser. Granted, some other applets running might have been introducing some crappy threads in there, but welcome to the real world. If we use Java, we share the same JVM with any other Applets our end-user is viewing, and if one dead-lock with the GUI thread, we're also dead.

Two options we use areJFreeChart (http://www.jfree.org/jfreechart/index.html), which is totally serverside generated. Not sure what you mean when you say you need interactive charting - we let the user spec some params and toss them a graph.

On the other side of the spectrum we also useSpotFire (http://www.spotfire.com/) which is not at all free, but which is REALLY powerful. Scientists and statisticians seem to love it...

Since the formats for a.swf file are publicly available from Macromedia.com or openswf.com and since people and companies outside of macromedia have written software that creates and plays.swf files, how closed is closed? Is it the fact that the format is actually owned by someone and enforced by a license?

If so, we might as well say that Linux is a "closed technology" because of the GPL.

Flash isn't overkill at all. Except for sound. This is essentially the sort of thing it's designed for: to quickly render vector graphics. Notably, it's got a far larger deployment than SVG, Java/Javascript, or VML. Also, because the viewer is closed, it's both compliant with its own standard, and relatively stable. Moreover, it's ubiquitous; it ships with pretty much everything, and can be downloaded in a form appropriate to nearly every major web

Putting together the responses to date, it seems like this is the story:

SVG: lots of potential; the ideal solution if the plugin is installed or easily installable; XML based

Flash: the pragmatic choice; installed nearly everywhere; works reliably on all platforms; can be driven via XML

VML: good fit for IE 5+ browsers, since it's supported in a default install; unsupported in Mozilla; deprecated technology; XML based

Java applet: slow to startup; JFreeChart looks very powerful provided startup times are acceptable and browser support is available

In case you can't tell, I'm facing the same problem as the original poster. I also can't deploy server-side solutions, so PHP, Perl GD, etc are all out.

Based on this, I'm inclined to build a generic XML solution, then rely on plugin detection and XSLT to deliver either SVG or VML as appropriate. That covers me for IE 5.5+ and anything with SVG support. The largest group that I don't have covered is Mac users and people with older browsers, and I could probably come up with a different XSLT to cope with them if the demand made it worth doing.

That's a nice one but two problems over there:1. That bounds us to IE since the "Save As" feature generates a very IE oriented output (even though it might work ugly on Netscape)2. Then, why not using VML ? More flexible, lightweight, it's even a w3c standard

I agree with you about the "big pig singlethreaded" thing, but that doesn't *actually* mean it won't work: provided you have a beefy enough server, I'm not aware of any reason why Excel can't run on it.

Even so, personally I would use this technique for pages that are updated periodically rather than on the fly.

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 funct

Well, very tempting, but how do you draw a pie chart with this solution? Granted you can position DIVs of one pixel anywhere in your page, the DOM control is not that fast that performance is going to become a major issue.

You add a few more functions, drawLine(x,y,xx,yy) and draw circle() or a draw piepeice() / drawArc(). Intially it would be alot of work. There may even be libraries out there already that does some of this. With DHTML you can also add in mouse movements (yes you can do that in flash and java too). At this point you are talking about creatig geometric shapes on a canvas using JS.

Well, I don't think you're right on this one. IE will be bundled with the OS, granted, but that doesn't mean you will not be able to install IE7 with WindowsXP. It just does mean it will be part of a service pack or another type of upgrade.