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
...no reason to not have it enabled for URE C include files and what
little real C code is still left. (But note that Clang ignores that
warning.)
Change-Id: Ia6940f9f940a0c226e9b724331d65c9862ce32e6
It was already possible to dump a PropertyMap as code, but not as data.
The plan here is that if we dump the customshape preset definitions as
data, then once there is a parser for it, we can get rid of the ugly
generated code.
Change-Id: If596941fedf71693e5d0bff436446ac0855c4c84
Store them under /Model/<json_file_name_without_extension>/
modeltools: functions for handling 3D models inside avmedia
Change-Id: Ia2bdad6064db372e1c946b6ab02c434545d1ed45
One would think there would exist some kind of shim library that would
automatically provide such traces, hmm.
Change-Id: I568d02a2ac70078dee0280d1feb3eab7bbd43030
This reverts commit 04b70c682e2cdc52b144961a83d05fd203de6884.
The OpenGLRender is not abstract enough for vcl. Leave it in chart2.
Conflicts:
chart2/source/view/inc/DummyXShape.hxx
chart2/source/view/main/OpenGLRender.hxx
vcl/Library_vclopengl.mk
Change-Id: I5392c8ee34462ff49059126ca2284d8ebe1eb379
Attempt to make some more complex documents render OK.
Stop using SvpSalVirtualDevice on iOS. Use AquaSalVirtualDevice in all
cases. Do use a CGLayer (the AquaSalVirtualDevice::mxLayer field)
after all, like on OS X.
Change-Id: I7f7dc00c526453786cc871fd88dfb73517b15c39
