Hi, Pete. Yes, it provides wrong information. At least it's not how IAccessibleText::caretOffset or selection works. But you're right we assume AT should check every embed characters separately when they met it.
Thank you. Alex. On Tue, Apr 20, 2010 at 7:52 AM, Pete Brunet <[email protected]> wrote: > 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 > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
