Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


 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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.