diff options
| author | Tor Lillqvist <tml@collabora.com> | 2014-07-14 20:23:22 +0300 |
|---|---|---|
| committer | Andras Timar <andras.timar@collabora.com> | 2014-07-17 13:29:21 +0200 |
| commit | 2d87310f83da8ceb7f7e0e12296a6e3c6a41a67b (patch) | |
| tree | 058272c38cd1597478c9c2ae1471ad1a7079ff9a /include | |
| parent | 7e68478edc0ad24c11657d12ed4f8289393ce1d2 (diff) | |
bnc#862510: Improve handling of OOXML gradients
OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients
have just a start and end colour, plus an optional uniformly coloured border
(on the "start" side). In addition, LibreOffice has the "axial" gradient mode,
which means the gradient is reflected in the middle.
It is thus obviously impossible in general to losslessly map OOXML gradients
to LibreOffice ones. But let's try a bit harder than earlier to get visually
more similar result, in at least some simple sample cases.
We look for the widest gradient segment and use that for the start and end
colours of the LibreOffice gradient.
Also, map an OOXML gradient to an axial LibreOffice gradient only if it is
symmetrical. Also, use the border property when suitable. In general, look for
the widest OOXML gradient segment (once a segment corresponding to the
LibreOffice gradient border, if any, has been accounted for) and use that as
the LibreOffice gradient.
Possibly some perceptionally better heuristic should be used... Like, if we
have a three-segment gradient, with a wide gradient segment between two
visually very similar colours (for example, two shades of red), and a narrower
segment ending with a visually very different colour (for example, yellow), it
probably would be best to represent that in LibreOffice as a gradient from the
first red shade to yellow, instead of as a gradient between the two shades of
red. Or even, if a first or last gradient segment is between very similar
colours, equalize those start and end colours, thus using a border colour in
LibreOffice instead. The possibilities for bikeshedding are endless.
I am sure there are instances where the old code (by accident?) produced
visually more pleasing results... But hopefully this works more pleasingly and
consistently in a larger number of cases.
Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
(cherry picked from commit f4a2f1e647354efb75be8c90384d6cd3e5f9b9bd)
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Diffstat (limited to 'include')
| -rw-r--r-- | include/sal/log-areas.dox | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/sal/log-areas.dox b/include/sal/log-areas.dox index 826872d6a514..0fb8193eb4ce 100644 --- a/include/sal/log-areas.dox +++ b/include/sal/log-areas.dox @@ -177,6 +177,7 @@ certain functionality. @li @c oox.cscode - see oox/source/drawingml/customshapes/README @li @c oox.csdata - see oox/source/drawingml/customshapes/README @li @c oox.drawingml - DrawingML +@li @c oox.drawingml.gradient @li @c oox.ppt - pptx filter @li @c oox.storage - ZipStorage class @li @c oox.xmlstream - XmlStream class |