| Age | Commit message (Collapse) | Author |
|---|
|
Which means we can get rid of the majestic hack of ScCaptionPtr
Previously, SdrObject was manually managed, and the ownership
passed around in very complicated fashion.
Notes:
(*) SvxShape has a strong reference to SdrObject, where
previously it had a weak reference. It is now strong
since otherwise the SdrObject will go away very eagerly.
(*) SdrObject still has a weak reference to SvxShape
(*) In the existing places that an SdrObject is being
deleted, we now just clear the reference
(*) instead of SwVirtFlyDrawObj removing itself from the
page that contains inside it's destructor, make the call site
do the removing from the page.
(*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear
because this can be called from UNO (e.g. sfx2_complex JUnit test)
and the SdrObjects need the SolarMutex when destructing.
(*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel
destructor because the existing code wants mpDrawObj in
SwAnchoredObject to be sometimes owning, sometimes not, which
results in a cycle with the new code.
Change-Id: I4d79df1660e386388e5d51030653755bca02a163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If a media shape had cropping defined, we already took that into account
when presenting a preview for it, but not during video playback.
The reason for this is that the preview may be set by a file importer
(e.g. PPTX) explicitly, in which case the preview is a bitmap we get
without any video processing.
As a start, implement video crop for the gstreamer backend (used on
Linux), and also pass in the media item (containing crop and other
properties) both during the edit view (MediaWindowImpl) and presenting
(ViewMediaShape). We pass in the whole media item, so in case later
other filters (e.g. black-and-white) are wanted, we have all that info
in the backends already.
Other backends (avmediaMacAVF and avmediawin) are untouched so far.
svx/qa/unit/data/video-snapshot.pptx is modified to have a yellow border
when cropping is unimplemented, which is now not visible with the
gtreamer backend, matching PowerPoint behavior. PPTX export was working
out of the box already.
Change-Id: If26b7a4391bcffe9cbddd9933e1bab69be52924e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138867
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
It is possible to provide an explicit preview of media objects since
commit 8fa1d453c94cdbb03dac646fb8db2ebd1a0e84bd (Related: tdf#149971
svx: support explicitly provided snapshots for media shapes,
2022-08-24), however they can't be cropped.
This means that media shapes from PPTX with cropping show unexpected
content and can also have a buggy aspect ratio.
Extend avmedia::MediaItem to store cropping and take it into account
when returning the preview bitmap in SdrMediaObj::getSnapshot(). PPTX
import works out of the box, as oox/ already tried to set a cropping
property on the media shape.
This is just the preview, the cropping of the video itself is not yet
implemented.
Change-Id: I8db3e0dcf252613d56eb0e6139adf097e53b15cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138808
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Snapshots / previews for media objects are used when the shape's video
is not playing. This is generated by seeking to the 3rd second in the
video, probably to avoid initial black frames.
The trouble is that PowerPoint takes the initial frame (at least in case
of the bugdoc), so our snapshot doesn't match the reference.
We already import a bitmap snapshot from PPTX files since commit
e2d46da076f43a7c0d56fc486b9f15339243f7c9 (avmedia: add doc model for
bitmap fill of slide narrations, 2021-01-21), fix the problem by
changing the snapshot generation to prefer this bitmap over generating
one from the video.
The crop properties of this bitmap / the video are still not yet handled
from PPTX.
Change-Id: Id985eaaaad5e4222d9a98203d054e08a0f97a0f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138763
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I33867397cd5783adb90e9dc2c62b037ced131e26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138081
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
We need to detect that the storage name is empty, so in that case
the root storage needs to be set as the current storage.
Change-Id: Ibe3287ccf1f1513a3531dcf4d540a456cca8dfb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137276
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Regression from commit 78e25558e86188314b9b72048b8ddca18697cb86
(tdf#106059 PDF export: create a reference XObject for JPG images with
PDF data, 2017-02-23), once a PDF image was inserted to a document, an
encrypted PDF export lost those images.
The reason for this is that we started to preserve PDF images as vector
data with the above commit, but this means we copied over PDF objects
from PDF images to the export result as-is, so encryption was not
performed for them.
Fix this by separating the write of the PDF object headers, stream
content and object footer and then calling
checkAndEnableStreamEncryption() / disableStreamEncryption() for each
object, even if it's not something our PDF export created but comes from
a PDF image.
Note that when existing PDF files are signed, PDF objects are also
copied into a vcl::filter::PDFDocument, but such PDF images are never
encrypted, so it's fine to have stub implementations in
vcl::filter::PDFDocument.
Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The Impress table properties dialog has multiple purposes: normally it
only affects the properties of the currently active cell, but shadow is
applied on the whole shape.
Regression from commit fdeb04f7c59cf8032fe17072ed779e70505cc6ab
(tdf#129961 svx: finish UI for table shadow as direct format,
2020-12-15), we started to apply properties to the current cell, and
then to the whole shape as well, unconditionally. This affects
undo/redo, as there is a separate undo manager while the text edit of a
table cell is active and when the text edit is ended.
Fix the problem by only applying properties on the shape when there we
actually have some properties: this way the text edit is typically not
ended, bringing back the old undo/redo behavior.
Note that we still need to end the text edit if the user explicitly sets
some shadow properties, that part is unchanged with this commit.
Change-Id: I78e28bd326a2c12c3775b33957adca4cd95ac582
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136357
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ife1958a39a7cf673b745a7724ee963e868b21432
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136064
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See tdf#42949 for motivation.
Change-Id: I157b331195cc8262e6bd1dcc536cb653587fc45f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The current solution checks implicit moveTo only on the first arc in
a sequence of arcs. The patch moves it into the loop, so that the
implicit moveTo is done for each command in a sequence.
Change-Id: I400fa8fc96d7377ede55296c71e7a82ce891cc24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133896
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I59b1b3f817a9028f132456ea5094f38f88674d00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133768
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The curved*Arrows start with two arcs, which should be connected by a
line. The used commands are double V and double B respectively. Both
have an implicit moveTo, so that there should be no line between.
Other applications show the shapes correctly without line. But because
of bug 148714 LO shows a connecting line so that the error was not
earlier detected.
The patch changes the segment definition so that for the second
command the variant with implicit lineTo is used. This does not change
rendering in LO but makes other applications rendering the shapes
like LO.
Change-Id: I4f799f89497e52b1a7e00d8e5345a66ce21c00a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133586
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This is always direct formatting, so FillProperties::pushToPropMap()
always has the needed info at hand.
Change-Id: I3317b618e0e8bb7688d0f0fbfe4546e2e8b4e947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Only the no-effects variant was working previously.
Change-Id: I50811a4c49d19dc801f0d1c841cbbdb2fae1ad60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
For shading parts of a shape not of Type 'ooxml-*', ColorData is used,
introduced about 2005. For 'mso_spt*' shapes they are set directly,
for others they are encoded as 'col-********' into the Type value.
During OOo time two changes were made, resulting in the bugs, that
colors are assigned to wrong segments and that shadings are too dark.
More details are in the bug report.
With this patch the colors are assigned to the correct segments again.
The too dark colors are visible in our preset shapes 'Octagon Bevel'.
The shape 'Diamond Bevel' with corrected color assignment is also
affected. Both need new ColorData. Since it is important for
Libreoffice to have good compatibility with OOXML, I have decided to
use only the four shading values available in OOXML. In the long run,
these shapes should be replaced by ones that contain the shading
information inside the <enhanced-path> element.
Change-Id: I4b8323c45bf702fc371d6e6c82dd9102d0fd9929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133132
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
XColorItem::maThemeColor already provided the document model for this.
Change-Id: Iefbd0aeaa37a813bb4c86386801e0116e8fae40d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132933
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The theme index is typically not a direct property, but comes from style
-> fillref -> theme index, so support that.
Change-Id: I00733db44bb5321019bbc7337d10feb0a34661a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131268
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See tdf#42949 for motivation
Change-Id: I25779cbfb1aa93c31d6e12ac95e136b3bdbbc058
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130403
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I.e. update the shape fill color when the theme of the master page
changes if the color is a theme color.
Change-Id: Ia1ed566230a8547334aa4a7d69627882aa690546
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130894
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I13e7f1dc5d93f352e79139acb64b46dee298c9fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130186
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
In preparation of adding import/export for this.
Change-Id: I195be9e9ccdbb25fa41878a2858c22ee11d189a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130467
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The toggles (Textpath,SameLetterHeights) and (Extrusion,Extrusion)
change a value by directly writing the value into the property. That
is lines (*pAny) <<= bOn;, for example. But that does not trigger
InvalidateHash() of the SdrCustomShapeGeometryItem. So the item has
still aHashState 'Valid'. On the other hand because of the change the
hash itself has changed. Therefore the == comparison between the
original item and its clone returns 'false' in customshapeitem.cxx#238.
And as a result, the assert in itempool.cxx#679 fails.
My solution replaces the direct writing with setting the value via
SetPropertyValue(), which includes the needed InvalidateHash(). The
method InvalidateHash() is private and so cannot be directly used in
fontwork.cxx and extrusionbar.cxx.
Change-Id: Ib6021defb61478de9cbefa8f26466a2fe21352a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130117
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
The fix tries to make rendering similar to MS Office.
The ODF standard follows closely the extrusion in RTF and MS binary
format. Rendering uses the 3D scene engine.
The main problem was, that the z-component of the direction was
interpreted with opposite sign. As result the maximum of a light was at
false position. Especially a direction from the observer to the object
has produced a light behind the shape and so looks as if light was off.
The wrong z-direction has produced lighting, which was less intensive
than in MS Office. To compensate that, a third light source was added
as workaround. That part is removed.
Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity
and D3DMaterialSpecular (= UI Specular color). That was not only wrong
in OOo but in my previous patch too.
D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'.
Relationship is Intensity = 2^c3DShininess.
D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and
and c3DKeyIntensity. The light source was missing, but needs to be
included, because c3DSpecularAmt is 'the ratio of incident to specular
light that is reflected on a shape'.
The old unit tests are adapted to this change.
MS gives no information how it softens a light in case of harsh=false.
ODF specifies it as 'implementation-defined'. The patch uses four
additional lights, which have directions in 60° angle to the original
light. The light intensity is distributed. That comes near to rendering
in MS Office. Changing our 3D engine to provide 'soft' lights was not
doable for me.
The way MS Office renders a 'metal' surface is different from ODF
specification. To distinguish the kinds, I have introduced a new
property MetalType. I have discussed it with the ODF TC (see minutes
from 2022-02-07) and got the advise to use namespaced values.
Therefore the datatype is not boolean.
The 'Surface' drop-down in the extrusion bar is changed to make the two
kinds of rendering 'Metal' available to the user.
If a user sets surface 'Metal' in the UI of MS Office, it sets not only
fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our
3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color
not implemented. To get a similar rendering I change the material color
of the 3D-objects as workaround.
Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
For example, to set a custom pixel size:
soffice --convert-to 'png:draw_png_Export:{"PixelHeight":{"type":"long","value":"192"},"PixelWidth":{"type":"long","value":"192"}}' test.odg
Change-Id: I628717ba36b6ad1ac03911eec06855c1745ef258
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129801
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: If8771e4c73656d6f6d236d2d530d0ec92c1f5a7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129533
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic98a25f495630517827c1e9f9827e1c45e1401ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128304
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Just use CPPUNIT_ASSERT_DOUBLES_EQUAL_MESSAGE
or CPPUNIT_ASSERT_EQUAL_MESSAGE
Change-Id: Ibf399cc802e31c5265ba1301f38df79958bf9e1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128262
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
UpdateSdrObject() is called for both group and non-group shapes, so
don't assume that they always have text, otherwise we would crash.
Change-Id: I3672673176f0cb462a8b8d61a68466f541e9ce06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128248
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Icebc6b95596e62628d00cc3c851f56a6a78ee727
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Added code to check whether the angles need to be changed when the
section is flipped.
Change-Id: I9cc3e16db74c6e9616385bc39849e4c73686b56c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127853
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
The context menu for Calc charts would call into
GraphicFilter::ExportGraphic(), which has explicit code for e.g. SVG,
but not for PDF. The graphic exporter to PDF is only meant to work with
images backed with PDF data, not with all shapes.
Fix the problem by explicitly handling PDF in
GraphicHelper::SaveShapeAsGraphic() in svx/, and invoking the normal PDF
export in that case. Continue to fall back to XGraphicExportFilter for
other formats.
This requires passing down the current document from sc/.
Change-Id: Ia5f78bffa1d26989bb0ad3ed265b922e609f076f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127969
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
These tests belongs to commit 453c5b6,
improve extrusion of custom shapes.
Change-Id: I3b89a887d72b6814540a659dfa088f1550a1d47b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126962
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: Ibcfb38261e9d5bdd44259849c060de0d8c3a69a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126913
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If41904da363187128c900910c39ee1d375271946
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126914
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The patch addressed these errors:
The property Origin is relative to the bounding rectangle of the shape
not to the snap rectangle. That error is visible e.g. for a block arc.
Rotation center x- and y- values are relative to the snap rectangle and
not absolute.
Rotation center z-value is in Hmm and needs conversion to Twips in
Writer.
Rotation is around rotation center, which might be different from shape
center. That has been ignored.
I have moved calculation of the 2D logic rectangle of the scene to
main method to be able to reuse the transformation and other values.
I consider using a special local class as unneeded overhead.
I have reordered some parts to bring geometry relevant parts together.
Change-Id: I35ad0721091b365ae99cd3d7b2afb0ad7efe47fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126847
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This builds on top of commit 48f0c5f73f99c919ec24deadc96c3cf5483c9314
(svx: update objects of pages of a master page when the theme changes,
2021-11-30), but now not only plain colors with colors with effects are
also considered. The luminance modulation / offset is what PowerPoint
uses the generate lighter / darker variants, tinting / shading is what
Word uses.
Change-Id: Ibfafb9be9986645117015bf3b05491daec8914be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126270
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Only text color as a start, and without effects.
Change-Id: I52b1c110870605134c414bcc94b50871cd49975b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126082
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Commit 87e5cac has introduced a local method for a common part of the
new unit tests. Identical parts are used in two existing unit tests.
The patch replaces them with calls to the new method.
Change-Id: I2945add642ac38048dd1fab4ffc3f2649a261650
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125168
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This adds the missing unit test for commmit
70a4cb766ed356bc17433ac1673e977bb0bf3d2f.
Thanks to Tomaž for extending the test framework to 3D.
Change-Id: Iffaa163c3d453318bc0ed7f8703af15bd20c8966
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125013
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This adds support for 3D drawinglayer primitive XML dumping and
adds dumping support for many more primitives and attributes that
were missing before. This is needed to be able to check the
fontwork objects, which can be rendered in 3D.
Change-Id: I0e78be4d4030a0cae3d2b952a1a38de8940ee310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124804
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ib3815aee68fdeb8f5eef465d01c51c66378fcd1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124086
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
ODF specifies for draw:extrusion-depth, 'The draw:extrusion-depth
attribute specifies the depth of an extrusion. It takes two white space
separated values. The first value specifies the depth of the extrusion
in units, the second value specifies the fraction of the extrusion that
lies before a shape. The second value shall be in the range [0,1].'
The default for the second value is 0. Because LibreOffice has no UI to
change the value, the error becomes only visible, if you create own
custom shapes.
On import the ODF values are put in CustomShapeGeometry>Extrusion>
Depth. Method GetExtrusionDepth() calculates from that the length
values rBackwardDepth and rForwardDepth so that its sum is the depth.
CreateCustomShapeProperties() in escherex.cxx#2699 and
ApplyCustomShapeGeometryAttributes() in msdffimp.cxx#1684 use them in
the same sence.
But methods Create3DObject() and CalculateNewSnapRect() in
EnhancedCustomShape3d.cxx have used these values as if they were
coordinates.
I have keept the calculation in GetExtrusionDepth(), because it
reflects the meaning in ODF. I have corrected the signs in
Create3DObject() and CalculateNewSnapRect().
Change-Id: If275bb263b6f3d790f5893a69f38f8433acfbe7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123997
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Multi-column shape text works by assuming a fixed height, then flowing
content to a next column once the current one is full.
Automatic height works by first laying out the text and then resizing
the shape to have a matching height.
When both are enabled, then we used to first calculate the automatic
height and then lay out the multi-col text using that height. PowerPoint
takes the height from the file format and lays out the multi-col text
using that fixed height, and only editing modifies the automatic height.
Fix the problem by not updating the automatic height when we have
multiple columns, this is meant to improve the stability of the layout
anyway.
Manual testing shows that editing the text on the UI still updates the
automatic height, as probably expected.
Based on Mike Kaganski's research - thanks! :-)
Change-Id: Iaf46c6008018b4bf26310322f25788a49c1d27f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123999
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The error happened if ScaleX in TextPath is true. In that case the
original font size is used for rendering if possible. Only if a
paragraph is longer as its sub-path length, the rendered font size for
the whole text is reduced until the text fits. The error was, that in
case the first paragraph was too long and the second paragraph fits,
the fact that the first paragraph was too long was overwritten from
the factor for the second paragraph. That resulted in wrong position
and size of the text and overlapping characters.
The meaning of fScalingFactor is related to the usual case, where
ScaleX is false. Keeping original font size is not achieved by using
value 1 for fScalingFactor (which would be obvious), but the adaption
to case ScaleX==true is done in FitTextOutlinesToShapeOutlines() by
tweaking the width from the text bounding rectangle.
Change-Id: Icf5829018a83be0f1197304d17da10a88130f702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123714
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I139776f74fb93f90dae787eeae18e4a2a2ed7351
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123700
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
In case of ScaleX=true in property TextPath, SDRTEXTVERTADJUST is
evaluated and should shift the Fontwork text. That did not work for
'LeftTop' and 'LeftBottom'.
Error was that in case of SDRTEXTHORZADJUST_LEFT the vertical shift
was not considered.
Change-Id: I4edb47515c4bf40e17b4054c3a10220df8468028
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123613
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
The setting ScaleX=true in property TextPath in CustomShapeGeometry
is used in import of WortArt of kind 'Follow Path' from MS Office. The
value 'true' means, that the text is not stretched to the path but its
original font size is used as long as enough place is available.
The method CalculateHorizontalScalingFactor() has increased the
scaling factor by 10 percent to make a 'padding'. That results in a
too short text and a gap at start and/or end. The problem is not only
visible in imported shapes but in user designed Fontwork shapes too.
PowerPoint has no 'padding'. Currently our own preset Fontwork shapes
always use ScaleX=false and therefore are not affected.
I have not found any reason for such padding. So this patch removes it.
Change-Id: I7f2c4eb9101be1f13b006d4178ffbe75eb4ed55a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123295
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This is a follow-up to commit 37a52d30bbfcf1d073779b50139c4dafa507be4b
(tdf#144091 svx: fix unwanted blur of shadow from table cell fill,
2021-09-20), where it turned out that the original bugdoc was just a
special case of almost full transparency (80%), that's why avoiding the
blur fixed the problem.
A more general approach instead is to multiply the alpha or the cell
fill of table shapes and the alpha of the shadow itself. The end result
is the same (80% transparency) for the first bugdoc, but this gives back
the blur on the second bugdoc.
Change-Id: I63560e3a73473c70157ecee8365ec7154217f269
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122532
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
