Age | Commit message (Collapse) | Author |
|
unused since bb494d6bd8c5868f34bd8f9444ed3eb401145f10 "check font and list
lengths"
(found by upcoming loplugin:unusedmember)
Change-Id: I985e8efe4892a28c78e80750cf9957fb02b00fb8
Reviewed-on: https://gerrit.libreoffice.org/83830
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(found by upcoming loplugin:unusedmember)
Change-Id: I1ca74aa2f4758c34fc1eb25f06615c1001933a39
Reviewed-on: https://gerrit.libreoffice.org/83829
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(found by upcoming loplugin:unusedmember)
Change-Id: I3ee03d5c98e5f4de1891852ab07af999911d3e8a
Reviewed-on: https://gerrit.libreoffice.org/83828
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
use virtual method instead.
Takes the opening time from 10.5s to 9.2s for me.
Change-Id: I015c05b112dd7e8b7ea3ef722e082d25a3062cce
Reviewed-on: https://gerrit.libreoffice.org/83847
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I246189a0de364a1a0a5e2dc902fa3804762fe389
Reviewed-on: https://gerrit.libreoffice.org/83626
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
when they have (sometimes incorrect) fixed cell widths.
Change-Id: I98bf37bfce72b84eed14e354520e4741ae2ddada
Reviewed-on: https://gerrit.libreoffice.org/83787
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Complex table-based writer doc with sidebar slow to open.
We are only using the extent data in SwAccessibleTableData_Impl as a
comparison method to see if that table structure has changed.
So just compare the rows and columns arrays instead of calculating
extents.
The downside is that we might fire events a little more often.
This takes the opening time from 17s to 10s for me.
Change-Id: I936cbc01072345d6360c0ec162de20b3111a588e
Reviewed-on: https://gerrit.libreoffice.org/83682
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
there are multiple objects in the doc and the ole cache hovers at the max size at
which it wants to purge excess object.
On save to docx, object a's chart model is fetched in order to save it, this
triggers activating that object a, so object b is purged from the cache.
storeOwn is called on b to save it to the document persist storage.
During save of object b to document persist, ChartView::getExplicitValuesForAxis
is called, which calls impl_updateView which eventually calls lcl_setDefaultWritingMode.
*if* IsCTLFontEnabled is on, then chart digs through its parents objects
looking for a chart in order to see what the writing direction is at the
insertion point of the chart, or failing that for the page its on)
(this also seems dubious as it might be any chart, not the current chart)
To see if the object is a chart it calls getPropertyValue("CLSID") which brings
the object into the ole cache, another object is purged from the cache, and the
object purged is object b (which is in progress of getting purged already)
object b is now purged in the inner case, so when control is returned to the outer
storeOwn the object properties have been deleted and all is lost
disallow a purge within a purge
Change-Id: Ia21e794759aa82b6bcf39c638be8b47ac58a9bb3
Reviewed-on: https://gerrit.libreoffice.org/83808
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
ooo53770-1.odt contains an invalid attribute
style:style:use-optimal-row-height, which was round-tripped as an
unknown attribute, triggering the assert in CheckValidName().
This reveals a confusing mess of SvXMLNamespaceMap::GetKeyByAttrName
functions.
The bCache flag for one of them was accidentally inverted in commit
78f0d15893c56d7368ddd7ded4e70f2a3bb9d2f4 "loplugin:constantparam in xmloff/"
There are basically 2 use cases for this:
* XML element and attribute names, which are XML QName and contain at
most 1 ':'
* XML attribute values, which are namespace-prefixed and may contain
any number of ':' in the "local" part of the value
Because caching is explicitly disabled for Calc formulas, just resolve
the inconsistent bCache by always caching element and attribute names,
and never caching attribute values, so we need just 1 flag.
Change-Id: I363ea2229d0bf5c7199d61b0fee0d9f168911bfa
Reviewed-on: https://gerrit.libreoffice.org/83619
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I13520c1f14530cc1f04290d4d0b204cc45b124eb
Reviewed-on: https://gerrit.libreoffice.org/83786
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Word has a feature to attach different page margins to sections, and
then refer to these section definitions via continuous section breaks.
The result is that the margin changes never introduce a page break, and
left/right margins are applied instantly, while top/bottom margins are
applied from the next page.
Now in Writer, either these continuous section breaks are mapped to a
page break and all margins show up as expected, or we don't do a page
break, and then the number of page breaks are as expected; but you can't
have both at the same time till the feature is missing in Writer core.
Commit c5ed52b1cd6f22787c94bec035ceecf9e1da3271 (ww8import create a
pagedesc if continuous section changes margins (bnc#875383), 2014-07-21)
tweaked this decision, so that the DOC import always creates a page
break, but left the DOCX import unchanged.
Fix the bug by going back to not creating page breaks on top/bottom
margin changes: this resolves the scenario and still keeps the original
situation fixed, too.
Change-Id: Id0e8c3a4ce40db8da024a0a20005eb0445325a1a
Reviewed-on: https://gerrit.libreoffice.org/83789
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The problem is that we now insert 2 dummy characters at the start of a
fieldmark instead of 1, so the checks in RedlineStack::MoveAttrs()
were off by 1 and we get the same invalid redline containing the start
but not the end of a fieldmark.
(regression from 7f2e61f884949ab27bcb7e1a02ece9a5cb4354b9)
Change-Id: I9752ca4c3a281539e37ddac4fe811e2f9d7374a6
Reviewed-on: https://gerrit.libreoffice.org/83783
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I8e6c77847e1c2ec386c27c34b75160f4a44da2fe
Reviewed-on: https://gerrit.libreoffice.org/83717
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Unlcear functions made experimental until documentation is available
Change-Id: I9e08752802409b05647d23f9ddd6514f109d1592
Reviewed-on: https://gerrit.libreoffice.org/83509
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: Iaf343e9858be36ca8772d9c12eee772d93b4c394
Reviewed-on: https://gerrit.libreoffice.org/83668
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Will be needed in COLEAT. And seems like a fairly obviously missing
API otherwise, too.
Change-Id: I990c605a7e3f9cff3b72f20a626477d010da9852
Reviewed-on: https://gerrit.libreoffice.org/81369
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit b0b0788ba040be2bf42aa19313759ba9f4811d38)
Reviewed-on: https://gerrit.libreoffice.org/83660
(cherry picked from commit 1562900446a99623a30fa9e719322a8c24132f9d)
|
|
Looks like it's the same as ::CheckNodesRange(..., false).
Change-Id: I1938892cdba9ff1d9758a0f1b6cb516e28f5d8bd
Reviewed-on: https://gerrit.libreoffice.org/83708
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I6ca104773eee6809258fdea6be6370b726da8fd4
Reviewed-on: https://gerrit.libreoffice.org/83707
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
The problem is that the check added in commit
06767a5394f1dfba71c4f0a2a07daa5664bdbd01 "sw: WW8: do not create
fieldmark with start in frame and end in body" doesn't work as well as
imagined; the CheckNodesRange will only check against mismatching
top-level and second-level (in the non-body-text top-levels)
sections, whereas in this case the start is in one table cell and the
end in the next one.
So replace that and move the check into MarkManager::makeMark(),
so other things than WW8 import are also checked.
Change-Id: I2bf32e7b579d87600b6b6718a3222f37c14aa53d
Reviewed-on: https://gerrit.libreoffice.org/83585
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I182763eb693eb9f681ac90f25e6367919328d454
Reviewed-on: https://gerrit.libreoffice.org/83618
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Writer stops analyzing text attributes when the selection
has more paragraphs than this max lookup value.
Increase this value to 10.000 as it's quite possible to have
longer texts with more than 1.000 paragraphs with the same style.
This also fixes tdf#112800.
Change-Id: Icd0c4026f55058af77334930e3601d18f9aae6ae
Reviewed-on: https://gerrit.libreoffice.org/83657
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
...that trigger -Werror,-Wdeprecated-copy ("definition of implicit copy
{constructor, assignment operator} for ... is deprecated beause it has a
user-declared copy {assignment operator, constructor}") new in recent Clang 10
trunk (and which apparently warns about more cases then its GCC counterpart, for
which we already adapted the code in the past, see e.g. the various
"-Werror=deprecated-copy (GCC trunk towards GCC 9)" commits)
Change-Id: Ie37bd820e6c0c05c74e1a862bb1d4ead5fb7cc9c
Reviewed-on: https://gerrit.libreoffice.org/83698
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and SwXFieldmark
Change-Id: I06654f5473ded6ba683c9755e500b7c44c3a7d7c
Reviewed-on: https://gerrit.libreoffice.org/83642
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
See tdf#99602 and tdf#120412 for many fixes related to escapement.
The poor formulas for AUTO style came to light in 6.3.0.1
with 6.4 commit 32262b0a537207832d7d126d8427d8949b9e821d
Looking at sw/source/core/txtnode/swfont.cxx, we can see in
CalcEsc() that for superscript the DFLT_ESC_SUPER_AUTO
is calculated as the difference between the two ascents.
Because the superscript is smaller, it has a smaller ascent,
so to reach the same ascent line as the original, we can
raise its baseline by fontAscent(fA) - superscriptAscent(ssA).
Since the ascent is approximately 80% of the total fontheight(fH),
we can calculate the Esc number (percentage * 100) as:
EscHeight = fA - ssA (formula in CalcEsc)
ssA = nProp/100 * fA (superscript ascent/height reduced by nProp)
.8 = fA/fHeight (improvement would be to query font.GetAscent)
Esc% = EscHeight / fHeight
Esc% = (fA - nProp/100*fA) / fHeight
Esc% = (1 - nProp/100)*fA/fHeight
Esc = (100 - nProp) * 0.8
DFLT_ESC_SUB_AUTO subscript is similar with the descent(fD)
being the remainding 20% of the fontHeight.
EscHeight = fD - ssD (formula in CalcEsc)
ssD = nProp/100 * fD (by definition of the function of nProp)
.2 = fD/fHeight (an approximation - each font will be different)
Esc% = (fD - nProp/100*fD) / fHeight
Esc% = (1 - nProp/100)*fD/fHeight
Esc = (100 - nProp) * 0.2 (in the negative direction)
For RTF, I can see no reason for the ++nProp except
to try and avoid nProp == 0. It is only .01% after all...
Change-Id: Ia7b9f8784572193dd05cb80afa56c90540c3e676
Reviewed-on: https://gerrit.libreoffice.org/80306
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I22c1efbacc5b2d35d49f8183929b6177bf91e93d
Reviewed-on: https://gerrit.libreoffice.org/83602
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I20f41f511ea38f960f081f92bc36e095f7752d28
Reviewed-on: https://gerrit.libreoffice.org/83599
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Send the menu structure instead using LOK_CALLBACK_CONTEXT_MENU.
We need to set commands for menu items to make fillPopupMenu()
method work.
We also need to check whether there is any selection during execution
of menu items. In case of LO core execution the suspicious text is
selected, however in case of LO online, there is no selection.
Change-Id: Id696ee9976d11f6b57e23a3bcc5b483a1d486639
Reviewed-on: https://gerrit.libreoffice.org/83598
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
MN_EXPLANATION_LINK is some link, but it's exectued internally,
which means the the link would be executed on the serves side and
not on the client's browser.
m_nCorrectMenuId is a sub menu which allows to specify new autocorrect
rules. Since m_nAddId is also disabled, I expect that extending
the dictionaries / autocorrect rule might be a problem for online.
Change-Id: Id6e8ed078f90a4f25a335a3ab5ec0e3056db648d
Reviewed-on: https://gerrit.libreoffice.org/83596
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Icf1f50d04ab5e7ba467d68613f4101a3fe48589b
(cherry picked from commit c2f58bc25cedf8a13a978b52a5bf012809fc38ed)
Reviewed-on: https://gerrit.libreoffice.org/83590
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
We don't need it after the construction. The text is stored by the
menu item.
Change-Id: I54b0392b4564e76d405824bb297e6f993a24a5fb
(cherry picked from commit dc842a4af87ae5f1edd6112ca4f2ff2ac25f5a50)
Reviewed-on: https://gerrit.libreoffice.org/83589
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
When the popup is in spelling mode. "IgnoreAll_Spelling" rule
triggers this method.
Change-Id: Ia1e1877f8501beff29f09bc33621c8f03008b7e8
Reviewed-on: https://gerrit.libreoffice.org/83588
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
When the popup is in grammar mode. "IgnoreAll_Grammar" rule
triggers this method.
When openning the spelling popup we have the suspicious text selected,
so we don't need the mouse position to apply the changes.
I updated GetGrammarCorrection() method accordingly.
Change-Id: Iaf86544ea5f7dbc4afa2889772a5a38c5fd5707e
Reviewed-on: https://gerrit.libreoffice.org/83587
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Introduced a new slot id SID_APPLY_SPELLING, which can be used
to apply any spelling / grammar related changes (e.g. ignore,
ignore all, replace with suggestion, add to dictionary).
In this commit, only the simple ignore is implemented.
Change-Id: I06ab84efeb955cc02ce3ff531bd8b5c20ddced9e
Reviewed-on: https://gerrit.libreoffice.org/83583
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Ief5470e0a61f0ca40549ab6d3768c795c3f04510
Reviewed-on: https://gerrit.libreoffice.org/83580
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Ic6b10d579fe1fb0afe5e80244e84ed456dc6cc87
Reviewed-on: https://gerrit.libreoffice.org/83579
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I3cb3b128ec54f82381bf6f0c17401a5d5fb58a96
Reviewed-on: https://gerrit.libreoffice.org/83578
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I10a89d7efa957e6b94e793158983c5acf623e511
Reviewed-on: https://gerrit.libreoffice.org/83575
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: I36df4777b408f9defd883d49413847152f6b496f
Reviewed-on: https://gerrit.libreoffice.org/83573
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
After this change we can make sw_CharDialog() a local function.
Change-Id: I34b15fccaed07b5d89f63a69da8c870fff0e9b14
Reviewed-on: https://gerrit.libreoffice.org/83571
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: If7303a082e06f6937fca911c578a40475546cda2
Reviewed-on: https://gerrit.libreoffice.org/83442
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I35b7235b7f53789d781a567efe15f13be16f7193
Reviewed-on: https://gerrit.libreoffice.org/83530
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
|
|
caused by commit 7376a47680b65cbdfd747a736f288e06f51f7f2d
(tdf#92335 DOCX: fix multiplying of "ListLabel" styles).
Change-Id: I7d6fc2be3ad7556b988cb00936b9b49deae23f19
Reviewed-on: https://gerrit.libreoffice.org/83443
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
see demo reproducer in rhbz#1775544 nChildCount is a count of all
descendants not just direct children.
Just looping while FirstChild returns something is sufficient.
Change-Id: If7b16032731d694bfffaae22faad5fe194d1822f
Reviewed-on: https://gerrit.libreoffice.org/83454
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This replaces LO 4.3 commit 8766011bccfd0f12f8dd77d2f94eb16e2e8c3471
DOCX import: set document-level font size default based on default para style
...and is needed for tdf#118947, since bogus DEFAULT_VALUEs
really hinder determining what a table style should override.
Shape text should inherit the font size from the style that is specified.
In many cases, it will not be specified, and therefore the default style
was appropriate, but in cases where a style IS specified, then of course
use that fontsize ... and every other character and paragraph property.
HOWEVER, I only added the properties used in vml import for now,
and I skipped asian/complex fontnames since VML only handles CharHeight,
and not CharHeightAsian/Complex.
-note: this does not affect direct formatting - it just sets
default value at the shape level, not at the paragraph level.
So far I have only looked at DOCX:VML - which satisfies the
unit tests. There are other codepaths that lead to PushShapeContext
though, and this should be easy to expand to other import
situations. I've tried lots of asserts to find unit tests
that should be modified, and so far they all seemed to point
to VML - although round-tripping doesn't use VML and still
requires at minimum the CharHeight property to be overridden,
so limiting non-VML to that to maintain backward compatibility,
and reduce regression footprint.
Since we have to emulate here (since paragraph styles are not
supported on Draw text), a perfect solution cannot possibly be
found - specifically in cases where multiple paragraphs exist
in one shape with different styles applied, or where some
pararaphs apply a paragraph property and others do not.
Compromise 1: For ambiguous paragraph styles, fallback to the
default paragraph style. Rationale: Normally, most styles
inherit from default and only change a couple of properties.
So MOST of the properties will match the normal style.
The chances that the default style will be correct are
more likely than that some other random default would be.
-note: no existing unit tests were ambiguous
Compromise 2: Ideally, each paragraph could report whether
it had DIRECT formatting, and the paragraphs could be
walked through instead of the shapes. But I don't think
that is reasonably possible in this SyncProperties situation.
At first I had a grabbag framework setup that monitored
when a paragraph property was set, and then skipped applying
that property. But I later noticed that the PropertyState
for paragraph properties actually did seem to reflect
that - which is a better solution if it works properly.
Regression potential:
-for VML: should be limited to non-charheight properties
where the default style sets some weird default, and
an ambiguous style sets it back to the program default.
Prior to this patch, the default style value wouldn't apply.
On the flip side (and more likely scenario), non-ambiguous
cases will use the correct value and look more like MSWord,
as seen in many existing unit tests that now use corrected fonts.
-for non-VML: should be none since I limit it to only
CharHeight which was previously emulated by changing the
program default.
Change-Id: I8f1fb7ed01f990dbf998ebe04064c2645a68e1aa
Reviewed-on: https://gerrit.libreoffice.org/81365
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
to make debugging easier
Change-Id: Ia19384a925a2bb437fa5d961e6c3d44eebe0c6b6
Reviewed-on: https://gerrit.libreoffice.org/83345
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
cause ~200 asserts of https://dev-builds.libreoffice.org/crashtest/299a13e8f7307b38ac10ad351273e2559e21ab16/backtraces
This reverts commit 1d81d52b5da45f26e9d3adeb3b279eb9a488b94f.
Change-Id: I8d00443f2fc8c71d6ef7baed5db0072847867ce1
Reviewed-on: https://gerrit.libreoffice.org/83406
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Now default compatibility mode AddParaSpacingToTableCells uses
not only paragraph bottom margin, but also proportional line
spacing before bottom cell border, as in MSO.
Note: disable testForcepoint76, because it fails again with
its fixed layout.
Change-Id: I52f6204a5efc63aac4aa332a1563ada0cbeb9618
Reviewed-on: https://gerrit.libreoffice.org/83236
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Take over the current document-specific print settings for
a newly created printer in 'sw::DocumentDeviceManager::Create_Printer_'.
This makes sure that the options of an 'SfxPrinter*' retrieved
by calling 'DocumentDeviceManager::getPrinter(true)' are in line
with the 'SwPrintData' currently set.
This among other fixes the issue described in tdf#118263,
comment 7, i.e. the options shown in "File" -> "Printer Settings"
-> "Options" were not properly initialized when the config option
for loading user-specific settings with the document was disabled.
(All checkboxes were unchecked in the UI in this case instead of
showing the default values.)
What happens is that when importing the document,
'bPrinterIndependentLayout' in 'SwXMLImport::SetConfigurationSettings'
is 'false', so that this block is entered there:
if( ! bPrinterIndependentLayout )
{
xProps->setPropertyValue( "PrinterIndependentLayout", Any(sal_Int16(document::PrinterIndependentLayout::DISABLED)) );
}
resulting in the following call stack where the printer is created and
set:
#0 sw::DocumentDeviceManager::setPrinter(SfxPrinter*, bool, bool)
#1 sw::DocumentDeviceManager::CreatePrinter_() const
#2 sw::DocumentDeviceManager::getPrinter(bool) const
#3 sw::DocumentDeviceManager::setReferenceDeviceType(bool, bool)
#4 SwXDocumentSettings::_setSingleValue(comphelper::PropertyInfo const&, com::sun::star::uno::Any const&)
#5 comphelper::MasterPropertySet::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&)
#6 SwXMLImport::SetConfigurationSettings(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)
[...]
Writer's default settings were not applied in this case.
For the case where loading user-specific settings is enabled,
no printer is set at this stage, but it's later set in the call to
'SwView::GetPrinter', in which case there is already an explicit
call to 'SetAppPrintOptions' after the printer is created via
'DocumentDeviceManager::getPrinter(true)', so all was fine there
earlier as well.
(Apparently, the same issue could be reproduced with the config
option for loading user-specific options enabled, but an ODT
document that has "PrinterIndependentLayout" set to "disabled"
in it's settings.xml.)
Change-Id: I39fd300fb56b767e7103b65537b0eac1365e5fd7
Reviewed-on: https://gerrit.libreoffice.org/83394
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Base class's SwPrintData::GetFaxName does exactly
the same thing, namely returning its 'm_sFaxName'
member, so just use this one directly.
Change-Id: Idd50eeeba94a1b1a25c5475511a60730368884c7
Reviewed-on: https://gerrit.libreoffice.org/83393
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|