Issue 101508 - Table in PowerPoint file shows text in wrong position
Summary: Table in PowerPoint file shows text in wrong position
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: OOO310m9
Hardware: Unknown Windows XP
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: oooqa, regression
Depends on:
Blocks:
 
Reported: 2009-05-03 16:26 UTC by raindrops
Modified: 2009-08-05 11:40 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Contains sample file and screenshots (181.46 KB, application/x-compressed)
2009-05-03 16:29 UTC, raindrops
no flags Details
Screenshots showing wrong distances from margin (55.70 KB, application/pdf)
2009-05-04 06:57 UTC, Rainer Bielefeld
no flags Details
1 cell Table example with 2*2cm textbox margin (104.00 KB, application/vnd.ms-powerpoint)
2009-06-16 17:21 UTC, sven.jacobi
no flags Details
fix as patch to evtl. be able to test/apply without CWS aw073. (6.14 KB, text/plain)
2009-06-22 16:33 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description raindrops 2009-05-03 16:26:27 UTC
I am reporting for 310m11 (build 9399), which is not listed in this bugzilla.

Problem statement:
If a PowerPoint file that contains a table is opened in Impress, it shows the
text in wrong position. This is seen in two different ways:

1. The left margin and top margin are reduced to ZERO.
2. When we click inside a cell to edit the text, the text jumps to a new location.

As a result, any powerpoint file becomes practically useless in Impress!

I am attaching a zip that contains-
1. The sample ppt file
2. Screenshots to illustrate the two problems described above.
Comment 1 raindrops 2009-05-03 16:29:27 UTC
Created attachment 61958 [details]
Contains sample file and screenshots
Comment 2 Rainer Bielefeld 2009-05-04 06:55:04 UTC
I checked with "Ooo 3.1.0 RC2 multilingual version German UI WIN XP: [OOO310m11
(Build 9399)]" and can confirm the reported effect. Same with "Ooo Dev 3.2.0
multilingual version English UI WIN XP: [DEV300m44 (Build 9395)]".

Looks fine with "2.0.2  German version WIN XP: [680m5(Build9011)]".
Comment 3 Rainer Bielefeld 2009-05-04 06:57:31 UTC
Created attachment 61965 [details]
Screenshots showing wrong distances from margin
Comment 4 wolframgarten 2009-05-04 08:17:20 UTC
Reproducible. Reassigned. 
Comment 5 raindrops 2009-05-04 08:33:10 UTC
The pdf file attached by rainerbielefeld does not show problem # 2 (text shifts
away when you try to edit it, by clicking in a cell of a table). However, I have
attached two screenshots, where I had clicked in a cell to edit it. You can
compare these screenshots to see that the text jumps away from its position.
When you exit the edit mode, the text again jumps back to its original position.
Thus the entire purpose of editing is lost, because you cannot set the left/top
margins!

I can attach a screencast (flash file) if this second problem is not clear.

Also, note that the figures in Column-1 to Column-3 are CENTER-aligned. That is
why the problem with their left margin is not so apparent. However, the text in
the first (untitled) column is LEFT-aligned. You can clearly see that in OOo,
this text touches the left edge of the table (i.e., its left margin is reduced
to zero.)
Comment 6 raindrops 2009-05-04 08:40:30 UTC
The target is changed to 3.2, which may take a few months to appear (provided
that the target is not pushed even further,as has happened to many of the bugs I
raised). 

The moot point is, do we have something actually usable for the time being??

When the OOo team decides to live with such basic issues, the OOo becomes a lab
model (a toy that is good to look at, but CANNOT be used in serious use.)
Comment 7 deye 2009-05-04 16:23:33 UTC
Now people with PowerPoint installed can save ppt files as odp in PowerPoint and
you can open them in OpenOffice. This would solve any compatibility issues,
because ODP is an open format and PPT is proprietary. Who would better know
their proprietary format than authors of PowerPoint? AFAIK, tables are new to
OO.o Draw and Impress, so they may be imperfect sometimes, especially when you
go beyond OpenOffice (importing, exporting to msoffice etc). But if don't go
beyond, OO.o is very usable.
Comment 8 raindrops 2009-05-04 17:49:37 UTC
I have had major problems when I convert documents (especially, odt->doc).
Besides, because 80% of market share is with Microsoft, a lot of MSO format
files are in circulation, which must remain in their native format if the edited
files are to be shared with the other users again. 

So conversion of files is usually not an option.

