use the sheet name to build the expected strings

Change-Id: I5f079975921338b9449186cc33a0acde180679d5
Reviewed-on: https://gerrit.libreoffice.org/6419Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Idc189a84da1aa0ac510e003134580eafc03b4b9a

Change-Id: I68110e2ff632d0446c127e428623fecb62aa14c5

valgrind complains about this when viewing a help page

Change-Id: I0f30f8b5121fa5e6ddbac0ea6e05005e40bc7fd9

Change-Id: Id7dc7a2853a8c56ee56eab55c078650e16c278fd

...after 800005b1 "Disallow
--without-system-cairo combined with (implicit) --enable-gtk."

Change-Id: I74f5e4f454f5e1724e258380bbbcd771bf58453a

Change-Id: I996038a45495a5b6a63622ac0d290ac4fbc0bedd

Project: help  91f8b3cb54e752a174ee10be4e528c7dcd4fb55e

Change-Id: Ib422584d2f6cbb8bfd88dd67aef96b8b062c3d38

This allows roundtrip of the whole tblCellMar XML fragment.

Change-Id: I41c5afd6b1cfa7322f5f1bd8c44ed6bffe10eb41

As the system gtk libraries may depend on later versions of libcairo.so.2 and
its bring-along libpixman-1.so.0 with the same SONAMEs.  So if it would ever
happen at runtime that our bundled libcairo.so.2 and/or libpixman-1.so.0 get
loaded before the system ones, the system gtk would probably not work correctly.

Ultimately, the bundled cairo can probably go completely.

This reverts 122a1376 "extensions: crude hack
for mysterious cairo link failure."

As discussed at #libreoffice-dev:
Oct 24 10:10:15 <mst__> sberg, caolan, dtardon  any idea what the proper fix is
  for pluginapp.bin? 122a1376  breaks on RHEL5
  tinderbox...
Oct 24 10:10:17 <IZBot> core - extensions: crude hack for mysterious cairo link
  failure -
  http://cgit.freedesktop.org/libreoffice/core/commit/?id=122a137672d761418a549568ad8cad623dd2b4b5
Oct 24 10:12:53 <dtardon> mst__, i'd try
  gb_Executable_use_external,pluginapp.bin,cairo
Oct 24 10:13:58 <mst__> dtardon, i'm not sure if that is the intent - the
  -lcairo comes from the gtk external so we should use same cairo as gtk i.e.
  system one? but id on't understand why linker won't find the pixman library
Oct 24 10:16:35 <sberg> mst__, I get no build failures in "make
  extensions.clean && make extensions" when I comment out that FIXME in
  extensions/Executable_pluginapp.bin.mk
Oct 24 10:18:59 <mst__> sberg, it only started to fail for me when i removed
  libcairo.so from solver, probably you still have a stale one
Oct 24 10:19:42 <sberg> mst__, in solver/*/lib/? no
Oct 24 10:20:48 <sberg> mst__, but turns out I'm using --with-system-cairo (as
  required by --enable-gtk3), so ignore me
Oct 24 10:22:53 <mst__> sberg, so if i rm solver/unxlngx6/lib/*cairo*
  solver/unxlngx6/lib/*pixman*  it still fails for me, how could system-cairo
  work then?
Oct 24 10:24:13 <sberg> mst__, in that /usr/lib64/libcairo.so has a DT_NEEDED on
  libpixman-1.so.0 (which "our" libcairo.so is missing, I'd assume)
Oct 24 10:24:44 <sberg> mst__, erm
Oct 24 10:41:18 <mst__> sberg, so if i filter out -lcairo in
  gb_LinkTarget__use_gtk then it magically works - are there any problems with
  that approach?
Oct 24 10:47:19 <sberg> mst__, so the root of the problem is that there's two
  different libcairo involved?  (just doing a local build --wihtout-system-cairo
  here, to see what's going on)
Oct 24 10:47:55 <mst__> sberg, i don't think so since i get same problem after
  removing all cairo libs from solver
Oct 24 11:12:11 <sberg> mst__, so the link line for pluginapp.bin contains
  -lcairo twice, apparently dragged in indirectly (via _use_externals gthread
  and gtk, likely), and does not contain "our" -L.../cairo/src/.libs (as it
  doesn't _use_externals cairo), but does contain -Lsolver/*/lib.  Now,
  /usr/lib64/libcairo.so needs libpixman-1.so.0 and there happens to be one in
  solver/*/lib that lacks syms compared to /usr/lib64/libpixman-1.so.0
Oct 24 11:13:43 <sberg> mst__, so this was nicely hidden when all the external
  libs were delivered to solver/*/lib, but in the end I think the bug is to
  combine system gtk with non-system cairo and/or pixman
