Issue 104397 - Problems when inserting a calc in Impress
Summary: Problems when inserting a calc in Impress
Alias: None
Product: Impress
Classification: Application
Component: formatting (show other issues)
Version: OOO310m1
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needmoreinfo
Depends on:
Reported: 2009-08-21 11:35 UTC by jorgefm
Modified: 2015-04-18 13:46 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

fire example (17.59 KB, text/plain)
2009-08-21 11:38 UTC, jorgefm
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jorgefm 2009-08-21 11:35:28 UTC
When incrusting an object ODS inside an ODP with the property Fact numeric 
zero to white in the ODP one doesn't keep in mind, however, when you enter in 
the incrusted ODS you leave correctly.
Comment 1 jorgefm 2009-08-21 11:38:23 UTC
Created attachment 64294 [details]
fire example
Comment 2 wolframgarten 2009-08-21 12:35:37 UTC
I am not sure if I understand your problem completely. Please give a detailed
step by step description and add, if useful, screenshots. Thanks.
Comment 3 fusero 2009-08-25 12:04:40 UTC
I am a partner of Jorge and would like to provide more detail on what is
happening. The key here is the property that can be found in Options Dialog: Calc -> View -> Display -> Zero Values

We uncheck this checkbox in a ods file and cell containing zeros do not show the
number and seem to be empty. This is the behaviour we want.

The problem comes when we insert this ods file into an odp one. In this case the
zeros are shown no matter what the setting was regarding zero values in the ods

Is this clear enough? I can provide two shots but i think that they are not needed.

Thanks a lot for your prompt answer.

Comment 4 wolframgarten 2009-08-26 12:05:15 UTC
Thanks for your explanation. Since the Impress is not capable of displaying this
calc feature this is an enhancement, not a defect. It needs to be implemented.
Comment 5 fusero 2009-08-31 10:47:31 UTC
so, what are the steps now? Is there any way to know if this will be implemented
or not? Do team need something from our side?
Comment 6 yohana22 2010-03-31 12:20:21 UTC
We’ve tried version 3.2 and the error is still in there.
Comment 7 Rob Weir 2013-02-02 02:57:29 UTC
This Issue requires more information ('needmoreinfo'), but has not been updated
within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. 

You can download Apache OpenOffice 3.4.1 from

Please report back the outcome of your testing, so this Issue may be closed or
progressed as necessary - otherwise the issue may be Resolved as Invalid in the
Comment 8 Andrius 2015-04-18 13:46:53 UTC
Andrius Kuznecovas (BBST Courses):

I can confirm that the issue is reproducible with the older version of OpenOffice v3.2 but it's now seems to be fixed because it's not reproducible anymore with OpenOffice v4.1.1 on OS X (10.10.3).

Initial steps to reproduce the issue is now irrelevant because latest OpenOffice introduced different workflows (you can't find some of the menus and some naming are now different as well). It's still possible to recreate the scenario with a little bit different workflow but everything is working as expected.

To reproduce the issue with version 3.2:

Create new Impress document.
Create new Calc document with various values in there (make sure you have zero values).
Insert Calc in the menu (Insert->Plugins->Calc).
Go to View -> Display -> Zero Values (in the ods file).
All the cells containing zeros do not show up (shows empty fields).
As a workaround (if someone still needs to use this old version of OpenOffice):

In the Calc before importing into Impress:
Create IF statements in fields that if they are zeros then fields should be in string/text format.
Now when you import Calc in the Impress and select (View->Display->Zero Values) they will show up as expected.
To sum-up: this bug is irrelevant (not reproducible / fixed) with the latest version of OpenOffice and should be closed.