Created attachment 55093 [details] xls file demonstrating the issue The attached document render adequately in LO 3.3: LibreOffice 3.3.0 OOO330m12 (Build:1) libreoffice-build 3.2.99.2 But is wrong in libreoffice 3.4.5r2 and 3.5-beta2. look especially at 'Sheet 6' on 3.3 it contain a graph with 2 series, with red-left-facing and bleue-right-facing arrow head as series symbol. on later version that chart is no in that sheet, but shows up on a 'Sheet 7' (that did not exist in the original document. and the chart is then out-of-scale. and the series icons are now a bleu dot for one and 'nothing' for the other.... a subtitle is also missing. on Sheet5 the label indicating the equation of the linear regression now display an insane amount of digits on Sheet 3 the scale get completely off. (y is from 0-4000, when on 3.3 it was 0-250 and the linear regression equation is squashed at the bottom left on all sheet: the number of digit displayed is wrong on 3.4 and above... looks like the format is ignored or lost Ps" when I mention 'Sheet <n>' above, I am refering to the nae of the sheet not their relative position
My "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4)]" wrongly uses dots instead of commas as decimal separator for German numbers, everything else looks very similar to the view in my "LibreOffice 3.4.5 RC1 - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:501)]" I did a quick comparison with view in MS EXCEL Viewer and LibO 3.5.0Beta2 Sheet 1 -------- @Norbert Thiebaud: Please - Attach screenshots with comments if you believe that that might explain the problem better than a text comment. Best way is to insert your screenshots into a DRAW document and to add comments that explain what you want to show - Keep in mind "ony 1 issue / report). Some of your observations might already be known, ... - add information -- what EXACTLY is unexpected ("the number of digit displayed is wrong" is not very significant) -- and WHY do you believe it's unexpected (cite Help or Documentation!) -- concerning your PC (video card, ...) -- concerning your OS (Version, Distribution, Language) -- concerning your LibO version and localization (UI language, Locale setting) –- Libo settings that might be related to your problems (video hardware acceleration ...) -- how you launch LibO and how you opened the sample document –- If you can contribute an OOo Issue that might be useful -- everything else crossing your mind after you read linked texts
This is not a valid bug report! I do not believe that 3.3 is a good reference, we need facts concerning the actual settings in the sheets. My "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4)]" wrongly uses dots instead of commas as decimal separator for German numbers, everything else looks very similar to the view in my "LibreOffice 3.4.5 RC1 - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:501)]" I did a quick comparison with view in MS EXCEL Viewer, LibO 3.5.0Beta2 and Gnumeric Sheet1 ------- MSEV: Number of digits Column G 5 ... 7 (G43, G62), 2 overlapping charts LibO: Number of digits Column G 6 ... 8 (G43, G62), (I can't tell whether there should be no. of digits settings, might simply be founding differences? 2 overlapping charts Gnum: Similar results, but using English(?) date + comma separator Sheet3 ------ MSEV: Chart X-scale 5000, Y-Scale 250 LibO: Y-Scale 250 wrongly 5000, I will submit extra bug Gnum: Similar to MWEV Sheet5 ------ MSEV: Chart X-scale 15, Y-Scale 200 Legend: 4 - 2 - 4 digits LibO: Chart X-scale 15, Y-Scale 200, looks ok Legend: 10 - 10 - 10 digits might be not ok Gnum: Legend: 6 - 3 - 6 digits Sheet7 ------ MSEV: a chart Chart X-scale 40, Y-Scale 240 LibO: a chart Chart X-scale 40, Y-Scale 1100 (see sheet 3) Gnum: a chart Chart X-scale 40, Y-Scale 240
Rainer, I closed it because as it turned-out I had an ods version of a similar content with a very simlar filename laying around and I was comparing apple and oranges... (yes the scale problem is indeed there... but that is less dramatic than what I described....) for info. I was doing so manual sanity check on 3.4.5r2 for MacOSX just before uploading it to pre-release...