office-gobmx/editeng/inc
Michael Stahl 2d045cdb69 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:

36e43b5299
e2ffb71305
70a6a4d425

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.

Change-Id: I50456c49b1a298569607e6c88f19f18441348ac3
2012-07-04 17:55:45 +02:00
..
editeng refactor handling of double border widths: 2012-07-04 17:55:45 +02:00
editeng.hrc re-base on ALv2 code. 2012-06-21 15:00:05 +01:00
editxml.hxx re-base on ALv2 code. 2012-06-21 15:00:05 +01:00
helpid.hrc re-base on ALv2 code. 2012-06-21 15:00:05 +01:00