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.
>
>