I would prefer that the embed characters, if they are next to one another, share a range of attributes.
Thanks, RG -----Original Message----- From: Alexander Surkov [mailto:[email protected]] Sent: Tuesday, May 18, 2010 11:13 AM To: Rob Gallo Cc: James Teh; IAccessible2 mailing list; Joanmarie Diggs Subject: Re: [Accessibility-ia2] Fwd: text attribute range calculation Rob, sorry I didn't get you. The second method: combine embedded characters into one range (that's you suggested). The third method: every embedded characters has own range. What is your preference? I'll do implementation and send a build to Joanie so we can see if there is negative impact on out-of-process clients. And if everybody will be happy then we'll request changes in IA2 spec to reflect this. Sounds good? Alex. On Tue, May 18, 2010 at 11:50 PM, Rob Gallo <[email protected]> wrote: > 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
