Ok. I don't mind. Thanks. Alex.
On Wed, May 19, 2010 at 12:49 AM, Rob Gallo <[email protected]> wrote: > 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
