Alex, given the string abc*def why don't you have to walk into the child node? If the attributes are different in the child node then the AT is getting bad information.
Or does the AT use this information only trusting that at least the abc and def have identical attributes and that further investigation of the child node is needed? Assuming that is the case then I don't think it matters how you break up the runs and the fewer the better. So I approve of your proposal of limited ranges where leading embeds are included in a range of following text and any embeds at the very end are included in the last range, e.g. two ranges for [*plain*plain)[**bold*bold**)* where [ is the start and ) is the end of the range. Pete === Alexander Surkov wrote: > Hi, Jamie. > > Yes, it affects on ATK as well. And it's worth to note that now > Firefox text attribute implementation is very slow on big documents. > So it might make sense to care about how to decrease number of calls. > > I cc'ed Joanie originally but eventually her email was lost from the > thread. Cc'ing again. > > Thank you. > Alex. > > On Sat, Apr 17, 2010 at 5:08 PM, James Teh <[email protected]> wrote: > >> On 17/04/2010 5:28 PM, Rob Gallo wrote: >> >>> This issue is a tough one. I would like to suggest yet another approach >>> where embed characters would have their own ranges, and those ranges should >>> basically return an empty attribute string, or a string that would amount to >>> plain text. >>> >> In principle, I totally agree with you. However, the problem is that >> this requires clients to make many more calls to >> IAccessibleText::get_attributes() than they would with the other >> approach. This isn't such an issue for in-process clients, but it most >> definitely a performance penalty for out-of-process clients. This will >> affect NVDA to some extent (we have a sort of hybrid of in-proc and >> out-proc stuff). However, if I'm not mistaken, this change will also >> affect ATK clients (all out-of-process), as the cross-platform layer >> implementation will be the same. Alex, am I correct here? >> >> Having said that, if I understand correctly, Firefox is already exposing >> these as separate ranges (even descending to get the formatting), so >> maybe this isn't such an issue. However, on a big block of text with >> lots of embedded objects, it could get a bit nasty. >> >> >>> Here's why: embed characters aren't, strictly speaking, text. They >>> represent objects which contain their own text. And the text of the target >>> objects should have their own attributes. If the object that contains the >>> embed character and the target object have differing sets of attributes, >>> that leads to confusion. >>> >> The idea that Aaron Leventhal proposed was that ATs should just ignore >> the formatting for the embedded object characters, as it has to descend >> to get the formatting anyway. It is done for the purpose of optimisation >> only; as I said, I totally agree with you in principle. This >> *definitely* needs to be very well documented if it is going to happen. >> >> Alex, if this is going to affect ATK as well, we should probably pull >> Joanie and maybe others into the discussion. >> >> Jamie >> >> -- >> James Teh >> Vice President >> NV Access Inc, ABN 61773362390 >> Email: [email protected] >> Web site: http://www.nvaccess.org/ >> _______________________________________________ >> Accessibility-ia2 mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 >> >> > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
