Age | Commit message (Collapse) | Author | Files | Lines |
|
Bug exposed with:
5259ab8104cfba60c40748ed0cd59d93df038c5b
sfx2 store: create temp files next to local files
bt:
6 0x00007faac67ad9b5 in sax_fastparser::FastSaxSerializer::FastSaxSerializer(com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> const&) (this=0x559f316f0e70, xOutputStream=empty uno::Reference)
at sax/source/tools/fastserializer.cxx:68
7 0x00007faac67c46e0 in sax_fastparser::FastSerializerHelper::FastSerializerHelper(com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> const&, bool)
(this=0x559f31721400, xOutputStream=empty uno::Reference, bWriteHeader=true) at sax/source/tools/fshelper.cxx:30
8 0x00007fa9bfa1b4cc in std::_Construct<sax_fastparser::FastSerializerHelper, com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>, bool const&>(sax_fastparser::FastSerializerHelper*, com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>&&, bool const&) (__p=0x559f31721400, __args=..., __args=@0x7ffecd609207: true)
at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/stl_construct.h:119
...
15 0x00007fa9bfa04087 in oox::core::XmlFilterBase::openFragmentStreamWithSerializer(rtl::OUString const&, rtl::OUString const&)
(this=0x559f318ed5f0, rStreamName="docProps/core.xml", rMediaType="application/vnd.openxmlformats-package.core-properties+xml") at oox/source/core/xmlfilterbase.cxx:511
16 0x00007fa9bfa04999 in oox::core::writeCoreProperties(oox::core::XmlFilterBase&, com::sun::star::uno::Reference<com::sun::star::document::XDocumentProperties> const&)
(rSelf=..., xProperties=uno::Reference to ((anonymous namespace)::SfxDocumentMetaData *) 0x559f2d673e28) at oox/source/core/xmlfilterbase.cxx:645
17 0x00007fa9bfa047c2 in oox::core::XmlFilterBase::exportDocumentProperties(com::sun::star::uno::Reference<com::sun::star::document::XDocumentProperties> const&, bool)
(this=0x559f318ed5f0, xProperties=uno::Reference to ((anonymous namespace)::SfxDocumentMetaData *) 0x559f2d673e28, bSecurityOptOpenReadOnly=false) at oox/source/core/xmlfilterbase.cxx:981
18 0x00007fa9bee21bd4 in DocxExport::WriteProperties() (this=0x7ffecd609d78) at sw/source/filter/ww8/docxexport.cxx:952
19 0x00007fa9bee24b0b in DocxExport::DocxExport(DocxExportFilter&, SwDoc&, std::shared_ptr<SwUnoCursor>&, SwPaM&, bool, bool)
(this=0x7ffecd609d78, rFilter=..., rDocument=..., pCurrentPam=std::shared_ptr<SwUnoCursor> (use count 1, weak count 1) = {...}, rOriginalPam=SwPaM = {...}, bDocm=false, bTemplate=false)
at sw/source/filter/ww8/docxexport.cxx:2149
20 0x00007fa9bee4438e in DocxExportFilter::exportDocument() (this=0x559f318ed5f0) at sw/source/filter/ww8/docxexportfilter.cxx:112
21 0x00007fa9bf9d6b8b in oox::core::FilterBase::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x559f318ed5f0, rMediaDescSeq=uno::Sequence of length 12 = {...})
at oox/source/core/filterbase.cxx:494
full bt here:
https://bugs.documentfoundation.org/attachment.cgi?id=193113
Patch prevents LO from crashing + make LO displays error message:
Error saving the document <filename>:
Write Error.
The file could not be written
Change-Id: I41a94eeb17bb6568b586d89755bce330154d1dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164808
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I94df85715874013a28167d417107b09609f0293e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164831
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia9e04aeda25f5a1b91950377c3eca335b443790b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164830
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I554f8b88e0f479c4fd27fcc6231e79d77371209e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164809
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ifcd144b89f1d5648a3c72471b691529251d26892
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164832
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Conversion of hex/dec colour notation
(example entry Color( 255, 255, 255), Color(0xFFFFFF) - COL_WHITE)
For the other available colour definitions.
Change-Id: I9eed0cd64adcbc8d25e1c22143a000906a457586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163729
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The patch it a continuation of commit 6e5529d7, that handles import of
the 3D-scene camera. This patch handles lighting of the 3D-scene. But
lighting in MS Office has features which we cannot yet render, address
in API or store in ODF. More than two lights, softing with Scale and
and Offset, or Specular/Diffuse for all lights are not implemented for
extruded shapes, for example. Thus the rendering results cannot be
equal to MS Office.
This patch contains a lot of workarounds and compromises to get a
rendering which looks somewhat similar. Unit tests are not really
meaningful in this situation. The included tests focus on the principle
aspects modern/legacy lightRigs and lightRig rotation.
The light rig values are taken from sections 2.1.1274 and 2.1.1321 in
[MS-OI29500] - v20231113.
https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oi29500
That version does not specify the used coordinate system for the
light directions. Find the discussion about that in
https://learn.microsoft.com/en-us/answers/questions/1551836
topic: LightDirection on shape with 3D effect is rendered different
than specified.
That version does not specify the values 'Specular' and 'Diffuse'
for legacy* light rigs. Find the discussion about that in
https://learn.microsoft.com/en-us/answers/questions/1608333
topic: What is 'Specular' and 'Diffuse' in the lightRig table in
section 2.1.1274 in [MS-OI29500]?
Change-Id: I91750dc231d0ea09115424d896d3a1260ba766ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164510
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
no need to pass it via the internal buffer of SequenceOutputStream when
we can read it directly
Change-Id: I832737d73309449a1f3a26a4b451977a2a580de3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164634
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d146806a8f96be0cd2323d716f12cba4e
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I42c6b7a8c7b0c0af17a2806c908f5a336ef206d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164599
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I'm really surprised this wasn't found much earlier.
Even DOC format isn't handling this.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf160049_anchorMarginVML
Change-Id: I92ee8eceb6c6bab5f027663bae94d7acdf01be3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164442
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
... so do not rotate the background image again. But because of
tdf#159515 the patch blocks extrusion for images that are imported as
background fill of a custom shape. To test that the fix works, you need
to change the code in shape.cxx. Remove the parameter bBlockExtrusion in
call of setExtrusionProperties() method and comment out the definition
of bBlockExtrusion variable.
Because of the blocked extrusion a unit test for tdf#159912 is currently
not possible.
Find more details about the patch in comment 4 in the bug report.
Change-Id: Ifa13988b18fbd5d63604ab0d0f3006e7ff480c02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164107
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Hmm, I like to complain when other people
don't comment on why certain situations are excluded,
and yet I did the same thing here.
Thanks vmiklos for pointing that out.
Change-Id: I4c5ddeaeee078f036fc31149fc29bc6acb277ab3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164040
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Change-Id: I4cab1e22f61113dd84b9ce77c639be5572ff9c77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164014
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I437af59b956753eaadea61db12500e5e7b45d9b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164008
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
In case of Stacked, PP calculates in the vertical direction
with the horizontal alignment.
We simulate it by setting TextVerticalAdjust at import time
(from PPTX) based on the ParagraphAdjust of the 1. paragraph
It is not perfect, because we have 1 TextVerticalAdjust / 1 shape,
and it does not support justified,
while we can have many ParagraphAdjust / 1 shape
(if the shape have more paragraphs)
For a better solution we should re-implement the entire stacked
thing, but that is a much bigger task.
Change-Id: I4011be0f118b870ab7f9e2ddc15c6dc5a21f8a89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163934
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Attila Szűcs <attila.szucs@collabora.com>
|
|
... and not as symmetrical linear gradients.
The benefit is that our export code
will be able to intelligently export it.
Apparently RTF export code does not intelligently export axials,
(now fixed - tdf#159824)
but VML and DML (and doc) do it well.
Unfortunately charts can be badly affected,
(avoided by ignoring when transparent)
and unit tests are implementation-tested...
This affects existing unit tests:
-tdf128345_Legend_CS_TG_axial.pptx: label imports fine:
lost on export (no change)
-tdf128345_ChartWall_CS_TG.pptx: wall gradient now looks axial:
lost on export (no change)
-textframe-gradient.docx: still round-trips OK: no change
-textframe-gradient.rtf: round-trips as linear: lost axial-ness
(now fixed: tdf#159824)
-fdo78663.docx: textbox font fill: still exports as solid: no change
I ran the assert check against chart2, oox, and sw
Change-Id: Ib16e9488a76b006bf335ff01a38acf7cde69cccb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163675
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and stop an automatic 180 reversal on import.
Some documents had gradient reversals on every round trip,
typically when the angle was 0-179
(mainly seen in ODT examples,
since DOCX/RTF imports defaulted to be angle 180).
The negative sign has special meaning,
indicating that the start and end colors
should be swapped.
Well, swapping colors was not intentional in the export logic.
Previously there was a mistaken idea
that any angles > 180 needed to be swapped on import,
and likely that is what prompted this overly complicated formula
to try to avoid any angle > 180 during export
by allowing negative angles.
This tdf#126533 patchset has already eliminated import checks
for angles > 180, so now a sane formula can be applied on export.
In order to do that, we have to avoid emulating color swaps
with 180 degree rotations at import time.
So ONLY do color swapping with start/end,
and leave the angle alone.
That GREATLY helps unit tests (which otherwise would flip-flop
the angle and the color start/stop).
Very unhelpful was an undocumented, indecipherable
inversion when converting to DML angle.
Boy, I hope I got this right...
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle3
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle4
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf126533_axialAngle2
Eliminating the inversion for ooxml7 test is fine
since inversion does nothing to an axial.
Otherwise, eliminating inversions corresponds to a color swap.
Change-Id: I2aae0a7595807569ffc740689ff3840692d6159d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163798
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
tdf#65295 already fixed one case
by removing the test for degrees > 180
for the linear-equivalent gradients.
Unfortunately the comment wasn't also removed,
so that was confusing: removed comment.
The test for degrees > 180 is not needed
for the axial-equivalent case either: removed.
The reason for that degrees > 180 case is likely due to
negative degrees, which is a documented reason
for swapping the colors: added swap if negative degrees.
All the affected, existing unit tests are improved now:
-tdf81345.docx: famous MS example: improved header gradient
-fdo78300.docx: fontworks: hard to tell without MCGR...
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf126533_negativeAxialAngle
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf77219_backgroundShape
Change-Id: I9f4d56375bb2cec28ffbd93df419d586da465b78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163417
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/oox/qa/unit/testscene3d.cxx(1): warning C4828: The file contains a character starting at offset 0x21ac that is illegal in the current source character set (codepage 65001).
Change-Id: Id1f69b2644ecb5302e15603dd5353a34757e76dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163782
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Discovered by https://gerrit.libreoffice.org/c/core/+/163717
Like these:
C:/lo/core/oox/source/export/shapes.cxx(2411): warning C4459: declaration of 'XML_line' hides global declaration
Change-Id: I74738753254ad1c468025d25bfb0bfe21787180f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3849d2263de113f09fc3f4839c156c2d0458d718
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163667
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
This depends on tdf#126533 which imports page style v:fill,
BUT ONLY IN ORDER TO support the unit tests.
The patch itself can stand alone
and fixes vml import into textboxes/shapes etc.
i.e. backporting could be possible by dropping the unit tests.
The pattern that VML uses to indicate foreground
and background is very different from what LO needs.
[Fortunately LO does not use the _guess_ from
vcl::bitmap::isHistorical8x8 to determine which
color is the background. Instead it always uses the first pixel.]
Documentation says that unspecified XML_fillcolor
and XML_color should be white, but observation
says it should be 25% gray (Word 2003).
25% gray == C0C0C0 == fillcolor="silver" == COL_LIGHTGRAY
Currently, we simply export as a colored, tiled image,
and not as a B&W type="pattern"
so no corresponding export changes need to be made to export.
Existing unit test documents that are affected:
-chart2export's PieChartDataLabels.docx (page background)
-ooxmlexport5's fdo77725.docx (minimized PieChartDataLabels.docx)
* both foreground and background are set to white => solid white
-sw/qa/core/data/ooxml/pass/fdo79131.docx (shape "inline")
make CppunitTest_sw_tiledrendering \
CPPUNIT_TEST_NAME=testTdf159626_yellowPatternFill
make CppunitTest_sw_tiledrendering \
CPPUNIT_TEST_NAME=testTdf159626_yellowPatternFillB
make CppunitTest_sw_tiledrendering \
CPPUNIT_TEST_NAME=testTdf159626_blackPatternFill
Change-Id: I9533ac4a7489081ffc62a10e900f5526abb906db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163106
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
When inserting and deleting content-controls
with change-tracking enabled, we hit a few
corner-cases that we need to handle more
smartly.
First, we shouldn't redline the controls
themselves, just the placeholder text.
Second, we have to take special care
to create valid XML structure with
the redline tags.
Includes unit-test that reproduces the
issues and verifies that both saving
and loading work as expected.
Change-Id: I6af4d0d2c3f0661e7990d5414cc93effc96f0469
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163647
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This patch imports bitmaps/tiled textures (primarily),
but also somewhat for gradients
(because of a gradient2 -> gradient mismatch somewhere)
and somewhat for patterns
(because patterns are not well imported in general).
Note that the imported fill likely will NOT match MSO,
because their background CHANGES BASED ON THE ZOOM LEVEL.
For example, my primary testing file (A6 landscape)
has a logo which is only 25% visible in Word 2003 at 100%,
but shows 90% of the logo at 200%, and many tiles of logos
when exported as PDF.
The same is true for gradients etc.
Changing background on zoom is an absolutely bizarre implementation,
and naturally LO could only accidentally look identical
(and should never try to do so).
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_noPageBitmap
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_pageGradient
This is slightly ugly, but I don't know how to make a COPY
of the XPropertySet UNO junk. All I have is references,
and dispose deletes everything, even the references.
I took some inspiration from RTF
which just disposes the shape after grabbing the background color.
Thus, just change the page style known to exist and be used,
and then simply remove the fill if it isn't needed in the end.
Any new page styles can just copy the default page style fill.
Change-Id: Id3ea002c685642ff4c289982d0108247a6e9bb8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162958
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I51796820bc4fdf3c792933b67a71b22c56fc36c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163642
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8ab5fc146f5787196db51fa45efd2639d8108107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163641
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I22372726ef167714076278eff9727ee79b951c56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163643
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I48d719c6e911f84f1609767df4f40f6f8684a0c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163640
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
ODF allows a 3D mode for custom shapes. That can be used to render
some of the 3D effects possible in MS Office.
MS Office has not published, how they calculate the 3D-scenes. Thus
most principles and values are found by experiments. My assumptions
are contained as comments.
This current solution does not work well for perspectiveFront camera
with rotation on only y-axis or on only x-axis. If someone has an idea,
what is wrong in my solution or what MS Office might specially do,
please tell me.
The tests do not cover whether the rendering in LO is the same as in
MS Office. I have no idea how to write such tests. To test manually:
In Powerpoint: Copy the shape and set the copy to wireframe. Cut the
copy and insert it as svg image. Move the image so that the lines cover
the original shape. Save it. In LibreOffice: Open the file and set the
shape to wireframe. Now you can easily compare the rendering of
PowerPoint and LibreOffice.
Extrusion can be used for images, that have a 3D-scene applied like in
tdf#45495. That would work with this patch, but the related places are
commented out because of tdf#159515.
This patch does not cover lighting and material and it does not
contain export.
3D-text is not contained in the patch. There are principle problems
with 3D-text. Thus a solution requieres a lot, including additions to
the ODF standard.
The comments in tdf#70039 contain more about aspects, where MS Office
and ODF are in principle incompatible in regard to 3D-effects.
Change-Id: I8a5da536ade2a4b67630af221ea47e0288450188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162594
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ie17b583af28d274b3e7817c646dd4f5873e03fef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160733
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For the benefit of MSO, do not write r:id="",
since MSO refuses to open such a document.
Change-Id: I21887021c747fc9a9764befc7081e21d99e47545
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163523
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Display Stacked text, and
Import/Export Stacked property from/to pptx.
It is a minimal implementation, it does not import/export to .odp,
there is no user interface to set this property.
Multiline Stacked text is rendered as 1 line text.
XML_wordArtVertRtl is mapped to XML_wordArtVert.
Editing of text containing space character seems to
not work correctly.
Change-Id: I535da45e3a2f2d1550bad2a40e9909e0d561d0ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163121
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
reduce log noise
Change-Id: I16a45c8c41292b245a507ee51924b2f465719c97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I71d94239c155f41d4535c023ea3aa8f974fcf2da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163082
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I2ecb6af11c95605c84e935b850fe94a1831a1497
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163043
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When we redline the ContentControl item
itself, we break docx XML. Instead, we
only need to redline the placeholder,
which we already do.
This simply disables redlining when
inserting the ContentControl item
while leaving it otherwise enabled
while inserting the placeholder.
Before:
<w:body>
<w:p>
<w:pPr>
<w:pStyle w:val="Normal"/>
<w:rPr></w:rPr>
</w:pPr>
==> <w:ins w:id="-1" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z">
<w:sdt>
<w:sdtPr>
<w12:checkbox>
<w12:checked w14:val="0"/>
<w12:checkedState w14:val="2612"/>
<w12:uncheckedState w14:val="2610"/>
</w12:checkbox>
</w:sdtPr>
<w:sdtContent>
<w:r>
<w:rPr></w:rPr>
</w:r>
==> </w:ins>
==> <w:ins w:id="0" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z">
<w:r>
<w:rPr></w:rPr>
<w:t>☐</w:t>
</w:r>
==> </w:ins>
<w:r>
<w:rPr></w:rPr>
</w:r>
</w:sdtContent>
</w:sdt>
</w:p>
</w:body>
The first <w:ins> and its closing tag
is not seen in the reference docx
file, and we can see that it's invalid
XML here.
After:
<w:body>
<w:p>
<w:pPr>
<w:pStyle w:val="Normal"/>
<w:rPr></w:rPr>
</w:pPr>
<w:sdt>
<w:sdtPr>
<w12:checkbox>
<w12:checked w14:val="0"/>
<w12:checkedState w14:val="2612"/>
<w12:uncheckedState w14:val="2610"/>
</w12:checkbox>
</w:sdtPr>
<w:sdtContent>
<w:r>
<w:rPr></w:rPr>
</w:r>
==> <w:ins w:id="0" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z">
<w:r>
<w:rPr></w:rPr>
<w:t>☐</w:t>
</w:r>
==> </w:ins>
<w:r>
<w:rPr></w:rPr>
</w:r>
</w:sdtContent>
</w:sdt>
</w:p>
</w:body>
Only the valid <w:ins> around the
placeholder exists.
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Change-Id: I1404e41aec3b5efdc2e4115236102ffa2733b15c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162802
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The problem in the bugdoc was the directory entries. These entries
are valid in ZIP packages (even if not common); they may be useful
to e.g. define per-directory permissions (ACLs).
In normal mode, ZipFile reads central directory; there we can read
if the entry has FAT file attributes; and then, if the entry is a
directory. Then it is OK to skip it.
In repair mode, central directory is not used, local file headers
don't contain a "directory" flag. A workaround is used, checking
if there are entries that represent directories of other entries.
Also this change fixes some places that didn't pass the recovery
flag correctly.
Change-Id: I324671841a2c4d0f279b03801d95c8f2eeb99b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162888
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... everywhere it is used to generate material for encryption.
Change-Id: Id3390376bb2f3a5fa1bbfd735850fce886ef7db2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162873
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
... and use a compatible 1/5 width if not specified.
This patch depends on the previous oox patch
(commit 301e27cbebf7d6e4c9b82290d7cd555c43f0c999)
which actually reads the width into the model.
Fixes a 7.2 regression from
commit b0068342398786ca50304260434a18880dddf74d
author Tünde Tóth on Wed Dec 16 18:26:26 2020 +0100
tdf#138777 pie chart: improve long data label width
and is basically a re-write of 7.1's
commit 20da1a5dd37c7edac620566c992d5a53b23a5f12
author Tünde Tóth <toth.tunde@nisz.hu> on Fri Oct 09 09:24:18 2020 +0200
tdf#134978 Chart OOXML Import: fix pie chart label custom position
This is very risky, but then ANYTHING changing chart2 is risky.
There were a lot of changes made in 7.1,
and they all invited regressions.
However, our chart implementation is not in a good state,
and certainly is not very interoperable,
so it is worth taking the risk.
Anything dealing with manualLayout at this point
should have originated as a pptx,
so forcing a compatible max width should be fairly safe.
It probably isn't actually all that risky after all.
largely copied code from
commit 4223ff2be69f03e571464b0b09ad0d278918631b
Author: Balazs Varga on Wed Jan 15 16:31:35 2020 +0100
tdf#48436 Chart: add CustomLabelPosition UNO API property
Fortunately this all goes away after a round-trip
since custom label placement is lost on export to OOXML,
and that really helps to reduce the risk.
make CppunitTest_chart2_import CPPUNIT_TEST_NAME=testTdf146487
Change-Id: I9722fc6c759c15ac3924780e6fc124f02fba07e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162590
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The width of text labels in pie charts is currently determined
completely arbitrarily.
If the file specifies X and Y coordinates along with W and H sizing,
then perhaps it is appropriate to use this?
We currently import but ignore X/Y,
so lets also make W/H available
so we at least have a chance to ignore those too.
Change-Id: I5caa48cf899e4e290eb2e8e78f731b6c5bcdd017
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162589
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Change-Id: Iac0985783a0c7334bd6ee3cfcaf37c135ac452ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162682
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove
non-const Sequence::begin()/end() in internal code, 2021-10-15) and
commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
probably an issue since:
commit 135ce256ce9e879663d828ec6e699de521fad867
Date: Mon Aug 14 15:59:18 2023 +0200
tdf#146487 Don't show generic diagram title when there is an empty title given
Change-Id: I12d8d6e78a8435b998084221402b6bdfc4a1a433
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162526
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
when the PPTX file only has table style id, but no table style content.
Change-Id: Ia3416478716a50beb6837988e98697fd88e916d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162368
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
|
|
...in code newly introduced in 135ce256ce9e879663d828ec6e699de521fad867
"tdf#146487 Don't show generic diagram title when there is an empty title
given", which caused CppunitTest_chart2_export2 to fail with
> /oox/inc/drawingml/chart/plotareaconverter.hxx:78:62: runtime error: load of value 222, which is not a valid value for type 'bool'
> #0 0x7f95cd9ed87c in oox::drawingml::chart::PlotAreaConverter::isSingleSeriesTitle() const /oox/inc/drawingml/chart/plotareaconverter.hxx:78:62
> #1 0x7f95cd9e506f in oox::drawingml::chart::ChartSpaceConverter::convertFromModel(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::awt::Point const&) /oox/source/drawingml/chart/chartspaceconverter.cxx:189:53
> #2 0x7f95cd9b6c34 in oox::drawingml::chart::ChartConverter::convertFromModel(oox::core::XmlFilterBase&, oox::drawingml::chart::ChartSpaceModel&, com::sun::star::uno::Reference<com::sun::star::chart2::XChartDocument> const&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::awt::Point const&, com::sun::star::awt::Size const&) /oox/source/drawingml/chart/chartconverter.cxx:93:20
> #3 0x7f95ce548f59 in oox::drawingml::Shape::finalizeXShape(oox::core::XmlFilterBase&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&) /oox/source/drawingml/shape.cxx:2245:50
> #4 0x7f95438150b2 in oox::xls::Shape::finalizeXShape(oox::core::XmlFilterBase&, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&) /sc/source/filter/oox/drawingfragment.cxx:113:30
> #5 0x7f95ce5267bb in oox::drawingml::Shape::createAndInsert(oox::core::XmlFilterBase&, rtl::OUString const&, oox::drawingml::Theme const*, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, bool, bool, basegfx::B2DHomMatrix&, oox::drawingml::FillProperties const&, std::shared_ptr<oox::drawingml::Shape>) /oox/source/drawingml/shape.cxx:1964:9
> #6 0x7f95ce4edb54 in oox::drawingml::Shape::addShape(oox::core::XmlFilterBase&, oox::drawingml::Theme const*, com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, basegfx::B2DHomMatrix const&, oox::drawingml::FillProperties const&, std::__debug::map<rtl::OUString, std::shared_ptr<oox::drawingml::Shape>, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, std::shared_ptr<oox::drawingml::Shape> > > >*, std::shared_ptr<oox::drawingml::Shape>) /oox/source/drawingml/shape.cxx:366:41
> #7 0x7f954381ef79 in oox::xls::DrawingFragment::onEndElement() /sc/source/filter/oox/drawingfragment.cxx:335:30
> #8 0x7f95cdcaee54 in oox::core::ContextHandler2Helper::implEndElement(int) /oox/source/core/contexthandler2.cxx:125:9
> #9 0x7f95cdd5c116 in oox::core::FragmentHandler2::endFastElement(int) /oox/source/core/fragmenthandler2.cxx:91:5
> #10 0x7f95caf68fca in (anonymous namespace)::Entity::endElement() /sax/source/fastparser/fastparser.cxx:514:27
> #11 0x7f95caf68998 in sax_fastparser::FastSaxParserImpl::callbackEndElement() /sax/source/fastparser/fastparser.cxx:1331:17
> #12 0x7f95caf58444 in (anonymous namespace)::call_callbackEndElement(void*, unsigned char const*, unsigned char const*, unsigned char const*) /sax/source/fastparser/fastparser.cxx:338:18
> #13 0x7f960adebeda in xmlParseEndTag2 /workdir/UnpackedTarball/libxml2/parser.c:10090:2
> #14 0x7f960ad929b5 in xmlParseTryOrFinish /workdir/UnpackedTarball/libxml2/parser.c:11868:14
> #15 0x7f960ad86334 in xmlParseChunk /workdir/UnpackedTarball/libxml2/parser.c:12151:5
> #16 0x7f95caf53231 in sax_fastparser::FastSaxParserImpl::parse() /sax/source/fastparser/fastparser.cxx:1085:21
> #17 0x7f95caf4cd18 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:890:9
> #18 0x7f95caf6e950 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:1470:13
> #19 0x7f95cdce50d1 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) /oox/source/core/fastparser.cxx:121:15
> #20 0x7f95cdce5868 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) /oox/source/core/fastparser.cxx:129:5
> #21 0x7f95cddbb234 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) /oox/source/core/xmlfilterbase.cxx:414:21
> #22 0x7f95cddb9b8d in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) /oox/source/core/xmlfilterbase.cxx:344:12
> #23 0x7f95441ceaa8 in oox::xls::WorkbookHelper::importOoxFragment(rtl::Reference<oox::core::FragmentHandler> const&) /sc/source/filter/oox/workbookhelper.cxx:1046:27
> #24 0x7f95442797f1 in oox::xls::WorksheetGlobals::finalizeDrawings() /sc/source/filter/oox/worksheethelper.cxx:1373:9
> #25 0x7f95442789e0 in oox::xls::WorksheetGlobals::finalizeDrawingImport() /sc/source/filter/oox/worksheethelper.cxx:996:5
> #26 0x7f954428744d in oox::xls::WorksheetHelper::finalizeDrawingImport() /sc/source/filter/oox/worksheethelper.cxx:1637:17
> #27 0x7f95441771de in oox::xls::WorkbookFragment::finalizeImport() /sc/source/filter/oox/workbookfragment.cxx:511:18
> #28 0x7f95cdd5b3ae in oox::core::FragmentHandler2::endDocument() /oox/source/core/fragmenthandler2.cxx:53:5
> #29 0x7f95caf4cfc2 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:896:36
> #30 0x7f95caf6e950 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) /sax/source/fastparser/fastparser.cxx:1470:13
> #31 0x7f95cdce50d1 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) /oox/source/core/fastparser.cxx:121:15
> #32 0x7f95cdce5868 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) /oox/source/core/fastparser.cxx:129:5
> #33 0x7f95cddbb234 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) /oox/source/core/xmlfilterbase.cxx:414:21
> #34 0x7f95cddb9b8d in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) /oox/source/core/xmlfilterbase.cxx:344:12
> #35 0x7f95435c4daa in oox::xls::ExcelFilter::importDocument() /sc/source/filter/oox/excelfilter.cxx:113:25
> #36 0x7f95cdcf953b in oox::core::FilterBase::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /oox/source/core/filterbase.cxx:488:49
> #37 0x7f95435c7733 in oox::xls::ExcelFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /sc/source/filter/oox/excelfilter.cxx:176:25
> #38 0x7f95857c5b40 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) /sfx2/source/doc/objstor.cxx:2393:34
> #39 0x7f9585781c6a in SfxObjectShell::DoLoad(SfxMedium*) /sfx2/source/doc/objstor.cxx:761:23
> #40 0x7f95859a9652 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /sfx2/source/doc/sfxbasemodel.cxx:1980:36
> #41 0x7f95862145e9 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) /sfx2/source/view/frmload.cxx:720:28
> #42 0x7f95536a9900 in framework::LoadEnv::impl_loadContent() /framework/source/loadenv/loadenv.cxx:1176:37
> #43 0x7f95536a091b in framework::LoadEnv::start() /framework/source/loadenv/loadenv.cxx:412:20
> #44 0x7f9553698f59 in framework::LoadEnv::startLoading(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&, int, LoadEnvFeatures) /framework/source/loadenv/loadenv.cxx:308:5
> #45 0x7f95536946e7 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/loadenv/loadenv.cxx:168:14
> #46 0x7f955376867d in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/desktop.cxx:591:16
> #47 0x7f95537688a6 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/desktop.cxx
> #48 0x7f9569f7cafa in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /unotest/source/cpp/macros_test.cxx:71:62
> #49 0x7f9580718c56 in UnoApiTest::loadWithParams(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /test/source/unoapi_test.cxx:126:19
> #50 0x7f9580717ef8 in UnoApiTest::load(rtl::OUString const&, char const*) /test/source/unoapi_test.cxx:108:5
> #51 0x7f9580719254 in UnoApiTest::loadFromFile(std::basic_string_view<char16_t, std::char_traits<char16_t> >, char const*) /test/source/unoapi_test.cxx:132:5
> #52 0x7f95d8bf1018 in testTdf123647::TestBody() /chart2/qa/extras/chart2export2.cxx:1242:5
(<https://ci.libreoffice.org//job/lo_ubsan/3048/>)
Change-Id: I870d811e78b8c55b84627ae609f98f623465dd9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162294
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
> oox/source/crypto/CryptTools.cxx:57:40: error: 'HMAC_CTX_free' is deprecated [-Werror,-Wdeprecated-declarations]
> void operator()(HMAC_CTX* p) { HMAC_CTX_free(p); }
> ^
> workdir/UnpackedTarball/openssl/include/openssl/hmac.h:35:1: note: 'HMAC_CTX_free' has been explicitly marked deprecated here
> OSSL_DEPRECATEDIN_3_0 void HMAC_CTX_free(HMAC_CTX *ctx);
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
> # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
> # define OSSL_DEPRECATED(since) __attribute__((deprecated))
> ^
> oox/source/crypto/CryptTools.cxx:112:29: error: 'HMAC_CTX_new' is deprecated [-Werror,-Wdeprecated-declarations]
> mpHmacContext.reset(HMAC_CTX_new());
> ^
> workdir/UnpackedTarball/openssl/include/openssl/hmac.h:33:1: note: 'HMAC_CTX_new' has been explicitly marked deprecated here
> OSSL_DEPRECATEDIN_3_0 HMAC_CTX *HMAC_CTX_new(void);
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
> # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
> # define OSSL_DEPRECATED(since) __attribute__((deprecated))
> ^
> oox/source/crypto/CryptTools.cxx:125:9: error: 'HMAC_Init_ex' is deprecated [-Werror,-Wdeprecated-declarations]
> HMAC_Init_ex(mpHmacContext.get(), rKey.data(), rKey.size(), aEvpMd, nullptr);
> ^
> workdir/UnpackedTarball/openssl/include/openssl/hmac.h:43:1: note: 'HMAC_Init_ex' has been explicitly marked deprecated here
> OSSL_DEPRECATEDIN_3_0 int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
> # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
> # define OSSL_DEPRECATED(since) __attribute__((deprecated))
> ^
> oox/source/crypto/CryptTools.cxx:499:12: error: 'HMAC_Update' is deprecated [-Werror,-Wdeprecated-declarations]
> return HMAC_Update(mpImpl->mpHmacContext.get(), rInput.data(), nActualInputLength) != 0;
> ^
> workdir/UnpackedTarball/openssl/include/openssl/hmac.h:45:1: note: 'HMAC_Update' has been explicitly marked deprecated here
> OSSL_DEPRECATEDIN_3_0 int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data,
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
> # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
> # define OSSL_DEPRECATED(since) __attribute__((deprecated))
> ^
> oox/source/crypto/CryptTools.cxx:512:12: error: 'HMAC_Final' is deprecated [-Werror,-Wdeprecated-declarations]
> (void) HMAC_Final(mpImpl->mpHmacContext.get(), aHash.data(), &nSizeWritten);
> ^
> workdir/UnpackedTarball/openssl/include/openssl/hmac.h:47:1: note: 'HMAC_Final' has been explicitly marked deprecated here
> OSSL_DEPRECATEDIN_3_0 int HMAC_Final(HMAC_CTX *ctx, unsigned char *md,
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0'
> # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0)
> ^
> workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED'
> # define OSSL_DEPRECATED(since) __attribute__((deprecated))
> ^
Change-Id: Ia9edc299b7cd4728fe32adbca8e1212170c328ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Bugdoc has autoTitleDeleted set to false (so title should be visible), but then an empty title is given.
In this case no default string should be added to the title, only in case of Pie Charts.
Any other Chart types show the default title in MS-Office.
Co-authored-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Change-Id: Ib445099a4a3d113cff6b1ffdfd093fe41c34716b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155681
Tested-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Importing the text marks the object as not empty. Then, the object would
behave as an outliner object. This includes showing in slide show; allowing
text esiting; stretching the placeholder image, which required a workaround
implemented in commit 7b3be7f6f3d800e2ad86f5a043e6e9b21ed4409f (tdf#140912
Better handling of the picture placeholders, 2021-12-01).
Instead, drop the custom prompt. More correct solution would be making sure
to mark the object as empty after setting the text; but this doesn't round-
trip to ODF; and it crashes export to PPTX. Proper support for the sustom
placeholder prompt feature should be done separately.
The new workaround (dropping the text) makes previous workaround (special
handling of the placeholder graphic) unnecessary. The unit test is updated.
Change-Id: Ic7f42493af8d1d725ffa39ffab58f1ff033351cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162202
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3d23186045c17006e50d9ef48bc26df3c79d28b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162052
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|