Home » Archived » BIRT » Graphing in BIRT
| Graphing in BIRT [message #2876] |
Thu, 13 January 2005 08:53  |
Eclipse User |
|
|
|
Hi,
I am currently investigating BIRT with a view using it to extending our
current reporting framework.
I was wondering what the format for producing graphs from report data, using
BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
multiple formats?
Regards
Nathan McKeown
|
|
|
| Re: Graphing in BIRT [message #2912 is a reply to message #2876] |
Thu, 13 January 2005 19:24  |
| Eclipse User |
|
|
|
Hi Nathan,
Internally, the charting engine writes to device independent primitives.
This means that any output format may be plugged in by writing a device
extension. A device refers to an implementation that translates rendering
primitives into a specific file format. For release 1, we will provide a
SWING device, an SWT device and an Image (PNG24, PNG8/GIF8) device.
You could easily write your own output format SVG, PDF.
E.g. for SVG, Apaches Batik provides a cost-effective mechanism for
implementing SVG output. You could use this library within a new SVG
device (by referring to our provided SWING device implementation) that
implements our primitive rendering interface.
The Chart Engine will be designed to work with the BIRT reporting
components as well as standalone. In the BIRT environment, as of release
1, charts will be embedded as a scalar bitmapped image into the various
output formats.
This will be enhanced in a subsequent release to embed vector charts (SVG,
PDF, etc) into the output report formats.
The chart plug-in components may be used independently within your
application if needed. In that context, you could choose to implement a
device renderer (primitives for a specific output format) and write to any
output format. The architecture is extensible and writing a custom device
renderer is a way by which you could write to your own output format.
Rohit Colaco
Actuate Corp
ECE Project Lead
-----
Nathan McKeown wrote:
> Hi,
> I am currently investigating BIRT with a view using it to extending our
> current reporting framework.
> I was wondering what the format for producing graphs from report data, using
> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
> multiple formats?
> Regards
> Nathan McKeown
|
|
|
| Re: Graphing in BIRT [message #2930 is a reply to message #2876] |
Fri, 14 January 2005 10:43 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
I'll echo Nathan's concerns. We found FOP to be unacceptable for
interactive document rendering for any but the smallest documents. At
the time there was discussion of a 'complete rewrite' of FOP to address
performance and scalability. I haven't followed the progress since then,
so I can't comment further. Of course RenderX, although it's performance
was better, had (at the time) fairly significant license cost
implications. Our intended strategy of leveraging FO as a convenient
intermediate form was dropped as a result.
Jim
Nathan McKeown wrote:
> Hi,
>
> I am currently investigating BIRT with a view using it to extending our
> current reporting framework.
>
> I was wondering what the format for producing graphs from report data, using
> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
> multiple formats?
>
> Regards
>
> Nathan McKeown
>
>
|
|
|
| Re: Graphing in BIRT [message #2966 is a reply to message #2930] |
Fri, 14 January 2005 13:24 |
| Eclipse User |
|
|
|
Originally posted by: jimreesman.yahoo.com
Sorry everyone. I just switched newsreader and fat-fingered both my user
information and the reply.
Jim
user@domain.invalid wrote:
> I'll echo Nathan's concerns. We found FOP to be unacceptable for
> interactive document rendering for any but the smallest documents. At
> the time there was discussion of a 'complete rewrite' of FOP to address
> performance and scalability. I haven't followed the progress since then,
> so I can't comment further. Of course RenderX, although it's performance
> was better, had (at the time) fairly significant license cost
> implications. Our intended strategy of leveraging FO as a convenient
> intermediate form was dropped as a result.
>
> Jim
>
> Nathan McKeown wrote:
>
>> Hi,
>>
>> I am currently investigating BIRT with a view using it to extending our
>> current reporting framework.
>>
>> I was wondering what the format for producing graphs from report data,
>> using
>> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
>> multiple formats?
>>
>> Regards
>>
>> Nathan McKeown
>>
>>
|
|
|
| Re: Graphing in BIRT [message #3059 is a reply to message #2966] |
Sat, 15 January 2005 02:13 |
| Eclipse User |
|
|
|
Hi Jim,
The charting engine will not use FOP for output generation.
It will have its own layer of abstraction for defining graphic primitives
rendering for which default implementations will be provided in release 1
for rendering as:
24-bit images
8-bit images
On an SWT graphics context (GC)
On a SWING graphics context (Graphics2D)
Custom extensions may be written to support additional file formats.
The device rendering framework is being tailored to suit the needs of
rendering a comprehensive set of graphics primitives, elaborate text
layout (focused on typical usage of text rendering in charts), event
handling and will be optimized for performance.
Rohit Colaco
Actuate Corp
ECE Project Lead
---
Jim wrote:
> Sorry everyone. I just switched newsreader and fat-fingered both my user
> information and the reply.
> Jim
> user@domain.invalid wrote:
>> I'll echo Nathan's concerns. We found FOP to be unacceptable for
>> interactive document rendering for any but the smallest documents. At
>> the time there was discussion of a 'complete rewrite' of FOP to address
>> performance and scalability. I haven't followed the progress since then,
>> so I can't comment further. Of course RenderX, although it's performance
>> was better, had (at the time) fairly significant license cost
>> implications. Our intended strategy of leveraging FO as a convenient
>> intermediate form was dropped as a result.
>>
>> Jim
>>
>> Nathan McKeown wrote:
>>
>>> Hi,
>>>
>>> I am currently investigating BIRT with a view using it to extending our
>>> current reporting framework.
>>>
>>> I was wondering what the format for producing graphs from report data,
>>> using
>>> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
>>> multiple formats?
>>>
>>> Regards
>>>
>>> Nathan McKeown
>>>
>>>
|
|
|
| Re: Graphing in BIRT [message #7841 is a reply to message #3059] |
Mon, 14 February 2005 17:16 |
| Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
I hate to ask, but this sounds a lot like Draw2d in the GEF toolkit. Why
isn't this used instead of making "yet another api"?
I'm getting a little worried about all the different sub-projects in Eclipse
seemingly working in silos.
Rohit Colaco wrote:
> Hi Jim,
>
> The charting engine will not use FOP for output generation.
> It will have its own layer of abstraction for defining graphic primitives
> rendering for which default implementations will be provided in release 1
> for rendering as:
>
> 24-bit images
> 8-bit images
> On an SWT graphics context (GC)
> On a SWING graphics context (Graphics2D)
>
> Custom extensions may be written to support additional file formats.
>
> The device rendering framework is being tailored to suit the needs of
> rendering a comprehensive set of graphics primitives, elaborate text
> layout (focused on typical usage of text rendering in charts), event
> handling and will be optimized for performance.
>
> Rohit Colaco
> Actuate Corp
> ECE Project Lead
>
> ---
>
> Jim wrote:
>
>> Sorry everyone. I just switched newsreader and fat-fingered both my user
>> information and the reply.
>
>> Jim
>
>> user@domain.invalid wrote:
>>> I'll echo Nathan's concerns. We found FOP to be unacceptable for
>>> interactive document rendering for any but the smallest documents. At
>>> the time there was discussion of a 'complete rewrite' of FOP to address
>>> performance and scalability. I haven't followed the progress since then,
>>> so I can't comment further. Of course RenderX, although it's performance
>>> was better, had (at the time) fairly significant license cost
>>> implications. Our intended strategy of leveraging FO as a convenient
>>> intermediate form was dropped as a result.
>>>
>>> Jim
>>>
>>> Nathan McKeown wrote:
>>>
>>>> Hi,
>>>>
>>>> I am currently investigating BIRT with a view using it to extending our
>>>> current reporting framework.
>>>>
>>>> I was wondering what the format for producing graphs from report data,
>>>> using
>>>> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
>>>> multiple formats?
>>>>
>>>> Regards
>>>>
>>>> Nathan McKeown
>>>>
>>>>
|
|
|
| Re: Graphing in BIRT [message #7862 is a reply to message #7841] |
Tue, 15 February 2005 13:26 |
| Eclipse User |
|
|
|
Hi Morten,
An important goal for the charting engine is that it needs to work in a
pure J2EE environment and that it be portable. Creating a dependency on
Draw2D would in turn create a dependency on SWT and OS dependent libraries
which doesnt work well for users who would like to deploy their reports
on an application server. In addition, Draw2D API is very restrictive in
that it uses integers in its co-ordinate system which causes rounding
off errors and erroneous output. The chart primitive rendering layer of
abstraction provides a device-independent floating point co-ordinate
system for which primitive instructions are written to individual devices
(of which, SWT is one). Since SWT (and draw2D) does not support floating
point math in rendering arguments, approximations would have to be
performed at several stages in chart generation and rendering resulting in
inaccurate output.
For your reference, here's how the 'drawLine' API has been implemented
using Draw2D's org.eclipse.draw2d.ScaledGraphics' implementation:
public void drawLine(int x1, int y1, int x2, int y2)
{
graphics.drawLine((int)Math.floor((double)x1 * zoom +
fractionalX), (int)Math.floor((double)y1 * zoom + fractionalY),
(int)Math.floor((double)x2 * zoom + fractionalX),
(int)Math.floor((double)y2 * zoom + fractionalY));
}
... where 'fractionalX, fractionalY' defines linear translation and 'zoom'
defines a scaling factor but as you can see, resulting co-ordinates are
truncated before they are plotted.
Another drawback with using pure Draw2D/SWT API is that it is limited in
its featureset and doesn't generically support certain advanced features
such as:
Text anti-aliasing
Fractional font-metrics
Primitive support for text rotation
Defining custom shapes using a combination of polygons and curves
So, to summarize, the design objectives for the rendering API are twofold:
a. Create a clear abstraction layer between the core charting engine and
the rendering API such that charts may be generated offscreen using high
precision metrics and transformations and the device extensions (for
specific output types) could translate the primitive instructions as
appropriate.
b. Implement device/OS specific rendering toolkits as pluggable/removable
extensions that implement our extension points allowing a great deal of
flexibility in deployment configurations.
This allows the charting engine to write out SWT charts within the eclipse
environment and non-SWT charts (possibly SWING or completely bypassing a
graphics toolkit and writing to a vector based file format e.g. SVG)
outside of the eclipse environment.
Hope that addresses your concern.
Rohit Colaco
ECE Project Lead
-----
Morten Moeller wrote:
> I hate to ask, but this sounds a lot like Draw2d in the GEF toolkit. Why
> isn't this used instead of making "yet another api"?
> I'm getting a little worried about all the different sub-projects in Eclipse
> seemingly working in silos.
-----
> Rohit Colaco wrote:
>> Hi Jim,
>>
>> The charting engine will not use FOP for output generation.
>> It will have its own layer of abstraction for defining graphic primitives
>> rendering for which default implementations will be provided in release 1
>> for rendering as:
>>
>> 24-bit images
>> 8-bit images
>> On an SWT graphics context (GC)
>> On a SWING graphics context (Graphics2D)
>>
>> Custom extensions may be written to support additional file formats.
>>
>> The device rendering framework is being tailored to suit the needs of
>> rendering a comprehensive set of graphics primitives, elaborate text
>> layout (focused on typical usage of text rendering in charts), event
>> handling and will be optimized for performance.
>>
>> Rohit Colaco
>> Actuate Corp
>> ECE Project Lead
>>
-----
>>
>> Jim wrote:
>>
>>> Sorry everyone. I just switched newsreader and fat-fingered both my user
>>> information and the reply.
>>
>>> Jim
>>
>>> user@domain.invalid wrote:
>>>> I'll echo Nathan's concerns. We found FOP to be unacceptable for
>>>> interactive document rendering for any but the smallest documents. At
>>>> the time there was discussion of a 'complete rewrite' of FOP to address
>>>> performance and scalability. I haven't followed the progress since then,
>>>> so I can't comment further. Of course RenderX, although it's performance
>>>> was better, had (at the time) fairly significant license cost
>>>> implications. Our intended strategy of leveraging FO as a convenient
>>>> intermediate form was dropped as a result.
>>>>
>>>> Jim
>>>>
>>>> Nathan McKeown wrote:
>>>>
-----
>>>>> Hi,
>>>>>
>>>>> I am currently investigating BIRT with a view using it to extending our
>>>>> current reporting framework.
>>>>>
>>>>> I was wondering what the format for producing graphs from report data,
>>>>> using
>>>>> BIRT, is likely to be (e.g. HTML,SVG, PDF, etc...) or will it support
>>>>> multiple formats?
>>>>>
>>>>> Regards
>>>>>
>>>>> Nathan McKeown
>>>>>
>>>>>
|
|
|
Goto Forum:
Current Time: Sun May 11 08:52:50 EDT 2025
Powered by FUDForum. Page generated in 0.02785 seconds |
Home