There is still libsvxlo.so <- libmergedlo.so dependency dropped,
but that does not break the build and I can't find the source.

Change-Id: I151375cad5d7365c309d9403810750b6cd2c5efb

This class is for use in the 1st step with the DOCX importer\exporter,
to hold information about 'track changes' that relate to formatting of
text portions.

Change-Id: I3f5231d0e49e0b493ec22efaac1c90b0d415f3ea
Reviewed-on: https://gerrit.libreoffice.org/6901Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I16e0be513b0b7ecbc54c0e2cb8974e801c13adbe

Change-Id: I9ade981c771367fd292600d73124f89b94a7a924

Change-Id: Ibdb27900b70b6ccebfde542b516e71c4c1a6e795

Change-Id: I8af2e887a6ad2b345b5b214eb02095c71cdafbc2

...in comphelper::PropertyMapEntry and SfxItemPropertyMapEntry.  And as the
arrays of such need to be initialized dynamically anyway, also change their name
members to proper OUStrings while at it.  Plus some const clean-up.

Change-Id: I67d4d7b5773fb020605f369daf39528bec930606

Change-Id: Ibeefc8e9aad57c28722b62610231d14ebc8a7403

Change-Id: I39462fc722a58b32e8829a9f2005a411871f255d

Change-Id: I55fd3fabb7594ee2c635cc0b02dbf506bd5ab3df

Otherwise ScAccessibleSpreadsheet::GetAccessibleCellAt could return wrong results
and JunitTest_sc_unoapi would fail at least on Mac OS X.

Change-Id: I65e9231920d13393a6991db318d330ee42a985d4

The eventual text colour is not known yet when LayoutText() is
called. So we need to re-do the layout and justification in DrawText()
in case we have a text colour.

