Hi Alex, I am very concerned about the possibility that the returned range of offsets might not include the requested offset. This has caused us problems in the past with word offsets and the like, and while this is a bit different, it feels bad to me. :)
Unfortunately, I don't really have any other options which don't involve having separate attribute runs for at least some embedded objects. For example, one possibility is to always include embedded objects at the end of an attribute run, but this breaks when there is an embedded object char at offset 0. Jamie On 15/04/2010 5:04 PM, Alexander Surkov wrote: > Hi. > > I have a question how to calculate text attribute range when embed > characters are presented within hyper text accessible. > > Aaron Leventhal suggested to not look into embed characters when text > attribute range is calculated so that, for example, if text attribute > value is changed inside an embed character then it doesn't affect on > result range. For instance, let's we have "abc*def", where '*' is > embed character. If "abc" and "def" have default formatting then range > should be (0, 7), i.e. it includes "abc*def" entirely. Also Aaron > pointed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=445677 > that NVDA is fine with that and we need to check with other AT vendors > if it works for them as well. That's the first part of my concern. > > The second part is what range the embed characters should belong to (I > assume everybody is ok that embed character doesn't break text > attributes range). > > Let's consider an example: > > *plain*plain**bold*bold* > > where * is embed character, plain is plain text (with default > formatting), bold is bold text. > > I can think of the following approach. > > 1) Start offset of the range equals to > a) offset of the first (counting from left to right) embed character > after the text where text attribute value is changed > b) offset after the last character of text where text attribute value > is changed if there is no preceding embed characters > c) 0 offset otherwise > > 2) End offset of the range equals to > a) offset of the first (counting from left to right) embed character > before the text where text attribute value is changed > b) offset of the first character of text where text attribute value is > changed if there is no preceding embed characters > c) otherwise offset of last character of the hypertext accesible > > For example, > > For example, > 0 as start offset and 12 as end offset is returned for the following > offsets: 0 offset (1st embed char), 1 offset ('p' of first 'plain'), 6 > offset (2nd embed char), 12 offset (3d embed char), 13 offset (4th > embed char). > 12 as start offset and 24 as end offset is returned for the following > offsets: 14 offset ('b' of first 'bold'), 18 offset (5th embed char), > 23 offset (6th embed char). > > In the other words start offsets starts from embed characters, end > offsets ends before embed characters (if embed char is not last > character of hypertext accessible). However this approach confuses me > because start and end offsets may not include the given offset, for > example, (0, 12) is returned fro 13 offset. > > What do you think? > > Thank you. > Alex. > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 -- 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
