Apache OpenOffice (AOO) Bugzilla – Issue 92143
text getRangeExtents reports incorrect 'x' values for spreadsheet cells
Last modified: 2013-08-07 15:14:30 UTC
Building upon http://www.openoffice.org/issues/show_bug.cgi?id=70916... I'm still not sure the text extents are reported properly, even in the left justified case. It looks as though the y, width, and height are accurate, but the x position is incorrect for spreadsheet cells. The patch at http://bugzilla.gnome.org/show_bug.cgi?id=363820 contains some print statements in it to help debug the problem. Here's an example when looking at dynamic.ods (attached to 70916): Information for cell C4 ("Column Heading C"), which is cut off at the 'd' on my display. That's the 'd' in 'Heading'. As a result, I can only see "Column Head" being displayed, and only part of the 'd' is showing. Something seems wrong with the text extent calculations. In the following, OBJECT EXTENTS are the extents of the cell. Each line thereafter represents the extents of the string. OBJECT EXTENTS: x=475 y=256 width=78 height=14 C: x=475 y=256 width=10 height=14 Co: x=475 y=256 width=16 height=14 Col: x=475 y=256 width=19 height=14 Colu: x=475 y=256 width=25 height=14 Colum: x=475 y=256 width=35 height=14 Column: x=475 y=256 width=42 height=14 Column : x=475 y=256 width=45 height=14 Column H: x=475 y=256 width=54 height=14 Column He: x=475 y=256 width=60 height=14 Column Hea: x=475 y=256 width=67 height=14 Column Head: x=475 y=256 width=73 height=14 Column Headi: x=475 y=256 width=76 height=14 Column Headin: x=475 y=256 width=82 height=14 Here's what seems wrong: 1) The 'x' position of the 'C' starts flush with the left edge of the cell. This leads me to believe that cell borders might not be taken into account, assuming the OBJECT EXTENTS are correct. 2) It seems as though the above is telling us the 'i' and perhaps part of the 'n' are within the cell boundary, which they are not. This again might be related to the left border not being taken into account. Furthermore, when looking at a cell with right justfication, cell C5 ("100"), the text extents seem to lead us to believe it's left justified: OBJECT EXTENTS: x=475 y=270 width=78 height=14 1: x=475 y=270 width=8 height=14 10: x=475 y=270 width=14 height=14 100: x=475 y=270 width=21 height=14 By using Orca's flat review functionality for characters (KP_1, KP_2, KP_3), which draws a rectangle around the character, it's also obvious that the text extents are not correct. Again, the y, width, and height seem right. It's just the 'x' position that is wrong. Thanks!
OOo 3.2
confirmed
accepted
fixed in CWS tbe37 The following files are affected: sc/source/ui/Accessibility/AccessibleCell.cxx r268609 sc/source/ui/Accessibility/AccessibleText.cxx r268304 sc/source/ui/Accessibility/AccessibleText.cxx r268609 sc/source/ui/inc/AccessibleText.hxx r268609
merged fixes into CWS swa11y32 The following files are affected: sc/source/ui/Accessibility/AccessibleCell.cxx r268652 sc/source/ui/Accessibility/AccessibleText.cxx r268652 sc/source/ui/inc/AccessibleText.hxx r268652
Thanks for working on this! I'd love to be able to test it out. Do you have a build that works on OpenSolaris 2008.11 b109?
williewalker: Great. I will provide a build and let you know when it's ready.
I tested with StarOffice 9.1.0 DEV300m41 (Build:9398) [CWS:swa11y32] on my OpenSolaris b109 machine with Orca from trunk and with a new Orca patch from http://bugzilla.gnome.org/show_bug.cgi?id=363820. Many thanks for making the build available. I'm not sure the problem has been fixed. :-( It is getting very close, though, and you've covered a lot of cases (thanks!). The one case that remains can be reproduced as follows: 1) Create a cell with text that is too wide for the cell. 2) Change the left/center/right alignment so that the left side of the text is clipped by the cell. In the above, the extents of the text seem to begin at the left edge of the cell and are incremented thereafter. That is, it is as though left alignment were enabled for the cell. Thanks for your work!
williewalker: You're right, if the text is too wide for the cell the horizontal position for right or center aligned text is wrong. I fixed this problem and will provide a new build. Thanks, I really appreciate your tests. The following files are affected: sc/source/ui/Accessibility/AccessibleText.cxx r270166
@tbe - your latest build from today seems to have resolved the problems nicely. Your latest fix actually exposes a bug in the Orca patch that was counting how many characters too wide the text was for a cell (we, too, were making a bad assumption that the text did not start prior to the left edge of the cell). That's an Orca problem and not yours, though. Many thanks!
TBE->ES: Please verify in CWS swa11y32_2nd.
This fix has been confirmed by the Orca team using the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]). Many thanks!
Thanx for verifying!
Fixed and integrated => closing now..