Re: Any example of AtkDocument implementation?

Ashutosh asked about AtkText, and whether it would be better to
break a large document into per-paragraph AtkObjects (each of
which implements AtkText).

This is what we recommend (per-paragraph AtkObjects,
with AtkText support).  If these text objects are individually focussable,
then gnopernicus should "do the right thing" when focus changes.

I am actually dubious about whether obtaining the entire text content
of an object each time it's focussed is a good idea; that's a question for
the gnopernicus team.  But you are quite right in saying that reducing the
size of the text objects will help in this regard.

I answer in a little more detail inline:

I'm trying to make an OCR application. I'm
implementing AtkText for the same now. I'm confused about a new point now. If the page has a
lot of text, the get_text implementation is always
receiving a request with start_offset = 0 and
end_offset = -1 (from gnopernicus). In that case, I am
returning the entire page's contents.
So, every time the focus moves away and comes back to
the page, the entire contents are sent back.

This seems like a very inefficient operation, I agree.

Currently, the entire page has one associated
AtkObject. If I create an AtkObject for every
paragraph/line/word and implement get_n_children and
ref_child (setting their pointers in the class_init
function), can the screen reader request for the text
of one child at a time?
Yes, the screen reader can and should do this.

I mean, can I return only the appropriate AtkObject's
text, based on where the user has clicked. If the user
clicks inside a particular paragraph, only that
AtkObject's text is returned. How can this be done? Do
I need to implement AtkComponent?

Every object on the screen should implement AtkComponent.
But I don't think in this case that AtkComponent will be heavily
used by gnopernicus.  For blind users, the access to various
paragraphs will be via keyboard navigation in almost all cases.

Otherwise, what is the advantage of creating an
AtkObject for each paragraph/line/word as against
treating the entire page as one object?
I think you've answered your own question :-)
Seriously, this becomes an even more significant issue for
scrolling text, which could become way too cumbersome without some
sort of subdivision of the document.

best regards,



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]