I've been using server side graphics using libs that don't require AWT image. This works fine for me (including server side svg generation etc.) and you can take advantage of the app engine image transforms.
On 21 Jun., 07:28, bradr <brad.rydzew...@gmail.com> wrote: > What about Google Chart > API?http://code.google.com/apis/chart/image_charts.html > > The Google Charts API lets your create charts by simply encoding your > dataset and chart formatting options in a URL. The URL returns a PNG > image. No javaScript is required. See this example Pie > Chart:http://chart.apis.google.com/chart?cht=p3&chd=t:60,40&chs=250x100&chl...World > > Google Chart API is pretty capable and offers features that JFree > chart lacks (such as Maps). In fact, JFreeChart has a sister project > called Eastwood charts which provides a URL-encoded way of exposing > JFeeChart that is identical to the Google Charts > API:http://www.jfree.org/eastwood/ > > An added bonus of Google Chart API is that your not rendering images > inside your JVM and burning through your AppEngine quotas, which > should reduce your hosting costs. > > On Jun 19, 11:51 pm, Blessed Geek <blessedg...@gmail.com> wrote: > > > > > IMPO, the best Java charting library in the world is JFreeChart. > > > But you cannot use it for GAE. > > > GAE architects would be overlooking one big phenomenon, if they ever > > recommend that we use client-side GWT graphics - you cannot and you > > should not if you are performing enterprise business charting. > > > When I used to code in Cobol and Fortran 20 years ago, we would > > produce a 4 foot tall 50 lb stack of report per manager. A manager > > would pull out an inch of that report - the rest is collected by the > > janitor at 6 pm. So web-based dynamism has saved a lot of trees - we > > compelled people to print their own reports. So now, should we think > > we should compel users to give up on JPG, PNG or GIF charts in favour > > of javascripted images? > > > No, javascripted images is not acceptable for charting. Javascripted > > images are good for SPC (statistical process control)/Shewhart, stock > > monitoring or various other real-time monitoring. But, when it comes > > to business reports, the user has to be able to right-click on the > > image and drag to paste on Open Office or MS Excel or Presentation. > > The user has to be able to edit the chart to place their own > > annotation in an Office graphics editor. Javascripted images is not > > usable that way. > > > I realise the problem with JFreeChart and other Java graphics library > > is their dependency on AWT - and I recall having to set up video > > display emulators on headless servers hosting Tomcat to allow charting > > servlets to run. I think someone from Google recommended that people > > try using an Apache incubator library called something-something.... > > but first, are you sure GAE allows BufferedImage - isn't that an AWT > > thing? Secondly the features of that something-something... incubator > > lib compared to JFreeChart is like comparing the size of this planet > > to the Sun. > > > So, if I need to sell my ideas to move things from local servers to > > GAE, Google needs to help me by providing means for Java graphics > > libraries to work on GAE (graphics which would either be stored on > > persistence repository or streamed directly to client). Otherwise, the > > only viable options are azure or ec2. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
