Thanks Loretta, That is useful to know and makes sense that for accessibility API, ActualText is used. Makes sense since ActualText is text, while "text" is more accurately a glyph stream rather than text per se. I suspect search and cut and paste may be in the two hard basket ... not sure if it is feasible or possible to use ActualText for cut and paste operations since there isn't necessarily anyway of linking a sequence of glyphs to specific grapheme clusters, let alone constraining selection of glyphs t meaningful sequences.. It might be possible to search ActualText but highlighting search results within a document would suffer from similar limitations ... unless tagging was done grapheme cluster by grapheme cluster but that level of tagging (equivalent of syllable by syllable tagging in European languages) would be overkill. It would appear that best approach would be to use ActualText. Does anyone know of a tool that can be used to edit or create ActualText for each tag? Something with a streamlined and user friendly editing UI for ActualText? Andrew Andrew Cunningham andj.cunningham@gmail.com On 5 January 2016 at 08:17, Loretta Guarino Reid <lorettaguarino@google.com> wrote: > For the accessibility API, ActualText will replace whatever it is an > attribute for, including glyph/test content. > > However, I do not know whether search or cut/paste support the use of > ActualText, and I would not be surprised to learn that they do not. If they > do not, you should definitely file a bug. > >
Received on Monday, 4 January 2016 23:15:01 UTC