GNOME Bugzilla – Bug 502101
Orca should speak indentation info when pressing tab in OpenOffice writer
Last modified: 2018-02-08 12:56:17 UTC
It would be quite useful if orca could speak how far the indennt is from the left margin when pressing tab. For example: If the cursor is at the left margin and the user presses tab 3 times they might hear: 0.5 inches, 1 inch, 1.5 inchhes: If it is not possible to determin the left margin, the left edge of the page would also be OK. The inverse should also apply when pressing shift+tab.
Mike, is this something you think we should do for GNOME 2.22?
(In reply to comment #1) > Mike, is this something you think we should do for GNOME 2.22? > It would be a really nice to have but the world won't end if we don't get to it.
Mike, if this was done are you expecting an addition to the OpenOffice/StarOffice application preferences tab to handle whether it's on or off? If so, what would you like the wording of that checkbox to be? Thanks.
I'm thinking that this functionality should just be tied to the "speak indentation and justification" feature so no new UI should be required.
Mike, you wrote: > The inverse should also apply when pressing shift+tab. I'm confused. Shift-Tab does nothing for me when I'm in an oowriter text window. In other words, the text caret doesn't move. What did you really mean and what should happen? Thanks.
Mike, I'm unclear from the initial description on whether you want the indentation spoken as you are entering new text or only when navigating or both. Also, if the user types a Tab in the middle of a line, should the indentation be spoken then (assuming settings.enableSpeakIndentation is set)? Please clarify. Thanks.
(In reply to comment #5) > Mike, you wrote: > > > The inverse should also apply when pressing shift+tab. > > I'm confused. Shift-Tab does nothing for me when I'm in an oowriter > text window. In other words, the text caret doesn't move. O for some reason I thought shift+tab would move back one tab stop. Please just ignore my comments on this one.
Mike answered my other questions via phone, so removing his name from the Summary.
Created attachment 102337 [details] [review] Start at trying to implement this feature. In creating this patch, I discovered that StarOffice/OpenOffice Writer is not giving us the indentation information. Again. Testing with both OOo 2.3 that comes with Ubuntu Gutsy and latest OOo 2.4-dev for Linux. Steps to reproduce: 1/ Start "swriter --norestore" 2/ Start latest Orca 3/ Type Tab With the patch applied, the following debug is output by Orca: allAttributes: {'vertical-align': 'baseline', 'weight': '400', 'family-name': 'Times', 'fg-color': '0,0,0', 'strikethrough': 'none', 'underline': 'none', 'size': '12', 'style': 'normal', 'scale': '1', 'left-margin': '0mm', 'stretch': 'normal', 'pixels-above-lines': '0mm', 'paragraph-style': 'Default', 'text-shadow': 'none', 'direction': 'ltr', 'justification': 'left', 'variant': 'normal', 'font-effect': 'none', 'text-rotation': '0', 'invisible': 'false', 'writing-mode': 'lr-tb', 'indent': '0mm', 'language': 'en-us', 'pixels-below-lines': '0mm', 'bg-color': '255,255,255', 'right-margin': '0mm', 'text-decoration': 'none', 'line-height': '100%'} Notice 'left-margin': '0mm' 4/ Type Tab again. Debug output shows: allAttributes: {'vertical-align': 'baseline', 'weight': '400', 'family-name': 'Times', 'fg-color': '0,0,0', 'strikethrough': 'none', 'underline': 'none', 'size': '12', 'style': 'normal', 'scale': '1', 'left-margin': '0mm', 'stretch': 'normal', 'pixels-above-lines': '0mm', 'paragraph-style': 'Default', 'text-shadow': 'none', 'direction': 'ltr', 'justification': 'left', 'variant': 'normal', 'font-effect': 'none', 'text-rotation': '0', 'invisible': 'false', 'writing-mode': 'lr-tb', 'indent': '0mm', 'language': 'en-us', 'pixels-below-lines': '0mm', 'bg-color': '255,255,255', 'right-margin': '0mm', 'text-decoration': 'none', 'line-height': '100%'} 5/ Type Insert-f (get text attributes). SPEECH OUTPUT: 'Insert' SPEECH OUTPUT: 'f' SPEECH OUTPUT: 'size 12' SPEECH OUTPUT: 'family-name Times' Sigh. I'll open YAOOOB on this and block this one.
I've reopened OOo #72262 on this problem http://www.openoffice.org/issues/show_bug.cgi?id=72262 Blocking this one.
Just tried this again with the OOo 2.4-dev (m6) build on my Hardy machine. I wasn't expecting it to be fixed, but then again I wasn't expecting it to be broken when I tested it back on 7th January. It's still broken. I'm FUTURE'ing this one as we have no control over the other bugs in other products that we depend upon.
We talked about this in the Orca team meeting yesterday. At that time, I thought we'd decided that all we wanted was for Orca to say something like "three tabs two spaces" if text indentation was turned on (and there were tabs/spaces at the start of the line). I've just checked. Orca does that just fine with this with oowriter documents. Looking back at the original bug description, I see something different: "It would be quite useful if Orca could speak how far the indent is from the left margin when pressing tab. For example: If the cursor is at the left margin and the user presses tab 3 times they might hear: 0.5 inches, 1 inch, 1.5 inches: If it is not possible to determine the left margin, the left edge of the page would also be OK. The inverse should also apply when pressing shift+tab." I believe from our discussion yesterday, that it's not possible to do this. Am I correct? If not, can somebody give me a hint on how to proceed with implementing this? Thanks.
Hmmmm.... Looking at this in Accerciser (as opposed to in my head which is how I was looking at it during team meeting): There seem to be two indentationy text attributes: 1. left-margin/right-margin 2. indent For any given text object (e.g. paragraph), increasing/decreasing the "indent" via the toolbar buttons or by dragging the little.... whatchmadoodles.... on the ruler causes there to be a change in the margin; not the indent. While it seems counterintuitive that pressing a button to change the "indent" doesn't change the indent text attribute, it does make sense to me that the margin(s) for that object are being changed. Issue 1: Nothing seems to be exposed to let us know where we are spatially for a tab character (i.e. that we've moved 1 inch or that we're 2 inches from the left edge of the page). We could compare character extents but that would only give us pixels as I understand it. And we don't want to do math to try to figure out the correct units (I assume). Issue 2: Doesn't *appear* that the OOo guys are using the indent text attribute for anything. I could easily be wrong here, but I just did some quick playing around in Writer and indent always seems to be 0mm. If I'm right about 2, then might the YAOOB be that Tab characters should have amongst their text attributes an indent property?
In OOo "indent" is used to expose "first line indent" (see format - paragraph). Technically the position to which a 'tab' character moves a the next one is not a property of the following character, but a property of the paragraph. I have closed OOo #72262 again and submitted OOo #88513 for the missing exposure of tab-stop positions (http://www.openoffice.org/issues/show_bug.cgi?id=88513). This probably will result in something similar to http://www.w3.org/People/howcome/t/970224HTMLERB-CSS/WD-tabs-970117.html With this implemented, Orca would still have to figure out itself which of the tab stop positions gets used after all when pressing tab (as this depends on the length of the text before the tab). But it appears to me that what you are really looking for is the effect position of the text at cursor, which is a layout information and not available as text-attribute. So shouldn't we just find a way to make easier for Orca to calculate the desired value from the character extend (e.g. by providing the pixel/inch rate) ?
(In reply to comment #14) > So shouldn't we just find a way to make easier for Orca to calculate the > desired value from the character extend (e.g. by providing the pixel/inch rate) > ? I believe the main goal is to allow the user to determine where the caret is on the page. So, we really are looking for a means for Orca to calculate this, and to present it to the user in meaningful units (i.e., ideally in the same units used for the ruler). Oliver, do you have ideas for how we could do this?
If we can do this it will really be what the users are looking for.
My idea was that Orca could ask for the bounding box of the character at the caret position, and then asks the ruler for it's value at the corresponding x-position. Unfortunately I don't see a way to do the latter part of this. What I would imagine here is an interface which returns a value for a position and the unit of measure. Are there any examples for accessible rulers in gtk+ ?
(In reply to comment #17) > My idea was that Orca could ask for the bounding box of the character at the > caret position, and then asks the ruler for it's value at the corresponding > x-position. > > Unfortunately I don't see a way to do the latter part of this. What I would > imagine here is an interface which returns a value for a position and the unit > of measure. > > Are there any examples for accessible rulers in gtk+ ? I don't know of any such interface for accessible rulers. It would be ideal if we could get this information, though. Right now, it appears as though the ruler is exposed as a AT-SPI panel with no children and useful information. :-( I'm also not sure how to get to it from the keyboard, but that's a whole separate issue. (In reply to comment #13) > There seem to be two indentationy text attributes: > > 1. left-margin/right-margin > 2. indent Yep -- makes sense. If I understand these, indent tells us where the first line of a paragraph will start relative to the page margin (the gray box drawn on the page). The margin attributes tell us where the line boundaries are relative to the page margin (with the exception of the indent, which takes precedence over the left margin for the first line). Does that seem correct? > Issue 1: Nothing seems to be exposed to let us know where we are spatially for > a tab character (i.e. that we've moved 1 inch or that we're 2 inches from the > left edge of the page). We could compare character extents but that would only > give us pixels as I understand it. And we don't want to do math to try to > figure out the correct units (I assume). If we had the needed information to do the math, I wouldn't mind trying it. We have it for some cases, I think, which is where we are at the first character on a line (where 'character' includes tabs). In these cases, I *think* we can look at the indent and left-margin attributes and report them as the offset. When we are not at the first character on a line, we might be able to look at the text range extents. Here's an example from accerciser that looks at the extents for the 2nd character: acc.queryText().getRangeExtents(1,2,1) The returned 'x' value seems to be from the left physical edge of the page and the returned 'y' value seems to be from the top of the paragraph. OK, so, with a left-margin=indent=0, we can now tell how many pixels the page margin is (the distance from the physical edge of the page to the gray box): it's the 'x' value of the extents for the first character. If we knew the size and units of the page margin (e.g., 1 inch), we could have something to help us with the math to convert the pixels into meaningful units (mm, in, etc.). This makes me wonder if OOo could expose a 'left-page-margin' attribute as part of the text attributes. This would be a measurement, in the same units we see for left-margin, from the physical left edge of the page to the gray box. For completeness, I guess 'right-page-margin', 'top-page-margin', and 'bottom-page-margin' would be needed. In the absence of useful page margin information, we could potentially hack if there were different kinds of paragraphs in the document (i.e., ones that had non-0 indents or left-margins). The character offsets from those beasts could be used to help us convert pixels to units. Thoughts?
(In reply to comment #18) > Yep -- makes sense. If I understand these, indent tells us where the first > line of a paragraph will start relative to the page margin (the gray box drawn > on the page). The margin attributes tell us where the line boundaries are > relative to the page margin (with the exception of the indent, which takes > precedence over the left margin for the first line). Does that seem correct? The (first line) indent may as well be relative to the paragraph margin, but I would need to check myself. The margin/indent values are currently exposed in 'mm' units, as the OOo ATK bridge does not know the rulers objects either. Exposing the tab stop positions for a paragraph the same way shouldn't be too hard and I will check whether the page margins can be exposed either. Does it make sense to file RFE(s) for a ruler interface either ? We would need it in at-spi / ATK as well ..
Thanks Oliver! > Exposing the tab stop positions for a paragraph the same way shouldn't be too > hard and I will check whether the page margins can be exposed either. I'm thinking page margins might be more useful since they, in combination with indent and left margin information, would allow us to determine the position for any character on a line. It should be a lot easier to expose this information as well since we wouldn't need to create a whole new API for it. > Does it make sense to file RFE(s) for a ruler interface either ? We would need > it in at-spi / ATK as well .. This might be an interesting thing. Aside from the ruler itself, are there other means in the UI to set ruler values? That is, if there already is a means to adjust the values associated with a ruler, there might not be a strong use case to make an interface for it.
(In reply to comment #20) > > I'm thinking page margins might be more useful since they, in combination with > indent and left margin information, would allow us to determine the position > for any character on a line. It should be a lot easier to expose this > information as well since we wouldn't need to create a whole new API for it. > Unfortunately the page margins are not in the list of attributes the OOo atk-bridge gets from the writer module. I have contacted the writer team for help on this, but I will probably have to go with tab-stops only for now (to have this in OOo 3.0 for sure). > This might be an interesting thing. Aside from the ruler itself, are there > other means in the UI to set ruler values? That is, if there already is a > means to adjust the values associated with a ruler, there might not be a strong > use case to make an interface for it. > Format -> Paragraph -> Tabs provides access to the tab positions.
OOo's UAA/ATK bridge will add an extra attribute which allows pixel to logic calculations. That should solve the problem.
(In reply to comment #22) > OOo's UAA/ATK bridge will add an extra attribute which allows pixel to logic > calculations. That should solve the problem. Thanks Malte! Has this been done and do you have a pointer to a build that I can use to test this out on OpenSolaris 2008.11 b109?
After discussions with the OOo engineers, more work is needed. See also http://www.openoffice.org/issues/show_bug.cgi?id=92233 - Expose mm/pixel ratio as text attribute.
Changing the status from 'blocked' to 'to verify' because the blocking bugs are marked as fixed. Note: Verification doesn't necessarily mean that Orca is doing the right thing yet; merely that in theory we should be able to implement what we need to do because we're getting the expected events and/or other information from OOo.
I have verified that we're getting the requested information now in OOo 3.3 dev m78. We're going to have to do some work on our end to use the information which is now being provided to us.
(3.0 Planning Spam-o-rama. Sorry!)
Not sure if we'll have time for this one between now and 3.0. But it would be awfully nice if we could do it....