If there are two embed characters next to one another, I have no problem with having the plain attribute range include both of them. So, if I understand it correctly, I think your third method will be fine.
Jamie had some concerns about out-of-process clients, so I don't know how negatively this will impact them. However, if they're parsing attributes, they'll be making a lot of cross process calls anyway. Thanks, RG -----Original Message----- From: Alexander Surkov [mailto:[email protected]] Sent: Tuesday, May 18, 2010 9:52 AM To: Rob Gallo Cc: James Teh; IAccessible2 mailing list; Joanmarie Diggs Subject: Re: [Accessibility-ia2] Fwd: text attribute range calculation Hi, Rob. Aaron suggestion was like [*plain*plain**)[bold*bold*), which I come here with. Your suggestion was [*)[plain)[*)[plain)[**)[bold)[*)[bold)[*). My last suggestion (based on your suggestion) was [*)[plain)[*)[plain)[*)[*)[bold)[*)[bold)[*). The difference between two last suggestions is embedded characters are combined into one range or not. My suggestion is quicker supposedly if we don't think about method call cost (however in the end it might be slower of course). The same time I'm fine your suggestion and Jamie agrees it's correct. So let's choose one which you feel comfortable with. Thank you. Alex. On Tue, May 18, 2010 at 10:19 PM, Rob Gallo <[email protected]> wrote: > Alex, > > After rereading the thread, I'm still not quite sure where we left things. > Can you write up what you think should happen based on our comments? > Then we can all take a look and make suggestions as necessary. > > > > Thanks, > RG > > > -----Original Message----- > From: Alexander Surkov [mailto:[email protected]] > Sent: Tuesday, May 18, 2010 6:04 AM > To: James Teh > Cc: IAccessible2 mailing list; Joanmarie Diggs; Rob Gallo > Subject: Re: [Accessibility-ia2] Fwd: text attribute range calculation > > Hi, Jamie, Rob and all. > > We should come to either solution as soon as we can. We shouldn't hit > a mark by the first shoot. First of all let's figure out more > logically correct and handy solution. I'll implement it and provide > Firefox build for testing. If you and Jonaie will find performance > satisfactory then we hit a mark. If not then let's investigate deeper. > So, please say again which way do you prefer and I'll start working. > > Thank you. > Alex. > > > On Tue, Apr 27, 2010 at 11:04 AM, Alexander Surkov > <[email protected]> wrote: >> 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-i >>>> a >>>> 2 >>>> >>> >> > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
