summaryrefslogtreecommitdiff
path: root/include/sal
diff options
context:
space:
mode:
authorTor Lillqvist <tml@collabora.com>2014-07-14 20:23:22 +0300
committerTor Lillqvist <tml@collabora.com>2014-07-16 18:21:27 +0300
commitf4a2f1e647354efb75be8c90384d6cd3e5f9b9bd (patch)
tree3c444b19805895b9ca37c4614300c1a4a91197b3 /include/sal
parent9aeadc76a4f2c878f83f07959d9d1694ff13fddf (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
Diffstat (limited to 'include/sal')
-rw-r--r--include/sal/log-areas.dox1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/sal/log-areas.dox b/include/sal/log-areas.dox
index c22b8e690308..e09e2c5f2f1f 100644
--- a/include/sal/log-areas.dox
+++ b/include/sal/log-areas.dox
@@ -179,6 +179,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