...the footnote mark buffer
A custom footnote mark is buffered into m_aSuperBuffer, and when the
mark sits inside a tracked insertion the start of the tracked change is
buffered there too.
The footnote path copies the mark text out and then clears
m_aSuperBuffer. So the buffered start is discarded but the states that
buffered into it still had their StartedTrackchange set.
On group close they emitted an end that has no start, and
RemoveTopRedline attempted to pop an empty redline stack.
So clear the flag on those states when the buffer is dropped.
seen loading ooo53739-2.doc converted to rtf and reloaded (also
ooo83985-4.doc), where the footnote sits inside the tracked insertion as
{\revised... {\super b{\*\footnote ...}}}
#1 writerfilter::dmapper::DomainMapper_Impl::RemoveTopRedline at engine/sw/source/writerfilter/dmapper/DomainMapper_Impl.cxx:10035
#2 writerfilter::dmapper::DomainMapper::sprmWithProps at engine/sw/source/writerfilter/dmapper/DomainMapper.cxx:3242
#3 writerfilter::dmapper::DomainMapper::lcl_sprm at engine/sw/source/writerfilter/dmapper/DomainMapper.cxx:1614
#4 writerfilter::LoggedProperties::sprm at engine/sw/source/writerfilter/dmapper/LoggedResources.cxx:365
#5 writerfilter::rtftok::RTFReferenceProperties::resolve at engine/sw/source/writerfilter/rtftok/rtfreferenceproperties.cxx:34
#6 writerfilter::dmapper::DomainMapper::lcl_props at engine/sw/source/writerfilter/dmapper/DomainMapper.cxx:4970
#7 writerfilter::LoggedStream::props at engine/sw/source/writerfilter/dmapper/LoggedResources.cxx:244
#8 writerfilter::rtftok::RTFDocumentImpl::replayBuffer at engine/sw/source/writerfilter/rtftok/rtfdocumentimpl.cxx:1921
#9 writerfilter::rtftok::RTFDocumentImpl::popState at engine/sw/source/writerfilter/rtftok/rtfdocumentimpl.cxx:3899
see also:
commit 013ec10d4e
Date: Wed Oct 22 22:35:01 2014 +0200
i#84172 RTF import: handle nested groups inside redlines
Change-Id: I2a7c5f3d3aef328a6e5a663dddc72175066fcafc
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4724
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 69a5dcf79103b16d44bdab56a94242ede0347977)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207398
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The glyph layout cache builds the layout for a substring by cutting it out
of the cached whole-string layout and reusing those glyphs without reshaping.
That is only correct at a cluster boundary that HarfBuzz reports as safe to
concatenate.
The previously checked unsafe-to-break flag is a smaller set and does not
cover boundaries where the surrounding text changes the glyphs, for example
which fallback font a run resolves to, so a subset could be cut where a fresh
layout of the substring would differ.
Ask HarfBuzz to produce the unsafe-to-concat flag and guard the subset with
it instead.
seen loading sd-cre-hea-ar-7e49187f4be1eb63.docx
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I8ff201a4af6c1c9e283a87267b47749a8ce717e6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5516
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 573d06f6ce4b5123ac7b0d55ae3e846c0a07cbf1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207395
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
If the query has comments then maintain the format when saving
and warn the user when switching or start editing in design view
that the comments could be lost. The user will have the choice
to keep the formating as well as the placement of comments in
the query.
Change-Id: I3de2313f8808a0b1093ce38de3bc9aa775656067
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207198
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Tested-by: Jenkins
* Update translations from branch 'master'
to 408d5ccae94d1499c5a7754b0758c7ec95156a3a
- Updated Slovenian translation
Change-Id: Iecb822443e73e40cd43def975b4ef7a0d2ba4d61
Extend PDFGraphicAnnotation with the raw PDF fields — /IRT, /RT,
/State, /StateModel, and /F plus each annotation's pdfium index —
that are needed to reconstruct a thread on the sd side.
The sd PDF filter uses them to:
- mark every imported PDF annotation as threaded (any PDF comment
can be replied to / resolved);
- link replies to their parent via /IRT (page-scoped per spec);
- collapse Acrobat-style state-change annotations into the target's
IsResolved flag — /IRT + /State + /StateModel, with /F carrying
the Hidden | NoZoom | NoRotate bits.
Only /StateModel = "Review" with /State = "Completed" maps to
resolved; other state models are discarded. /RT = "Group" is honoured
as a grouping relationship, not a reply. Acrobat's per-user state
model (each reviewer maintains their own state-change pointing at the
same target) is collapsed to a single boolean per comment — resolved
if any reviewer's latest state is Completed. The mapping is lossy;
the in-code comment on StateChange documents the trade-off.
Also make newly added comments threaded (allowing to resolve), when
the document is PDF.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I88e2bbe1202ada7b2e21a3ed90f2eb28760dcd6f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1455
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 72a729882982ebf29cbbc5bdf5000621b53b2d8a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207212
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
FontStyleBox::Fill inserted an entry only when weight/italic/width
attributes differed from the previous one, but these are not the only
attributes that can change between style. For example Fontin Sans has
both Regular and Small Caps styles and they have the same
weight/italic/width, so we were showing Regular while using Small Caps.
Change-Id: I01f6530c1c54e083faf722eabfac7ab925b39c00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207382
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
The test that checks the editable and creatable properties in nested
directories was always checking them on the provider node instead of the
nested directory node. This was probably due to a cut-and-paste
kerfuffle.
Change-Id: I083c84fff1229553ddaedd99b4f6c11f5127ed70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207342
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Added the behavior of inserting multiple images through the insert
dialog, which is similar to DnD.
The method for creating a dialog box for inserting images has been
extended to allow the selection of multiple images: aDlg.setMultiSelect(true).
File selection is now handled as a list instead of a string.
Previously, when inserting an image into an area with another image,
the new image was inserted next to it, although it was expected to replace
the existing image, similar to other modules. In the current patch, when
inserting a single image through the paste dialog or DnD into an existing
image area, the existing image will be replaced. However, if insert
multiple images into an existing image area, the new images will be inserted
next to each other. This behavior is consistent with other modules.
Change-Id: Ia64634f969e53342dfe2828a67a6ee4277134f7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205754
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
Added the behavior of inserting multiple images through the insert
dialog, which is similar to DnD. The anchor can be changed in the settings under
Tools -> Options... -> LibreOffice Writer -> Formatting Aids -> Image -> Anchor:".
The MultiSelection flag has been added to FileDialogHelper to
allow selecting multiple images. File selection is now handled as
a list instead of a string.
In addition, the behavior of replacing already inserted images has been adjusted.
When inserting a single image on top of an existing one, it will be replaced (as is).
When inserting multiple images in the area of an existing one, they will be inserted
instead of replaced, as multiple images are not replaced by a single image, which is
the more expected behavior (to be). This is based on the proposed commit
in sc: https://gerrit.libreoffice.org/c/core/+/200891
Depends-On: Id299be0112ffe0bdf1aafb534edbfb216859dbf4
Change-Id: Ibadac0445964dec7fad740c0fb519803a30d3319
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196196
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
Added support for selecting multiple images in the insert dialog. Fixed an issue with inserting multiple images via DnD.
When inserting a single image into a shape with a background or onto another existing image - they are replaced.
If insert multiple images into a shape or onto an existing image - they are inserted instead of being replaced.
To achieve this, SetMultiInsertState(...) and isMultiInsert() methods have been added for DnD, and the boolean
variable isMultiInsert is passed for insertion via lcl_InsertGraphic(...).
Change-Id: Id299be0112ffe0bdf1aafb534edbfb216859dbf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200891
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
Previously, the ability to use connecting lines in sw and sc modules was added.
In sd, in addition to connectors, a dialog with connector attributes (SID_CONNECTION_DLG)
is available, which can be called through the context menu. In previous patches,
this dialog was not attached to the context menu in sw.
The current patch allows to call a similar connector attributes dialog in the sw module.
Change-Id: Ieb7b972bd50b2d282aaa552d99e7781217284c44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206710
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
Probably introduced to avoid nonsense values like km all settings
was rejected and mm used. We should allow users to full configuration
and km was removed from the list anyway.
Change-Id: I4e71218334f2ba7cb52b5663c12c7314b6c7a063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207354
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Move code that is the same for the if/else branches
out of those to share it.
Change-Id: Ibf0c6a08e4b98bf5eb16defad33bd437a145033b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207364
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Determine the view mode and use the same call to
SfxTemplateManagerDlg::setTemplateViewMode instead of
having 2 separate branches.
Change-Id: I671325bb7ab075e6492363850534bc82c015f76e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207362
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Let the TemplateDlgLocalView take care of
focusing the widget that is currently enabled
due to the current mode instead of having
to take care of such implementation details
in SfxTemplateManagerDlg that uses
TemplateDlgLocalView.
Change-Id: I1cdf66fd93dcab84b82c6de97cf658c371f7d19a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207358
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Do that in the class itself, instead of calling
weld::TreeView::connect_column_clicked in the
only subclass.
Also make the handler (and while at it, also the tooltip
one) private.
Change-Id: I18cb307b65c49cd1217d2b47ace8a53e94d87faa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207357
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
TemplateDlgLocalView has such a mode, so move the enum class
to where the TemplateDlgLocalView is.
ListView doesn't need to know about those enums, as the
mode only decides whether the ListView is used or not,
but that's the concern of the TemplateDlgLocalView.
Change-Id: I10953235148755a0db02b748cbd67e7fd674ba05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207356
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
LineBreaks seems to be a possible edge case,
especially on an empty line.
isFieldMarkPortion:
There are FieldMarkPortions, but a true is not passed
from inside of one of those, but from a SwTextPortion.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172113_linespacingLineBreaks
Change-Id: I42871de563bf596bc33960d75abfcda87f1437c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205852
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
I guess they probably used to be consistent before LO 7.1.
After 7.1, only the last line still had a gap
simply determined by the largest portion in the line.
The other lines were determined primarily
by the largest TextPortion in the line.
That is inconsistent and rather confusing.
The other lines get their gap height
from GetLineSpacingBaseHeight.
So change mnHeightOfLastLine
to also use 7.1's GetLineSpacingBaseHeight
which now results in high interoperability with MS formats.
SAFETY FACTOR: very safe
It fixes MS formats and only affects new documents.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf164835_nonDummyLineHeight
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf137335_whitespaceLineHeight2
make CppunitTest_sw_layoutwriter2 \
CPPUNIT_TEST_NAME=testHiddenParaLineHeight
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172113_linespacingNumbering
Change-Id: I55669b1c6018c0f8a030088622d796edd7c781c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205316
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This improves document layout: both visually
and for interoperability with Microsoft formats.
Prior to this patch, the line's calculated line spacing gap
was placed above the line (for intra-paragraph line spacing).
There are four problems with LO's way of placing the gap above:
1.) The height of the first line is ignored.
LO uses the mnHeightOfLastLine as the first line's 'before gap'.
This means that the last line's height determines two gaps,
while the first line's height doesn't determine any gap size.
2.) Font designers already build a gap
appropriate for single line spacing into the font itself.
By adding the (larger) gap above the (already large) font
it didn't create a visually appealing paragraph.
3.) And of course it is based on the tallest item,
which means that the rest of the characters already
have an enlarged gap above. Why make it even larger?
4.) And of course, since it doesn't match Microsoft's layout,
it didn't display native DOC/X files correctly.
While not everything done 'the Microsoft way' is better,
this aspect of their line-space handling certainly is superior.
SAFETY FACTOR: very safe
It fixes MS formats and only affects new documents.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172233_linespacingGap
Change-Id: I34533db9fec7e92e9357a652d980421cdcd13739
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205815
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes an oversight from the 7.1 change
that only SwTextPortions should inform the line-spacing gap.
They missed that the font of first portions (of anything) also do.
Preventing this 'random' initial definition of line-spacing height
certainly is needed for interoperability with MS formats,
which of course have no such anomaly.
SAFETY FACTOR: very safe
It fixes MS formats and only affects new documents.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingFirstPortion
[Note: page 2 is basically just a sanity check for later.
It is not changed by this unit test.]
Change-Id: I9375e526b58d59fe46fcf5d104557a207fc3b43c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205838
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Pure RTL text is just an SwTextPortion,
but I guess if there is anything 'different' in the paragraph
then it becomes a multi-portion SwBidiPortion.
So clearly SwBidiPortions ought to inform the line-specing gap.
Interestingly, rotated text should be treated the same as normal text
in terms of determining the line-spacing gap (according to MS Word).
It seems a bit odd to do so IMHO, but it is consistent at least.
Although our double-line Asian layout is not that closely aligned
to how Microsoft implements it, MS Word clearly does define
the line-spacing gap based on the height of double-lined text.
I assume that this applies to Rubies as well
(where again our implementation seems rather different from MS Word).
So then these should all be treated the same as normal text
in terms of determing the line-spacing gap.
SAFETY FACTOR: very safe
It fixes MS formats and only affects new documents.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingBidi
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingDoubleLineText
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingVerticalText
Change-Id: I54ad841883b1704bf931effdb3943681dbb96ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205599
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Follow-up from the similar previous patch.
This fixes a 7.1 regression from
commit d336e6c260
affecting both LO and MSO formats.
The problem occurred when a non-LineSpacingBaseHeight
was already as tall or taller than a following
otherwise-tallest LineSpacingBaseHeight,
resulting in inconsistent line spacing.
I'm not sure what situations the previous patch's
CalcLine fix wouldn't catch
(and it is hard to identify since portions are
just being built here - so the entire line is not yet known).
But for completeness and copy/pasta value,
the same fix is applied here.
Change-Id: If220f229fd75211794d34181ec8dcd25a782876d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205568
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a 7.1 regression from
commit d336e6c260
affecting both LO and MSO formats.
The problem occurred when a non-LineSpacingBaseHeight
was already as tall or taller than a following
otherwise-tallest LineSpacingBaseHeight,
resulting in inconsistent line spacing.
I also took the opportunity to rename things.
A similar situation exists in InsertPortion,
but I'll handle that in a separate patch.
I'm not certain it REALLY matters there,
although it is always good to set a good coding pattern.
SAFETY FACTOR: unsafe, but necessary
Consider it a regression fix, as it could affect ODT since 7.1.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingSecondPortion
Change-Id: Ic06d1b2917ab5c9a5ff6db678db46bd7d0dc4008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205457
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Most of this patch is just No-Functional-Change cleanup/renaming.
The only change is the new function IsUsedToCalcLineSpacingHeight.
This fixes (only for non-ODF formats and new documents)
a LO 7.1 regression from
commit d336e6c260
which caused intra-paragraph line-spacing calculations
to ignore the size of most non-plain-text content.
Specifically broken for both ODT and Microsoft formats
were things like fields, content controls, and FieldMarkCheckboxes.
But that 'regression' also had some 'good' results.
Things that it accidentally fixed (in terms of Microsoft interop)
were Tabstops, Hidden text, and Footnote/Endnote markers.
P.S. No attempt was made to 'fix' regressed ODT files.
SAFETY FACTOR: Very safe
It fixes MS formats - and doesn't affect previous ODT files.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_intraLinespacing
The VCL test is hit because the .fodt has no config:config-item,
so it picks up the new default.
This is a reference field with 1.15 line spacing and 96pt font.
make CppunitTest_vcl_pdfexport CPPUNIT_TEST_NAME=testTdf142806
Change-Id: I24cb1af505550b47fae8e7b61b3345f0346da52d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205456
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Currently, line spacing is a totally inconsistent and
non-interoperable mess.
LO 7.1 introduced radical changes
without a compat flag, and without handling edge cases,
so inconsistencies and unpredictabilities abound.
The ODF (and DOCX) specifications say nothing
about how line-spacing ought to be implemented.
This LO 27.2 patch introduces a new compat flag
which will be utilized by succeeding patches.
Things which will be fixed:
1.) Consistently place the gap below the line.
Currently this is only done for the last line (by the first line).
The other lines place their gap above the line.
2.) Also use the first line to define a gap.
Currently the last line defines two gaps (above and below),
while the first line doesn't define any.
3a.) Consistently define the gap height for all lines.
Currently the last line's gap depends on the tallest 'anything'
while the other line's gaps are (supposedly - since LO 7.1)
determined only by TextPortions.
3b.) Predictably define the gap height.
-don't give special advantage to the first portion
-don't ignore text-like content (fields, MultiPortions, etc.)
-resolve various implementation errors
4.) Be highly interoperable with MS formats
Currently our line spacing doesn't look anything
like how MS Word shows it.
Change-Id: Ic4c70b1f3d1b912cc4b8526ede7c2241200d5008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205814
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This odd bug is even seen prior to the 7.1 changes,
but it is clearly wrong given 7.1's TextPortions only...
Since the footnote marker in the text run
is not considered to be IsTextFrame or InTextGrp,
it doesn't affect either LO or MSO line spacing
and thus should not set LineSpacingBaseHeight.
[I'm using terminology from later patches here^^^]
I caught this when doing a
make CppunitTest_sw_ooxmlexport16 \
CPPUNIT_TEST_NAME=testTdf141231_arabicHebrewNumbering
where a debug/sanity check walked through the portions
and found a highest value that didn't match GetLineSpacingBaseHeight.
IIUC, on a final run of the line
(after a prior run had already determined the final line height)
it was taking that finalized line height [rInf.GetTextHeight()]
and applying it to LineSpacingBaseHeight.
SAFETY FACTOR: unsafe, but necessary/exotic
This is a real edge case, and should generally
have minimal effect in a typical, reasonable document.
This fixes a bug, not a 'previous layout choice'.
In the worst case, it could easily be put behind a compat flag.
const IDocumentSettingAccess& rIDSA
= m_pInf->GetTextFrame()->GetDoc().getIDocumentSettingAccess();
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172169_linespacingFootnote
Change-Id: I797cebd919c2cf48ed8d89c7fa7617ab348a0185
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205670
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes an inherited-from-OOo bug for ODT and DOC/X.
If the only thing on a line is a comment,
then don't set the MaxAscentDescent to 1.
Instead, it should remain at zero
so that things like CalcHeightOfLastLine
use the font metrics to calculate a reasonable height.
SAFETY FACTOR: unsafe, but necessary
This could affect older ODT files,
because it is a bug that is being fixed.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf172113_linespacingComment
Change-Id: If4a29ce47c5e83697015feaade11243937e6d0c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
* Update translations from branch 'master'
to f9e3df1bee2312fa85f27175ec2227fadd08cad8
- update translations for 26.8/master
and force-fix errors using pocheck
Change-Id: I2082c913a7b93daa88cb96a65d892def741f689e
The assignment of pRule is unrelated to the comment
so move the comment inside the loop.
Change-Id: Ib0aebef609fb0b52c0f8183568abdfc873173bdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207377
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Xisco Fauli