1.a) There is only one call to SvTokenStream::SetCharSet
2.b) That call is from SvTokenStream::InitCtor and the argument is
   gsl_getSystemTextEncoding()

2.a) SvTokenStream::SetCharSet is the sole caller of SvChar::GetTable
   i.e.
   pCharTab = SvChar::GetTable( nSet, gsl_getSystemTextEncoding() );
2.b) so this is in practive only ever...
   pCharTab = SvChar::GetTable( gsl_getSystemTextEncoding(),
        gsl_getSystemTextEncoding() );

3) SvChar::GetTable returns a table for converting from one encoding to
   another.

4) so the whole thing is a no-op, i.e.
   pCharTab can be dropped
   SvChar::GetTable is then unused and can be dropped
   SetCharSet and GetCharSet are then also unused

When we draw this text we assume it's in RTL_TEXTENCODING_IBM_437 and convert
from RTL_TEXTENCODING_IBM_437 to unicode.

So why when we determine the width to use convert from RTL_TEXTENCODING_IBM_437
to the system encoding, which could be anything, and get the width of that ?

It depends on CPPUHELPERLIB which for iOS depends on BOOTSTRAPUNOLIB
which hasn't been built yet.

LGPLv3+/MPL

Since we now link to the (also static) bootstrap.uno component which
hasn't been built yet.

Murphy says it's the part that is dropped which will be interesting
one anyway.

Will be used for iOS at least.

Factor out the part of loadSharedLibComponentFactory() that handle the
symbol that has been successfully looked up.

it's rather weird to have only access to either date or time, but
not the whole object