Oct 24 11:14:49 <sberg> mst__, as long as our cairo and/or pixman have the same
  SONAMEs or exported symbol names as system ones, all hell can happen at
  runtime anyway
Oct 24 11:15:32 <mst__> sberg, but... why then does it fail for me if i don't
  have the cairo/pixman libs in solver?
Oct 24 11:15:57 <mst__> ahhh  -Wl,-rpath-link,$S/instdir/unxlngx6/program <-
  taht must be why
Oct 24 11:17:40 <mst__> is it normal that -Wl,--trace does not print out what
  libraries were found via -Wl,-rpath-link? it only appears to print explicit
  -lfoo
Oct 24 11:18:27 <sberg> mst__, because of -Linstdir/*/program
Oct 24 11:20:27 <mst__> sberg, so we need
  -Wl,-rpath-link,$S/instdir/unxlngx6/program obviously;
Oct 24 11:22:08 <mst__> sberg, apparently everything builds successfully when
  filtering out -lcairo from GTK_LIBS, do you think that is the best workaround
  for this?
Oct 24 11:22:14 <sberg> mst__, no, we need to change configure.ac to disallow
  --enable-gtk --without-system-{ciaro,pixman}
Oct 24 11:22:39 <sberg> mst__, similarly to how we already disallow
  --enable-gtk3 --without-system-cairo
Oct 24 11:24:48 <mst__> sberg, that would be sort of pointless, since linux is
  afaik the only platfrom where cairo is used at all - effectvely we could
  remove bundled caior then?
Oct 24 11:27:04 <sberg> mst__, effectively yes, unless it would still be useful
  for some --disable-gtk scenario
Oct 24 11:33:41 <mst__> caolan, cloph does RHEL5 have a sufficiently recent
  system cairo?
Oct 24 11:34:43 <cloph> cairo 1.2.4 on the CentOS 5.9 (well, more like 5.10 now)
  system
Oct 24 11:37:08 <jcorrius> my RHEL6 build uses internal cairo
Oct 24 11:37:47 <caolan> rhel-5 cairo is 1.2.4
Oct 24 11:37:54 <mst__> caolan, the other option i can see is to do $(call
  gb_LinkTarget_add_libs,$(1),$(filter-out -lcairo,$(GTK_LIBS))) in
  gb_LinkTarget__use_gtk which works-for-me(TM)
Oct 24 11:38:30 <sberg> jcorrius, not for very much longer ,)  (it typically
  happens to work by luck to combine system GTK with bundled cairo)
Oct 24 11:38:59 <mst__> thorsten, are you aware of any reason why we must bundle
  cairo on linux?
Oct 24 11:40:05 <sberg> mst__, "<caolan> rhel-5 cairo is 1.2.4" and we only
  check for "cairo >= 1.0.2" in cofingure.ac, so all should be good
Oct 24 11:40:35 <sberg> mst__, "works-for-me(TM)" just by luck
Oct 24 11:41:33 <mst__> sberg, well perhaps guess the real problem is that
  pkg-config spits out a spurious -lcairo for gtk+-2.0 so...
Oct 24 11:42:19 <mst__> ... but of course if a sufficiently good cairo is
  available everywhere we don't have reason to bundle it anyway
Oct 24 11:45:45 <sberg> mst__, at least my /usr/lib64/libgtk-x11-2.0.so.0 does
  have a DT_NEEDED on libcairo.so.2, so even if pkg-config wouldn't spit it out
  we would still be in trouble at runtime
Oct 24 11:47:05 <mst__> sberg, at runtime we have this problem for a lot more
  libraries than just cairo
Oct 24 11:47:43 <sberg> mst__, but why refuse to fix the problem, at least for
  cairo, where there is apparently no good reason to bundle it anyway?
Oct 24 11:48:36 <jcorrius> is cairo used on Windows for anything?
Oct 24 11:48:42 <mst__> sberg, since there is no good reason to bundle it anyway
  i don't object to removing the bundled cairo
Oct 24 11:49:38 <mst__> sberg, ... but i can still hold the opinion that gtk
  shouldn't put -lcairo in its pkgconfig :)
Oct 24 11:53:12 <sberg> mst__, since "pkg-config --cflags gtk+-2.0" includes
  "-I/usr/include/cairo", one could argue that cairo is a "re-exported" part of
  that, so should also appear in pkg-config --libs output; one could likely
  argue either way
Oct 24 11:55:27 <mst__> sberg, well but if you're calling functions from cairo
  then you're using cairo directly whereas if you just call gtk functions you
  have no need to link cario
Oct 24 11:56:47 <sberg> mst__, sure, my argumentation depends on that
  "re-exports" argument (which might be thin); anyway, are you going to remove
  bundled cairo
Oct 24 11:56:54 <sberg> ?
Oct 24 11:57:34 <mst__> sberg, i'm going to force it to system in configure for
  now
Oct 24 11:58:13 <sberg> mst__, I have a patch for exactly that already locally
  here, so could push that if you've not done that too already anyway
Oct 24 11:59:00 <mst__> sberg, i havent' finished my freetype patch yet because
  people always distract me on irc so you can push
Oct 24 11:59:01 <sberg> mst__, or, rather, my patch just errors out in the
  --enable-gtk --without-system-cairo combination, so if you have a better one,
  go ahead

Change-Id: I071e759a55f46338b36c3cf8ac7cd5591bd9e376

Change-Id: I99293a91018c130415bd3816fa23f44643512a74

Change-Id: Iec4b0d041ec0389630d21572d6c5658639d85b17

Change-Id: I0494f06ec8709fdf33ace6772823d7b986ff5847

Project: help  4327d90e23cba2f2829a4d2bf0ed449fbeb92cdb

Change-Id: I0539e2708b973b8bea7bd63488277f00201c6c46

...otherwise e.g. during execution of sw/PythonTest_sw_python.mk
workdir/*/LinkTarget/Library/libtest.dylib would not find
workdir/*/LinkTarget/Library/libunotest.dylib without yet another addition to
DYLD_LIBRARY_PATH.  (Special cases where NONE libs are located somewhere else
than workdir/*/LinkTarget/Library/ can be and are still found via
DYLD_LIBRARY_PATH.)

