Age | Commit message (Collapse) | Author |
|
... which is the type corresponding to the related published property
"LayerID" of com.sun.star.drawing.Shape service.
Without this, the code asserts on values passed to the published API
from external sources to be in the 8-bit limits, which is incorrect.
Change-Id: I0449a7dd313f7e6c4adbc1c1f7b8c50b6a51434e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121760
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ifbd41d2de4642f4855f594067ccbbd71464a66d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130345
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I705530b841a5e1a4c45f78408948d4cdba630d96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130291
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
To allow advanced Diagram/SmartArt support in the future
this is a first step to organize imported SmartArt Data in
a way that will allow to re-layout loaded SmartArts, under
re-usage of the oox::Theme (held available).
It is designed to work without holding available the
original XML snippets defining the imported Diagram in any
way, also for performance reasons. It tries to re-use some
of the already basically added functionality, including
the systematic layouting using the generic layout
algorithm, plus some already available text extraction.
Before being sure that the former state can be completely
replaced this is optoinal and used when
SAL_ENABLE_ADVANCED_SMART_ART is defined. Some new stuff
is already done but e.g. the redefined reLayout method will
not (yet) be triggered. It works and reliably produces a
re-layouted identical version, also preserving
transformations.
Change-Id: I08cfbae04afa663d0589530aae549216d853128d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130171
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
shaves 2% off the load time by avoid the cost of
comphelper::getFromUnoTunnel
Change-Id: I9d0438bd0ad3cf753d34fe181481f3a57193651c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130284
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaa240aeae8bacbff6bccd9bf0721a02414b6f47d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130288
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ic57c49ce1c65ecca4e87be970e76bf16ba234711
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130273
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia3e0521a013c3226f2fd5fdfef4e67dc1d5a0374
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130276
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
by using the Properties related code to create an SfxItemSet with the
correct ranges, instead of creating an empty SfxItemSet and updating it.
Shaves 2% off the load time of a large chart.
Change-Id: Ia1f8527fa52ab5b8c70e13e1e2ab8c8f25739b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130270
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This helps with performance when we do series of actions
updating styles. In that case we will only request update.
When we will reach idle state we will do it only one time.
What removes unnecessary updates in the meantime.
Change-Id: I9fc59992833a6cf98c42571c1189b3c5d49ba5a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126840
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130232
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I23a0cd10b6936de920a294901f860620fc2af0a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129894
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit 6f938dce6eaa927cfde39491ef7a0bc1d07df66b
("update video pos and size after change if currently playing").
Change-Id: Ib618fcd7347255d0cae352b7fc90aa85a2c14d32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130215
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
I'd prefer if it changed size during the resizing/repositioning, but
at least make it immediately take the final size after the
resize/reposition has happened.
Change-Id: Ic3b4dd23921ad5cf6092f1514dd6538f9946998a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130178
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
/home/noel/libo3/svx/source/toolbars/extrusionbar.cxx: In static member
function ‘static void svx::ExtrusionBar::getState(const SdrView*,
SfxItemSet&)’:
/home/noel/libo3/svx/source/toolbars/extrusionbar.cxx:938:25: error:
‘eMetalType’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
938 | if (eMetalType ==
EnhancedCustomShapeMetalType::MetalMSCompatible)
| ^~
/home/noel/libo3/svx/source/toolbars/extrusionbar.cxx:933:31: note:
‘eMetalType’ was declared here
933 | sal_Int16 eMetalType;
| ^~~~~~~~~~
Change-Id: Ie98bb04900d271299cb930bf6d12af46d45ae8c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130128
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I58c60262ca543bafb4db4433dbb98b195f7571ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130063
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I07ec409ea3663e789b6505dbfc999666525ed97f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130062
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In preparation of adding UNO API for this.
Change-Id: Iecb2e44c43bca9e892fcb6242870ec12faa48be5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130050
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
regression from
commit 9a850dd9f3c221660b6259bdfd64a77343f2256c
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 12 10:27:38 2022 +0200
used cache value in ViewObjectContact::getPrimitive2DSequence (2nd
attempt)
for reasons I do not understand, the cached maObjectRange is wrong at this
point in the execution, so switch back to fetching it again, like the code
did before the above commit,
Change-Id: I4a9f0abc38e59ef687b460689a30ee4badf620a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129994
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The cost of creating a SfxItemSet to pass around changed item
information is surprisingly high, so avoid that and just pass
the vector of changed items down (which we are already building
anyway).
Change-Id: Ifa48e3ce07fb6c92ad05a119ae95ce002af76199
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129976
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
shaves some small amount off the profile of loading a large chart
Change-Id: I24c99a68382663e52baccd34e22b63bf16fa1eb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129954
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to reduce boilerplate at call sites
Change-Id: I290c2bf60ad5e6ddb000aa26cf543830ed39120a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id36f7b1b8313868e730018737b353d92adbde33e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124337
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/collabora/online-buildscripts/staging/builddir/libreoffice/svx/source/sdr/contact/objectcontactofpageview.cxx:353:57 in
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: /home/collabora/online-buildscripts/staging/builddir/libreoffice/include/svx/svdview.hxx:235:65: runtime error: member access within address 0x61c000489880 which does not point to an object of type 'SdrView'
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: 0x61c000489880: note: object is of type 'SdrPaintView'
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: 7c 04 80 3b 90 58 b9 3d 60 7f 00 00 30 51 96 0a 20 60 00 00 38 51 96 0a 20 60 00 00 38 51 96 0a
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: ^~~~~~~~~~~~~~~~~~~~~~~
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: vptr for 'SdrPaintView'
Change-Id: Ifc9177902ac834d400d6bf9f72b94e82f544b348
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
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: I196c6cafaf0ccb6c2547ca56b0e7c48c9e0dd6ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129798
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
nothing directly extends IPropertyValueProvider
Change-Id: Ib393bd31bde7f68d8b21dc3bdeeb30b538de1488
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129797
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) rename the enum to make it's purpose more obvious
(*) remove the enum header - it belongs to this class, no need to have
it somewhere else
(*) return property name by const&, no need to copy here
(*) use a o3tl::enumarray instead of a std::unordered_map - there are
only 3 entries here, and two of them are ALWAYS used, so just flatten
the data structure.
Change-Id: Ic496bd5220d55be1209a3243c095d461df0a02ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129788
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can avoid constantly generating new TextForwarders which
are the same as the one they replace.
The underlying problem is that of tdf#123470 but this solution should
be safe to backport
Change-Id: I742f2a9ce0024adf9bd0acc5bb8edb9372fc0af5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129775
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these things are never shared
Change-Id: I21c3b7cf2abf6e47a8839ac60e7bf27b7282ed76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129784
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ad212dfff8b34d05e3b45107a1ef033a4efc454
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129651
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
shapes in writer. The problematic commit is
5e37acbaaa0b0891829907331ecacd2d3b67526d
lokCalcRTL: shapes: do not send negative(X) invalidations
The above change forced the lok mode to use the second branch hence avoid the
view-transformation based invalidation. This patch restores the old
branching condition, but do the negation of invalidation rectangle in
case of lok-calc-rtl mode(IsNegativeX).
Change-Id: I679473f0610d2edabeb6071edbb32a63a436d053
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128491
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 242d2752aa6af2c52affc90e84b58c59c5fa779d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129440
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@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>
|
|
Inform editeng that negated document x coordinates are used in this case
and ensure that editeng generated invalidation rectangles always have
positive X coordinates.
Conflicts:
sc/source/ui/view/gridwin4.cxx
Change-Id: I2e450707ce02f7bcd8e4d299f857c37ebbd5e2c6
(cherry picked from commit 0fe02bb99e5dfa8379a49de75683fc350e4c4dbd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129360
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
After commit 2e1a38ceb6866248ec30f6fe58cd3adc1b910eec that moved the command buttons in the Manage Changes dialog to the List tab, the Manage Changes sidebar started showing the buttons twice.
This patch remove the duplicated buttons from the sidebar.
Change-Id: I767e88ba9ca7595913b6ddc57d152febd595f504
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129103
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I3a21e2aa5a2c482c0bac1d4c9bf84f8b56261408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129492
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I70f34ac5e9b5d2f2d6c0375e823908eaa2e540b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129487
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
for these cases where draw wants to massively scale the units
the underlying "metric conversion" are already using sal_Int64 anyway
Change-Id: I94e120d72644319548f75b2f68cfe60d4829a2e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129356
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Conflicts:
svx/source/svdraw/svdview.cxx
Change-Id: I153334940b41859e6fd9dee64217925627f0f292
(cherry picked from commit bb37b46182bcff2f10edcc590cedbc4bb5820c4b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129359
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Which is useful to see, as a 2 page Draw document has 2 normal pages and
a master page (3 sizes), but in practice there can be only a single
size, so it's useful to see what size is coming from where when they
don't match.
Change-Id: I505653029ae67ea0a57c8f8bb61cf475d77aaccb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129425
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This reverts commit 87866def6bfe2ee91be34a5ce37b79d6da881617.
This also reverts commit 98d6ed2aeb22b27fddf716a372f483b89ecea841
< tdf#123973: sd_png_export_tests: Add unittest >
Change-Id: Ic3c8c70ef789b83cec0614e766a3c067cbf078fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129351
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
|
|
Change-Id: Ica74dd5e55d30605ee03affa4b724ffa4ec65b5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129357
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Meant to be SfxUInt16Item, until the below commit accidentally
introduced SfxInt16Item usage.
commit 4d814ec1518c98d2ca251a5a10287f40a427ea6e
Author: Armin Le Grand <alg@apache.org>
Date: Wed Apr 24 09:50:54 2013 +0000
Related: #i122111# Adapted pState usages in NotifyItemUpdate methods
Change-Id: I2aff5cc1eea9257186b4da12a73f928503bc233c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129353
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
LOK client expects all coordinates to be in +ve document coordinates, so
negate the negative X coordinates of LOK RTL shapes before sending the
selection/handles messages.
Conflicts:
svx/source/svdraw/svdmrkv.cxx
Change-Id: I683581370c5b115efbe315224d6218ec2e74c7f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129190
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
LOK client expects tile invalidations in positive document coordinates
irrespective of RTL flags.
For this introduce a flag mbNegativeX in svx class SdrMarkView to
indicate the case when all x coordinates are negated (this happens only
for the LOK + Calc + RTL mode). Use this flag to counter negate the
x coordinates before sending invalidation rectangles.
Conflicts:
sc/source/ui/view/drawvie3.cxx
Change-Id: I35d8142718b538e55b668a8ee18f3dd1fe433951
(cherry picked from commit 5e37acbaaa0b0891829907331ecacd2d3b67526d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129195
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
The conversion from Metafile to Bitmap in GraphicExporter
is based on metafiles which does just not deliver enough
precision when getting the bounds to do the correct size
calculation for the target Bitmap.
So I changed that to use Primitive functionality what
produces better data. That old fix/correction itself was
based on hairlines only which is anyways no longer
sufficient since LO uses less hairlines nowadays, what
is good in general (They are a relic of non-AA times
when it was not possible to paint/work with lines taller
than one pixel).
Thus, cases need to be solved more generic based on
better data. It would also be good to change this
to primitives completely, but that is too much for now.
Change-Id: I71bd136b106ef8ff3ba51458c46df08269773c01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129235
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
only instantiated with one type, so just turn it into a normal class
Change-Id: If3ae908f3e226ae9f4d3b81a7a7d9ba492ccda4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129283
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When selecting text containing several different
kerning values, the pItem returned is a VoidItem.
This was showing up as random numbers in the
TextCharacterSpacingControl spinbutton.
Change-Id: I94cfc566daa42e0d8c3d403eb08af659f01e6d5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129270
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
When the kerning menu opens, it defaulted to very tight,
regardless of what the current setting was.
However, the current value can easily be connected to the
menu options, so lets do that.
This depends on increasing the spinbutton range beyond -2.0,
done via LO 7.4 commit 2334561bf15ec9b061636919efbd0e2a7b89e29b
Change-Id: I0be0956bf1cc3604faecc691aeac70a5bbba807b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128909
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|