refactor handling of double border widths:

Word uses a completely different definition of "width" of a double border
than OOo and ODF: for Word the width is apparently the largest of the 3
component widths, while OOo and ODF define the width as the total with of
all 3 components.  The new border implementation in LO 3.4 was apparently
inspired by Word's double border definition, which resulted in
various import filter regressions, see the previous fixes:

36e43b52992735c622833e923faa63774b9e2f76
e2ffb71305c5f085eec6d396651c76d6daee3406
70a6a4d425558340bb49507975343a3e0a1bdde8

These fixes set the ScaleMetrics, which actually seems sub-optimal as
there is a ScaleItemSet function somewhere that apparently re-scales
all items in an itemset, which could undo the fixes.

Also, one of the fixes actually managed to break RTF/DOCX import
of double borders, as that ended up in the same code via the API.

This commit now reverses the change, so that the width of a border is
now always the total with of all components, which is (imho) much more
intutitive, and also leads to a consistent UI where selecting say 3pt
width has predictable results, no matter what the border style.

The border widths are now converted in the Word format import/export
filters (writerfilter and sw/source/filter/ww8), and various tests
were adapted to the new handling.

(cherry picked from commit 2d045cdb69176b280812dda0b813371cf1ac72e2)

Conflicts:
	sw/qa/extras/ooxmltok/ooxmltok.cxx

Change-Id: I50456c49b1a298569607e6c88f19f18441348ac3

0 files changed, 0 insertions, 0 deletions