Change-Id: I47ec3aeb14445b697bf8f5af34c5d16a14069735

Change-Id: I4ffa1aa2dce0bf1d0c87d56f72589112ec1222a1

Change-Id: I49da06b94bdc91b1cdc4bb3d047804d353b0aba8

Change-Id: I02c56a86454b5ed6df29c3af60b3da2c7bd4b7e1

Change-Id: I8d65b76fd93b63b51db88b7b09902ba64732dd97

Change-Id: Iac9ac4e48115ea09aeffa11bbd8da399266aede9

Change-Id: I8ff9bb01bef265af70390ae94b762930689aa1ba

Change-Id: I61ea54ff5a5771ad2dee1b3514c97fbdd9f241b9

Change-Id: I497d7ddc90bdfed9cd49e0b0c988a74f733bfa36

The file unused.easy contains a lot of symbols which are known
to be required, even they're currently not referenced by anyone.

Change-Id: I048c1656b240f7d601e4c99b8d9c4969b3954c87
Reviewed-on: https://gerrit.libreoffice.org/1084Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>

That is actually XID, not a pointer.

Change-Id: I9fa807fc4f33c07b2b4ebbb5e1b7163eb53411c3

In general, DOCX tables provide a grid for the table, then use spans in
case different number of cells are used in different rows. In this case,
the cell width is ignored, as the wished width can be counted from the
grid and span values.

However, it's also valid to simply provide more cells then the amount
defined by the grid, and in this case the cell width should decide the
final width of the cells. This commit adds support for this later case.

Change-Id: I0dd6c1f0c06f81c2afa00489b7ad1f33ff300a7c

Change-Id: I7f5bbbd1d8a2491c86c2875ae155ef4b10154377

Change-Id: I92a5de2344e82f99ac94608e1455afa8c33bd54a

Change-Id: I6be70c0b8d73f4d1d1428c0df94ea6d8bdc782f7

Change-Id: I19316f0fd04f75d980719676c928c3455e0f07b7

Change-Id: Iff8904ac0c856dd3175b429b4919a04a57c1b6ad

Change-Id: I5b05a7aded3ed80e0269155100ad075bffecf9ea

Add moz prebuilt & msvcrt80 copy

Change-Id: I335c25904c16db534a4878ff6a17db202eaef4f5
Reviewed-on: https://gerrit.libreoffice.org/1100Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>

Change-Id: I394817653afa738e7e3d19a1d82f892fb3b35c19

Change-Id: I4bed439df3d4f4c0a87a6e406048de2af6995b89

that create some clutter on some of the caller, this will
be resolved as things progress to ward OUString only
This is done that way to be incremental and avoid creating too big patches

Change-Id: I4a881d85cc2ee1eb53bc0c0d0902838b1d3720a2

Change-Id: I23ae9d3e8bf71ef9ece75ea013d18c36ab2e69d4

Change-Id: I9f5f6106ec81c33383f5936335dc965b84360116

Change-Id: I2b87838136f01ff463c66863803eea3c9cd17df9

Change-Id: I02ca7f7770e2d53371e7c597c087c4a370ce8d3f

Change-Id: Icaa3e29fbd5674271e69fa17ed9249c65b4a9c40

Change-Id: I61f57ed6a5aad0bf7a69319c36b080213b74ad6a

Change-Id: I93daafcb6cc161f10ec87fe9f1dc877e2154299d

Change-Id: I5ec8f1061aa41ac0c4bb46d9159be439892706a1

most use of that API is to add a single sal_Unicode, it is
silly to manufacture a full OUString just to pass that via
AddToCode to then append it to a OUStringBuffer

adding AddToCode(sal_Unicode c) to simplify these case

also remove a silly iteration over a OUString's character to
re-add each character one by one via AddToCode()

Change-Id: Ia8a58551a1c24312baaa250b8d36fe21c46127e7

Change-Id: I6d93cb64126d60c35fda58039989d57b18a44773

Change-Id: I79bd0aecb98b7b47ee892ed4ce1b53abcd09ff44

Change-Id: Ia6a4cd46b3bda875baeb9fcdda98a1964aedf841

Project: help  c3cfcf7098787f11ca987ef8db65fbb670d8da6e
do not localize a single non-breaking space

Change-Id: Iaae38e666f5d5f9746065111a22a58187970554b

Change-Id: I9e6b10e2b019ae0805862e29fc934d1ebe3f86f5

Project: translations  de54a2fcdee6bd2d8005a819d4a3a822b2a8043f
glib is gone

Change-Id: I58c33b91f205641f9cc8cdfcd9ecfadc77341b82

If we already have such an include dir, let's have all headers there.

Change-Id: I2100b5308e7fdad9d98cfde76434ff485aca20c7