We get more similar linking errors elsewhere anyway. We would need a
more generic fix. As for now, just apparently not possible to build
with the LLVM g++ from Xcode 4. Use g++-4.2 / gcc-4.2 if you want ot
use Xcode 4. But note that for Xcode 4.2, you might need to do:

ln -s i686-apple-darwin10 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin11

This reverts commit f3e10529.

i.e. font names are often typically in English, so fairly useless
to take the English name to preview what effect the font will have
in a CTL/CJK script.

More languages and scripts need to be added, but this should be
sufficient to bootstrap this up

it seems that the heuristic to trigger the inflate hack from frob is both wrong in the code ( my fault ) and additionally doesn't always hold true ( found a document where the heuristic is triggered falsely ) So. removing that heuristic entirely for now

Seems the graphic load code is stupid and not using the path name /
file extension to guess file type, but only "magic byte" detection.
Giving filter framework the path now, so that .svg actually loads.

Merge of dev300 broke this - we *do* want import to call this
implImport() actually. Also, the service names were bogus
previously.

Previously, svg images were always wrapped as .svm metafiles with
a preview graphic. Sucks for interop - so now, we save true svgs
at least for bleeding edge extended odf1.2

It can happen that the ure-link symlink shall be created while its
parent directory has not yet been created.  The logic in the Perl code
is so confusing and beyond fixing, that an easy hack out was to flag
the respective directory as always-CREATE, which kind of works around
the problem.

The Windows-only code in pyuno/zipcore/python.cxx may still need fixing.

...e.g., with "import uno" in a stand-alone pyhton process (where it
is hopefully harmless that UNO does not get access to any -env
command line args).

Moved uno ini, folded fundamentalbasis ini into fundamental ini, merged
version inis.

check InsertTabs/InsertTab/DeleteTabs too

Apparently there are two style flags for detecting the widget
is horizontal.