Apache OpenOffice (AOO) Bugzilla – Issue 8855
Cells in table does no "remember" their vertical alligment
Last modified: 2013-08-07 14:43:03 UTC
1. Open the attached file. 2. At first the document opens at the end of it (but that's another bug) 3. Uf you do not click on the doc all is fine. 4. Clink in the main table with prices. 5. The digits in some cell will allign at bottom now. 6. Change it so it's alligned to the top. 7. Save the document and reopen it. 8. Same thing happengs. OOo 1.0.1, also 643 is affected. Tested on Win 95, win 2000 and win XP.
Eugene, thank you for using and supporting OOo. Please attach the file which reproduces this problem via the "Create a new attachment" link.
Created attachment 3439 [details] The file (I have many of them)
Attached as text file.
Eugene, you need to use the "Binary file (application/octet-stream)" option as the file type for OOo files. Could you please reattach the file at your convenience?
Created attachment 4858 [details] the file, sorry, I just now saw the request...
I'd very apriciate if this is fixed untill 1.1 (SO6.1) final. Tnx.
Same bug in 644m7 and SO6.1 beta. Is someone actually knows about this bug?
It only seems to occur in cells that display a result from a formula, so it must be linked to the default style for formula results. There's a workaround for your problem : if you type in a soft line break at the end of your figure, using the the Shift-Enter key combination, you will get the result you want and it will stick when you save. Alex.
I tryed this workaround, but it is not a 100% workaround, since the second row may be a one liner, then I need to delete the added brakes.
I opened the document in OOo1.1rc3 and all looked fine ... Then I clicked "Print File Directly" and some cells realligned to bottom... I set the whole table to "top alligned" and saved the file... I reopened the file and clicked anywhere in the table and the realligning began again... reassigned to fme@openoffice.org
FME->DVO: Is the cell alignment attribute saved properly?
dvo: The current behaviour is, admittedly, rather silly. There appear to be at least two things going wrong. One was previously reported in the internal bug #107116#, and an additional aspect was reported here. I'll mark the internal issue as duplicate to this one, so all information is kept in a single, public location. Bug description from #107116#: --------- #107116# ---------------------------------------- In table cells, the default vertical alignment is 'top' for text, and 'bottom' for numbers. This is implemented as follows: There are four internal alignent values (none, top, center, bottom), where 'top' is the default. In the context menu, you can select three values, top, center, bottom , which set 'none', 'center' and 'bottom', respectively. If a cell value is cahnged from text to number or from number to text, the vertical alignment is changed from top to bottom, and from bottom to top. (The implementation of this is at the bottom of ChgTextToNum and ChgNumToText in swtable.cxx.) Result: 1) If you enter text/numbers and change between those at will, text will be at the top, and numbers wil be at the bottom. (Reason: The top/bottom fiddling mentioned above.) 2) If you select vertical alignment center or top in the menu, the content will always remain in the center and top. (Reason: 'center' and 'none' are never changed, and top in the menu sets the value 'none'.) 3) If you select 'bottom', the value will be bottom aligned. But if you change it from number to text, it will jump to the top. (Reason: The top/bottom fiddling.) It would be much more logical to use 'none' as a default value, which will be at whatever position is suitable for the text type, and then never change top/bottom/center values. This is a successor bug to #106568#. --------- #107116# ---------------------------------------- Additionally, there is some problem with loading and saving. 'top' (internally 'none') is apparently saved as default, but loading uses 'top' (internally 'top') as default. This is why Eugene sees the problem again after a save/load cycle.
When importing an Excel file, I see all cells top aligned even if they are configured to be "standard"-aligned. Trying to align them to the center vertically does not give the same "center" as with a new file: it is much lower. Please tell me if this (or part) should be reported in another bug!
Due to time limitations, this has been retargeted to "OO later".
*** Issue 28902 has been marked as a duplicate of this issue. ***
*** Issue 31588 has been marked as a duplicate of this issue. ***
Is this issue still valid with 2.0.2?
Yes, it is.
*** Issue 65504 has been marked as a duplicate of this issue. ***
I have the same problem with tables!
Dear developers, what is the current status of this issue? Thanks a lot for your attention. WBR, Kirill Palagin.
Dear developers, is it so difficult to solve this problem? Vertical alignment is basic function for any text editor, which can work with tables, and it is surprisingly that Writer can't do it without errors. Thank you!
Have the same problem on Windows Vista machine. Still in OpenOffice 2.2.1
Dear developers! Can You target this annoying issue to the nearest release? It realy delivers greater inconveniences during work. Thank You!
re-setting owner - DVO is not working on Writer anymore. re-setting target for re-consideration (there's a relatively high number of votes I think).
MRU->OS: it does not matter wether the document is saved in sxw or odt format. When clicking into table 5, some of the cell's vertical alignment will chage from "top" to "center". I will target this to OO 3.0 at first, 'cause the issue has many votes and I think that the behavior is very annoying for the user.
Making summary a bit more significant.
Tables are being made a lot. Still not fixed in OOo 2.3
mru, version 3.0 is approx 1.5 years away. In addition to that targets are very flexible. So can we consider 2.4 as target for this issue? Thanks a lot for your attention!
I agree: version 3.0 is very long-run prospect for such absurd bug in one of the basic functions of text editor.
Dear sirs. Please, bring forward this issue to ver. 2.4. Our department can't completely prefer OOo to MSO only because of this issue: now using OOo we have to waste a lot of time to look through large documents before printing.
Comments from (dvo Sep 18 2003) hold relative simple suggestion, I think
Simple suggestion, but not a solution. Just imagine, what price a examination of document with 30-50 large tables! DVO didn't have enough time I think, and tried to present this bug as Writer;s "look-and-feel".
Cor-> canis: I meant a relative solution for development. Not for the users. Sorry for not being clear in this aspect.
Cor-> canis: I meant a relative simple suggestion for development. Not for the users. Sorry for not being clear in this aspect.
canis-> cornouws: Sorry, I didn't understand. Unfortunatelly this "simple suggestion" can take over 1.5 years.
Hi canis, That's indeed inforunate. If my impression is right, it might be doable for development to pick this one up rather easily. But that's not in my competence to judge or decide ... (If it might help you, I can provide a simple macro setting the allignment of all cells in tables in a document. But if there are complex tables and differences between various tables and rows, the macro becomes less simple ;-) - you can contact me by mail if you so wish.)
cornouws, thanks, but such macros won't solve this problem. Developers are only "sheet anchors" in this situation.
Oliver, are we on track for 3.0 with this issue? WBR, KP.
Fixed in cws os112 in sw/source/filter/xml/xmlimpit.cxx
Thanks a ton!
Reassigned for verification
Verified in CWS os112.
Checked fix in DEV300m12.