Re: [Libreoffice] Oracle Report Builder corrupting chart objects

 Kohei,

Please, not option 3, ORB is the only descent way to have some  reports 
out of the Base app.

Greetz

Fernand
> Hi there,
>
> This is concerning the following bug report:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=36339
>
> where chart objects get corrupted pretty much 100% of the time for the
> reporters and several others but was not initially reproducible on my
> side.  It turned out that it was because my development build didn't
> have Oracle Report Builder (ORB) installed, and installing this
> extension made this bug 100% reproducible.  Chart objects get destroyed
> on double-check after load, 100% of the time.  This is very very bad.
> Since our release ships with Oracle Report Builder, this makes chart
> editing totally unusable with the release version of LibreOffice.
>
> The reason that chart objects get corrupted is simple.  When the chart2
> code queries for the service name of UNO object that can save the data
> from document of type com.sun.star.chart2.ChartDocument into XML, both
> the default chart filter 'chart8' and the 'StarOffice XML (Base) Report
> Chart' filter (the one from ORB) claim to handle it.  And because the
> report chart filter comes first during the loop to look for a handler
> ser, it gets picked.
>
> During the export, this doesn't really cause a problem since the chart2
> code appears to expect this and provides necessary functionality for the
> ORB extension even through ORB itself doesn't have any code for this.
> The only difference is that the chart content stream is now associated
> with the "application/vnd.sun.xml.report.chart" mime type, instead of
> the default "application/vnd.oasis.opendocument.chart" type.
>
> This mime type difference, however, causes load failure during import,
> and because the chart content stream is read *when* you double-click on
> the chart object, *not* when the file is loaded, it blanks the chart
> object when double-clicked for the first time, as described in the bug
> report.
>
> Now, 3.3 also had ORB installed by default, and it didn't cause this
> problem.  When it saves a document with chart, it saves the chart object
> using the opendocument.chart mime type, not the report.chart mime type.
> So I assume that's the correct behavior.
>
> Ok. So far I've described why the bug happens. Now the question is how
> do we fix it?  There are several ways to fix this.
>
> 1. Promote the chart8 filter as the preferred filter for the
> chart2.Document type.  This can be done by the attached
> chart8-is-preferred-for-chart-document.diff patch.  This will ensure
> that during the query for the right filter service type, the chart8
> filter gets picked over the one from ORB.
>
> 2. Remove the type detection definition for the chart2.Document type
> from the report builder itself.  This can be done by the
> report-builder-dont-act-like-chart-handler.diff patch.  This will
> prevent ORB from advertising itself as the chart filter provider.
>
> 3. Don't ship with Oracle Report Builder.  I hope I don't need an
> explanation for this.
>
> I think option 1 is pretty safe, but I don't really know if this would
> cause any side effect in other, unexpected places.  For instance, the
> latest ORB seems to claim some limited charting functionality, and this
> may mess that up, or perhaps it may not.
>
> I'm not sure how safe option 2 is, since I'm not too familiar with the
> ORB code (all written in Java I might add...).  There may be some code
> that relies on the chart filter provider inside ORB, but then there may
> not.  I don't really know.
>
> My preferred option is option 3.  Because, while I was test-driving ORB,
> it crashed several times due to null pointer exception from the Java
> code.  And when it does that, it takes the whole soffice process down
> with it.  It doesn't appear to be very stable.  But then, maybe there
> are users out there who appreciates this extension.  I don't really
> know.  It would be nice to know the original motivation behind including
> this extension.  Was there a high demand for this functionality?
>
> Anyway, we need to decide on one of these options.  Feedback is
> appreciated.
>
> Kohei
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice