Project: help  4d6f86d203814a211eae9dfacd4baf195ca4ff1d

tdf#97745 housekeeping

Fix links in bookmarks.js
Better font size for Index and Contents
Fix CSS file

Change-Id: I42966be1d88b12393b6dd95adb2719baf76a025c
Reviewed-on: https://gerrit.libreoffice.org/40549Reviewed-by: Olivier Hallot <olivier.hallot@edx.srv.br>
Tested-by: Olivier Hallot <olivier.hallot@edx.srv.br>

Change-Id: I0f457e60da1ca765dfdb1458b9de629b0dbeccad
Reviewed-on: https://gerrit.libreoffice.org/40545Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: Icc388182b9b7b6a6617793be09217f06bed7332d
Reviewed-on: https://gerrit.libreoffice.org/40527Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

1. First quotation mark of \B command switch of TOC field command
  wasn't written when exporting.

2. Quotation mark wasn't ripped off when writerfilter parsing TOC
   field command.

3. FindInCommand accidently ripped that last character of the last
   command.

Change-Id: If283776048f3c8d896c466cf4d742e44b6d85e96
Reviewed-on: https://gerrit.libreoffice.org/38745Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

The problem here is that the SplitNode() calls in SwRTFReader::Read()
destroy the order of the bookmarks, which causes an assert later
from the std::lower_bound() when a new mark is created.

The 2 marks that cause the problem are:
SwPosition (node 5, offset 0)
SwPosition (node 5, offset 0), SwPosition (node 5, offset 0)

During the 2 SplitNode calls, the second one is corrected by
ContentIdxStore and remains on 5, but the first one is not and
becomes:
SwPosition (node 7, offset 0)

ContentIdxStoreImpl::SaveBkmks() does different things when a
mark position is exactly on the parameter position: if it has
only one position, it is ignored, but if it has a second
position, then both its positions are corrected.

It is not possible to change the sort order so that marks with
one position are sorted behind marks with 2 positions, because
while SplitNode() corrects marks "backward", JoinNode() uses
ContentIdxStore to correct marks "forward"; hence manually sort
the marks.

Change-Id: If5b35f18bfd47ffe98c0f67e84d380ca801411a3

This was changed in d72aad21

Change-Id: Ie93f603c82669ca612fbf9635a62c50e63702a85

The GEN VCL backend simply ignored the result of the timeout.

Change-Id: I0c1b34927ba97886cf11b2c2a203c3e82d851dc9

mbDelete is gone, as we simply check for mpTask.

Change-Id: I9d451f2445fb6b978d177b45d75abde2595c5fac

ScXMLDDELinkContext
ScXMLDDESourceContext
ScXMLDDETableContext
ScXMLDDEColumnContext
ScXMLDDERowContext
ScXMLDDECellContext

Change-Id: I8f272ea395e125316268d2ec77e4be44389e5542
Reviewed-on: https://gerrit.libreoffice.org/40540Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Noticed by Eike.

Using the scfilt component as in the other calc tests does not work
as the test immediately starts to fail. In general it looks
dubious that the test does not use any component files.

Change-Id: Ic44ff5112c6a131f3820e32f7a71ea2f90142cd3
Reviewed-on: https://gerrit.libreoffice.org/40536Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I7c58328b4943e1891d2643ea52c3486894c35fda
Reviewed-on: https://gerrit.libreoffice.org/40535Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Ia0162482841854cc4cb5c2b004bc978809bdf4c2
Reviewed-on: https://gerrit.libreoffice.org/40534Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

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

Change-Id: Ice32a16d14d0132a19e8209d311bb799fd7ee0c8
Reviewed-on: https://gerrit.libreoffice.org/40526Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I136ee42523a40c576d7cf0b66abbf50ad9be052f
Reviewed-on: https://gerrit.libreoffice.org/40517Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Made corrections/finetuning for Calc and Writer.
Had to remove some former code which tried to do
corrections.

Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b

