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.

I believe the current algorithm just tries to minimize the run attribute set,
but I may be wrong ..

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".

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.

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!

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

> 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!!

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.

>(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.

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"?

> 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!

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.

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 ***

closing...