[sw-issues] [Issue 81718] [a11y] OOo Writer should r eport run attributes for the end position of a paragraph
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User mt changed the following: What|Old value |New value Status|NEW |RESOLVED Resolution| |DUPLICATE --- Additional comments from [EMAIL PROTECTED] Wed Oct 24 11:16:26 + 2007 --- See my comments in http://www.openoffice.org/issues/show_bug.cgi?id=82637 When that one is fixed, things should normally be reported as expected. There is only this special case left: The user is at the end of the (normal) paragraph and presses the key or button for bold. There is no way for reporting this, because getRunAttributes is not defined for this position. Because we are talking about a character based API, not about a cursor position based API, I don't want to change that API to accepts the position para-len. If this would fix the issue, we could discuss it, but is doesn't: Enter some characters XXX YYY, put the cursor behind XXX and press bold. When the user now types a character, it will be bold. But when I ask for the attributes of that position, I wouldn't expect to get bold, because the space is not bold. Since we don't have some what would be if... API in AT_SPI or UAA, this is not fixable. Provide strong arguments for the use case and we can implement it, but not w/o new API in UAA, AT-SPI, JAA, IA2, ... Not sure how to handle this issue now. If it would be about the special case, I would close it with wont fix. But the special case was only part of the discussion, and the original issue will be fixed with #i82637#, so I will set this one to duplicate. For the special case, if someone insists on it, he can feel free to write a new issue... *** This issue has been marked as a duplicate of 82637 *** - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer should r eport run attributes for the end position of a paragraph
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User od changed the following: What|Old value |New value Status|RESOLVED |CLOSED --- Additional comments from [EMAIL PROTECTED] Wed Oct 24 12:21:00 + 2007 --- closing... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 07:49:19 + 2007 --- OD-williewalker: From my point of view, your proposed solution is more or less the same as my proposed solution (a). Thus, you will refine the AT-SPI API specification and I will check, what can be done in the UNO accessibility API and in the accessibility bridge for the mapping of the AT-SPI API to the UNO accessibility API. If you want a fast workaround, which will be correct in most cases, you can do the following: If the user request the attributes for the character, she/he wants to input at the end of the paragraph, you can provide the attributes, which are provided for the last existing character. For most cases, this will be appropriate except the cases, in which the user explicit change a certain character attribute at the end of the paragraph. But, in this case the user made an explicit action and she/he should be aware of this action. Is it ok for everybody, if I change the issue type to enhancement and change the issue summary to [a11y] OOo Writer should report run attributes for the end position of a paragraph? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 14:40:24 + 2007 --- you will refine the AT-SPI API specification and I will check, what can be done in the UNO accessibility API and in the accessibility bridge for the mapping of the AT-SPI API to the UNO accessibility API. Agreed, but the difference is that it will be possible for you to support the new behavior much much sooner since it doesn't require any new API. All it's doing is extending the interpretation of an existing API. Given the variance in the AT-SPI implementations we see all the time across Java, OOo, FF, and GTK, I also think it is probably OK for you to go ahead with this change without requiring the specification to be strictly enhanced to include this. For the API enhancement, I've opened the following support reqeust for AT-SPI: http://bugzilla.gnome.org/show_bug.cgi?id=487918. Please let me know how your investigation goes. If it's possible for you to do this sooner than later, it would be great. Is it ok for everybody, if I change the issue type to enhancement and change the issue summary to [a11y] OOo Writer should report run attributes for the end position of a paragraph? This would be more accurate. Thanks! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer should r eport run attributes for the end position of a paragraph
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User od changed the following: What|Old value |New value Issue type|DEFECT|ENHANCEMENT Summary|[a11y] OOo Writer reports |[a11y] OOo Writer should r |normal text as bold in cer|eport run attributes for t |tain circumstances|he end position of a parag | |raph Target milestone|--- |OOo 2.4 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 15:03:21 + 2007 --- Setting target to OOo 2.4 and adjusting summary and issue type. I'll have to talk to MT about the UNO accessibility API - hopefully next week. I'm not sure, if the UNO accessibility API can be extended as it will be done for the AT-SPI. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Wed Oct 17 09:32:37 + 2007 --- Ok. Thus, we have to figure out a solution. I've presented two possible solution. Does somebody else has further possible solutions? After having collected the possible solution, we have to decide, which one is the one, we want to follow. Please give your input. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Wed Oct 17 22:17:00 + 2007 --- (a) Define and implement a new method at the OOo UNO accessibility API, which serves this request. Define a corresponding method at the AT-SPI and connect these methods together in the accessibility bridge. Adding new API will probably be too long of a process for an AT to be able to provide compelling access to OOo in this case. Instead, I think we might be able to extend the definition of the existing API (see below). (b) Reuse the existing methods directly in Orca: In general the attributes of the to be inserted character at the end of a paragraph are the same as the ones at the currently existing last character. Exceptions are - as you already mentioned - the explicit made changes by the user at the end of the paragraph,e.g. Control-B at the end of paragraph. Thus, to get the attribute set for the to be inserted character at the end of a paragraph, the attributes for the last existing character has to be determined and additionally the explicit made changes by the user has to be considered - issue 70872 is planned to be fixed in OOo 2.4 If I understand it correctly, this would require the assistive technology to scour the user interface as well as make semantic interpretations to correlate toolbar object values (whose names are in the locale of the user) with text attribute values (whose names are machine readable). This does not seem like a viable solution. :-( So...here we are. I definitely acknowledge that the AT-SPI as specified certainly seems to be insufficient to give us the information we need to present to the user. :-( As an alternative solution, I propose extending the strict interpretation in the following citation: cite ... Parameters: offset the offset of the character whose attributes will be reported. ... /cite The extension of the interpretation would be if the character offset equals the length of the string, the reported attributes will be for any character that will be added to the end of the text in its current state. This seems like it might accomplish our goals rather easily. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User joaniediggs changed the following: What|Old value |New value CC|'es,joaniediggs,mt,obr' |'es,joaniediggs,mt,obr,wil | |liewalker' --- Additional comments from [EMAIL PROTECTED] Tue Oct 16 15:36:11 + 2007 --- But, I want to state that the current implementation in OOo Writer doesn't reports normal text as bold in certain circumstances. Do you agree to this statement? Agreed. A more accurate title for this bug would be OOo Writer allows ATs to conclude that normal text is bold in certain circumstances. :-) Please allow me to explain: When an AT wants to identify the attributes associated with a given character, it looks at the default attributes and then applies any reported character attributes on top of them. Thus in Rich's example, the default attribute weight:600 is present. If you query any of the bold characters in his example, they will not report a weight. Therefore, an AT concludes that because the default weight is 600 and no character weight is being reported, the text must be bold. Similarly, for any of the existing characters in his example that are not bold, the default weight is 600, the character reports a weight of 400, and the AT concludes that the character is not bold. So far so good. Here's Rich's bug: When you attempt to query the attributes at the end of the paragraph, the default weight is still reported as 600; the non-existent character does not report anything to the contrary. Therefore, the AT concludes incorrectly that the character that is about to be typed is bold. Regardless I've thought that it is necessary to explain, that things are mixed up here: an existing function/method is used outside its defined parameter range. Do you agree to this statement? Agreed. Is it correct, that you need a method/function/workaround, which provides the attribute set, which will be applied at the character, that will be inserted at the end of the paragraph? That is correct. If your answer is Yes, then let's work together to find an appropriate solution for this problem. Excellent. Thank you! The solutions you propose sound good to me. But if it's not already obvious, my background is in education; not software development. :-) So when I see things like UNO accessibility API, I feel the need to bring in Willie Walker. So I'm CCing him. Having this fixed for 2.4 will be awesome though. I really appreciate it OD!! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Tue Oct 16 07:52:40 + 2007 --- OD-joaniediggs: I've no problem in fixing this problem and I will do it, if the request for the change is clear. But, I want to state that the current implementation in OOo Writer doesn't reports normal text as bold in certain circumstances. Do you agree to this statement? I've thought that it is necessary to explain, that things are mixed up here: an existing function/method is used outside its defined parameter range. Do you agree to this statement? Is it correct, that you need a method/function/workaround, which provides the attribute set, which will be applied at the character, that will be inserted at the end of the paragraph? If your answer is Yes, then let's work together to find an appropriate solution for this problem. I've got two solutions in mind: (a) Define and implement a new method at the OOo UNO accessibility API, which serves this request. Define a corresponding method at the AT-SPI and connect these methods together in the accessibility bridge. (b) Reuse the existing methods directly in Orca: In general the attributes of the to be inserted character at the end of a paragraph are the same as the ones at the currently existing last character. Exceptions are - as you already mentioned - the explicit made changes by the user at the end of the paragraph, e.g. Control-B at the end of paragraph. Thus, to get the attribute set for the to be inserted character at the end of a paragraph, the attributes for the last existing character has to be determined and additionally the explicit made changes by the user has to be considered - issue 70872 is planned to be fixed in OOo 2.4 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Mon Oct 15 10:27:27 + 2007 --- A Control-B in an empty paragraph causes that the character property Bold is set at the complete paragraph as its so-called default attributes. The reason for this is the following feature in OOo Writer: A character attribute, which is applied to all characters of a paragraph, are set as the so-called default attributes for this paragraph - it's automatic paragraph style will contain this attribute. I can't reproduce the following: cite Now modify the above steps so that you get rid of all bold characters prior to typing non-bold ones, i.e.: 1. In a new document, turn bold on with Control+B 2. Type hello 3. Turn bold off with Control+B 4. Backspace until hello is gone. 5. Type world The end result on screen looks the same as the result of the first example, yet the problem goes away: The default weight is 400 (along with the weight associated with the character just past world) rather than 600. /cite The first step set Bold as the so-called default at the paragraph. The virtue of step 3 is lost, if the next action isn't a key input. After step 4 Bold is still the default attribute and typed world in step 5 is Bold. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Mon Oct 15 12:18:03 + 2007 --- Regarding the UNO accessibility API of OOo: Methods com::sun::star::accessibility::XAccessibleText::getCharacterAttributes(..) and com::sun::star::accessibility::XAccessibleTextAttributes::getRunAttributes(..) aren't defined for the caret position behind the text of a paragraph. The same is hold in my opinion for the AT-SPI method Accessibility::Text::getAttributeRun(..). In its definition it's said the following: cite ... Parameters: offset the offset of the character whose attributes will be reported. ... /cite Thus, parameter offset have to be the offset an existing character. The offset value, which you get at the caret position behind the text of a paragraph is no valid parameter value for this method. Conclusion: (a) There is no defect in the OOo Writer accessibility API regarding run attributes for existing characters. (b) There seems to be the request, that a user wants to know the attributes of the character, which she/he is willing to input a the end of the paragraph in the next moment. From my point of view, this is a request for enhancement. Please give your comments on my information/thoughts. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Mon Oct 15 16:17:13 + 2007 --- In order to keep focus on the original issue reported by Rich, I opened a new issue (issue 82637) regarding the definition of default attribute. w.r.t. Not being able to reproduce that one particular example: I no longer can either. Perhaps it was a development build or fluke in Ubuntu Gutsy. So never mind on that one. :-) My apologies. As for Rich's reported issue and whether or not the (other) examples I cited are defects or requests for enhancements: To be honest, as far as the blindness community is concerned, we don't care what you call it as long as you fix it. :-) That said, if we must call it something, I would call it a defect. As a sighted user, I can look at the formatting toolbar and immediately identify what formatting will be applied to the next character I type. The fact that this much-needed information is not currently exposed to users who are blind is not a feature in need of implementation; it's a problem in need of fixing. This problem is compounded by the fact that we get attributes exposed as default attributes that don't actually apply to the character that is about to be typed, hence Rich's bug. And I'm afraid it's further compounded by the fact that we don't get events to let us know that bold (or whatever) had been toggled. See issue 70872. Getting these issues resolved would make a huge difference to users who are blind. Thanks! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y] OOo Writer reports normal text as bold in certain circumstances
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User obr changed the following: What|Old value |New value CC|'joaniediggs' |'es,joaniediggs,mt,obr' Assigned to|es|od Summary|[a11y]|[a11y] OOo Writer reports | |normal text as bold in cer | |tain circumstances --- Additional comments from [EMAIL PROTECTED] Thu Sep 20 13:05:10 + 2007 --- I believe the current algorithm just tries to minimize the run attribute set, but I may be wrong .. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y]
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 Issue #|81718 Summary|[a11y] Component|Word processor Version|OOo 2.3.0 RC1 Platform|All URL| OS/Version|All Status|NEW Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|ui Assigned to|es Reported by|richburridge --- Additional comments from [EMAIL PROTECTED] Tue Sep 18 21:31:55 + 2007 --- See also Orca bug #477895 for more details. http://bugzilla.gnome.org/show_bug.cgi?id=477895 Tested on my Ubuntu Gutsy system (with all the latest updates), plus OpenOffice 2.3.0 (openoffice.org-core 1:2.3.0rc1-1ubuntu1, Mon Sep 10 09:46:11 GMT 2007). Steps to reproduce: 1/ Start Orca 2/ Start OOo Writer with oowriter -norestore (not sure if -norestore is important - that was just the way I was trying it). 3/ In the empty text document, type in the following (without the quotation marks): control-b bold control-b space control-i italic control-i space normal 4/ Type Insert-f The text caret is to the right of the normal text. It thinks it's bold. -- It has been suggested that at this point, the caret offset might be nonsensical, and because of this, it's using a text caret offset of 0. If this is the case, it might be better to use the text caret offset of the last character on the line. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y]
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User richburridge changed the following: What|Old value |New value Keywords| |accessibility Summary|[a11y]|[a11y] - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y]
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 --- Additional comments from [EMAIL PROTECTED] Wed Sep 19 02:20:44 + 2007 --- I wonder if instead it might have something to do with the default attributes associated with a paragraph, along with when and how those attributes are established and updated. Consider the following: 1. In a new document, turn bold on with Control+B 2. Type hello 3. Turn bold off with Control+B 4. Type world 5. Move to the w and then backspace to get rid of hello At this point the text at caret offset 0 is the w and it's not bold. Nothing in the document is bold. However if you call text.getDefaultAttributeSet() or text.getDefaultAttributes() for that paragraph, one of the values that's returned is: 'weight:600'. If you examine the text attributes of any of the characters in world with text.getAttributes(), you'll see that 'weight:400' is returned (and thus explicitly defined). The weight hasn't been defined at the caret position just past the d, therefore if you query its attributes, you get 'weight:600' (i.e. another instance of Rich's bug). Now modify the above steps so that you get rid of all bold characters prior to typing non-bold ones, i.e.: 1. In a new document, turn bold on with Control+B 2. Type hello 3. Turn bold off with Control+B 4. Backspace until hello is gone. 5. Type world The end result on screen looks the same as the result of the first example, yet the problem goes away: The default weight is 400 (along with the weight associated with the character just past world) rather than 600. Modify the steps yet again: 1. In a new document, type hello world 2. Select hello and make it bold. Now the character at offset 0 is bold, yet the default weight (along with the weight associated with the character just past world) is still 400. It would seem that the default text attributes for a paragraph in Writer are defined as whatever formatting is associated at the beginning of a paragraph when the paragraph has a length of 0. And it seems that this is what gets returned when you query the text attributes for the offset just beyond the final character in the paragraph. Is the assumption that the about-to-be typed character will inherit the default attributes? If so, what Rich proposes is, I think, a more accurate assumption to make. HOWEVER, consider: 1. In a new document, type hello world 2. With the caret just past the d in world, and without having typed anything else, press Control+B to turn bold on. We know that the next character is going to be bold. We can look at the formatting toolbar and verify that bold's been toggled on. And once we type that character, text.getAttributes(11) will return 'weight:600' as expected. But UNTIL we type that character, text.getAttributes(11) will return nothing (of any use anyway). Therefore, an AT deriving the formatting of a character by looking at the default attributes and factoring in the character attributes, would conclude that the to-be-typed character at offset 11 is not going to be bold -- and it would report that incorrect fact to the user. I'm not sure how best to expose attributes for characters that don't yet exist, but are about to. :-) But it would be handy if there is a clever way to accomplish that because, in this instance, the attributes associated with the last existing character are not applicable. As long as we're on the subject of attributes ;-) I wonder if the implementation of default attributes is OOo is consistent with how it's defined in the AT-SPI. There (http://www.gnome.org/~billh/at-spi-idl/html/interfaceAccessibility_1_1Text.html) default attributes are: the text attributes which apply to all text in the object by virtue of the default settings of the document, view, or user agent; e.g. those attributes which are implied rather than explicitly applied to the text object. For instance, an object whose entire text content has been explicitly marked as 'bold' will report the 'bold' attribute via getAttributeRun(), whereas an object whose text weight is inspecified may report the default or implied text weight in the default AttributeSet. Based on that definition, what *I* would expect to find exposed as the default attributes are only those attributes associated with the entire paragraph style (e.g. the default style, the heading 1 style, the text body style) as defined for the document/template. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 81718] [a11y]
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81718 User joaniediggs changed the following: What|Old value |New value CC|''|'joaniediggs' - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
