| Re: [birt-dev] better graphics |
Again, for client side we used Highcharts. We later added a "3rd Party" palette item for D3, Protovis, and a few other client side libraries. For server side, we used PhantomJS and I believe later switched to headless Chrome when PhantomJS was deprecated. Sorry I didn't post it earlier, I couldn't remember the name of PhantomJS. Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: Yair Lenga <yair.lenga@xxxxxxxxx> Date: 3/1/23 5:57 PM (GMT-06:00) To: birt-dev@xxxxxxxxxxx Subject: Re: [birt-dev] better graphics 1. The SVG option, when available, addresses the “resolution” problem. It create pdf (and may be HTML, did not try) that looks great at any resolution, including zoom. 2. Problem with both svg and png is that they are created for fixed aspect ratio. Works ok if the output is pdf or page like. Does not work well to when using mobile devices, or resized windows - the XY ratio is fixed at generation time. Also, svg does not address well the need to keep fonts at readable size (e.g. 8-10 points) to attach labels to chart elements at fixed font size. 3. Major issue with almost all server side libraries is that they have fallen behind Client side libraries. State of the art, best looking libraries nowadays are generating svg graphics with typescript/_javascript_. The charts generated by Birt charting (and most open source server side) looks outdated, I would even say “boring”. 4. Users expect charts to be responsive, react to mouse overs, provide some animation, etc, server side charting usually not able to provide those. Bottom line : built in charting is good for “static” reports - there are many good use cases for that, but they are many other use cases, especially for HTML reports/dashboard where “flashy” charts are expected. Yair Sent from my iPad _______________________________________________ birt-dev mailing list birt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev |