Age | Commit message (Collapse) | Author | Files | Lines |
|
If the wrap polygon is influenced by crop at import time, we need to do
the opposite at export time.
Do this for RTF and DOCX, where there is matching import code in
writerfilter/, leave DOC alone for now.
Test this by changing testFdo76803 into an export test, then seeing how
the first point's Y position fails and fixing up the exporter, so we
get back the old good value.
Change-Id: Ieef18aad3c76f7945c7348201b07bcb27a4cd48d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94246
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I244b5d92f945d504027a54f52e110d6dc99d7b3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93964
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Word first applies the crop, then applies the wrap polygon on the
remaining visible part of the image.
Writer applies the crop on the original bitmap, and even has explicit
code to make sure the uncropped bitmap is used for the wrap polygon, see
how SwFlyFrame::GetContour() calls SwNoTextFrame::GetGrfArea(), which
will extend the resulting size based on cropping.
Fix the problem by moving and scaling the wrap polygon, so it ends up
where it would in Word.
Also adapt testFdo76803, which had a similar crop+wrap polygon case, but
the different there is quite small.
Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94149
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
at paragraph style based numbering.
See also commit 99b2d53346d4b01b491cd1f7fae3304ac0572e12
(tdf#132802 DOCX import: fix list bottom auto margins).
Change-Id: I6bfea3ace5c94f9d45267e309a21ac8a97c20a37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94111
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Formula are aligned inline again, but in the
right position, fixing both import and export.
This partially reverts
commit 8b613c4603047dc24aa9b03fb49f4fe1b65af2a3
(tdf#121525 OOXML import: fix formula alignment).
Co-author: Tibor Nagy (NISZ)
Change-Id: If5c13db749fe5c3b1aee754b47dabc9fabd7ebb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93631
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
of the last list item, when its numbering based on
the paragraph style.
Before tables, table rows and before paragraphs without
numbering or with different numbering list items got a
regression from commit 9a132c8fab7d4d70b91e5ed92429c70a0466afcb
(tdf#122342 DOCX import: fix bottom auto margin in lists)
Change-Id: I23c73d94569e785ec780d708d983764534e356c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93973
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Vertical frame alignment was calculated from above
margin instead of the bottom one, resulting bad
positions, when vAnchor wasn't defined.
Co-author: Attila Bakos (NISZ)
Change-Id: I81bcf53ec826d5dcc9790c661d784b507d9ababc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93556
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Earlier, in LO 7.0, I made an error in
commit dbd98ebe9f90cedb41a90375688b200c35dd8928, where
I failed to notice the difference between setLineId and setNumId,
and removed setNumId as what I thought was duplicate code.
(Thanks for pointing that out Mike Kaganski!)
Reviewing the relevant code, setNumId seems to effectively be
redundant after all. Removing it and just using the LineId value.
There is a slight difference in the code flow, since numId was
only set if the list didn't exist, but that appears to
be irrelevant. Lists are not parsed/created until after
styles are finished, so !pList.get() is implied by IsStyleSheetImport().
Change-Id: I2575966c8f1781bb278c787a2928d2b459867940
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92125
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
... when the first page has a heading
Regression from commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX
import: first page header should always set default headers as well,
2014-11-21), the problem is around how to split a first + follow page
style on import, and then do the opposite on export.
This is described using a single section in OOXML, but Writer has 2 page
styles for this (unlike in case of the DOC filter). This means the
header margin has to be taken from one of these page styles. The above
commit tweaked the import, so the follow page style has the wanted
header margin, but this leads to incorrect layout.
Fix the problem by tweaking the export instead: it has random access to
the doc model, so it can take the header margin from the first page
style if needed, and then the import side can be reverted, leading to
correct layout.
Also remove some leftover debug code in test/, which was added in commit
5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (convert AnimationImport to
fast-parser APIs, 2020-02-18).
Change-Id: I4bbf7271f3a437e8432399bd1e32e9d24190a501
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94013
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
List overrides should be applied only once on first list with
override appearance in document. Next reference to this list
should not override again and reset list numbering.
Change-Id: I7a24398d5980ca97a74fa8ad09d91ac9adff15ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93894
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Default value for list numbering startAt is zero. If it is not
proveded numbering starts from this value.
Change-Id: I2cf7be9063e7bfb8b72d6ba77fcd9507e33bb848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93899
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
mostly done using
git grep -wl namespace
| xargs -P 8 perl -i -pe 's/namespace\s*([\w:]+)\s*\{\s*namespace\s*/namespace \1::/g'
Change-Id: Ic53dbaf443cf81fb8940155f2582a7128d829e6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93406
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Paragraphs in outline (having style "Header XXX") can also be
a part of list and have custom bullets.
Simplified code of SwXNumberingRules::SetPropertiesToNumFormat():
do not check for properties special for outline/chapters and removed
redundant data shuffle with local maps.
Change-Id: I1fa7f8f5359acee1d5aa62d9700641490bb91b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93672
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
This looks like copy/paste code.
xCrsr isn't really used, and I hardly doubt that it needs
to verify that a Crsr can exist in order to ensure
that the dummy paragraph is really created.
In fact, even checking for xTextAppend.is() shouldn't
be necessary because before this it was being used
without checking. But since I myself am a copy/paste
programmer, and I see lots of examples where this
is tested in similar situations, I leave it as it is
just to be safe.
Change-Id: Ie45d4bc9d0e1cf0a0d7602b83962805165c3b85d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93413
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
at paragraph style based numbering.
See also commit 1bf7f6a1a50ee9f24a3687240fe6ae390b905a6b
(tdf#106690 DOCX import: fix automatic spacing before/after
numbered para block).
Change-Id: I532181019ca97a86475c9bb0a1eea1c836705bab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93581
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
when its value comes from the numbering style, but
the left indentation is overwritten by paragraph
settings. The problem caused by that these settings
are not independent in Writer core.
Change-Id: I5d6759bb215b82dfcaa5cbd3e191ac7ea8a8bb00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93478
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
This looks mostly like copy/paste proliferation of
a pointless test for xText after it has already
been used.
Since this has already been working for years,
there is no point in testing if xText.is(),
since it would have crashed if it wasn't
during the xCrsr definition.
Change-Id: I6a032c0bdc7bb587f223f191623a2e3885d444bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93412
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Regression from 821ab16a1fb0353397914131ab559685d12b92b7 (writerfilter:
convert factoryimpl_ns to Python, 2014-07-27), this was probably
unnoticed so far, because writerfilter/qa/ooxml/watch-generated-code.sh
says the end result is the same with or without this.
Change-Id: I570c411c26a399db1df94b56eebce83fe716ae57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93440
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Table paragraphs collected for table style processing
were mixed when both body text and footer contain tables,
i.e. clearing paragraph vector at processing the first table
resulted missing paragraph vector and table style processing
for the other one.
Now tables in footer, also nested tables collect their
paragraphs in separated table paragraph vectors.
Regression from commit 6c5da2cd7af5c2d90e4d8e9635ba8c9989c87923
(tdf#119054 DOCX: fix not table style based bottom margin).
Change-Id: Ib8568d8379cfb7da869120cdc7fe12895252d661
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93415
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
to find places where we are converting stuff to unique_ptr
instead of using std::make_shared.
As a bonus, this tends to find places where we are using shared_ptr
where we can instead be using unique_ptr avoiding the locking overhead.
Change-Id: I1b57bbc4a6c766b48bba8e25a55161800e149f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The OOXML equivalent is <wp:positionV relativeFrom="bottomMargin">, and
the position is typically a negative number (i.e. the position is the
offset between the top of the shape and the top of the top or bottom
margin; not the distance and it's always the top of some margin).
Change-Id: Ia979bc8bfaa37d29b0947c4408335e0a80c05880
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93172
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Formula alignment was not handled at all.
Now "oMathPara", "oMathParaPr" elements
and m:jc attribute are handled using paragraph
alignment, as a workaround.
Co-author: Tibor Nagy
Change-Id: I71546755492e0f9187c77f5324bada6f3c68f0dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91435
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
to the slightly higher namespace, to make it easy and more readable to
use directly in a for-loop-range expression.
And make it return a reference rather than a pointer, since it is never
allowed to be nullptr.
Change-Id: I15d0b32493ef65cfc601b247c272b318f1eadfd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93049
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Multilevel lists are more flexible in case of DOCX. There is
supported custom format for any level in DOCX unlike in LO
and ODT where we are limited only with prefix and suffix
for hardcoded list levels separated by dot. At the same time
DOCX can have lists not only "1.2.3.4", but "1/2/3/4" or even
"1!2>3)4" and such format can vary on each list level.
Here is basic implementation for list format as a core feature
for all documents and old way (prefix-suffix + ".") is left
as fallback.
Practically its usage is currently implemented only in DOCX
import/export.
Some RTF/OOXML unittests were redesigned: since we are not creating
prefix/suffix for these formats conditions should be checked in
a different way.
Change-Id: I1ec58bcc5874d4fa19aee6a1f42bf1671d853b14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92106
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
This is the same as page, but it is from-left on odd pages and
from-right on even pages, i.e. our "mirror on even pages" mode.
Change-Id: I018e0ac165a3d802f64cfc314d5c5f58da3cb580
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92965
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I83a61da7dda6c72552eecd377f1c3744c92a797e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92909
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ieec5099a8ce9fa3f07e36be244071efc1b101cf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92803
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c9fe715c0d188d3970027fcb63c6c039c957fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92733
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
List level overrides are not just about numbering,
it is about numbering restart. Thus some changes to DOCX
import/export were added.
Improved support for several lists referring the same
abstract list, especially in situation when one list
have overrides.
In addition some export cleanup is made: less unnecessary
list duplications, less level overrides when no properties
were changed.
Change-Id: Ic7a69bc2e3080b39f5205cb90b46d14247abf305
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92412
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I39ef69269a3fafa188b44e741274ec770de463a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92657
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and update pches accordingly
Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144
(tdf#115719 DOCX import: increase paragraph spacing for anchored
objects, 2018-02-14), this is another case where the workaround for the
Word layout bug is not needed.
tdf115719.docx and tdf115719b.docx are tweaked to have <wp:anchor ...
behindDoc="1"> for 1 shape, as the original bugdoc has it. This allows
us to render both the tdf#115719 and tdf#131446 bug documents the same
way as Word does.
Change-Id: I0c3f197c3360882cd64f8dcf286c6051dc11d674
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92599
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I5a5e54fb42e20855b75af7ab523465a032ab46e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92504
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I6b28c6782f22190b7b22b11361c200d68d672aea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92347
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I31df6c4fd82c6f6d15bbe5228e92e5171cacba51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92410
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3d7fa2984975205d284575c60c6c47284b00c4a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92209
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
This reverts commit 708f95b87410c640f0e9e22892f4a71194631cd9.
Stephan said I have it all backwards.
Asserts are primarily "documentation", and there is no point
in asserting something if you aren't going to accept it as true,
at least not without any other qualifying remarks etc. So a
simple "assert(p)" should never be followed by "if(p)".
These asserts basically show that "yes, I'm using this pointer
without checking on purpose, and not as an oversight."
Change-Id: I7350b627a2acf027d1a6d5b33ea272050d23ce6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92059
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Prior to this commit, numbering on paragraph styles
was lost on import. This didn't affect layout at all,
but it did affect user editing.
DOCX: export already was fine, just import was missing.
RTF: export is explicitly ignored for non-paragraphs,
(ParaNumRule_Impl), so I am ignoring RTF, since
this fix is meaningless unless both import and
export are working.
This is a bit tricky because styles.xml is loaded before
numbering.xml, so the names are not known until after
numbering.xml has finished. So this helper function runs
at the end of the numbering.xml import process.
Several existing unit tests nicely confirmed a few things.
-tdf95377.docx: numId 0 overrides an inherited numbering
-chtoutline.docx proves that outlineLevel styles are exempt.
-fdo61343.docx actually has nothing in numbering.xml,
so it is possible to have a numbering with no name.
Of course, it is a really messed up document, too...
Change-Id: I270a581f08704c2595d861ce5c5b546f9d6ba6b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92058
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Remove duplicated StyleSheetImport section,
and redundant valid pointer check.
Change-Id: I468733fc627fbdbebb2daf7087ce9e65158751df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92065
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I7863aedccbf22a0958f407b8f3aefe7ed997f9b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91812
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
In an age where GDB (or whatever other platform debugger
you prefer) is easy to use, there is no point in
asserting something that is going to crash anyway, is there?
Asserting is only good in these cases if you follow it using
an _if_ statement. Noel informed me that it can also be used
to silence false positive coverity warnings.
Change-Id: I5a5cb7a22019768ec2807f6918d4a8ebb51194de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92049
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A simple lookup of the list's stylename has no need
for a styleId. That is only used during the naming of
the style, in which case both id and styletable are needed.
Let's not be confusing and just create a
separate function to simply return m_StyleName.
Change-Id: Ib0303a45d6154988f27c37d2c1470b0529d6c762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92035
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Copying redlines to frame text was failed in tables inside
frames. Skip these redlines temporarily.
Regression from commit e8bae67b3dbcc90ace8264b6b1aefaf0ce459aba
(tdf#125894: DOCX: import tracked changes in frames).
Change-Id: I4f3ca2e95fb2e7637f8cf8dca1088a7727bcf98d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91985
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Python 2 support was retained for use with --enable-python=system
on RHEL7 and SLES. The time has arrived to remove it.
Some .py files that were imported from third parties are not changed to
enable easier replacement with updated versions if necessary.
solenv/gdb should continue to support Python 2.
bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access
Launchpad.
Change-Id: I26414ae8e9f8402c90336af82020135685694217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
to fix left table indent when direct formatting
doesn't overwrite the table style.
Note: The imported values are adjusted
correctly according to the differences in
calculation of table indent positions. See
commit d2db4bc9507653a46fdea282d41b9683910a072f
(tdf#119760 docx: table starts at left, not mid-border).
Change-Id: Ieb6f078b3bd3605d538f2eedb7a5030784a738b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91765
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
no need for it to be a class, and no need for the data to be allocated
at runtime
Change-Id: I80bca34b2af221534eae5a6e90de369fa29037e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91878
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|