Bug 87044 - REPORT-BUILDER: Charts aren't shown, leave blank place on the page
Summary: REPORT-BUILDER: Charts aren't shown, leave blank place on the page
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.beta2
Hardware: Other Linux (All)
: high major
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:4.5.0 target:4.4.0.0.beta3 ta...
Keywords: haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2014-12-06 09:06 UTC by Robert Großkopf
Modified: 2018-04-22 16:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the report - there should be charts, but only empty places were shown. (72.42 KB, application/vnd.oasis.opendocument.base)
2014-12-06 09:06 UTC, Robert Großkopf
Details
Shows the report executed with LO 4.1.6.2 (and versions before) (6.91 KB, image/png)
2014-12-06 09:07 UTC, Robert Großkopf
Details
console bt (17.87 KB, text/plain)
2014-12-07 08:51 UTC, Julien Nabet
Details
console logs on 4.3 (38.31 KB, text/plain)
2014-12-07 08:55 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2014-12-06 09:06:30 UTC
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
Comment 1 Robert Großkopf 2014-12-06 09:07:47 UTC
Created attachment 110501 [details]
Shows the report executed with LO 4.1.6.2 (and versions before)
Comment 2 Julien Nabet 2014-12-07 08:51:38 UTC
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
Comment 3 Julien Nabet 2014-12-07 08:55:48 UTC
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.
Comment 4 Julien Nabet 2014-12-07 08:57:14 UTC
Lionel: one for you? (perhaps I should create a new bug for the crash with master sources?)
Comment 5 Julien Nabet 2014-12-07 09:05:16 UTC
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.
Comment 6 Julien Nabet 2014-12-07 11:12:40 UTC
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?
Comment 7 Michael Stahl (allotropia) 2014-12-12 15:30:03 UTC
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.
Comment 8 Commit Notification 2014-12-12 17:10:53 UTC
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.
Comment 9 Commit Notification 2014-12-12 17:13:25 UTC
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.
Comment 10 Michael Stahl (allotropia) 2014-12-12 20:15:01 UTC
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).
Comment 11 Julien Nabet 2014-12-13 16:48:58 UTC
On pc Debian x86-64 with master sources updated today, I confirm the bug is fixed.
Comment 12 Commit Notification 2014-12-16 20:33:05 UTC
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.
Comment 13 Lionel Elie Mamane 2014-12-17 09:50:56 UTC
(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!
Comment 14 Commit Notification 2014-12-17 10:02:58 UTC
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.
Comment 15 Michael Stahl (allotropia) 2014-12-17 13:08:21 UTC
(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...
Comment 16 Lionel Elie Mamane 2014-12-17 13:55:05 UTC
(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.
Comment 17 Commit Notification 2014-12-18 05:48:25 UTC
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.