Bill, A smart sentence divider will not stop at Mr.
It doesn't need to be fast, it only needs to keep up with the reader. - Aaron Bill Haneman wrote: > Aaron Leventhal wrote: >> I think SENTENCE support should be removed, and the rest kept. The >> rest are usually already implemented in some form by the app. >> >> Sentence can be implemented by the AT if it really needs it. > I think this would be inefficient, since one never knows how many > lines/words/etc. are required before a sentence-ending mark is > encountered. >> I don't want to have to deal with the i18n issues here. > I think they are not so difficult, except for languages where they are > impossible. For the latter case, we need to define what the API > returns (i.e. what do we return if the locale doesn't really support > sentence end marks). >> Also the AT needs consistency and every app will do this differently. > Really? I don't see a lot of inconsistency in the current SENTENCE > support - for English, we have a few well-defined sentence end > markers: ".!?", and SENTENCE blocks don't span 'paragraphs'. Why is > it any harder for the app than for the AT? > > Bill >> >> - Aaron >> >> >> >> >> Bill Haneman wrote: >>> Peter Korn wrote: >>> >>>> Hi guys, >>>> >>>> In addition to the discussion about state deprecations, I'd like to >>>> give another kick to the apple cart - keeping/removing some of the >>>> text range constants. I put the letter/word/line/sentence stuff in >>>> in the first place, thinking it'd be useful for several AT use >>>> cases and trusting that the Java parsing support for those chunks >>>> would do the right thing. >>>> >>>> Alas, as Harald points out supporting this generally (especially >>>> sentence) is a right pain. And I have a feeling that screen >>>> readers aren't using this API. So, while we are in a deprecating >>>> mood, perhaps we should deprecate this too? >>>> >>> I am not in favor of this removal. It's actually much easier to >>> implement in most cases than "LINE", and we need to keep the old >>> ones around for back-compat guarantees anyhow. >>> >>> I think a good case can be made for retaining this for 'talking >>> book', page-reading, and similar use cases (i.e. meta clipboard apps >>> that cuts one sentence, etc.) >>> >>> regards >>> >>> Bill >>> >>>> Regards, >>>> >>>> Peter Korn >>>> Accessibility Architect, >>>> Sun Microsystems, Inc. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> Subject: >>>> Re: [Accessibility-ia2] Suggest remove IA2_TEXT_BOUNDARY_SENTENCE >>>> From: >>>> Harald Fernengel <[EMAIL PROTECTED]> >>>> Date: >>>> Fri, 19 Jan 2007 11:24:35 +0100 >>>> To: >>>> [EMAIL PROTECTED] >>>> >>>> To: >>>> [EMAIL PROTECTED] >>>> >>>> >>>> Hi, >>>> >>>> On Thursday 18 January 2007 21:30, Aaron Leventhal wrote: >>>> >>>>> Application internals almost never have support for this, and >>>>> developers >>>>> will have to do lots of extra work to support it. Very difficult to >>>>> implement given I18N. >>>>> >>>>> I don't believe this is something the AT wants to have the app >>>>> support >>>>> for just accessibility, because the support will end up being >>>>> incorrect >>>>> or very different between implementations. >>>>> >>>> I agree to this, I'd love to see Sentence go. It's not only a >>>> nightmare to implement, it can also lead to obscure bugs with >>>> languages that don't have a concept of "sentence". >>>> >>>> Harald >>>> >>>> _______________________________________________ >>>> Accessibility-ia2 mailing list >>>> [EMAIL PROTECTED] >>>> http://lists.freestandards.org/mailman/listinfo/accessibility-ia2 >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Gnome-accessibility-devel mailing list >>>> [email protected] >>>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>>> >>> >>> _______________________________________________ >>> Gnome-accessibility-devel mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >>> >>> > > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
