Age | Commit message (Collapse) | Author |
|
Having the layout algorithm dependend on IsPaintLocked() is very
problematic; it is typically set when the layout is invoked from
SwViewShell code, as happens several times when loading a document in
response to window resize events etc., but not for idle formatting or
from SwXTextDocument::getRendererCount(), hence these bugs only
reproduce with soffice --convert-to pdf, not via UI.
For tdf#156724 the problem is that the table is split, during formatting
of the split row a new footnote is created on page 1, and this reduces
the space, so splitting fails and is never attempted again.
When the document is loaded from UI, when the table is split the
footnote already exists and so splitting succeeds; it was created by
a call from SwLayAction::FormatLayout() of the cell frame.
It turns out that when the condition is removed completely, testUXTSOREL
will take 5 minutes instead of 5 seconds, which seems excessive; the
problem there appears to be that a text frame in a columned section
moves forward and backward; plausibly columned section content should be
formatted by ::CalcContent() only.
(reportedly regression from commit c605283ad6785dea762feab5fdffd9d27e75c292 and commit
7e8b4756d95057f069467b34e7849f9354856578)
Change-Id: I9ed73588efeec654a769eee8aa825186bd51e059
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155672
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Iea2113030bb82ee02bd84140f5def7040b4f4fcb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154087
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3d825590e60190cf95f514b5df606a83ea4193b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154086
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Make warning messages clickable and go to the problematic paragraph.
Change-Id: I5ca0b33b6f50b5d08993ebd0fc2749804e80de48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155587
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Make clickable and highlight the problematic text.
Change-Id: Ie53c74b0364d08e4299e4c27ff2744a8c547844e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155586
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Change-Id: I5975a46e2692b1af221ca716d2a117e424948c15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155664
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ieb276dcbd91873bd5121ae7534f0e120c88a88d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149114
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The problem is that SwFrame::FindNext_() returns itself, because it's a
table frame 401 and its last cell is empty.
There was a nested table in the cell, but during an attempt to split the
outer table 401, the inner table moved backwards.
This is due to code that was added in commit
c9c956f2716c58e2573a9ac07073f712d736ed02, which only checks that the
height of the table frame is 0, but in this case the inner table does
contain a text frame which has never been formatted yet, but still the
table frame's size and print area was set to valid.
Unfortunately adding an obvious !ContainsContent() check to the
condition breaks uiwriter4 testTdf114306_2, the last table is not on
page 4 but on page 5, for no good reason.
So just fix SwFrame::FindNext_(), it should never return "this" anyway.
(somehow regression from commit 53a0a86df6eb5fc64a85ecd03f2e354fd4d8e213)
Change-Id: If043a53c32f175fc560d422c4a4e16d8e8c6ef49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155563
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Seen with gcc 7.5.0.
Change-Id: I34940865f62ff397a3a6813fbabd0fb45a01d88f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155654
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
* Update dictionaries from branch 'master'
to e32c98b7aa5dc8b451f3ca1ba2f447f4534e77fc
- tdf#156723 Remove false pleonasms for pt-BR
+ Removed "prefeito municipal"
+ Removed "Pessoa humana"
+ not removed "salário-mínimo" (rule does not exist)
Change-Id: Ic5a9487cf49f764ff3bc5587b54bca7f40d7264f
Reviewed-on: https://gerrit.libreoffice.org/c/dictionaries/+/155570
Tested-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Map sprmTFNoAllowOverlap to
SwFormatWrapInfluenceOnObjPos::mbAllowOverlap on import, and do the
opposite on export.
Change-Id: Id61be49adb39862e30ffb2da9ff9aabae11f7d83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155650
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
it may have left a cell the original range needed in a dirty state,
leading to an assert when the threaded calculation is attempted which
would not have happened if the attempt to expand the range wasn't
attempted.
seen in crashtesting example: forum-mso-en4-784502.xlsx
to reproduce this, load sample document
after it has loaded:
(gdb) break column4.cxx:1946
(gdb) break column4.cxx:1966
data, recalculate, recalculate hard,
the first time breakpoint #1 gets hit:
at column4.cxx:1946 NeedsInterpret is true, so cell
{nRow = 1, nCol = 0, nTab = 3 } was dirty and is set
not-dirty by Interpret. mxGroup->mbPartOfCycle is false
so this returns successfully to allow threading.
the bt to there was:
#0 lcl_EvalDirty(mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>&, int, int, ScDocument&, boost::intrusive_ptr<ScFormulaCellGroup> const&, bool, bool, bool&, bool&)
(rCells=..., nRow1=1, nRow2=4, rDoc=..., mxGroup=..., bThreadingDepEval=true, bSkipRunning=false, bIsDirty=@0x7fffffff4a16: true, bAllowThreading=@0x7fffffff4a17: true)
at sc/source/core/data/column4.cxx:1963
#1 0x00007fff9eef70d1 in ScColumn::HandleRefArrayForParallelism(int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&) (this=0x15ee480, nRow1=1, nRow2=4, mxGroup=...)
at sc/source/core/data/column4.cxx:2012
#2 0x00007fff9f44448a in ScTable::HandleRefArrayForParallelism(short, int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1eebda0, nCol=0, nRow1=1, nRow2=4, mxGroup=...) at sc/source/core/data/table1.cxx:2567
#3 0x00007fff9f06b691 in ScDocument::HandleRefArrayForParallelism(ScAddress const&, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1ba9a40, rPos=..., nLength=4, mxGroup=...) at sc/source/core/data/document.cxx:1792
#4 0x00007fff9f3018f7 in (anonymous namespace)::ScDependantsCalculator::DoIt() (this=0x7fffffff4eb8) at sc/source/core/data/formulacell.cxx:4585
#5 0x00007fff9f30085a in ScFormulaCell::CheckComputeDependencies(sc::FormulaLogger::GroupScope&, bool, int, int, bool)
(this=0x2142cf0, rScope=..., fromFirstRow=false, nStartOffset=0, nEndOffset=3, bCalcDependencyOnly=false) at sc/source/core/data/formulacell.cxx:4720
#6 0x00007fff9f2ff392 in ScFormulaCell::InterpretFormulaGroupThreading(sc::FormulaLogger::GroupScope&, bool&, bool&, int, int)
(this=0x2142cf0, aScope=..., bDependencyComputed=@0x7fffffff56d7: false, bDependencyCheckFailed=@0x7fffffff56d6: false, nStartOffset=0, nEndOffset=3)
at sc/source/core/data/formulacell.cxx:4829
so the CheckComputeDependencies at the start of
ScFormulaCell::InterpretFormulaGroupThreading is successful for aPos of
{nRow = 1, nCol = 1, nTab = 3 } and the cell is not dirty at that point
*however* in the following loop of
for (SCCOL nCurrCol = nColStart; nCurrCol <= nColEnd; ++nCurrCol)
in InterpretFormulaGroupThreading, CheckComputeDependencies for
column 3 is called and the breakpoint #2 is hit, in this case
mxGroup->mbPartOfCycle is true and the {nRow = 1, nCol = 0, nTab = 3 }
cell is set dirty again.
so later during the threaded calculation the cell is found dirty and the
ScFormulaCell::MaybeInterpret() asserts that
!rDocument.IsThreadedGroupCalcInProgress()
Change-Id: I40385f5e8240680c220249dd2966b196efaf5e0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155463
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Instead of referring to developer-only terminology
tell users what to do
For example, Word uses the warning "Objects not inline" in this
case and actually explains below what needs to be done
Change-Id: I7650807b7520d2f10d75e1417cdf42978a31a417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155629
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
|
|
* Update helpcontent2 from branch 'master'
to ebdeebb9b004df574ec90ead903ffa9c9b1f3235
- Revert "tdf#155193 Do not deliver Help files with indexer=exclude"
This reverts commit 539abfa7c3bbc9f0b234402083c743890b965cf7.
Reason for revert: daily builds fail to build with errors like
ERROR: file '/home/tdf/lode/jenkins/workspace/lo_gerrit/tb/build_master/instdir/help/en-US/text/shared/autokorr/01000000.html' does not exist
See https://ci.libreoffice.org/job/lo_daily_tb_linux_dbg/654/console
Change-Id: I9d00fb2596b280bf09934dfc87db64feb8fe6a80
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/155600
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Subscribe to receive pinch gestures by calling
`QWidget::grabGesture(Qt::PinchGesture)` and
forward that as the corresponding `SalGestureZoomEvent`.
From looking at what values the gtk implementation uses,
`1 + pPinchGesture->totalScaleFactor()` seems to be a
proper choice for the
`SalGestureZoomEvent::mfScaleDelta` value.
With this in place, zooming in and out of a Writer
document with a two-finger zoom gesture works for
me with the Qt-based VCL plugins in Writer on my laptop
that has a touch screen.
(It seems to be a bit more smooth with qt5/kf5 than
with qt6, where doing several zoom gestures after
each other sometimes requires to wait a bit before
doing another gesture in order for that one to be
processed properly.)
Qt documentation for gestures: [1]
Corresponding commit for gtk VCL plugins:
commit f2bd19f6720239db228cd4388be8e928505c51b6
Author: Povilas Kanapickas <povilas@radix.lt>
Date: Thu Aug 25 00:18:30 2022 +0300
vcl: implement touchpad zoom gesture support on gtk backend
[1] https://doc.qt.io/qt-6/gestures-overview.html
Change-Id: I288943d923463fee44314969648e03dca84c483f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155649
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Regression from commit 209dce614c43f63f63f5b42a746665c0ec1cbfe3 (sw: fix
ODT import of paragraph marker formatting, 2022-12-20), the bugdoc has a
first paragraph with nested spans (the outer sets the boldness) and the
text does not appear as bold in Writer anymore.
What appears to be the problem is that our model is just a list of spans
for a paragraph, so nesting is converted to a list of spans, but now the
outer span char format is lost.
Fix the problem by making the condition of the 'no upgrade from char
format to para format' more strict: do this in case we have empty spans.
That fixes this new use-case and leaves the original one fixed.
Note that in the long run it may make sense to always disable the
upgrade from char format to para format, but that has to be done in a
way that does not break the import of nested spans.
Change-Id: Ie6fafb3e9649e50790c7ecae8e136e6600f3341e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155648
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I8fae71e5053950441a2e0920590264c2cb858924
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155546
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When we get in one or more tables we notify row and column count.
When we get out one or more table we notify we are leaving a table.
When the fosused cell changes we notify the new row/col index.
The paragraph content is notified together with table info, so that
client has some opportunity for getting the screen reader to report
together content and table info.
Change-Id: Ic524259aa1879a70fc3de2467bdee27475352b7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155577
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
On macOS, with Skia/Metal or Skia/Raster with a Retina display
(i.e. 2.0 window scale), the alpha mask gets upscaled in certain
cases.
This bug appears to be caused by pending scaling of an existing
SkImage in the bitmap parameter. So, force the SkiaSalBitmap to
handle its pending scaling.
This change consolidates the three duplicate fixes added in the
following commits into the AlphaMask(const Bitmap&) constructor.
commit 12fd870113a663dde5ceb38c61f1986a34095d0e
commit ce2d9f5dd4b6a26847c4779bce4866d969ff4400
From my light testing, the bitmap's SkImage is not scaled except
when running macOS with a Retina display. The only exception is
that this fix will be triggered on all platforms when exporting
to PDF images with an alpha mask.
Change-Id: Iea5afd55aac984ca606b2b4b44e457d81d76fac0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155568
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
|
|
to improve import performance
Change-Id: I8dd3483372d20cbbb8694bae02a7d8b062324ff0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155613
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ib48be194ca09c5d94253da9d725ed51bd8b71a50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155646
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1539912 Missing move assignment operator
cid#1539913 Missing move assignment operator
Change-Id: If46cb15c20479a4a88fdfa70fe4bb662004239d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155645
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
If the start point reference mark is selected
with mouse direction up, it should extend to show
the correct input formula reference.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I41f2ea52bf7de341eccadfba80e91fd76a6fd2de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155618
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit f4f171506dc64a288344cb3c1eacc2c2d53283e8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155591
Tested-by: Jenkins
|
|
When the user makes a 'mouse as pen' drawing in slideshow, then each
mouse drag step generates a separate, very short two-point line. When
the drawings were made persistent, from each of this mini lines an
individual shape was created.
Now lines, were the end point of one line equals the start point of
the next line, were combined to a polyline. That way a drawing, which
was drawn with one mouse drag, becomes one shape now.
This does not solve, that too many of such mini lines were generated.
But it makes it easier to handle them in edit mode.
Change-Id: I8662831f309b201c049844a613877190ca0da5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155643
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This reverts commit 69972719542cd686687ddd91f2b5284483513608.
There are some odd things gone in with some of these changes that I do understand. Reverting until I have worked it out.
Change-Id: If5316654c16a697a2aff5eccdffaa5b2a6e0052d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 0f3b36bd2749f360df84d1594c01e619ba0f4930.
There are some odd things gone in with some of these changes that I do understand. Reverting until I have worked it out.
Change-Id: Ifa383ee7ed2db4f81e2b0ac593e652288a07514f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155596
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit eb6110aae0af9e27f71dac95274b8f3879090deb.
There are some odd things gone in with some of these changes that I do understand. Reverting until I have worked it out.
Change-Id: I3856b878cfaa6fd1b282a473965b2ec68779a616
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155597
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7e716a9a9c93b848a332c782f75db8e02f034416
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155642
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
regression from
commit 81994cb2b8b32453a92bcb011830fcb884f22ff3
Author: Noel Grandin
Date: Fri Apr 16 20:33:10 2021 +0200
Convert internal vcl bitmap formats transparency->alpha (II)
Change-Id: Ia2248b27cbe20296fc6f96a4afc0c38e29f8750f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155641
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which an importer can use to insert a note and defer instantiating an
SdrCaption until the user activates it
Change-Id: I7d4afe7857d4ee9c49e7b43c5f94150b72ce9a95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155612
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I2403143fc5c33c95755f1c7f5d6c8f9dbff23226
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155545
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id2c317c44e6bc4e2c9d0d0e7fd830b6b414e8c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155624
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icd34f01536d29c1bdee77a97311682019e6352b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155626
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
if so, only concatenate the characters that are in the same line
so the alignment will be calculated based on the
line's width
Change-Id: I704370c0a470f8b4cff97c51ad9863158118ee8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155636
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Id1e32a696dd97d1bded467834e5fbd14345d02c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155619
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For a DOCX file, there were four of them during a recovery
if the file was on a USB or renamed or whatever.
Now there aren't any.
Change-Id: I5cbad6e4ed1a1bc1d3b8e805a6b493f4ee61ec68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155567
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This patch fix the following problems:
- Remove all children when accessibility is disabled
- Update the currently focused paragraph when accessibility is enabled
Change-Id: Ib65a14052ee8e0f965c0546897fd67641bba50ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155576
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ibaaec56e7cb42d113be07bb719de3534de24833c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0336d39dd003f18383326b3f7806597612edf755
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155623
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Usually, when the document is loaded, a CARET_CHANGED accessibility
event is automatically emitted for the first paragraph. That allows to
notify the paragraph content to the client, even if no input event
occurred yet. However, in Cypress tests no accessibility event is
automatically emitted until some input event occurs. So we use the
workaround in this patch to notify the content of the focused
paragraph, without waiting for an input event.
(cherry picked from commit d6f929c03ca08a0c1134937a1ff1a42f75221e93)
Change-Id: I8696c5f9ea069824614e9b541f4959b315dbda5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155575
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I270bb35f577cc1ee56233c585665478cbaab9085
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155616
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieeaf50f3a086d01b5492eb3ab9b211f132f045ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155611
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ie9d718293f907e19e29ed6f8aea4a2bf9d88dfe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155610
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and set them in one block. No behavior change intended.
note: type passed as TextFitToSize seems to be wrong
Change-Id: I349aeba5176ef6c10163069a73d0367469aadd6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155588
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
no change in behavior intended, the SdrCaption doesn't support
the skipped conditions
Change-Id: Id909ae4ed115c1ad3398d2a62c6432ff1dfde453
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155585
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I62f42e54c776f15ea83c5fc861bb4f4ff899e891
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155584
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
no change in behavior intended
Change-Id: I32043bdf1d29521d8503df315fa786236e272f7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155580
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
on the same font over and over again getting the same results
Change-Id: I0c301e3fd4c1838645c25d4f6f7b330acc988135
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155569
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I500c5d9f15c6a57622a28ea7cbf3b5f90761b5c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155582
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I5fe74e633e8374eb38cf39f5989f7d2e696e445e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155581
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|