I think I'm fine with Rob suggestion. It's even easier from implementation point of view. And AT doesn't need to traverse the string between offsets to find embed characters to query attributes for it.
However please you consider to have own range for every embed characters like [*)[plain)[*)[plain)[*)[*)[bold)[*)[bold)[*) The reason of the suggestion is the following. I'm not sure embed characters follows each after other in the rich text too often. Usual case is: <p>This is a text with a <a>link</a>. This is a picture <img src=""></p> But if we deal with text containers that contains a structure elements rather than text then embed characters will follow each after other. <body> <p>halla</p> <p>hdfdf</p> </body> We should traverse all paragraphs to include into text attribute range (since they are embed chars). If the document has one million of paragraphs then it shouldn't be very performant. Thank you. Alex. On Sat, Apr 17, 2010 at 5:27 PM, Alexander Surkov <[email protected]> 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