Change-Id: Ia301746842ef49393d0229915c01b61e378ca100

Project: help  bb440434d0561b291c73cf467c16e803934b8abb

Change-Id: I32b9d2398d2d734a0d96c937b2238d8ff9a74ef7

Change-Id: I6104ee3bb0928275a0e4ffb9a7ca1be37ebc1f9e

Change-Id: I69e75dbbaa16b6dc407a69ba8137c09888db50ce

Change-Id: I9d1267d6fc14a3149fb92a486bee3023a531e574

Change-Id: Ia31a6f56fd8347f6fc50677e86a414f4c5ed81b1

Change-Id: I4b967187bca35527a3c3d718952ae0a3ae6ebae9

Change-Id: I1e7a75ad4c8d35cb6adef8d6c4104f1955ad4574

This allows e.g. storing a table style's w:tblPr -> w:tblInd -> w:type.

Change-Id: I653edc8912ce4e61c703bfffc6e3dcf322295b6f

This allows to store keys in table style's tblPr (no contents yet).

Change-Id: I2aa80c8bee3f76a7c0090407f97156e3e3061a1d

With this, we can store tblPr (itself, not yet its child elements)
inside table styles.

Change-Id: I7e9008fec566e73c50c4ccfc565fd0e8a3293998

And also add a method stub where contents will be preserved as well.

Change-Id: Ide52102d1bdf6bf9d73b84ed6760f2b1e086a805

Change-Id: I3aba3f85face62e0b8d54aebb92412c350aa2923

Change-Id: Ie2aadab8302f365379a569989bd9640db55b9716

... to hopefully be able to generate a diff when the next release of
MS-LCID.pdf will be available at
http://msdn.microsoft.com/library/cc233965.aspx

Change-Id: I10877cdc8d4b90c6b971dfa5e05ad796fd2a2d00

... as downloaded from http://msdn.microsoft.com/library/cc233965.aspx

Change-Id: I07f81ca0d6230c38f1f80f93f262debdf939ca87

as opposed to "hyperlink". Be more generic and consistent
across both ctrl+click and click modes.

Change-Id: I673ed59fc9f3408a0c4534c6490d9bbc3598bc08

Change-Id: Idf0fee94ef2c360ce509b34a2828022a8daf04d0

when link is in a toc, and Cursor in protected areas is
disabled, causing the cursor to leap before the toc
before trying to see what's under the cursor in order
to jump to it

Change-Id: Iaf348e3621df02628b4d2ac8c1165df7082237ed

Change-Id: I37a5edbc578a71cb7eba29c3191cfa36e90ca022

Makes it more obvious to the code reader that nothing wrong is going on (or
the compiler would have complained).

Change-Id: I2ab420ffeb71f5c0b68e1b7db039cb9cde6af801

Change-Id: Ia8a47bcd07cf10302b5cf6f550627e5c7cd1d9f6

Change-Id: I202ab418d2cf0d4f0f9d7786fec837dd76abd7b5