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.
Formerly PRODUCTVERSION was used but that did not contain
the microversion digit. It is better to have it in MSI
ProductVersion, because a higher build number of a lower
microversion looked newer from the MSI point of view, and
update failed.
MSI ProductVersion is now major.minor.micro.build, e.g.
3.6.1.1206 (build number is taken from minor.mk)
+ added ProductName (a required parameter), It is LibreOffice
+ CompanyName is configurable, it is $(OOO_VENDOR), that is set
--with-vendor configure switch. If not set, then CompanyName is
empty string which is fine, too.
+ Binary file version and FileVersion string show the same value,
and version number is sane: main version + subversion + microversion
+ build number, such as 3.5.0.0
+ LegalCopyright text is the same as in the About box, year range
can be set in minor.mk
- removed archaic and overcomplicated version number calculating macros
- removed version.lst, copied relevant content to minor.mk
- removed binary RCDATA resources, I don't think they were of any use
In case the data source has a formula cell, the number format may be
inferred from the formula result in case the cell format is General.
Also,
1) no need to use UNO API in the API implementation. Let use the
internal API here.
2) this method didn't take into account the hidden cells.
TODO: We need to handle number formats for external ref data properly.
We dump the library's symbols we're trying to stubify, and then
assemble another library that looks just like it, except with all
of it's innards sucked out.
We also use pkgconfig to find all the relevant dependencies and
to build an entire library tree.
Catalan (Valencian) has no ISO 639 code assigned and the UI localization uses
the ca-XV hack where XV is of the reserved ISO 3166 user-assigned range. This
should not escape to document content therefor internally a replacement to
ca-ES is done for all locale attribution. For the UI localization to be
distinguishable under Tools->Options->LanguageSettings->UserInterface this
needed a special handling to allow Catalan (Valencian) again.
Setting a page-anchored object to cell-anchored didn't show the anchor
immediately until you unselect the object and re-select it. Same for
the cell-anchored to page-anchored direction.
This commit fixes it.
Currently on File->Properties we display "LibreOffice 1.0 Text Document"
etc. for OpenOffice.org XML format documents, which is wrong: these
should not be re-branded.
This should fix the spurious segfaults caused by running the test while
the library is being overwritten in parallel that cannot be reproduced
by just running the test.
CLASSPATH is supposed to show where to find the classes needed by Java
programs running at build time. The -cp switch to javac tells where to
find classes referenced by the code being compiled. These are
different things. (But it doesn't seem to have mattered much in our
build system.) So use T_CP instead, named in the same fashion as
T_CXXFLAGS etc.
But... for some reason this change, which as such should be just more
or less cosmetic, also fixes a build problem in the "scripting" module
on Windows, seen by Noel Grandin
(http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/19016
) and me.
