Hi, Pete. 1) I'd say S_FALSE because there no lexem was found.
2) "In the preceding sentence the offset at the start of a word is considered to be inside the word." -> (I'd have more precise version or something similar) "All offsets enclosed between (including) start and end word offset are considered inside word offsets". Thanks. Alex. On Tue, Apr 30, 2013 at 12:29 AM, Pete Brunet <[email protected]> wrote: > > On 4/28/13 9:41 PM, Alexander Surkov wrote: > > Hi, Pete. > > If the string consists of spaces then ATK get word at offset "will contain > the word after to the offset if the offset is not inside a word". In this > case there are no words so I think (0, 0, "") triple is returned. However > ATK is not really clear (see for example > http://asurkov.blogspot.ru/2013/04/atx-text-pitfalls.html) to state it > certainly. > > > Returns the substring of the specified text type at the specified > > offset. Refer to IA2TextBoundaryType for more details. > > I'd changed that to "Returns the substring defined by specified text type > at the specified offset. Refer ...", otherwise it makes me think that > "word" should be returned in case of word type when offset is outside the > word. > > > For the word boundary type if the offset is not at the beginning or > > inside a word the returned string will contain the word before the > > offset. > > Offset at the beginning a word is also an offset inside a word. But > actually I like ATK wording: > "The returned string will contain the word at the offset if the offset is > inside a word and will contain the word before the offset if the offset is > not inside a word." > > Thanks Alex, > > I need input from everyone on how to handle the case of text completely > full of whitespace when the text boundary is anything but character. > > Options: > 1) S_FALSE plus 0, 0, NULL pointer > 2) S_OK plus 0, 0, "" > > Although today's text is not clear enough the first one is how I expect > people currently interpret the spec. > > Here another draft, assuming #1 above. I don't want to change the > behavior of the empty text scenario if AT are already relying on that > behavior. > > Returns the substring defined by the specified boundary type at the > specified offset. Refer to IA2TextBoundaryType for more details. > > For the word boundary type the returned string will contain the word at > the offset if the offset is inside a word and will contain the word before > the offset if the offset is not inside a word. In the preceding sentence > the offset at the start of a word is considered to be inside the word. > Boundary types of sentence and paragraph should exhibit similar behavior. > > If the index is valid, but no text is found, S_FALSE is returned along > with out values of 0, 0, and a NULL pointer. This would happen for > boundary types other than character when the text consists entirely of > whitespace. > > Do you have any comments regarding the before/after methods? > > Pete > > > > > 2) If the given offset is a word start then Ctrl+left arrow and Ctrl + > > > right arrow return a previous word. Should an order be opposite > > > instead since it contradicts to getTextAtOffset semantic? > > > > I didn't follow that, e.g. why should ctrl+rightArrow move to the > > previous word, but hopefully the above rewording will address your issue. > > Yes, it address. > > Say the caret is right before 'w' in "Hello world". If you press > ctrlLeft+sfhitCtrlRight then you select "Hello ". If you do an opposite > thing "ctrlRight + shiftCtrlLeft" then you select "world". So the order > makes a difference. Getting back to the spec the "world" is wanted however > the spec says to return "Hello ". > > Thank you. > Alex. > > > On Sat, Apr 27, 2013 at 2:12 AM, Pete Brunet <[email protected]> wrote: > >> >> On 4/16/13 1:29 AM, Alexander Surkov wrote: >> > Hi. There are couple issues with IAccessibleText spec. >> > >> > 1) IAccessibleText::getTextAtOffset interface wording is a bit >> > confusing [1], it says: >> > >> > "If the index is valid, but no suitable word (or other text type) is >> > found, a NULL pointer is returned." >> > >> > This makes me think (presumably makes me think wrong) that if the >> > offset is outside the word then there's no suitable world. However the >> > boundary types part says [2]: >> > >> > "The range provided matches the range observed when the application >> > processes the Ctrl + left arrow and Ctrl + right arrow key sequences. >> > Typically this is from the start of one word to the start of the next". >> > >> > It means the previous word should be returned. >> > >> > Notes: >> > >> > a) A word start boundary from ATK (an analogy to IA2 word boundary) >> > says to return previous word as well [3]: >> > >> > " will contain the word before the offset if the offset is not inside >> > a word." >> > >> > b) Firefox returns previous word in this case too. >> > >> Hi Alex, What does ATK do when the text area is full of spaces and no >> other text? That seems like the case where S_FALSE and NULL would be >> returned (except in the case of IA2_TEXT_BOUNDARY_CHAR/ALL). >> >> How about this rewording? >> >> Returns the substring of the specified text type at the specified >> offset. Refer to IA2TextBoundaryType for more details. >> >> For the word boundary type if the offset is not at the beginning or >> inside a word the returned string will contain the word before the >> offset. Boundary types of sentence and paragraph should exhibit similar >> behavior. >> >> If the index is valid, but no suitable text for the specified boundary >> type is found, a NULL pointer is returned. This would only happen for >> boundary types of word, sentence, and paragraph when the text only >> consists of spaces. >> > >> > >> > 2) If the given offset is a word start then Ctrl+left arrow and Ctrl + >> > right arrow return a previous word. Should an order be opposite >> > instead since it contradicts to getTextAtOffset semantic? >> > >> I didn't follow that, e.g. why should ctrl+rightArrow move to the >> previous word, but hopefully the above rewording will address your issue. >> > >> > ATK says to return this word (i.e. the offset it belongs to), Firefox >> > does it in ATKish way. >> > >> > >> > [1] >> > >> http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_text.html#a9bd84b099ac7ce2435280549e90c8827 >> > >> > [2] >> > >> http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_accessible_text_8idl.html#ad3da05c9bed9f44b1e52eb4adb2924f6 >> > >> > [3] >> > >> https://developer.gnome.org/atk/stable/AtkText.html#atk-text-get-text-at-offset >> > >> > >> > Thank you. >> > >> > Alex. >> > >> > > > -- > *Pete Brunet* > > a11ysoft - Accessibility Architecture and Development > (512) 467-4706 (work), (512) 689-4155 (cell) > Skype: pete.brunet > IM: ptbrunet (AOL, Google), [email protected] (MSN) > http://www.a11ysoft.com/about/ > Ionosphere: WS4G >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
