Re: PDF accessibility and complex script languages.

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.

On Mon, Jan 4, 2016 at 1:10 PM, Andrew Cunningham <andj.cunningham@gmail.com
> wrote:

>
> On 5 Jan 2016 7:25 am, "Duff Johnson" <duff@duff-johnson.com> wrote:
> >
>
> >
> > It’s typical for PDF consuming tools that extract or process text to use
> ActualText. Software that cannot process ActualText cannot be claimed to
> support accessible (i.e., tagged) PDF.
> >
> >
>
> I need to do more testing i suspect.
>
> Image with ActualText seems to work fine.
>
> Text AND ActualText combination seems to need more testing.  I need to do
> more testing of text extraction and searching. Even something as simple as
> cutting and pasting from a PDF seems to be problematic.
>
> When I have cut and pasted from a test PDF for instance the operation
> seems to occur at the glyph/text level, and not the ActualText.
>
> I guess i need to try alternative software. And map out what would work
> best for each language.
>
> Andrew
>