If a software cuts you off from 80% of the total users, is it logically designed?
Comment 9 deye 2009-05-05 06:05:53 UTC
>must remain in their native format if the edited files are to be shared with
the other users again
If you want 100% compatibility, to share files with 100% of users, you should
use ODP format (not exporting anything to not native formats), because anyone
can install openoffice on their computer without any problems. But exporting to
PPT, you advertise an old and proprietary format and loose some formatting.
After all, even you are not sure, that it is completely compatible with
msoffice. This way you just advertise a proprietary presentations format that
even has no native tools on many platforms. Better use ODP format. They are
adult people and can easily find what program can open it.
Comment 10 raindrops 2009-05-05 09:16:11 UTC
I tried OxygenOffice 3.0.1 (because it says on the tin that it applies many
patches that Sun has avoided because of politics.)

OxygenOffice does not have problem-1, and it has problem-2 but to much lesser
extent (when you click inside a cell to edit a line, it moves only a little
downwards. In comparison, the line moves by a much larger amount in OOo 3.1 RC2.)

I have not tried OOo 2.2; but different versions of OOo seem to have different
amount of movement when in edit mode. This can be investigated further.

*******
It is not the question of advertising- With a 80% share, MSO does not need any
advertising. OOo does. Through word of mouth of users. BUT when there is no
compatibility with MSO, and certain large-scale loss of formatting, no one would
even try out OOo.

Most people do not use OOo (or any other freeware) out of a sense of duty or
social responsibility. They do it to save money. Purely selfish reason. But if
they hear that OOo is too painful, they will not abandon MSO. Many have already
paid for MSO, so they may as well continue using it. Others are using a pirated
copy of MSO, so the fact that OOo comes free does not impress them.

The only way to make them switch to OOo is to offer them more features with
guaranteed painless migration. And THAT factor is missing.

BTW the SP3 of MSO has now taken away the USP of OOo: pdf conversion. It also
can handle the ODF docs. They have done it despite being market leaders. What is
the OOo counterstrategy?
Comment 11 deye 2009-05-05 16:21:02 UTC
There were no tables in OO.o 2.2 for Draw and Impress, they were converted to
lines and text.

>It is not the question of advertising- With a 80% share, MSO does not need any
advertising. OOo does.
What is the interest for OO.o to be advertised? It is the interest not for OO.o,
but for users. Another case with MSO. Maybe, indeed, MSO does not need
advertising, but you advertise MSO by using their format anyway. As you heard,
now it is possible to use ODF directly in MSO. Problems resolved. Old MSO
formats will die soon, but you can convert them to ODF or OXML. If we should
talk, we should talk about OXML. Why to waste time on old and alien formats?
Yes, this bug can show something wrong in Draw and Impress tables, but PPT is
not the goal.
Comment 12 sven.jacobi 2009-06-16 17:21:45 UTC
Created attachment 63030 [details]
1 cell Table example with 2*2cm textbox margin
Comment 13 sven.jacobi 2009-06-16 17:31:04 UTC
sj->aw: The text box margin is ignored when displaying the table, if a cell is
in edit mode the cell is displayed correctly. The problem first appears in OOo 3.1.
I made another example that is illustrating the text box margin problem even
better, in this example there should be a text box distance of 2cm to each side.
Comment 14 Armin Le Grand 2009-06-22 15:18:32 UTC
AW: Added to CWS aw073, taking a look...
Comment 15 Armin Le Grand 2009-06-22 16:23:32 UTC
AW: Indeed, the text distances for table are at each cell. I will need to adapt
ViewContactOfTableObj::createViewIndependentPrimitive2DSequence to take this
into account (with primitives, this is the ONLY place i need to change :-)). To
do so, i add default parameters to the helpers createNewSdrTextAttribute and
createNewSdrFillTextAttribute to provide pointers to integer values for
attruibute creation, used only from
ViewContactOfTableObj::createViewIndependentPrimitive2DSequence. Testing...
Comment 16 Armin Le Grand 2009-06-22 16:32:44 UTC
AW: Works as expected. Thanks to primitives, this can be easily, centrally and
safely be fixed in a single place :-)
Commenting a little bit more, checking in, done.
Comment 17 Armin Le Grand 2009-06-22 16:33:56 UTC
Created attachment 63144 [details]
fix as patch to evtl. be able to test/apply without CWS aw073.
Comment 18 Armin Le Grand 2009-06-24 11:55:53 UTC
AW: Checked on installed Win32 install set, works as expected.
Comment 19 Armin Le Grand 2009-07-01 11:26:51 UTC
AW->WG: Please verify, e.g. with SJs example or the original example SJ may be
helpful for questions.
Comment 20 wolframgarten 2009-07-17 11:54:07 UTC
Verified in CWS.
Comment 21 wolframgarten 2009-08-05 11:40:43 UTC
Tested in m54. Closed.