For some reason this is needed only on iOS. On OS X, the original code
manages to display coloured text correctly. But then, on iOS a virtual
device is used, and who knows what other strange things going on. Some
of the scary warnings printed make you a tad unsure everything is
working correcly... (Like "SdrPageView::DrawLayer: Creating temporary
SdrPageWindow (ObjectContact), this should never be needed (!)")

Change-Id: Ide99c163dea0f758a373c8dab9c54681ff57f624

.tab extension is a known extension for tab-separated values
according to Wikipedia.

Also add .tsv .tab files to the list of known text files, so XML
detection code won't run on it, and won't output errors to console.

Change-Id: Ifb8edc40900cb4669264e1e989c01efd61ff24bf
Reviewed-on: https://gerrit.libreoffice.org/7038Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>

...at least in CppunitTests

Change-Id: I75f05581db5423dc54ea7810a8cd2bd0f9c0c3f0

Change-Id: I6f8c6827c00db50184a46f39968f882b944d18d4
Reviewed-on: https://gerrit.libreoffice.org/6967Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>

Change-Id: Id9bb0ae05395fe635aec1a42e8b3c0995cf81463

Change-Id: Iecfd714834b1d2f24098d55b9b32daa5ca76b1de

Change-Id: Id7ec3a3fe546bbd68f74c732c9708a61d400e946

And reduce header dependency on docsh.hxx which a lot of files include
directly or indirectly...

Change-Id: I2de25380f8b634456e0add940fbb775ac11414cd

Change-Id: I084cbb9a4330a81212852d963181297b5bef22e4

  Issue :
    In chart1.xml,
       <c:chart>
        <c:plotArea>
         <c:stockChart>
    there are four types of series as Open,Low,High
    and Close.

    For Open series,
      <c:ser>
       <c:idx val="0" />
       <c:order val="0" />
    an attribute "val" should be 1 and not 0.
    i.e. index should start from 1 and not from 0.

  Implementation :
    - In ChartExport::exportCandleStickSeries(),
      Using idx variable, we are writing index value
      which should be greater than 0. So for idx=0,
      we are adding value 1 while writing index value.
    - Added Unit tese case for chart export

Conflicts:
	chart2/qa/extras/chart2export.cxx

Change-Id: I4d5ffefbc8fcf62b50c13ca1b3ed80290962fc4e
Reviewed-on: https://gerrit.libreoffice.org/6925Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>

Change-Id: Ifc5e6ae2f3161e33f93b1485269f6dc164f74e40

Change-Id: Ieb8dd13763c6d5e6d30ce641683de79d89d135df

Change-Id: Ib2dbc4af73394c9c35a7f273fd8966b91ac3eb84

Change-Id: Id382726b86726515a9ae3017c11fad0420136a4c

"UNO_ENV_SUBST:" should not be used.

Change-Id: If23b174de792cd69dc79e70dd8f5e8a31badb96d

We store the values of themeFontLang tag to the document grab bag so
we can save it back to the document on export time.

Added unit tests to check that the attribute is properly set back and
also that the theme fonts are correctly applied to the text.

Change-Id: Ia54c513796ba38a571396ca7b72dfd28463c15fd

We were applying the theme fonts taking only into account the
<a:latin>, <a:ea> and <a:cs> tags to set latin, eastAsia and cs fonts
respectively. Word uses in addition the <a:font> tags to define a
font name per language, in combination with <w:themeFontLang> tag in
settings.xml file which indicates the default language for latin, cs
and eastAsia. For example, with <w:themeFontLang w:bidi="he-IL" />
the default language for cs text is Hebrew, if the theme says
<a:font script="Hebr" typeface="Arial"/> then the selected font for
those sections of text should be Arial.

In theory, Word would also be able to define the language for a
specific section of text and that should receive the proper font from
the theme definition, but we are currently not supporting it. More
info: http://blogs.msdn.com/b/officeinteroperability/archive/2013/04/
22/office-open-xml-themes-schemes-and-fonts.aspx

Main changes in this patch:
* Added setter and getter values to ThemeTable and SettingsTable to
  be able to pass the values read in <w:themeFontLang> tag.
* Added support to manage the values in <w:themeFontLang> and
  <a:font> tags, which used to be discarded.
* Added methods to translate locale definitions to the language codes
  used in the <a:font>, using a table defined in the link above.

Change-Id: I78e6da5feab34cb9ff770a2c60e2f7229e7fb140

Change-Id: I32bc4852396b0eff9962dc5cd007faf0bb9f5eaa

Use RGBA consistenly. Wonder why the code was changed to use BGRA at
some point?

I got the picture in the document to show up with correct colours but
unfortunately not the RED GREEN BLUE etc text. Weird. Even weirder, if
I add a temporary hack in CoreTextStyle::SetTextColor() to use some
other colours for non-black text (instead of the ones passed in the
parameter), those colours do show up. This is a mystery.

Change-Id: I591424a19fa02b3f095035e989cbc49fff94b8ca

Except for our external api where the Oriya is stuck (and similar for
the vba implementation)

Change-Id: I8288c930567385eea49a4c303727b13ef8b8a89f

Change-Id: I075db734dae73244d90a39b655fca2dc48d921c7

Change-Id: Idf6a849b08fd76841d0dd5555e75b698e5d730cb

Change-Id: I9600d4fffc4cde7046b43729f95d5a96aa1cdf38

Change-Id: I2158aed3dfe71370add52759976232647286fa7e

This reverts commit 90f91088 for now:
Ach, old GCC doesn't like plain string literals to initialize members
of OUString type...

Change-Id: I50563a00406259bb5d41831e2a2796762450d097

...in comphelper::PropertyMapEntry and SfxItemPropertyMapEntry.  And as the
arrays of such need to be initialized dynamically anyway, also change their name
members to proper OUStrings while at it.  Plus some const clean-up.

Change-Id: I67d4d7b5773fb020605f369daf39528bec930606

It includes a small PNG image, too.

Change-Id: I31169698a7573b7a6e272277a49cefe76c74f959

just die when you are supposed to, without this endless amounts of accessiblity
cells remain after sorting slides with tables in them

Change-Id: Ice9a86b8b806e58f9bf871341a38f7729798dda9