Issue 31097

set Keyword

accepted

according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690
this issue will be set to OOoLater

set target for new chart issues

changed summary to indicate a 'new chart' issue

changed issue type from defect to task to better reflect that this issue is only
a working issue for the chart reimplementation

Changed target to 2.x

Taking over for milestone 8

->kla: Either this issue is fixed, or I don't understand it. Please provide some
more comments, attach some screen shots or a bug-document. Thanks.

What changes of datapoints lead to incorrect size changes of data points? And
how are those changes visible (larger, smaller?)

Ok, found out what the problem is: If you select a different symbol for the data
point, the size is overwritten by a default size (probably always 1,03cm).

chaged subject.

This is no regression over the old chart. The behaviour is the same in the old
implementation. Only the default size for changed symbols (not bitmaps) is
"0,21cm" in the old chart and "1,03cm" in the new chart. That's the only difference.

changed prio

changed target

changed type to defect and made summary more clear

How to reproduce:
1. Create a line chart with symbols
2. Change the symbol size of a series (e.g. make it 1cm large)
3. Select a different symbol from the "Symbols" menu (last entry in the drop-down)
=> The size is reset to 0,25cm.
Also, when you select "Automatic", you get a different size, this should also
not happen.

Note, when choosing a bitmap (Galery or From File), it is correct that the size
changes, as the bitmaps have different sizes and should not be scaled
unnecessarily per default.

Technical Note: I think the problem might be the brush-item that contains a size
together with the symbol. The dialog that handles symbols is in svx. It is used
by chart and for bullets in writer. Some code is only for chart, there should be
comments about that.

Created attachment 48599 [details]
The patch file of about issue31097#-v1

Hello Bjoern,
The patch file only fix the "symbols" menu, however the "automatic" menu have 
not got to fix, please review it, if it has any problem,please tell me.thanks!

Hello bm,
Please review the patch,thanks!

->iha: Would you be so kind as to have a look at the patch, as I am on vacation
the next week. Thanks

I've tested the patch and there are still problems.
If you switch to 'No Symbol' and then back to one of the standard symbols the
size is still zero. Furthermore I think switching to 'Automatic' should not
change the size also.
maoyg, please consider the following:
The boolean bDontSetSize indicates when the size will be modified while changing
the symbol type.
The value of this boolean is wrong in some cases.
The size should only be changed when a symbol from file or from the gallery is
selected. Because these symbols have a size by themselves and should get their
original size on selection. In all other cases the size should not be changed -
even not when 'No Symbol' is selected.
As the naming is very confusing I suggest to replace the variable bDontSetSize
with a variable bResetSize, which has opposite meaning then. The default of the
new variable should be bResetSize=FALSE. And only for the above mentioned cases
it should be set to true.

Created attachment 48951 [details]
The patch file of about i31097#-v2

Hello iha,
Please review the patch,thanks.
If there are any problems about it,please tell me,asap! :)

Hi maoyg,
That looks better. But there are still scenarios which are problematic with the
new behavior:
1) When a user starts to choose a symbol from file and aborts the dialog with
cancel then the size is set to zero (this should be avoided). It is wrong to
change anything in that case I think. So return from the method when you get no
graphic there.
2) If an image from gallery or file was set before with a size with an aspect
ratio different from 1:1 and the user now switches to standard symbol, the
standard symbol looks broken as the aspect ratio does not fit. I think we need
this additional logic: If the user switches from gallery or image to standard
symbol and the aspect ratio is different from 1:1 then the size must be adapted
still. Please reset the size in those cases to a mean value of width and heigh.
2b) If we need this complex logic for the standard symbols anyhow, I think we
should use it for the automatic symbol also. The old code line 
"aSymbolSize=aAutoSymbolGraphic.GetPrefSize();" ignores the variable bResetSize
badly anyhow. So I would suggest to remove it. Please have an eye on the
variable 'bNewSize' here also. For me it looks wrong that it is set to false.

Created attachment 49065 [details]
The patch file of about i31097#-v3

Hello iha,
I think the variable 'bNewSize' in case MN_SYMBOLS_AUTO is useless,please 
review the patch,thanks! 

Hi Mao, the second problem is not solved.

Created attachment 49110 [details]
The patch file of about i31097#-v4

Hello iha and bm,
I have finished the patch,the second problem have been solved.
Please review the patch,thanks!

Created attachment 49273 [details]
The patch of about i31097#

Hello iha,
I have removed the variable "bFirstSize".Please review the patch,thanks.

The last patch does not compile on recent master version (e.g. SRC680m235) as
the patch contains compiler warnings which are treated as errors.
Furthermore I think the new use of the variable bNewSize is bad design. We have
the variable bResetSize to manage resizing already. The parallel use of a very
similar mechanism only introduces complete confusion.
Testing the behavior of the new patch we now have the problem, that the size is
again changed when switching from standard to standard symbol in case the symbol
has had a different aspect ration than 1:1.
Please try again, without using the variable bNewSize.
Instead remember the old symboltype at the beginning:
long nPreviousSymbolType=nSymbolType;
Then reset the size dependent on from which old to which new symbol type the
user switches.

Created attachment 49443 [details]
The patch file of about i31097#-v6

Created attachment 49543 [details]
The patch file of about i31097#-v7

Hello iha,
This problem has been solved on the patch i31097#-v7.Please review it,thanks!

Hi maoyg, thanks for the patch!
It is committed to CWS chart15.

Fixed in CWS chart15.

->Thomas, please verify in CWS chart15.

Works fine for all Datapoints -> verified

seen ok in current master -> closed