Changed quite some places of SdrObjCustomShape usage to use
references instead of pointers, thus forcing to more secure
handling. Changed some test and change methods, even found a
memory leak by doing so.
Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7
In docx a colour value is represented as a 6-digit hex RGB value, or
alternatively the word "auto" to represent automatic colour.
- Add support for reading the value "auto" as COL_AUTO. Previously
this would be read as if it were a hex value, stopping at the
letter 'u' which is not a valid hex digit, resulting in the colour
0x00000A - a very dark blue, which looks close enough to black that
it went unnoticed for a long time :-)
- Remove code which tried to handle this wrong 0x00000A value,
including the constant OOXML_COLOR_AUTO, as it is no longer needed
and will cause surprises for anyone who really wanted this exact
shade of dark blue
- Fix unit tests that were checking for 0x00000A
Change-Id: I6000070341931147ff9341ad6281cd3b53c02b46
Reviewed-on: https://gerrit.libreoffice.org/50995
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This is preparing to change how GraphicManager works where it
won't base itself around GraphicObject anymore but Graphic. No
functional or cosmetic change was made to the classes, only
changes that were needed because of the move and rename.
The only thing that wasn't moved is the GraphicRenderer as it
is not needed in vcl for now (but makes sense to move it in the
future to keep graphic stuff together).
grfmgr was renamed to GraphicObject as the GraphicManager will be
changed a lot and most likely moved out, so the name grfmgr won't
make any sense anymore.
All the UNO implementations were renamed with a prefix Uno and
used the same name as the class name. This is made to be more
specific which are the Uno objects (for example graphic.cxx
contained the implementation of XGraphic, which is similar to
graph.cxx contains Graphic).
Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137
Reviewed-on: https://gerrit.libreoffice.org/51068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
when we open a cryptoapi encrypted binary msoffice document. That way when we
save as the same format, and try to reuse the generated keys for encryption, we
have matching std97 encryption keys available because we always export using
that scheme.
Change-Id: I25f24a01d102242615768255ce888acb08ef6447
Reviewed-on: https://gerrit.libreoffice.org/48680
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
I (tried to) keep the RTF filter style consistent locally with astyle in
the past, but now that's redundant when we have an enforcing
clang-format mechanism in place. So drop the astyle config and switch to
clang-format in the RTF filter case.
To minimize backport pain, do this shortly before the libreoffice-6-0
branch-off.
Change-Id: I708dbeb0b5ad2afacc90029ee5abba9495f4601f
This reverts commit a599eeab78, plus follow-up
fa4431449d "Avoid bogus loplugin:dllmacro
'unnecessary *DLLPUBLIC declaration ...'". See (abandoned)
<https://gerrit.libreoffice.org/#/c/42983/> "loplugin:dllmacro: Handle implicit
member functions" how this would have needed to be extended to give consistent
results across Linux and macOS, but then would have started to remove DLLPUBLIC
from entities that apparently need to at least have default type visibility on
macOS and started to make tests fail.
on classes which are fully defined in a header file
Rename the dllprivate plugin to dllmacro and add the functionality
there.
Change-Id: I4581d551c46a8f61213d95973f323359d08278d8
they were defined in escherex.hxx as SHAPEFLAG_*
and in msdffimp.hxx as SP_*.
Added include for escherex.hxx to msdffimp.hxx.
Filled the missing flag bits.
ShapeFlag::Deleted is not used at the moment.
Convert ADD_SHAPE macro to lambda.
Fix horizontal/vertical mixup in RtfSdrExport::AddLineDimensions.
Comments for flag Connector were wrong. The flag applies to shapes
which ARE connectors.
MSO definition: "connector: A line that is used to connect two
or more shapes and that remains connected to those shapes."
So Rectangles and such with Connector flag don't make sense.
Change-Id: I735de00110411b280a302840dc0fcdfac5156399
Reviewed-on: https://gerrit.libreoffice.org/41754
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Inline anchored VML shape had wrong vertical position
** In MSO inline shapes are positioned to the top of the baseline
* During export all shape ids were the same (shape_0)
** VML shapes used to be exported only as fallback,
I guess that's why it did not cause any issue before.
** Override the shapeid generator with a new one, which
actually generates unique shapeids.
Change-Id: I752f39d092d0b61d91824141655dae662dbeafbc
Reviewed-on: https://gerrit.libreoffice.org/41319
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Johnny_M