Created attachment 59233 [details] Try opening the report in 3.3.4 and then in 3.5.2 RC1. In 3.3.4 it is opening with two charts. A report, designed in LO 3.3.4, with a chart could not be opened in LO 3.5.2 RC1. It fails with "Failed to parse the report".
Created attachment 59254 [details] Shows report in LO334 with charts and in LO352 (failed in GUI and while editing) Could be, that you cannot see any charts in LO 3.4.* too. So I made a screenshot. OOo 3.3 starts the report, but dont show charts - earlier versions of OOo show the charts and LO 3.3.4 shows them too.
Hi Robert, Will try this out to see if I can confirm, but I wouldn't be surprised if Kohei's work on Calc Charts during 3.4 development has caused this. I know that he touched on the problem there and the distinction between Calc chart instantiation and Base chart instantiation. There should be something on this in the developers mailing list archive. I will have a look. Alex
Tested on Ubuntu Oneiric LO 3.4.5 : I can see the graphs in the report, so the problem must have come later, during 3.5 development. Will test with a 3.5 version later. Alex
Just tried to edit the Report in 3.4.5 - I shifted the graph with the mouse, which lead to an instant crash of the whole application :-/ Alex
Hello Robert, Alex, I have tested in with <quote> LibreOffice 3.4.6 OOO340m1 (Build:602) </quote> under Debian Testing AMD64, where I could open the report, but did not see the graphs ... :( I have tested it with 3.5.2RC1 as well as with 3.5.2RC2, where I got the same error message as Robert ... :( I will change the status to "new", so the developers will have a look at it ... ;) Have a nice day and HTH Thomas.
[Reproducible] with "LibreOffice 3.5.2.2 English UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit) Works fine with 3.4.5, so REGRESSION "LOdev 3.6.0alpha0+ English UI/Locale [Build ID: 9518535-d09cf17-8a74106-c695ecd-16afab (libreoffice-3-5-branch-point)]" {Win-x86@9-Voreppe Win32 pull time 2012-02-29 04:21:51}. OS: German WIN7 Home Premium (64bit) did not find any Java, so I was not able to test. [Reproducible] with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 485138f-e92bf75-4c1bcb5]" Win-x86@6 – 2011-12-06_21:37:02) Still worked fine with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [(Build ID: 4f11d0a-adcf6d5-c4bb9bd)]" Windows_2008R8 - 2011-11-18) Master from September 2011 will not open report, Message: "Oracle Report Builder required". @Lionel: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug. Please mention Comment 2!
Modify Version due to comment 6
Created attachment 59400 [details] logs in console The attached file shows errors and warnings
(In reply to comment #2) > I wouldn't be surprised if > Kohei's work on Calc Charts during 3.4 development has caused this. I know that > he touched on the problem there and the distinction between Calc chart > instantiation and Base chart instantiation. There should be something on this > in the developers mailing list archive. I will have a look. Kohei? Does this ring a bell? If this is true, you'll most probably be much faster than me in tracking this down. Don't hesitate to ask me if you need collaboration on this.
(In reply to comment #9) > (In reply to comment #2) > > > I wouldn't be surprised if > > Kohei's work on Calc Charts during 3.4 development has caused this. I know that > > he touched on the problem there and the distinction between Calc chart > > instantiation and Base chart instantiation. There should be something on this > > in the developers mailing list archive. I will have a look. > > Kohei? Does this ring a bell? If this is true, you'll most probably be much > faster than me in tracking this down. Don't hesitate to ask me if you need > collaboration on this. That report builder is riddled with problems. There was a problem getting the right filter picked because the report builder pretends to have a valid import filter when in fact it's not. All I did was to make the core chart import filter the "preferred" filter in order to get that picked. Other than that I have no idea. I'll be away for 3 weeks, so I won't be able to look into this.
BTW it's not so much the calc chart vs base chart. It's the internal chart vs report builder chart.
Kohei's commit e358b60b11879399a0ffdad59216e837f01d08f9 Plan: revert it and see if it "fixes" this problem. If it does, the problem is probably that now Report Builder does not find its own filter. Make sure in some other way that Report Builder finds its own filter.
Just as a hint. If you know the exact filter name to use, you can put that into the media descriptor via "FilterName" property, and the type detection will use it unconditionally. This is something new I've worked on for 3.6. That will bypass the problematic type detection process in case you already know which filter to use beforehand.
Or if you can wait until I get back, I'll be able to look into it. If it's indeed a type detection problem, it's my area.
*** Bug 48315 has been marked as a duplicate of this bug. ***
It seems reverting Kohei's commit does not solve this. Hmm... It could be we just moved to a stricter parser or call the parser differently so that errors lead to an abort rather than ignore the XML node with error. When opening with LibreOffice 3.3.3 OOO330m19 (Build:301) tag libreoffice-3.3.3.1, Debian package 1:3.3.3-4+b1 I get these warnings&errors on stderr/stdout: Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:table:1.0:calculation-settings>: Start to ignore this element and all of its childs. [Location: Line=2 Column=4637] Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:drawing:1.0:g>: Start to ignore this element and all of its childs. [Location: Line=2 Column=6778] Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:drawing:1.0:g>: Start to ignore this element and all of its childs. [Location: Line=2 Column=6806] Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:table:1.0:calculation-settings>: Start to ignore this element and all of its childs. [Location: Line=2 Column=4637] Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:drawing:1.0:g>: Start to ignore this element and all of its childs. [Location: Line=2 Column=6778] Jul 9, 2012 6:41:06 PM org.pentaho.reporting.libraries.xmlns.parser.AbstractXmlReadHandler startElement WARNING: Unknown tag <urn:oasis:names:tc:opendocument:xmlns:drawing:1.0:g>: Start to ignore this element and all of its childs. [Location: Line=2 Column=6806]
Hmm... Manually removing these tags from within the odb does not fix the warnings in 3.3.3. So it seems they are in some dynamically generated XML. The table:calculation-settings comes from reportbuilder/java/com/sun/star/report/pentaho/output/OfficeDocumentReportTarget.java:writeNullDate() but the drawing:1.0:g stuff, I haven't found anything. Do these tags ring a bell for anyone?
*** Bug 53176 has been marked as a duplicate of this bug. ***
I have just tested the opening of the report with charts under different LO-Versions. The bug doesn't appear in any 3.3.* and 3.4.*-version. The first version I have installed with "failed to parse the report" is LO 3.5.0.1.
*** Bug 48251 has been marked as a duplicate of this bug. ***
*** Bug 55895 has been marked as a duplicate of this bug. ***
I'm going to raise this issue with our next conference call. We'll try to move it forward
Robert: I tried to reproduced the problem described here and succeeded with 3.5.4.2 I tried too with 3.6 sources and master sources (future 4.1), I had a crash. Could you give a try with these one or both of these versions to confirm this?
(In reply to comment #23) > Robert: I tried to reproduced the problem described here and succeeded with > 3.5.4.2 > I tried too with 3.6 sources and master sources (future 4.1), I had a crash. > Could you give a try with these one or both of these versions to confirm > this? I haven't installed any LO by sources. But I tested this behavior with LO 3.6.4.3 and LODev 4.0.0.0 beta1. No difference in the behavior since LO 3.5.0 RC1. Don't know, who had set the version to 3.6. I have corrected this to the version, where it appears first.
(In reply to comment #23) Hi Robert, you can find out such changes clicking the 'History' link at the top. The the name of the "Master" Version has been modified several times, so that now the 3.6 indeed seems a little misleading (it also includes 3.5 Master Versions), but in these versions you always have to check the Comment where the Master version has been selected. As you can see in Comment 6 I reproduced the problem with "MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 485138f-e92bf75-4c1bcb5]" Win-x86@6 – 2011-12-06_21:37:02)", what is far before the Version 3.5.0 RC1 (2012-01-22) Because this "3.6 Master old" might be misleading, I changed Version to 3.5.0 Beta1, what is quite close to the Version where I observed that first time.
On Version 4.1.0.0.alpha0+ (Build ID: 6880e2d31a38d5f4b44ba4f5b4a2b3e361a6631) this gives the following error message both on screen (in a message box) and the console : Jan 10, 2013 9:04:41 AM com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory execute SEVERE: Detected an IncompatibleClassChangeError Alex
*** Bug 60153 has been marked as a duplicate of this bug. ***
Unfortunately this one is impossible to bibisect because there are different problems for every step so you end up using git bisect skip quite often, then you hit the actual bug once, and after that it errors out because of how may skips you are forced to do. There is no step that actually just works. Removing bibisectrequest :0
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed4c0da91205e95cc9c907add0f62d7cdce807d4 fdo#48056 revert part of return "correct name for shapetype" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2493acd50c9c2e1922381e09ea33860894e320b2 fdo#48056 treat report chart as draw chart The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f7eb34071af02e9cfe79f926a69e66992f1c6b20&h=libreoffice-4-0 fdo#48056 revert part of return "correct name for shapetype" It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d69a05d97c8a686ff24bd6d89905dfd3aee6a1cb&h=libreoffice-4-0 fdo#48056 treat report chart as draw chart It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=777661cedbccf69876794eb7152367401d25d4ed&h=libreoffice-3-6 fdo#48056 revert part of return "correct name for shapetype" It will be available in LibreOffice 3.6.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e868f818c9863461cdf388e3d9fddaffb70d9ca&h=libreoffice-3-6 fdo#48056 treat report chart as draw chart It will be available in LibreOffice 3.6.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Can confirm, that it works with LO 4.1.0.3. So I set the status to "Verified"