Overhauled the edge extension calculations to better
use all existing cuts, for cases with single and double
lines. Also a preparation for more complex edge cuts.
Changed BorderLine paint in Writer, it was setting the
svx::frame::RefMode attribute at the Style *and*
was manually moving the geometry which lead to a
double applying of the offsets

Change-Id: I446d04632050272849f43accb8dcbde574d10cf4

Overhauled BorderLinePrimitive to use two constructors
offering using one or three edge definitions for
construction to better refrlect possibilities. Adapted
usages. Better processing, less memory. Preparation
for using more decent LineExtend values (four per line
needed)

Change-Id: Iac9d9ae64874fea38fd6e2a04221698481cc0d0e

Added usage of defined extensions to the BorderLinePrimitive,
also added a first version to detect all cuts with adjacent
borders and produce the correct extensions, for single and
double lines. Not completely happy with it, but a first
version

Change-Id: I4b12a6cc0a70278bd5c506e9b3b2c5c126930dad

Handling and paint of borderlines greatly adapted
to primitive usage. Solved the double paint mechanisn
to no longer use the sc-local special cases. The
svx tooling for borderline paint is now the only one
and was extended to also handle diagonal lines.
Big cleanups/removals of old paint to OutputDevice
and sc-specific rendering. All other app-usages
of borderline also adapted. Preparations for careful
line-start/end adaption prepared and possible due to
unified coordinate-system usages and basegfx class-usage

Change-Id: If9e4efcfc0fe25e14d4052907038ca5cf222a432

Abstracted and adapted CreateBorderPrimitives further,
added CreateDiagFrameBorderPrimitives for diagonal
geometry.

Change-Id: Ia2b20d197e1fd29ad9e9eb40a5194efdeac9872e

Change-Id: Ib9b73b5c05ec2e6846ea3adc950ccab5d1c0a9b0
Reviewed-on: https://gerrit.libreoffice.org/40439Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I4fb250468fc17fc8be94d666ef231636b4609c1d
Reviewed-on: https://gerrit.libreoffice.org/40520Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>

Change-Id: Iaac1f13e6c189e2e13b86258268741c14a537799

had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis

Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ifdd86590f4258c84006f7ca94ea06058e600db1e

Change-Id: I608b818063f3ac66c6b36f9f8d221a54bfe1be24

Change-Id: I273847d01a457bf79a9b9182b370ffb58284c952
Reviewed-on: https://gerrit.libreoffice.org/40498Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

Though meFieldUnit appears to not be used anywhere, but ...

Change-Id: I99e8392e4a773ba00868904e0f2ff5fdbc4bc47d
Reviewed-on: https://gerrit.libreoffice.org/40521Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I578d89cb732bf3e75b83ee6c65d0320659b5c3f8
Reviewed-on: https://gerrit.libreoffice.org/40514Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>

Change-Id: I9e542f6e131de1a05dd54a84a260453ea2edcb62

Change-Id: I62e021b2ec7ac9df122389fd128f7a7770317a43

Change-Id: I55896eb939a864c3437e3f3c5b13c272966e4b85

Change-Id: I59da77da208e5360b43ad2c18389e7a0ff7b84d2
Reviewed-on: https://gerrit.libreoffice.org/40152Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: Ica9c66fe09f7340f76f62e536527dc63b3735d90

Change-Id: I27b0b82ac5be631c0d47f486603e241026dcabd9

and then turning it back into the code again

Change-Id: Iae9cddb18a6bdad4b1ba8c2af81f3d29a7f26725

Change-Id: I986352cd2db4a9bd794ec25fbef9168be08a70ce

Change-Id: I0624690f8af05adb2466219a4e508e634c490ef1
Reviewed-on: https://gerrit.libreoffice.org/40436Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

that way we can avoid the super slow code path for filtered
rows when we only care about selected shapes

Change-Id: I175fa841e406dbbe7075296f2e0a0e79fa115fb7
Reviewed-on: https://gerrit.libreoffice.org/40496Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>