If an extruded custom shape is mirrored, the lights in the scene are
also mirrored. This should not happen. MS Office keeps the light
direction in relation to the camera direction for binary files and pptx
files with legacy camera. We should do the same, especially since the UI
does not allow the user to set the light directions at arbitrary angles.
Otherwise the shape receives only ambient light.
Change-Id: I091d78c581b3d247f8b0680cd57654e3df330cdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165562
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
This removes the code that handles the IO_PENDING and the graphic
"context" handling from XBM image format.
Partial loading of images complicates the image filter life cycle
a lot (many exceptions) and is not really needed so much today as
this was needed in the past. In most cases we load the whole image
in one pass anyway. Even loading from the network should be fast
enough to not cause issues for the user.
Most image filters don't even implement this like PNG and nobody
noticed for many years that this is not supported.
To handle IO_PENDING case it is probably better to load the
bitstream into memory and then load the whole image after that
in one pass. This can also be implemented all inside (Imp)Graphic
in a very straight forward way.
Change-Id: Idb11f4ffa821467374b19f22b5841cfe940b9457
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165208
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
We reset the last used member variable in many places in the same
way, so instead of duplicating the implementation, add that to a
method.
Change-Id: I747559ecf1a6736f976b4d560ab5052c19431898
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165207
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Graphic memory manager was changes so that it can work with any
object that implements a specific interface (MemoryManaged). With
this it will be possible to use other objects (that take a lot of
memory) to be managed by the manager. It is also a first step to
move memory managin responsibilities away from Graphic and move
it into the specific objects instead (BitmapEx, Animation and
VectorGraphic).
Change-Id: I7638bd89a1c9ece5c4bc95b506d2192492894ef3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164958
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The command NewGlobalDoc is not supported by Calc, Impress and Draw, so they should not exist in the Tabbed UI. Otherwise, a gap appears, since there's no info about this command.
Change-Id: I0dd2b4639cfb44437d6726d6f138c4767c5a3175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165351
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
As part of the efforts in #42982 to improve the UNO API
error reporting, this commit adds error messages in several
files to help improve debugging experience.
Change-Id: I7a51d4fd1e3a57798d70bc3464b034649948a287
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165253
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
The "TextAutoGrowHeight" property doesn't shrink the shape automatically
when its content is smaller than the current size.
Change-Id: Ia7f94d7452d1a1c3f004aebd73b6ed5cbfd9b43b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165551
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
to reproduce the underlying problem: data, calc, recalculate hard:
which asserts that cell I367 is dirty during parallel calc
checking the dependencies for a parallel calc is supposed to find what
cells it depends on and either: ensure they are not dirty or detect its
not possible to do the parallel calc
checking starts in J9 where::
J9: =SUM(H$8:H9)-SUM(I9:I$9)
J10 =SUM(H$8:H10)-SUM(I10:I$9)
for the first sum it detects that the input range is H9:H367 and checks
that for dirty results, but for the second sum it detects a range of
just I9 and the dirty I367 is not detected and the problem arises on
calculation
The code to detect the range is:
// The first row that will be referenced through the doubleref.
SCROW nFirstRefRow = bIsRef1RowRel ? aAbs.aStart.Row() + mnStartOffset : aAbs.aStart.Row();
// The last row that will be referenced through the doubleref.
SCROW nLastRefRow = bIsRef2RowRel ? aAbs.aEnd.Row() + mnEndOffset : aAbs.aEnd.Row();
where for the I9 case has nFirstRefRow true and nLastRefRow false so we
just get a range of I9:I9 instead of I9:I367.
Trying to create a doc from scratch to reproduce this case proves
tricky, so trim down the original document to the sheet and subset
of columns that can trigger it.
Change-Id: I44bfd1f6d3a3ee13db9024c5b2efa2588cc30521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165510
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
LibreOffice embeds RTL/LTR direction markers in currency strings, which
defeats the default gtk search mechanism, so switch in our one instead.
Change-Id: Ia118f8c8e27103c21955683f8a2fd3c17c2b2098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165557
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
so for the case of using "automatic" for the document background the
spelling checking textbox background area updates to match
Change-Id: I8723afb946176596b0a5fa43aa3bb3c036dee12c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165554
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
we know that ScPatternAttr uses a single, contiguous range of
item ids, so we can compute the item offset at compile time.
Shaves 1-2% off some workloads.
Change-Id: I623b8cb3e0d5d070118117196d2b48575f505725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165550
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
