Change-Id: Iea0576e61963dbdb72c88fe332c7cfe3e8ab7ff0
Reviewed-on: https://gerrit.libreoffice.org/1794Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>

The function getHorizontalEdge contains more function calls to the
getRowCount().  Instead we store the return value of getRowCount()
value in a const integer varible nRowCount and use it.

Change-Id: I3e1460913099d1060d5005329e0b63e5ebcd362c
Reviewed-on: https://gerrit.libreoffice.org/1777Reviewed-by: Radek Doulík <rodo@novell.com>
Tested-by: Radek Doulík <rodo@novell.com>

Change-Id: I5f5982b2a2768d021f24693a285274544e07e40f
Reviewed-on: https://gerrit.libreoffice.org/1737Reviewed-by: Radek Doulík <rodo@novell.com>
Tested-by: Radek Doulík <rodo@novell.com>

Change-Id: I977d8d7f1d14ea6616cf4dc3dc49d201804b7c39

Change-Id: I0a3a3461080289af1726cf5f62d10b76dec9e57c

Change-Id: I13eda8a66e437c5f428b3ee3e9106f25cc9d02b7

Change-Id: I64e43e472215df35872e447e381047e64002184b

Project: help  3b379c4c53bbf69335694f214ca17393b9465ec1

Change-Id: I95ebe1915edb53ae25f3f85512b7b843726d8473

Project: help  17a2d59b68e705ae92509ea65bacacc2015f3127

Change-Id: I69ff4f69e3ef93ed36cdcda9c54513624e8c98d0

Change-Id: I8cf518a18e4846f9e687d05c7f7c0eb774abba6f
Reviewed-on: https://gerrit.libreoffice.org/1751Reviewed-by: Radek Doulík <rodo@novell.com>
Tested-by: Radek Doulík <rodo@novell.com>

Change-Id: Icf6aa698e69a2271cf68f420ceaec4aaffe94ad0
Reviewed-on: https://gerrit.libreoffice.org/1671Reviewed-by: Noel Power <noel.power@suse.com>
Tested-by: Noel Power <noel.power@suse.com>

Change-Id: I6798f7f855ed65a7628b4a178497205bce2e6060

Change-Id: Ib6a4e79d539f79911840acf783b5b62fab27acfe

Without this, pasting a chart object from one Calc doc to another may
occasionally incorrectly switch to range references *if* the destination
document contains the "right" set of sheet names.  With this fix, pasted
chart objects always switch to internal cached data source when pasting
to another document, while retaining range references when pasting within
the same document.

Change-Id: If1dbc854c5faae62f06ece155fad470b229ca0c7

Change-Id: I2ac599fa2897dc4fe3256b50300cb467c647e320

Change-Id: I579694780b64e532b0e61017783bc4e72f8d2936

Change-Id: Idc81352de3d2a9550457e8f56fd819c0296fd2a8

Change-Id: I698f60daf4e591b57d8d99c130d2e524dc10c306

Change-Id: I1d112948f6e0595329f44e34d8d1cba37ae8fd6e

Project: help  a7662a33f70582067dd9dc303ec7228a28f36a12

Project: dictionaries  0aeb113339d2bdeb0cb7fe3a9a2b1ae1c3fd9367

... otherwise the first page will not be updated on page style changes.
(uncovered by commit c41675a7,
 which should have fixed this too)

Change-Id: I04f75b2a8e8929767fb36dd7085c3a273f07c93a

...where it could default to something like CP 1252 instead on Windows, while
keeping backwards compatibility for now with running under Python 2 (where
things apparently worked well with the original code).

Change-Id: I0ddd06771a36e1cd2cc2ce78abd8bd667db7778f

Change-Id: If7983092a3842bf1841d8a19dc1776668c17d3f3

Project: help  f96ff336fd0c754564e93da04d6531721ab745b5

Seems ScDrawLayer::GetObjDataTab was used mistakenly thinking that only an anchor
for that tab would be returned ( but actually whatever anchor is returned gets the
tab set )

Change-Id: I5d240f80a9974f6e4032875ed00350c94621bde7

Project: help  2d030d074953cf178778c4afa2338915d4019e91

Change-Id: I81bc6e119019f9bd4f90ae4ed77fbb65455260cd

Change-Id: I32e514fbfbd323b688b25b9e2165d0c76e3c4db5

 - don't remove parentheses around subqueries
   (without the parentheses, it is not valid SQL)
   * when saving a Field (name value) typed by the user interactively
   * when parsing SQL and constructing the initial Query Design view

 - automatically add the necessary parentheses
   when a SELECT statement is entered as column name

Also:

In code saving a Field (name value) typed by the user interactively,
factorise some common code

Assorted minor fixes (typos in comments, etc)

Change-Id: I3843258323c903cba23238b0730ec4eb5875f792

Change-Id: Ib0c7151b311029318c213abb86e6541e3b27d040

Change-Id: I8a67235e5110618f45fe9d9467bbb7ff90c7c712

Change-Id: I2b408a23162b1200bbcd530be7acb42435388b04

Change-Id: I4e56da8820d5c92d3b6e2ff2c749bdc0cef46d73

Change-Id: I9cc578ff3355e720181e68f252d678696ecfeed1
Reviewed-on: https://gerrit.libreoffice.org/1765Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

...to 75e32e15 "default to --without-help and
--without-myspell-dicts."

Change-Id: I018b8033f3a9d485b5cf5a9392719748426de53b

Change-Id: Id54b9a480b345b52f86c53f6a0a939c18807ec05

...in X11SalGraphics::GetGlyphBoundRect

In MultiSalLayout::GetBoundRect we loop through each fallback font and union
each level's GetBoundRect to get the result, which seems reasonable, except
that for each level that means a call to SalLayout::GetBoundRect which calls
X11SalGraphics::GetGlyphBoundRect.

Those sublevel SalLayouts don't know that they are sublevels so they never set
the level bits on their glyphs. Which results in
X11SalGraphics::GetGlyphBoundRect always searching for that glyph in the level
0 font, so there's a mismatch between the font the SalLayout's are created to
use and the font that gets used.

Now, SalLayout::GetBoundRect is a fairly simple thing, it just calls
GetNextGlyphs 1 by 1 and X11SalGraphics::GetGlyphBoundRect on the result of
that.  So I *think* that if we remove the specialized
MultiSalLayout::GetBoundRect in favour of the default implementation, then
because MultiSalLayout::GetNextGlyphs is specialized to do-the-right-thing and
set up the glyph ids correctly, then we bubble the ids down
to X11SalGraphics::GetGlyphBoundRect correctly to get it to
use the right font and we get the correct bounding size.

defb4d60a2d22fd36a0ff3f077faa6a0932b45a4
defb4d60a2d22fd36a0ff3f077faa6a0932b45a4

Change-Id: Idefb4d60a2d22fd36a0ff3f077faa6a0932b45a4