Age | Commit message (Collapse) | Author |
|
Change-Id: I5d6c4a67cb2a09e7cd5bd620c6b262d188701b89
Reviewed-on: https://gerrit.libreoffice.org/34714
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id4faf59eab8c72a2d78157bca15a5e07f9622dde
Reviewed-on: https://gerrit.libreoffice.org/34512
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>
|
|
... and update the tests accordingly.
Change-Id: Id11f2d19274e743b0e2a0bbeb0c21936f12b7777
|
|
Change-Id: I88a5cbc952a1ddc2f8ccd5f34b86bf797916171c
|
|
Improved readability of calls to osl::Condition::wait.
Change-Id: I69fb9815561013f1eb9fd4a649e32902e09473c6
Reviewed-on: https://gerrit.libreoffice.org/34399
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I.e. the test documents now reflect what is created by LO if you insert
a PDF image into a document manually on master.
Change-Id: Ibacce15220a21b159b5e987678c381a98a29fd1a
|
|
Replace creating a full Draw component with direct pdfium library calls.
This also means that the result is now a bitmap, not a metafile for now.
Also decouple HAVE_FEATURE_PDFIMPORT and HAVE_FEATURE_PDFIUM, the first
is the "import PDF into Draw" feature, the second is the "insert PDF as
image" feature.
Change-Id: I72c25642ec84cc831df362e02b1520c6e6d9adcf
Reviewed-on: https://gerrit.libreoffice.org/34217
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I47bf134a7ef0ebcd45ec3cc2c7cf805387ecadb9
|
|
Change-Id: Ib6434063f4dfebb5f3e180c7136b411dbf0d94d0
|
|
For SVG there are 2 draw:image children in the draw:frame, and the
SdXMLEventContext::EndElement() applies the content of
office:event-listeners to the shape created from the last draw:image
and then MultiImageImportHelper::solveMultipleImages() throws
it away because it's the bitmap fallback of the SVG.
Avoid that problem by calling solveMultipleImages earlier:
The ODF schema ensures that all the draw:image elements occur before
the optional property-bearing child elements of draw:frame,
so we just call solveMultipleImages on the first such optional
element, so that all subsequent properties get applied to the one
surviving shape.
(likely regression from 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70)
Change-Id: I2be5f6f424dbfd90ca2179ce6f9057929540e762
|
|
Change-Id: I88af4618dfbeab920163117c2da9e51fcf694d84
|
|
For a gradient fill we need to generate a name because
ODP export works with this name.
In case of shapes it works because when fill attribute
changes some internal name generation is triggered.
The same thing doesn't work for slide background
so generate this name explicitely in oox code.
Change-Id: Ic6ebf37ef3d66a9c274747ca04653363b1fe6d02
Reviewed-on: https://gerrit.libreoffice.org/33937
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
A few properties of FillProeprties have the same nWID
but have different nMemberId, such as FillGradient,
FillGradientName,FillHatch,FillHatchName, FillBitmap,
FillBitmapName, and FillBitmapURL.
When putting value of an item, the default item was put
first, despite the value of the item might have already
been put.
Move the part of the code that put default item upfront
so that it will not overwrite actual value accidentally.
Change-Id: I54288420abde333e5b3e4cdd31ca9fae0c3ed7ab
Reviewed-on: https://gerrit.libreoffice.org/33594
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
reference classes, uno::Reference and rtl::Reference.
Specifically rename Is()->is() and Clear()->clear().
Change-Id: Icb7e05e2d09cb9977121508b837ba0961dabb4ae
Reviewed-on: https://gerrit.libreoffice.org/33576
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In part of a table shape is selected, then only operate on the selected
cells, not on all of them.
Change-Id: I3a9ba2b99bcaa2e355b6fcdafdd142d4a809bce6
Reviewed-on: https://gerrit.libreoffice.org/33524
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The indentation in these files is consistent otherwise, let's keep it
that way.
Change-Id: I1d73caa03425cd4d1c98ff07935512b002fb2c72
|
|
Change-Id: I7aa74260f1456a22bae368738e3947ead1ecc7be
|
|
Change-Id: I8335ee35bae11c8014d6591744199e55bc3ec41b
Reviewed-on: https://gerrit.libreoffice.org/32854
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Equivalent OOXML markup is <p:sp useBgFill="1">. For now only handle the
case when the slide doesn't have an explicit background, and assume that
in that case we can default to white solid fill.
This partially restores the code removed in
6137b5f72f5ec491ea6bd6631a65484fa24d2973 (coverity#735432 Logically dead
code, 2014-03-25), so that ProcessData::aBackgroundColoredObjects is
actually read.
Change-Id: I9e7a9a41965db50638e9d9d1b2361af9fd7a98ca
|
|
The bugdoc has two shapes. The red rectangle is supposed to be covered
by the other shape, but it wasn't as the fill style was set to none. The
reason for that was we ignored useBgFill, unless the slide had an
explicit fill style. Assume that in that case a white solid fill is the
default.
Change-Id: Iea20e216e44e13db68887f285c10bc1a8feacf0a
Reviewed-on: https://gerrit.libreoffice.org/32786
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The problem itself was fixed by commit
2ad50c9a8c8411a57bbbd7a52734e72ffc4cc0ee.
Change-Id: Ie7f0781e1f5a4d6c5297882a5f64a68b85558515
|
|
Change-Id: I25ce98ed391f70292bed6238645b121b9cf50d5e
Reviewed-on: https://gerrit.libreoffice.org/31771
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I35de0c30a3f4f82bc923e467d5f0acf0ed90684f
|
|
Change-Id: I56cce69ddb21f7f9336b8f59e181e91306e92019
Reviewed-on: https://gerrit.libreoffice.org/31623
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Idbe8e393b64f2a151e20c1851d7c14fa161acf97
Reviewed-on: https://gerrit.libreoffice.org/31635
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iac074bd6f59d2fc890459b45801d0a6143c3eb9e
|
|
Change-Id: Ic960da6a479523a9255357d5f4cede212ff9c6a2
Reviewed-on: https://gerrit.libreoffice.org/30404
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Icea85b778375f591583732919a999cb066c40868
|
|
Change-Id: Iec273714108598d7017e73a9e7d384f8410d6ee1
Reviewed-on: https://gerrit.libreoffice.org/31263
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
OOXML noSmoking shape has different definition so that convert LO's
forbidden shape to OOXML noSmoking do not produce good result.
I put it on whitelist and now the geometry looks correct although handle
is lost.
This partially revert unit test for the shape in
2b4f9d0b2b0006fc7bebb9e696a32eabd1aeb993, where forbidden is exported as
a preset shape.
Change-Id: I2e134940fa4a36e6b7b814b008d859691fbcdd6a
Reviewed-on: https://gerrit.libreoffice.org/31110
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
Change-Id: Ib62df74ee8a53dac13c0ca8a839096932cf84c20
|
|
We current use platform APIs to calculate line spacing, however
different platforms behave differently:
* FreeType and Core Text will prefer hhea table over OS/2, and OS/2 Typo
metrics over Win ones.
* GDI’s TEXTMETRIC only uses OS/2 Win metrics, while NEWTEXTMETRIC seems
to use Typo one, but we use only the old TEXTMETRIC.
So we get inconsistent line spacing and we have no control which of
three competing sets of line spacing metrics we end up using.
The current conventional wisdom is that:
* hhea metrics should be used, since hhea is a mandatory font table and
should always be present.
* But if OS/2 is present, it should be used since it is mandatory in
Windows.
OS/2 has Typo and Win metrics, but the later was meant to control
text clipping not line spacing and can be ridiculously large.
Unfortunately many Windows application incorrectly use the Win metrics
(thanks to GDI’s TEXTMETRIC) and old fonts might be designed with this
in mind, so OpenType introduced a flag for fonts to indicate that they
really want to use Typo metrics. So for best backward compatibility:
* Use Win metrics if available.
* Unless USE_TYPO_METRICS flag is set, in which case use Typo metrics.
This patch does this by reading the hhea and OS/2 tables directly and
implementing the algorithm above.
Quick comparison with Microsoft Office 2016 shows similar line spacing
as the new line spacing here, so I guess we are improving compatibility
as well.
Change-Id: I4541e67e3e14508e3529e73083056a09de02e637
Reviewed-on: https://gerrit.libreoffice.org/31053
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
...as they apparently hold raw pointers to objects destroyed early, so only
destroying the item sets in the SdDialogsTest dtor caused use-after-free crashes
during shutdown.
Change-Id: Ibe3848c81a56fb0db4bf1fca0eab35836aab6a66
|
|
1. Store the path of all polygons of a PolyPolygon in
the same path element so it subtract overlapped area.
2. Set the size of the path as the bounding box of
PolyPolygon so the points of the polygon scale and
offset properly.
Change-Id: If6e21d1ac0544b45ef68073cf14bcc08c1d7dbef
Reviewed-on: https://gerrit.libreoffice.org/30982
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
1. Export PolyPolygonShape and PolyLineShape.
2. Rename WriteBezierShape to WritePolyPolygonShape because
ClosedBezierShape, OpenBezierShape, PolyPolygonShape,and
PolyLineShape share the function and all use
EscherPropertyContainer::GetPolyPolygon to get PolyPolygon
structure and use WritePolyPolygon to write xml tags.
Change-Id: I9ffdc26cf1f6fe8ea3b91b7b218d67f9e5585617
Reviewed-on: https://gerrit.libreoffice.org/30972
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
...from slide master.
The problem caused by that PPTX files contains not a
one-level master slide set, but has two levels: one
called slide master, other called slide layout.
Slide layout inherit properties from slide master and
normal slide inherit propetries from slide layout.
Bug appeared because, slide layout inherited properties
were not forwarded to the normal slide.
Change-Id: I587582498cf4315087f9a576c1b7fc41ee23e2fd
Reviewed-on: https://gerrit.libreoffice.org/30969
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I5df25a16303719593d40f08d1e7c15e4636a2d02
|
|
Text properties are applied on a shape during text insertion,
but if a placeholder shape has no text, then it has a placehodler
text which should have the right text properties.
Change-Id: I54175d52dd25915ee4d7153298e01ec07c6be1f6
Reviewed-on: https://gerrit.libreoffice.org/30881
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Id41b7777739bfa93610f955e6c31f8bb979b8e2c
Reviewed-on: https://gerrit.libreoffice.org/30902
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ie07ef2f9e9f6d0b31b513afa913b79d9c641e4f1
|
|
Change-Id: I955facfe3e901fcb76798dab342f96a67d5ac63f
Reviewed-on: https://gerrit.libreoffice.org/30894
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...as the trivial derivations (used to offer "convenience ctors") didn't
override Clone(), so -fsanitize=vptr would cause warnings like
> sd/source/ui/dlg/layeroptionsdlg.cxx:42:26: runtime error: downcast of address 0x603001dff830 which does not point to an object of type 'const SdAttrLayerName'
> 0x603001dff830: note: object is of type 'SfxStringItem'
> 61 05 80 1e 70 d6 f7 22 67 7f 00 00 01 00 00 00 4e 6e 00 be 60 f8 df 01 30 60 00 00 02 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'SfxStringItem'
> #0 0x7f66931db4b0 in SdInsertLayerDlg::SdInsertLayerDlg(vcl::Window*, SfxItemSet const&, bool, rtl::OUString const&) sd/source/ui/dlg/layeroptionsdlg.cxx:42:26
when doing "Insert - Layer..." in Draw.
Change-Id: I54ade09027daecc8bbf6f4789a8b5318bbe8d22d
|
|
Change-Id: I3e38b1d445c368c28e807202b94c603bd2b2c672
Reviewed-on: https://gerrit.libreoffice.org/30872
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Otherwise on Windows we can't regenerate reference files.
Change-Id: Ia293fb62651ff981b127893e26ef1d19172d2a2b
Reviewed-on: https://gerrit.libreoffice.org/30788
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I4302d0d767a1bf50fd34a78e9aa0ad6d6b0c7a22
|
|
Change-Id: Ibebcd1c1ebfea0ecdf9d90b6f8bcc8ceb87df456
|
|
Change-Id: I95b4358f0d4311e8f427c8de18863049fb718d9b
Reviewed-on: https://gerrit.libreoffice.org/30731
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
to b1164b07f9fdcd06a77dbdd74d45245a7c42c93e "loplugin:constantparam in sd"
Change-Id: I5e03c9ab19af630cdc536fddcb2f39815084b714
|
|
with addition of...
- svxlo-SvxColorListBox
+ svxcorelo-SvxColorListBox
This reverts commit db380aab1063e8a5e40111c40ee9f7921aa82601.
Change-Id: I3af7aa0abb1a430bce64188244404fcbd480b128
Reviewed-on: https://gerrit.libreoffice.org/30598
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|