RBBI: if fBreakType not set and dictionary, Bad Things happen

Making setBreakType() public to allow external programs to set fBreakType themselves. We have done this in OpenOffice.org for line break.

See also http://www.openoffice.org/issues/show_bug.cgi?id=84467 that proposed a different approach to fix the issue.

Ticket 84467 from OpenOffice.org has a better fix than making setBreakType public.

The break type should not be settable by users after construction. OpenOffice.org's temporary fix is causing significant binary compatibility issues for ICU distributers.

Patch I made to allow OO.o to access setBreakType without rewriting ICU sources

I just attached a patch that will hopefully be a good example of how to work-around the problem (and allow access to RuleBasedBreakIterator::setBreakType(type)) without going in and munging the rbbi.h header file, with drastic consequences!

Under FreeBSD, the "fix" produced by the OO.o team has rendered OO.o un-buildable if a user has also installed icu from ports (as needed with the latest GNOME). The above fix can be applied to the OO.o sources. The check for a public setBreakType in configure can be removed, and OO.o with build again against the system's ICU (--with-system-icu=yes configure arg).

I recommend that anybody else who's experiencing the same bug should try implementing a similar work-around in their own sources (rather than editing ICU) until the problem is resolved.

The original problem that led to filing of this bug is no longer present - that is, all of the relevant code checks for fBreakType being out of range and handles it appropriately (there is still no way to set fBreakType for a BreakIterator created using "new RuleBasedBreakIterator()" but it is not clear that is desirable anyway.

What does remain as a possible issue is that the break iterator machinery does not cope with fData being NULL, which would happen as a result of doing something like the following:

UnicodeString text= ... BreakIterator* b = new RuleBasedBreakIterator(); b->setText(text); int32_t p = b->next();

Here, the call to next() will crash. This doesn't really make sense anyway since there are no rules. But if desired it could be fixed with some NULL tests on fData.

Based on this, downgrading from critical to major (could go lower).