Change-Id: I5242bbb171ba21da43e535255b7e9dd73c1d4930

Change-Id: Ibe80e9837f1c8275d625e942eb75ecc8de897bf5
Reviewed-on: https://gerrit.libreoffice.org/2574Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Initial set of changes to improve UX for autofit.

Conflicts:
	vcl/source/fontsubset/cff.cxx

Change-Id: Idaf328b48a55fbcef13746f74120c13b6b435c93

Change-Id: I1865eec0dcb29c74e98a6f42f7cf37a2851f8e85

Change-Id: Iadf57ef1dfb7e108d1c7461e60705304f448ab78

Change-Id: Ic1522b0c3a292af061f5777e06e796dd82884fbf

Change-Id: I06255940f41c32493187d1ec847f7238fef4e9f8

Change-Id: I50980d9510b82277a5da04cc4f6c1d3ec8e7c756

Change-Id: I0c0f4ce1304b561bf94af5444c83d8920062568b

Change-Id: Icc3cbfc3eae6ade037960497e7fe2addf1912897

Change-Id: I9eb3c97ffe2dd122960bb4c5f5b0594767ea0fb9
Reviewed-on: https://gerrit.libreoffice.org/2556Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>

Conflicts:
	vcl/unx/generic/fontmanager/helper.cxx

Change-Id: I2d58b83c51a2c8b529727be0aeb5ef612f883acc

Change-Id: I53d8a164fe9333c286a04f88a0834feeecacd5ed

...to manually build solver/*/bin/test-passive.oxt via "make
Extension_test-passive".  There's still room for improvement in gbuild, though:

* There should be no need to add the extension's native library and jar UNO
  components (which nothing else links againts) to the central Repository.mk.

* There should be no need to move manifest.xml around.

* There should be no need to move .java files around.

* Let "make Extension_test-passive.clean" clean up again.

Change-Id: Ib44558061c4c0fda6be5943bd02b5a42cd15c52e

...as a prerequisite for gbuild'ifying desktop/test/deployment/passive/, which
builds a test extension that does not match those default description/license
settings.

Change-Id: I200ff0ceb9750ed4b1c187305f10469f789d29cb

Patch By: Lei Debin
Found By: bjdujing@gmail.com
Extended for better Debug Info by: Herbert Duerr

Conflicts:
	filter/source/msfilter/msdffimp.cxx

Change-Id: Ibb2e7daae425a711b5b6cadfa81446e9adeb68f1

Change-Id: Ia05bc5b8d1f9396ed8c1d27d54976308e6df36f4

Change-Id: I492f93a9ef5244681a28aed16e81c7558e38a875
Reviewed-on: https://gerrit.libreoffice.org/2573Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: I889a32bce4f3c0eab5d3d5ef199dd321755cb177

Change-Id: I589ff778383f6e1a5fa910be687787658cb414a0

there seems to be some problem ( regression from 3.6 ? ) with dealing with
addresses returned from named ranges where the addressing mode of the named
range is different from the addressing mode of the document itself

Change-Id: Icfcd047819a4d1c89ae9509ea1a2e1b2d5386101

Note: some of the test documents have some tests disabled in order to run
without errors, these are identified by the following lines

Rem [#FIXME disabled 3.6 ] in the macro source.

note: some of these errors are expected and were always happening, some
errors e.g. those pastespecial specific ones in
qa/unit/data/xls/TestCalc_Rangetest2.xls
seem to be to do with problems with the test harness.

note: there are some others ( e.g. in Window.xls & windows2.xls ) that seem
to be related to hard sizes and screen resolution ( these should be adjusted
sensibly )

Change-Id: I07a43a2802d4e1794ac2f8c648f666b5bcd13a04

Change-Id: Ib2cbcc33e6188c60c183b5f47e9ae9c9d4c91b95

Change-Id: Ibac7f624f1a1dcce653dff4bec573be457d70075
Reviewed-on: https://gerrit.libreoffice.org/2125Reviewed-by: Muthu Subramanian K <muthusuba@gmail.com>
Tested-by: Muthu Subramanian K <muthusuba@gmail.com>

Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5

Don't know what this affects, though. Things seem to have worked as expected
even with the hardcoded bogus value?

Change-Id: I945bdcd53260fc5f43cf0031dfd96637168475f0

Change-Id: I815cc4a703b7ca6d2894807396a06a3394b40676

Change-Id: I9031ab98f263bcc32b747c85e1715b80c7059ae9

Change-Id: Iea153d6e1b648ac6a7bdf8978cfc1f8016158d6c

Change-Id: I4a0a6ab0998f41ce238d0570fba2133b79c8f19e

Now the type detection process is a lot more simpler.

Change-Id: I5a3a68afef8276a7f07be75c0b2db8151512b3fb

In theory we shouldn't have to do this any more now that we do test
against all possible format types in the first pass.  But let's test
if my theory is right...

Change-Id: I70d73a99aec56a66deaeb3f942fd2641a2cc7f48

Change-Id: I5a614ae032149b755d609ff05b9ef2fdb842dadf

I did my best to check each and every one of them and rank them to the
best of my ability.  Any mistakes are to be fixed as they are discovered.

Note that while working on this, I've noticed that we don't actually have
any real type detection codes for many of these format types, especially
the graphic file formats.  If we ever have trouble loading any file type,
check if it's caused by not having any detection code for it, and if so,
we should write one for that file type.  That said, my casual tests on
loading graphic files didn't cause any trouble.

Change-Id: I1398cbb72b2d4ccf75434a9aa0d2a5c5d17bdaad

Else it would incorrectly declare a non-zip archive format as a zip-based
format.

Change-Id: I017b63768dc89f7fe6e2202a661faf5f692b1a92

The old type detection would only test file format types that are
relevant to the current document service.  But this would not work
if the user tries to open an Excel document whose name ends with a
non-default extension (such as .tmp) from Writer UI.

To amend this, we need to test all possible format types that are
supported by all our modules regardless of the current module, but
prioritize them per current module.

TODO: The above scenario doesn't work yet.  I still need to fix
the individual type detection services to get it to work.

Change-Id: I51dbdff28299aa64cedc6752b9ff82b96d5d79cf

Change-Id: I5a059f7799255262d46e5248813da4409eb83a9a

Change-Id: If31092ecc2b746acbe5731bf9383560e93aa3a69

Change-Id: I1a591ec4061c73657c26552d41c58b970696038f