Apache OpenOffice (AOO) Bugzilla – Issue 101508
Table in PowerPoint file shows text in wrong position
Last modified: 2009-08-05 11:40:44 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.
Created attachment 61958 [details] Contains sample file and screenshots
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)]".
Created attachment 61965 [details] Screenshots showing wrong distances from margin
Reproducible. Reassigned.
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.)
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.)
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.
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?
>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.
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?
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.
Created attachment 63030 [details] 1 cell Table example with 2*2cm textbox margin
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.
AW: Added to CWS aw073, taking a look...
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...
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.
Created attachment 63144 [details] fix as patch to evtl. be able to test/apply without CWS aw073.
AW: Checked on installed Win32 install set, works as expected.
AW->WG: Please verify, e.g. with SJs example or the original example SJ may be helpful for questions.
Verified in CWS.
Tested in m54. Closed.