Age | Commit message (Collapse) | Author |
|
Change-Id: Ic76ccc49b9291fe82c56974eb6237cd3b85d91c8
|
|
This is supported in GCC 4.6.0 already:
https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html
Change-Id: I2f67e588eea3a323a2e9c81e39e56ab2e715a817
|
|
This has been supported by GCC and clang for a very long time.
Change-Id: I410a2b39004c932003f8cbefe935aedb109b1163
|
|
Change-Id: I9c879cc16de0d5353a5ab8ce4c8a8cd7f000a170
|
|
Change-Id: I3339324ec99bbed56f81f2aa4e6cf54edcbec8e6
|
|
Change-Id: I26fa823b987b2edfbb1be054a5f4d03bbe95a308
|
|
Change-Id: I0e2b38ab8e7fae483539e02e93d25d2532bd70ef
|
|
Change-Id: I9691048ca7dc6e18cc904b29e8f6f59b11e002cf
|
|
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
|
|
Change-Id: I885acc9b4a52835fa256c2ecd1b8da917b4f7ba7
|
|
Change-Id: If7704edc5baa9759abc680b8d2040b9cdfe92317
|
|
Change-Id: Ia5fbdfd83971ac946de6d022be55d5a286a1bf5a
|
|
...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
|
|
Change-Id: Ia3fe1ff0075434d0b6903bf978c16499e07d699d
|
|
Change-Id: I3d389174684cdc86ddb098629da57ebf142424c9
|
|
Change-Id: Ie60e0b64a2d9d8a045cb3c59fc781d6f9b2808a0
|
|
Change-Id: I095f45b537690fe98bf385d99194db6319d7ac93
|
|
While at it, make it use SAL_INFO instead of fprintf.
Change-Id: Id4018819f8f790bef219e5aca3b6bbb5f6acd6aa
|
|
Change-Id: Ife10cae3f0bd7dd294c74799412528f2596369c8
|
|
Change-Id: I77e10d2644b18b150f9489c7f754405974af107a
|
|
Change-Id: Ic3e2a5ed247b35b4e6d80a4ad824bc9b535783fb
|
|
Change-Id: I2bad7938ddd02da8aa7191aebbd9221220fb303e
|
|
Use avmedia.opengl to be more explicit.
Change-Id: I07878c3648de2e4786bf8a5144ef0c1fbb5530f1
|
|
Change-Id: Ia89a2dce799c7ba90bcd19919195bfd2c7a4a180
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7362c843ae7abae74e82b330832cb007478d853c
|
|
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
|
|
Change-Id: I6f4ed9a816c13d35b92059c68132d90fe532b321
|
|
Change-Id: Ib7b19a53fe6b523b302276d5123c070eb46a4737
|
|
Change-Id: Iaca31b4e12c258b762b3d88fbad0fb08b4f1fc16
Reviewed-on: https://gerrit.libreoffice.org/8832
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Conflicts:
include/sal/log-areas.dox
Change-Id: I770b8b9fb82f873ccb88dc26ac05206f703ddf33
Reviewed-on: https://gerrit.libreoffice.org/8805
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
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
|
|
Change-Id: Iaf2de623c0893b0f500d54ce6558bf40af6e655b
|
|
Change-Id: Iaaf36d012e353f73f083c9c0ebbbb6d0953b16c8
|
|
Change-Id: I3773f5432ff4e2a005e0c67d9c65fdb00de6f16b
|
|
Change-Id: I9c809cae0420e73d2e4a447b9d8a3a03e42dc723
|
|
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
|
|
Change-Id: I6383ae3f94fc18aec92596b9d857d3fde5869dd6
|
|
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
|
|
Change-Id: Iba543bf0642071ab4a9164af8a4bcb35ac1ecfd0
|
|
Change-Id: I4553ce218fbcf2ac681b284c71e7d558a451511c
|
|
Change-Id: I5fe47cfaee84c17584ba7c3d160e65b55f4e3474
|
|
Change-Id: Ia94c417be95f5cd8c1d694a61c5004b0e8486416
|
|
Which can happen on mobile platforms if we don't want them.
Change-Id: I53639ccc75886708850d2d3a01eec76104b7f2c9
|
|
Change-Id: If4aba89909a3ef049a756182c37d8a5d6812ae70
|
|
Changed OSL_ASSERT to SAL_WARN_IF
Change-Id: I6f81a265aefe769e1449b1f10c796bf3aa1d0f1c
|
|
Change-Id: I63a990dca554c9defd4f168fa250ebc1685baafd
|
|
Change-Id: Ia1ad04c24f0d50cdb5aac3a5f6d5171bd5c23c70
|
|
Change-Id: I61579c7f84bb3df0d9c493cb93b47a00b0d174b4
|
|
Change-Id: I497d2d93e1a1819ff709c94007ae98f5ef312e77
|