Created attachment 110500 [details] Open the report - there should be charts, but only empty places were shown. Open the report of the attached database. There should be shown charts for the different categories. Works up to LO 4.1.6.2, fails since LO 4.2.0.0 beta2 (first version of LO 4.2 I could test here). LO 4.2 shows only empty places for the charts - no content, no axis ... It is a problem with this special charts. Could be it fails because there are month and year of dates used for this charts. When opening the report for editing there will be shown content in the chart. My system: openSUSE 12.3 64bit rpm Linux
Created attachment 110501 [details] Shows the report executed with LO 4.1.6.2 (and versions before)
Created attachment 110528 [details] console bt On pc Debian x86-64 with master sources updated yesterday, I had a crash. I attached bt with symbols + logs
Created attachment 110529 [details] console logs on 4.3 On pc Debian x86-64 with 4.3 sources updated about 2 weeks ago, I could reproduce the blank problem and had no crash. I attached logs.
Lionel: one for you? (perhaps I should create a new bug for the crash with master sources?)
Michael: after having looked a bit at the bt, I searched in git history of xmloff/source/style/impastpl.cxx and found this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a242b463132d67a4a2d6e69319e0da367145cc0 Thought you might be interested in this one.
About the crash, just before I've got: (gdb) p aPropertyStates $1 = std::__debug::vector of length 74, capacity 74 = {{mnIndex = 0, maValue = uno::Any 20100}, {mnIndex = 1, maValue = uno::Any -1}, etc. After, I've got: length 75, capacity 148 = {{mnIndex = 0, maValue = uno::Any 20100},... {mnIndex = 0, maValue = uno::Any "N20100"}} ! This last one comes from this block: 1221 if ( (_xParentFormattedField.is() || xFormattedField.is()) && !aPropertyStates.empty() ) 1222 { 1223 sal_Int32 nNumberFormat = 0; 1224 if ( _xParentFormattedField.is() ) 1225 nNumberFormat = _xParentFormattedField->getFormatKey(); 1226 else 1227 nNumberFormat = xFormattedField->getFormatKey(); 1228 { 1229 sal_Int32 nStyleMapIndex = m_xCellStylesExportPropertySetMapper->getPropertySetMapper()->FindEntryIndex( CTF_RPT_NUMBERFORMAT ); 1230 addDataStyle(nNumberFormat); 1231 XMLPropertyState aNumberStyleState( nStyleMapIndex, uno::makeAny( getDataStyleName(nNumberFormat) ) ); 1232 aPropertyStates.push_back( aNumberStyleState ); 1233 } 1234 } see http://opengrok.libreoffice.org/xref/core/reportdesign/source/filter/xml/xmlExport.cxx#1221 So is the index wrong? Or should the last value replace the old value? Or should we test if index 0 still there and so we don't go in this block?
this was fixed in 4.1.2 by this commit: commit 76408b0f0d7e91cddb8b056069a2ee547109b156 Author: Lionel Elie Mamane <lionel@mamane.lu> AuthorDate: Wed Apr 10 17:49:53 2013 +0200 fdo#67930 work around fdo#68024 don't emit string-value attribute but master towards 4.2 has a different commit: commit fc92c1abebcfe9b18649d35b76bf22e001e332da Author: Lionel Elie Mamane <lionel@mamane.lu> AuthorDate: Mon Aug 12 18:41:44 2013 +0200 fdo#67930 don't use variables for formattedtext in header/footer I don't know why it was going through variables. Instead, put the value where it is supposed to, like for formattedtext in detail section. Try it, and if something breaks, we can revert. This also works around fdo#67930 ... apparently that one had some unintended side effects leaving this scenario unfixed.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d6ce95ae2288859fe74d601f1bdaf616ab1ee7f0 fdo#87044: reportbuilder: Revert "fdo#67930 don't use variables ... It will be available in 4.5.0. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0efdc1504c3e8cb4644cefadd86bc131e78e4d2e&h=libreoffice-4-4 fdo#87044: reportbuilder: Revert "fdo#67930 don't use variables ... It will be available in 4.4.0.0.beta3. 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.
i have no idea what the actual problem is but reverting the one fix for bug 67930 and using the other seems to make it work; also i'm quite convinced that the use of an office:string-value attribute is wrong here anyway (see bug 68024).
On pc Debian x86-64 with master sources updated today, I confirm the bug is fixed.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=760ad24e1d44e9f86caf5e8fb9b8f69899ed0716&h=libreoffice-4-3 fdo#87044: reportbuilder: Revert "fdo#67930 don't use variables ... It will be available in 4.3.6. 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.
(In reply to Michael Stahl from comment #10) > I have no idea what the actual problem is but reverting the one > fix for bug 67930 and using the other seems to make it work; Thank you very much for looking into this and these findings. I took a look at it, to understand what went wrong and ensure the fix would be "the right one". Oh, what a mess. The basic design of reports is "formatting by tables": each section of the report is a table, and cells are sized (and merged if need be) to place everything at the position it should be. The general principle is that each control is its own table cell. Note that this has the effect of forbidding controls to overlap in any way, as table cells are not allowed to overlap. *But* charts are different. Charts are not their own table cell. Charts are always (structurally) placed in the first column first row (cell A1), *but* their position / size attributes may lead to them "overflowing" from the cell and actually being placed "over" other cells; and quite possibly, as in the example in this bug, actually not being (presentationally, in the rendered document) a single pixel in the A1 cell they are placed in. Shapes are also treated in this way. Why are charts treated differently in this way? I'm not sure. 1) This does have the side-effect of allowing them to overlap with other controls, *but* I'm not sure this is completely intentional. Indeed, the drag'n drop code refuses to have them overlap with other controls. To have them overlap, one has to edit the size/position properties numerically (that is, in the properties side-pane that F4 brings up). 2) It *also* has the side-effect that they are always placed on the page that the first row is placed in, even when the table is split over several pages, and that the "right" place for the chart would be another page. This seems to be (nearly?) exactly (for shapes) bug 52126, and looks related to bug 83354, bug 55202 and possibly also bug 73707. 3) I'm not sure that is actually valid ODF. Michael, do you have a good informed opinion on that? Is a <draw:frame> inside a <text:p> inside a <table:table-cell> allowed to "overflow" the <table:table-cell>? Actually reverting "fdo#67930 don't use variables for formattedtext in header/footer" was not necessary, cherry-picking "fdo#67930 work around fdo#68024" was enough. Since, as the comment said, the code commented out by the former leads to an overly complex and fragile document structure, I'm going to revert the revert. Michael, again many thanks for the findings in this bug!
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=08715e24c13d21767544725292d8dbf1c2381479 Revert "fdo#87044: reportbuilder: Revert "fdo#67930 don't use variables ..." It will be available in 4.5.0. 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.
(In reply to Lionel Elie Mamane from comment #13) > 3) I'm not sure that is actually valid ODF. Michael, do you have a good > informed opinion on that? Is a <draw:frame> inside a <text:p> inside a > <table:table-cell> allowed to "overflow" the <table:table-cell>? well it depends on the anchor type of the frame, if the anchor type is "as character" then it cannot overlap with anything else except another frame with a different anchor type; other anchor types put the frame "above" or "below" the text and so overlaps are possible. there are also other attributes that influence this like 20.390 style:wrap and 20.391 style:wrap-contour and 20.343 style:run-through etc., not sure how all of those work inside a table... > Actually reverting "fdo#67930 don't use variables for formattedtext in > header/footer" was not necessary, cherry-picking "fdo#67930 work around > fdo#68024" was enough. Since, as the comment said, the code commented out by > the former leads to an overly complex and fragile document structure, I'm > going to revert the revert. Michael, again many thanks for the findings in > this bug! oh, i didn't actually check that, i just assumed since there were 2 different commits it's one or the other...
(In reply to Michael Stahl from comment #15) > (In reply to Lionel Elie Mamane from comment #13) >> 3) I'm not sure that is actually valid ODF. Michael, do you have a good >> informed opinion on that? Is a <draw:frame> inside a <text:p> inside a >> <table:table-cell> allowed to "overflow" the <table:table-cell>? > well it depends on the anchor type of the frame, if the anchor type is > "as character" then it cannot overlap with anything else except > another frame with a different anchor type; other anchor types put > the frame "above" or "below" the text and so overlaps are possible. It is text:anchor-type="paragraph", so I understand at least it is valid ODF.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=118d064589fb76296a9737c8abb89b7081d61cc9&h=libreoffice-4-4 Revert "fdo#87044: reportbuilder: Revert "fdo#67930 don't use variables ..." It will be available in 4.4.0.2. 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.