Afreed, this could be quite useful.  We could  have another check box just after the "speak indentation"  one in the config UI.  We should also probably have unbound hotkeys for togling both the indentation and attribute settings.  

One toggle should be sufficient, they can afterall do a per-application text-attribute selection if they bring up the application specific orca settings.


Also for minimizing verboseness (if they have selected minimal verboseness:

When the target is a single word then we drop the end attribute announcement?
taking the example from above:

"this is some [bold]text with some [red]attribuutes."
and we extend to use the full announcement when the attribute change spans more than one word boundary.
i.e. we still wish to hear:
"this is some [bold]text with[regular] some [red]attribuutes inn [black] a slightly longer paragraph."

Mike, what do you think about this less verbose alternative?

Thank you

Jon, folks are going to start thinking that I'm paying you to submit these RFEs.  Check's in the mail, by the way. <grin>

This is a topic I periodically bring up (and did just the other day).  As you indicate, having to move to each bit of text that you suspect has a certain format and then ask for that format is not efficient.  Plus, you have to suspect that text needs to be checked.  (i.e., given the inefficiency of the current process, you're likely to verify that you made the important text bold, but less likely to check that you didn't accidentally make something else bold because you got distracted).

I like your idea, and Mike's follow up suggestion.  I'm wondering, however, if we want three levels instead of two:  Basic, Detailed, and The Kitchen Sink.  Basic and Detailed are what you describe in your opening comment and should more than meet the needs of documents that you are creating yourself.  When collaborating on documents with others, however, it's hard to known what formatting they may have used.  For instance, I personally never use strikethrough or font colors.  Therefore, I wouldn't bother to have these items checked in my list of text-attributes I care about.  Other people might give me a document that uses these things, though.  And if I edit (or copy and paste) text with that formatting, I am in danger of applying that formatting in places I did not intend.  So the Kitchen Sink option would allow me to find this information while proofreading without having to modify my preferred text attributes to include every possible attribute.

The other notion I've toyed with in the past is a way to get a list of text that has attributes other than the default ones.  That way you don't have to read over the whole document looking for purple, blinking, shadowed text from your wacky colleague.  You could just ask Orca.

Anyhoo, just some ideas I figured I'd toss out....

(In reply to comment #2)
> One toggle should be sufficient, they can afterall do a per-application
> text-attribute selection if they bring up the application specific orca
> settings.
> 
> 
> Also for minimizing verboseness (if they have selected minimal verboseness:
> 
> When the target is a single word then we drop the end attribute announcement?
> taking the example from above:
> 
> "this is some [bold]text with some [red]attribuutes."
> and we extend to use the full announcement when the attribute change spans more
> than one word boundary.
> i.e. we still wish to hear:
> "this is some [bold]text with[regular] some [red]attribuutes inn [black] a
> slightly longer paragraph."
> 
> Mike, what do you think about this less verbose alternative?
I like this idea.  It's timely as we have long had verbosity settings in orca which we really haven't used.  In the orca team meeting the other day we decided that I would spend some time improving verbosity for orca 2.24.  After CSUN I'd like to have a group chat about verbosity.  Would you be interested in a discussion in the orca chat room on this topic perhaps the week of March 17th or March 24th?  
thanks 

(In reply to comment #3)
> Jon, folks are going to start thinking that I'm paying you to submit these
> RFEs.  Check's in the mail, by the way. <grin>

:) thanks, but we are both open sourcers
Its you who is deserving of the money, im only bug tracking.

> This is a topic I periodically bring up (and did just the other day).  As you
> indicate, having to move to each bit of text that you suspect has a certain
> format and then ask for that format is not efficient.

yep indeed :) it was from the conversation that i picked this up, and since it was a few days ago and I still hadnt seen any feature request put in for it, i took the liberty to put it in myself.

It also fits in with my current procrastination attempt to organize my lecture notes in tomboy.

> Plus, you have to
> suspect that text needs to be checked.  (i.e., given the inefficiency of the
> current process, you're likely to verify that you made the important text bold,
> but less likely to check that you didn't accidentally make something else bold
> because you got distracted).
> I like your idea, and Mike's follow up suggestion.  I'm wondering, however, if
> we want three levels instead of two:  Basic, Detailed, and The Kitchen Sink. 
> Basic and Detailed are what you describe in your opening comment and should
> more than meet the needs of documents that you are creating yourself.  When
> collaborating on documents with others, however, it's hard to known what
> formatting they may have used.  For instance, I personally never use
> strikethrough or font colors.  Therefore, I wouldn't bother to have these items
> checked in my list of text-attributes I care about.  Other people might give me
> a document that uses these things, though.  And if I edit (or copy and paste)
> text with that formatting, I am in danger of applying that formatting in places
> I did not intend.  So the Kitchen Sink option would allow me to find this
> information while proofreading without having to modify my preferred text
> attributes to include every possible attribute.

hmm, yes, this kitchen sink idea is a very valid one, sorry for not spotting it earlier.
Then i guess the argument could be to have the full proofread (where all attributes+indentation is considered) and the basic one, where the only once that are announced are those attribs which are selected.
i.e. the advanced one is now our basic, and the kitchen sink is our advanced.
Trying to keep the number of functions that the user is exposed to, to a minimum.

> The other notion I've toyed with in the past is a way to get a list of text
> that has attributes other than the default ones.  That way you don't have to
> read over the whole document looking for purple, blinking, shadowed text from
> your wacky colleague.  You could just ask Orca.

an attribute search thing? (yes it would be very useful!)
i.e. colleague said that they have marked disertation ;) comments in pink, and we have to find all those.

> Anyhoo, just some ideas I figured I'd toss out....

lots of great ideas! but who ends up trying to implement them :)

I would love to contribute where possible, but I'm affraid I dont use gaim and not familiar with irc chat clients.
I will try in the meantime to find something usable.
assuming ill get something going, either date is fine by me

Hi Mike,

Hope you and the team had an excellent time at CSUN.

Did you want the chat about verbosity this week or next? and if so what day/time(GMT)?

Thanks

Hi Jon, I think I'm not going to get this together this week.  Lets set this up for early next week.  When I clear my head I'll send a message out to the orca users list for comment in a day or so.  

we seem to have had a lot of recent traffic on the mailinglist with regard to verbosity of attribute changes and additional information that might be useful when proofreading documents.

Might we consider specking out some of the needed interaction?

Thank you

Thanks for filing this bug.  Please feel free to add any comments you feel are important here and I'll migrate them to the spec section of the wiki when I get a chance.  

We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place.  Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.

I'll give this one a try.  I also would love to have a feature like this.  However, I think the attributes page should maybe have a set of options similar to that used with the Orca+F key so the attribute selections spoken could be different for the hot key and different yet for the reading down through the document.  I would also like to include tracking of style changes in OOo Writer so Orca would automatically speak when you pass over a header, like it now does for tables.  I don't want to cause scope creep with this bug so we should probably make a list of items and work them like sub tasks or break up the bug into separate implementations.  I say this because I would also like to see Firefox navigation to include the notification of crossing into and out of tables like OOo Writer presently does.

After reading this again, I'm thinking like an anew column could be added to the text attributes page and use it for document reading or scrolling.  Just check the items you would want to hear while rolling down through a document with the down-arrow key.  You've already got the attributes listed so just add the column say, after the braille column and go from there.

I would be interested in this one so feel free to assign to me.

*** Bug 620108 has been marked as a duplicate of this bug. ***