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 11:38:43 +0000 |
| commit | 7a34e0815d541709e96fcb7162895e90a8d08f30 (patch) | |
| tree | d39f63bdbba4f8c77c5d67fd18689a2e25a7637f /include | |
| parent | 61aabb7d814b634e29003d8b555938f40b6f6fb4 (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
Reviewed-on: https://gerrit.libreoffice.org/10359
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-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 7d8d70f6f0c2..46656e28dad0 100644 --- a/include/sal/log-areas.dox +++ b/include/sal/log-areas.dox @@ -140,6 +140,7 @@ certain functionality. @li @c filter.xslt - xslt import/export @li @c oox.cscode - 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 |