Date: Thu, 1 May 2008 01:50:03 GMT From: Marcin Cieslak <saper@SYSTEM.PL> To: openoffice@FreeBSD.org Subject: Re: [icu-support] [Fwd: Re: ports/121787: when devel/icu is installed, openoffice fails to build] Message-ID: <200805010150.m411o3Lf007765@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/121787; it has been noted by GNATS. From: Marcin Cieslak <saper@SYSTEM.PL> To: "Steven R. Loomis" <srl@icu-project.org> Cc: ICU support mailing list <icu-support@lists.sourceforge.net>, cokane@freebsd.org, bug-followup@freebsd.org, George Rhoten <grhoten@gmail.com> Subject: Re: [icu-support] [Fwd: Re: ports/121787: when devel/icu is installed, openoffice fails to build] Date: Thu, 01 May 2008 03:45:56 +0200 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48EE52BC953722DF5355A8A3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Steven R. Loomis wrote: > There is a temporary patch at >=20 > http://bugs.icu-project.org/trac/ticket/5498 >=20 > , but longer term, setBreakType() should not be called from a parent=20 > class or a subclass. >=20 > Instead, use >=20 > BreakIterator::create*Instance(=E2=80=A6)=20 > http://www.icu-project.org/apiref/icu4c/classBreakIterator.html >=20 > You could call it from within a switch statement. >=20 > or the parameterized (in C) >=20 > ubrk_open( UBreakIteratorType =E2=80=A6 )=20 > http://www.icu-project.org/apiref/icu4c/ubrk_8h.html >=20 > ICU does not need to be modified for this case. In some cases, OpenOffice.org loads pre-compiled rules (for example,=20 there are three different word iteration modes, with exceptions for some = languages). Source for those custom rules is here: http://l10n.openoffice.org/source/browse/l10n/i18npool/source/breakiterat= or/data/ (dict_word_xxx, edit_word_xxx, count_word_xxx indicate different word=20 iteration modes). OOo function loads binary images on demand in a similar way as this is=20 done in BreakIterator::buildInstance: UDataMemory* file =3D udata_open(U_ICUDATA_BRKITR, ext, fnbuff, &sta= tus); if (U_FAILURE(status)) { ures_close(b); return NULL; } // Create a RuleBasedBreakIterator result =3D new RuleBasedBreakIterator(file, status); // If there is a result, set the valid locale and actual locale,=20 and the kind if (U_SUCCESS(status) && result !=3D NULL) { U_LOCALE_BASED(locBased, *(BreakIterator*)result); locBased.setLocaleIDs(ures_getLocaleByType(b,=20 ULOC_VALID_LOCALE, &status), actualLocale); result->setBreakType(kind); } OOO.org bundles a version of ICU 3.6. I think that similar problem was already discussed there: http://www.nabble.com/Minor-changes-needed-to-ICULanguageBreakFactory-(IC= U4C)-td10069414.html Can we achieve loading custom rules and have them still bound with=20 locale and break type information in some elegant way? Is there any way we can use "ICULanguageBreakFactory" for this? Or maybe = the above-quoted interface from BreakIterator::buildInstance() could be=20 somehow exposed (we supply complete UDataMemory* structure)? The code doing this is here: http://l10n.openoffice.org/source/browse/l10n/i18npool/source/breakiterat= or/breakiterator_unicode.cxx?rev=3D1.34&view=3Dmarkup I have started scribbling some notes on this: http://wiki.services.openoffice.org/wiki/LoadICUBreakIterator I might have missed something obvious, though. --Marcin --=20 << Marcin Cieslak // saper@system.pl >> --------------enig48EE52BC953722DF5355A8A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSBkg1z2W2v2wY27ZAQOMpgP/bxG+wJB97tugoLiWnDju4vYIbTAYUkvn PzN0Vz6Iu/KkdMlyLMCIqQYiqsS1IxGmsT6sgX4jgHYRyiCstSThExF0Y2rCPomA b9OdYRomS8cy/RpRQi5HEXg+8kbFQY6iZVNzQpHjRbATDBQxBfKFmRBnJ8Yi0Tpj 6wrlF7L+Sco= =9kuP -----END PGP SIGNATURE----- --------------enig48EE52BC953722DF5355A8A3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805010150.m411o3Lf007765>