Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I1f69b29a34efee5577e513282d32c52963793361
|
|
We now have a single libexpat instead of libascii_expat_xmlparse and
libexpat_xmltok. Hmm, no idea when that changed, but OK, that just simplifies
the fontconfig patch. (Note that the bundled fontconfig is used only for
Android.)
Change-Id: I3973d35a566bd3c86b013c96b7f3a6a8e249c2c0
|
|
This reverts commit 78c7bbc3ce92493ca98c605f92733e31ad87ef70.
It is no longer the case that both expat_utf8 and expat_utf16 are linked
into the same library: we only use expat_utf16 in shell Explorer
extensions, which cannot be linked into libmerged anyway.
Conflicts:
expat/expat-2.1.0.patch
Change-Id: I579c10d405d8a40cafcb2dbe09e967c6079f7b16
|
|
We need to be able to link both into one binary in the
disable-dynloading case.
Change-Id: I499e204dfef2af488d4a350cb3a5bcfc03ca887f
|
|
Change-Id: I6fa2b9a50c525fb2d8666a144409eb9a3ad2698a
|
|
Sigh, spent one day, more or less, tracking down a weird fontconfig
problem, where all the diagnostic it offered was "unknown encoding"
when reading the fonts.conf file.
It turned out that I was being screwed by our fun two versions of the
expat_xmlparse library: One where XML_Char is char and one where it is
short. The intuitively "more normally" named libexpat_xmlparse is the
latter, but fontconfig works only with the former as it implicitly
expects XML_Char to be char.
|
|
|
|
It will probably be simplest to just use FreeType on Android,
too. (Android uses it itself, but doesn't provide its API publicly.)
Probably fontconfig, too, although there shouldn't be much
configuration per se that a LibreOffice-baed app would have to do at
run-time; it will have to bundle all fonts it is going to use anyway,
I think, so all font information is known a priori. But maybe in the
future there will be user-installable system fonts on Android, or
something.
|