GNOME Bugzilla – Bug 363820
Orca should inform the user when text in given cell in Calc is too wide for that column
Last modified: 2009-11-09 21:35:14 UTC
When using Calc, it is possible to write more text in a given cell than will fit. Visually it is clear when this has occurred: If the cell(s) to the right is(are) empty, the text will extend into subsequent columns; otherwise, the text will get cut off. It is difficult to determine non-visually that one has written more text than will fit. Orca should therefore inform the user when this has occurred and, ideally, detail the extent to which the text has "bled" into subsequent cells. (Suggested at Boston Orca users group)
We probably can get the extents for the text and compare it to the extents for the current table cell. If it is greater, then we keep comparing it against the extents for each of the table cells to the right until we know exactly how many "cells worth" we have. Will/Mike, should this be the default behaviour? ...
To add more to this, the users were asking for information such as "n characters too long". This would give them the information needed to help them resize the cell or edit the cell contents to fit.
I think that if we are going to provide information that the cell is to long by default then it is also a good idea to provide this extra information as well.
Mike, I'm looking for the wording you would like here. Something like: "n characters too long" or "n characters greater than cell size" or what? ... Thanks.
Also (for the record)... I can easy do this as they are navigating into a new cell, but should this "n characters too long" (or whatever) be also reported: 1/ as they are typing input into a cell, and they go beyond the cell extents ? 2/ when they press Return in a cell (i.e. finished entering new input)? Thanks.
I've discovered that OOo is returning bogus width and height values for the text extents of the contents of the spread sheet cells. I've filed OOo issue #70916 against this: http://www.openoffice.org/issues/show_bug.cgi?id=70916 Tomorrow, I'll attach a patch that should do the right thing, assuming that we were getting good text extent values from OOo scalc. Hopefully it'll be the basis of a patch when the OOo problem is fixed. The intent initially with this Orca request enhancement is to report the "n characters too long": 1/ when you navigate to a spread sheet cell that contains text that is too long. 2/ when reporting the summary of the text just entered into a spread sheet cell when the user presses Return. Another place where it could be reported is as the user is typing text in, but rather than continually saying "n character too long" as you enter each character, case #2 above, allows you to simply go back, and re-edit the cell again, removing the extra characters, just after you press Return. Repeat and rinse. More tomorrow.
Created attachment 75476 [details] [review] Patch that will hopefully implement this enhancement when the underlying OOo bug is fixed.
Created attachment 75478 [details] [review] Cleaner version of the patch.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
(In reply to comment #8) > Created an attachment (id=75478) [edit] > Cleaner version of the patch. > Just going through our unreviewed patches. We all know it is hard to test since the OOo blocking bug has not been fixed (currently targeted for OOo v2.4), but I just want to comment that it probably needs to use ngettext and a translator comment for the "%d characters too long" string.
This patch is so old, then it will need to be reworked to fit with the existing StarOffice.py script. Before doing that, I'm going to wait under the OOo folks actually fix the underlying bug so that it can be properly tested. Noted that it will need to use ngettext as well. Marking as "needs-work" for now.
The underlying OOo issue has been marked as verifyed/fixed. Marking this one as "[to confirm]". When a publically available build of OOo with this fix in is available, I'll rework the really old patch we have and test it out.
Created attachment 115191 [details] [review] Updated patch This is an updated version of the previous patch. The underlying OOo bug is giving better information, but still not great. I don't think OOo is taking cell margins or text alignment into account when computing the text extents. I'll update http://www.openoffice.org/issues/show_bug.cgi?id=70916.
Created attachment 115192 [details] [review] Patch with better debug output This patch provides better debug to let us know which characters we're looking at.
See http://www.openoffice.org/issues/show_bug.cgi?id=92143 for the new bug.
Created attachment 131453 [details] [review] Updated patch for trunk Updated patch for trunk.
Created attachment 131729 [details] [review] Revised patch to include text clipped off the left hand side The OOo guys are giving us better data now with an internal build (yeah!). This exposed a problem with Orca where text that was clipped on the left hand side was not being counted in the "too long" count. This patch fixes that. I also noticed that the "Where Am I" code doesn't include the too long count. Should it? (I think it should)
> > I also noticed that the "Where Am I" code doesn't include the too long count. > Should it? (I think it should) > I agree I think it should.
Retargeting to FUTURE since this depends upon an OOo fix, and it doesn't look like that fix will land until OOo 3.2.
Just a quick note that Joanie has also verified http://qa.openoffice.org/issues/show_bug.cgi?id=92143 has been fixed in the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]).
Created attachment 139884 [details] [review] Patch that works with the new speech generators This patch, which pylints to a 10.0 but is not regression tested yet, works with the latest Orca from git master and the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd])
Scratch that. New patch coming up.
Created attachment 139902 [details] [review] Patch to add the too long string This patch pylints and tests well. Committed to git master for 2.27.90.