Accepting with tentative target milestone 'OOo 1.1 Beta2'.

Hi Eike, Karl,

After I've provided mapfiles for the libraries in all 3 modules, the
combined size of all libi18n*.so, liblocaledata*.so libraries decreased
by ~2 Megabyte. As some combination of these libraries is always loaded
during SO / OOo startup, this will help reducing the startup time.

Unfortunately, I discovered the following issue only when linking the
'libi18n' from module 'i18n' (the one of 'i18n_simple' has no issues).

Though 'i18npool' is supposed to be a UNO component (implementing
more than 100 services), 'libi18n' links against 'libi18npool' to
import private (implementation) functionality of 'libi18npool'.

This is not only poor style, but also a maintenance nightmare (you
can't simply fix / change a services implementation in i18npool,
though the public API is not affected).

There are two independent issues:

1) i18n/source/GNUcollator/GNUcollator.cxx directly imports (via a
'new Transliteration_caseignore()' statement) the implementation
class of the corresponding service in i18npool.

As 'class GNUCollator' itself is a UNO service implementation of
interface XCollator, this issue could be fixed using the official
'component' way, i.e. keep a reference to the XMultiServiceFactory
(alias 'service manager') that should be passed to the constructor
of any service implementation, and just create an instance of the
'transliteration_caseignore' service, as everyone else needs to do.

2) i18n/source/search/exprclas.cxx directly imports the 'unicode::*'
static helper functions from i18npool.

As these 'unicode::*' functions are nicely encapsulated and obviously
useful in at least two places, this issue could be fixed by moving
this functionality out of 'lib18npool', and provide it as it's own
shared library (with C++ exports, no mapfile required for now). This
library should then be delivered by 'i18npool', and both 'i18n' and
'i18npool' would import it. A name for this that came to my mind
was 'libi18nutil'.

I do understand that these issues most probably originate in the
history of the i18n/i18n_simple/i18npool modules, and how the code
needed to evolve.

However, as my proposed changes do have non-neglectable benfits, I'd
like to see these issues fixed, if at all possible on childworkspace
tag 'cws_srx644_tune01'.

Comments welcome,
Matthias

Hi Matthias,

For first issue, the API used by GNUcollator is not a public API, 
that is why we could not use UNO service. Since this is a temporary 
solution, we will remove GNUcollator and use one from ICU eventually. 
I am waiting for test case from Eike and hopefully we can remove it 
from beta2.

For second issue, I have extract Unicode::* from i18npool and create 
new share library i18nutil. I need scp module to add new binary file 
for installation.

Karl.

Hi Karl, Eike,

Regarding the first issue, yes, I've obviously missed the fact that
'getNextChar()' is not in the 'XTransliteration' interface (though the
header file suggested exactly that with 'throw uno::RuntimeException').

What's your estimated time frame for removing this hack (if it's at all
possible without exchanging the entire collator against the ICU one)?

I'm currently planning for reintegration into the master in about two
weeks time. Would that fit?

Regarding the second issue, I've already updated i18npool to your
changes, and they look good so far. I have also added 'scp' to the
child workspace.

But before you do the 'scp' changes, please rename the new 'i18nutil'
library into 'i18nutil$(COMID)'. As it doesn't export a compiler
independent C API, but a compiler dependent C++ API, it should be
decorated with the C++ compiler's name, i.e. 'libi18nutilC52.so' on
Solaris (Forte 5.2),  'libi18nutilgcc3.so' on Linux (GCC 3.x) and
'i18nutilMSC.dll' on Windows.

Sorry that I forgot to mention that in the first place.

Matthias

I introduced macro I18NUTILLIB in solenv/inc/libs.mk and
i18npool/util/makefile.mk, and added the $(COMID) to libi18nutil in
i18npool/source/utility/makefile.mk and solenv/inc/libs.mk

Also added the i18nutil library to scp/inc/gid.inc and
scp/source/global/setupzip.scp

Thanks Eike!

I could not remove GNUcollator since ICU collator could not handle 
ignore Karan at this moment, which make that we have to call 
transliteration to pre-process whole string and may cause performance 
drawback. We will figure out how to add ignore karan into ICU after 
6.1.

So I extract case/karan/width ignore from i18npool and put them into 
i18nutil which will be share between i18n and i18npool.

Hi Karl, Eike,

I guess, the original issue (missing mapfiles) is fixed by now (and
you're working on the other i18n related stuff on another workspace).

Thus, marking as 'resolved fixed'.

Thanks,
Matthias

Verified...

Verified integration into SRX644/m12s1 -> closing.