What seems to be a long-standing calamity was apparently exposed
by my 7.5 commit 0031f34d0b.
Without this fix, nIdx was never changing,
so the while loop ran infinitely - ever since initial creation.
Since synchronized SwTextNode::GetMinMaxSize (mentioned in the comment)
doesn't loop, it doesn't seem to need any changes.
Change-Id: I503839d93f212d354dd66e8a5dfdf3f4730f068f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211691
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Similar to my earlier commit 45311ffe34
tdf#164402 find&replace format: find white font color
a COL_AUTO should not be allowed to match a white color (or vise versa).
Since this should be a pattern that is always followed,
make a function to handle it.
Change-Id: I1f2c96891264c960f42d7d6ec50ef1dfa012b921
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211584
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 26.2 regression from my
commit fe2381cb81
tdf#169219 swrelpagesize ui: update on relation changes
where I said that the size changed if the listbox containing
'relative from page' or 'relative from paragraph' changed_from_save.
Well, that list box value was never saved, so it always reported true.
That has exposed other existing bugs...
Change-Id: If0990dfae5effb8c29eeb5abc18c6d4af7dc3f12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211517
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This allowed headers and footers paragraph content
to be put into frames by paragraph/style formatting.
I'm pretty sure the bIgnoreFrameState bits were irrelevant
ever since bIsPreviousParagraphFramed was put on the m_StreamStateStack.
commit 86ad08f9d2
Author: Michael Stahl on Fri Feb 2 17:17:28 2024 +0100
writerfilter: fix missing paragraph break on tdf136445-1.rtf
That was a mass move to the stack,
so no surprise that there was no attempt at a thorough cleanup.
Change-Id: Icd98045b55056d9cb4acd8c2fc37febb975539af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211487
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Basically everything needs to live on the m_StreamStateStack.
I dislike pointers, and I (although I am a complete novice at this)
see no reason why SdtHelper should be a pointer
instead of just a normal object.
So I changed it.
I also have no idea whether I have handled this transition
intelligently or not - but a reviewer said it was OK.
[Earlier patchsets left this as a pointer.]
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf158349_SDTstreamStateStack
Change-Id: I910e232210f0a5ee61f441a782148dab4c557eee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211167
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Update helpcontent2 from branch 'master'
to 68fb498922c5d857b8cdf3b6e00f616ea969e2da
- tdf#107230 Save preview image help: remove 'in PNG format'
Although ODF formats use the PNG format for their thumbnails,
MS formats CANNOT use PNG or else MS Office complains.
tdf#173164 plans to use JPEG format for MS format thumbnails.
This amount of detail in a help file is irrelevant anyway IMHO,
so just remove it altogether.
cd helpcontent2
vi whatever
git push origin ecma2:refs/for/master
Change-Id: I56edc6fdfcf2a331e0c4101fe61b3e9111b06b07
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/210641
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
This works around a 24.8 regression from
commit efb805eb24
tdf#159897 docx import: fix broken hyperlink
The logic to strip out quotation marks is totally flawed.
It is also incomprehensible.
So just work around it by putting the tooltip info
at the end of the command so parsing
it will not absorb other field codes.
Surprisingly only one existing unit test with a TOC w/ tooltip?
make CppunitTest_sw_ooxmlexport14 CPPUNIT_TEST_NAME=testTdf32363
Change-Id: I63a76f57f6d75d145a782f0ca0a395696f67cf81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210653
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Disable the checkbox to save preview image
if the expert config says thumbnails are not allowed to be generated.
Change-Id: I5c2cceffb3f0ac301814b347ce0d3a6eff0cc79f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210639
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Since SfxDocumentInfoItem didn't compare m_bUseThumbnailSave
in operator==, it didn't notice that putting *pInfoItem
was different from the previous value.
It also isn't checking m_bUseUserData,
but that doesn't seem to matter in the current implementation
so I'll just leave that absent for now.
Change-Id: Ibd1e5b161a92f659c72b235885a7f01fdd9e4115
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210634
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The table style definition allows for special definitions
for the first and last rows and columns.
That means that the corners are somewhat ambiguous,
so each corner cell can also have a special definition.
However, the corner cell definition only applies
if both that row AND column have a special definition.
Change-Id: Ia5a0ecc2f5cf5ecd0f63e83883a4b693669828e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210612
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This reverts 27.2 commit 0a03f797bb.
Microsoft Office was unable to open any of the documents we produced
when the thumbnail was in PNG format.
It complains about corrupt content.
Change-Id: I9975374830459007bcf8cbda37ca9e0115eb74a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210471
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Using the rounded integer width of a single character
and using that to determine how many times to repeat it in a give space
is bound to result in disaster.
Instead, determine an approximation of the real size of the string.
This is just layout stuff - no idea how to capture it in a unit test.
Change-Id: Ie0cbc891d986357a1037b1476cb1cd4c9601e876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210439
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No Functional Change intended
The beginning of the function already exits if it doesn't exist,
so no need to check again.
Introduced by commit 29b10216ce
Change-Id: Id4c42ace993c136b96a66a453cde471c27e41ce2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209993
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
MS Word reads a -1 value as the maximum value,
and outputs it as 65535.
The unit test has a value of 65536 (max + 1)
which MS Word treats as zero.
If we add a typical tabstop value (say 1000) to the max value,
then MS Word treats it as 1000.
This does NOT work the way that convertTwipToMm100_Limited suggests.
MS Word is NOT ignoring values over 0x8000/SAL_MAX_INT16.
It simply imports the number as a uInt16 and uses whatever that is.
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf168607_tabstopZero
Change-Id: I837fc3f59d5f303100e97885f756aa66a6f579d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209281
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
When the cursor position is requesting a spelling correction,
and it is over top of numbering (which translates to ContentIndex 0),
then don't return a spelling alternative
for the first word in the paragraph.
Change-Id: Ie57eaaea443db9ccf0a7c76c6c8c2ccf1cfb4080
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209296
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
GetDropSize is expensive because it goes down into the layout.
There was no need to call this twice.
Found while fixing up some of the documentation.
Change-Id: Iaa44cc9e9cf62b8b1aa7a325c926b01cd8c9ad59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209226
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
When the user presses RETURN,
they almost certainly want a new paragraph/newline,
but there is much less certainty
that they want the autocorrect.
Since initial import these have been a single undo event.
This patch splits it into two undo items,
and places the AutoCorrect item last,
so that the first undo restores before the AutoCorrect
and the second undo removes the new paragraph/newline marker.
Two other improvements:
-after autocorrect undo, keep the cursor at the empty paragraph,
not after the auto-correction.
-don't autocorrect newline if DoAutoCorrect is false
(a 2007 regression from a newby contributor).
Somewhat amazing to me is the extreme lack of EDITUNDO_ choices.
Change-Id: I4c525171d07d641ce5ddd5243c1ccb1eb1f7ac5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209139
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Since intitial import, this arbitrary-sounding TWIP of 56
was set as the minimum tabstop size.
But MS Word UI allows the value of zero,
so I don't know why a limit would have been placed in OOo.
In LO 3.3, a zero value became invalid,
so the smallest number we can use now is 1.
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf168607_tabstopZero
Change-Id: Ie1e44884aea3b4704c62eb5acad34e9a178bfd9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209133
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a 26.2 regression from
commit aced0ab0ee
IIUC, SvxLineSpaceRule::Fix is an exact height for the entire line,
while SvxInterLineSpaceRule::Fix is an exact amount added on top of the
height of the font (aka Leading).
Since this bug was only concerned with line spacing
that could be less than the font height, 'Leading' wasn't a concern.
Since the original patch didn't actually affect Fixed,
it likely isn't a concern either.
Change-Id: I51e716fb55d9a28cdfdb0feaa8e661ff0910f02f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209129
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a LO 3.3 regression.
In MS Word, you can set the default tabstop to 0 inches.
That means that a tabstop is effectively invisible.
In LO, the smallest the UI allows is 0.5cm,
but it accepts almost any value internally.
The value zero is refused in SvxTabStopItem::PutValue,
so just emulate using a mm100 value of 1 instead.
Change-Id: Ie2093da327373982bcd5c59a48309e3cbc132a50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209125
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Update helpcontent2 from branch 'master'
to bf149fe6c84725f9a9c42d383f85fd83a4290bec
- tdf#158011 documentation: add 'Page Break' to F&R Attributes
cd helpcontent2
vi whatever
git push origin ecma2:refs/for/master
I found documentation on the wiki that said
that hd_id and par_id just need to be unique,
so I created them by hand.
Change-Id: I701368b7d1a8010152793bbf765d3afb025532e6
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/208534
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Reviewed-by: Justin Luth <jluth@mail.com>
* Update helpcontent2 from branch 'master'
to 3a7c9104199ddb09e06aad8d6ce1a34ee8bea581
- tdf#74078 documentation: remove 'Page Style' from F&R Attributes
Remove documentation from help
for an attribute that has been removed from the dialog.
git push origin ecma2:refs/for/master
Change-Id: I76768722d66fc5622fb627d8da084b3e506c8c74
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/207741
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
Page Style is not a 'on or off' kind of attribute.
In order to compare a Page Style, you need a name to match,
and the attribute dialog has no ability to specify a name.
Change-Id: Ifd7e85bd7e0cc80e2ee9fbda87520c60045364f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207619
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
If track changes has deleted some text (that is visible to the user),
and the search string matched a mixture of normal text and deletions,
then do not replace that found-string with the replacement text.
That only makes sense right? All kinds of strangeness can occur
when that kind of mindless replacement is allowed,
ESPECIALLY when doing a replace-all.
On the other hand, when the search string is ENTIRELY found
within deleted text, then:
-it can make sense to change it (i.e. in order to fix a misspelling)
-it needs to remain deleted.
It never makes sense to find and replace deleted text
and have the replacement text become not-deleted.
make CppunitTest_sw_uiwriter11 \
CPPUNIT_TEST_NAME=testTdf36582_findReplaceRedline
WARNING: ReplaceImpl is also used during spell checking,
which already strips out the deletions from the searched text.
Thus replacement NEEDS to work during the replace mode.
This requirement is captured by the existing unit test:
make UITest_writer_tests4 \
UITEST_TEST_NAME=spellDialog.SpellingAndGrammarDialog.test_tdf66043
Change-Id: Ie6e82fd8c3aa81ef7da619e4dbd6d41993eb16e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206676
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
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
The program creates a 2cm margin
when chosing 'Normal 0.75in' from the page sidebar.
Well 2cm is 0.79in, so fix the wording to reflect reality.
In addition, for Draw, each margin is half of what the value showed.
Be consistent with Writer, and show the value
for only one margin.
make UITest_sw_sidebar \
UITEST_TEST_NAME=tdf133189.tdf133189.test_tdf133189
Change-Id: Ice89d95464cd29e0bcad5af7a74f5db154fe9689
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207051
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 24.8.3 regression.
Hidden paragraphs were no longer being hidden,
due to commit 7b8cec8322
tdf#162268 sw: ApplyParagraphMarkFormatToEmptyLineAtEndOfParagraph
That's because only numbered paragraphs were filling
the paragraph marker's character properties,
and thus the hidden property was missing.
Remove my cautious limitation to only do this for numbering.
RES_PARATR_LIST_AUTOFMT in general has been around since 6.4,
so most 'generic' issues related to it should be ironed out by now.
An alternative solution would be to set
APPLY_PARAGRAPH_MARK_FORMAT_TO_EMPTY_LINE_AT_END_OF_PARAGRAPH to false.
make CppunitTest_sw_ww8export4 \
CPPUNIT_TEST_NAME=testTdf164800_hiddenPara
Change-Id: I5adf468f6a64e4331d307ccb22e17485c8d1205e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206487
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Amazingly, the round-tripping of this compatibility flag
was not implemented when it was defined/imported in 2012.
Also amazingly, this hasn't caused an uproar
when changing formats from ODT->DOCX.
The layout difference can easily be very significant,
since with HTML auto spacing, the maximum of the below and above
paragraph spacing is used,
while in LO native mode, the result is cumulative - they are added.
make CppunitTest_sw_ooxmlimport CPPUNIT_TEST_NAME=testN778140
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf145716_nonHTMLspacing
Change-Id: Ib18abf5e019c8b434ee13fef42b948ea282b2cb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206417
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
No Functional Change intended
SwWW8AttrIter already has m_rNode,
which was initialized by the same rNode.
Even commit ccf4753648
inconsistently used rNd (which became m_rNode) in one instance
and only used the passed rNode in the other instance.
Just to double check, I asserted that m_rNode == rNode
and that passed a make sw.check.
Change-Id: Ia5f221f2d5a0b5245f64216a803e203a31f5dd58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206272
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
A cross-reference is something that spans text,
so it always has a start and usually an end
(unless it is empty - in that case it is a dummyChar without an end).
So, when converting that to a DOCX or RTF bookmark,
don't write two bookmarks which don't span anything,
but instead write a single bookmark
that spans the start and end position.
Previously it wrote both a start and an end each time,
first for the start, and then again for the end.
So we had a duplicated bookmark name (always bad),
and neither bookmark spanned any text.
The result was that an F9 refresh
caused all the references to empty out.
This looks like an implementation error (at initial import)
since originally the function was called with a bool bStart,
but it was never used.
AFAICS, we never import anything from MS formats
as an SwFormatRefMark / SwTextRefMark,
so this is only for ODT -> DOCX/RTF.
(It worked for DOC format, so DOC must be more clever
about multiple bookmarks with the same name.)
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf148294_crossReferences
Change-Id: I7bcc60c8e7f6aa80f2086d90935334ed232d59b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Justin Luth <jluth@mail.com>
The problem I'm trying to solve is a broken document
where the cell ends without closing a started a w:fldChar.
While the cell should be able to polute itself,
by forcing this to end at the end of the cell I can prevent
some broken xml from affecting the rest of the document.
Change-Id: Ieb820e44c71bdf5aca9b8053ead158a60fcc737a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205976
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The problem I'm trying to solve is a broken document
where the footer starts a w:fldChar twice but only ends it once.
While the footer should be able to polute itself,
by moving this to the StreamStack I can at least prevent
some broken xml file from affecting other non-broken xml files.
Other than that, No-Functional-Change intended.
Change-Id: I0aede748af10f654aa3273c6538f90e7986e80c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205966
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a longstanding issue that was exposed
by 25.2 commit f806fc136b.
Microsoft has this rather weird rule
that spaces and tabstops shouldn't affect the height of the line
(unless they are the only things on that non-last paragraph line).
Well, we create a FlyPortion when the paragraph
wraps around a fly. But since that part of the 'line'
is not coming from the paragraph itself,
it shouldn't negate bHasOnlyBlankPortions.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf164835_nonDummyLineHeight
Change-Id: I7cf49752d7c1d82bdfac9335bdec5b26a7afb2d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205135
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This was changed in 25.2 to mean only a space portion,
but that altered some existing logic so that a HolePortion
is no longer considered a blankPortion.
This reverting patch is only based on a code read.
I don't have evidence that it causes problems,
but I see no reason for the change based on the logic
of the rest of the commit.
Change-Id: I2c2210682a191e4efba0f301a6ae83330d91d932
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205134
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The variable bHasOnlyBlankPortions already existed
when bHasNonBlankPortions was introduced.
They both say the same thing and are functionally equivalent,
so remove the newer one.
Change-Id: I564dc0a444379f65049af95251d4807d29355606
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205133
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
In 25.2, this implementation error was introduced.
Found by code reading.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf137335_whitespaceLineHeight
Change-Id: Ied9d426753aae851a5fd1e19173567036b9af0ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205132
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
These variables were already initialized to zero
and nothing could have changed their values so far.
Initially the variables were defined without being initialized,
but that was 'fixed' by
commit 9338bc5db6
Author: Jens-Heiner Rechtien on Thu Sep 27 08:17:13 2007
INTEGRATION: CWS swwarnings (1.63.130); FILE MERGED
Change-Id: I0c8ac054b433be6cfdd8cbf2f8ef79ed5fffee9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205131
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This patch depends on 26.8's tdf#156499 for DOCX.
When MS Word opens a document,
it does NOT update the fields with the current variable value.
(Well, except for the SAVEDATE field,
and PRINTDATE needs to be updatable if a print is requested.)
However, MS Word's fields can always be updated via the F9 key.
So the new LO SubSoftFixed property keeps a field locked
until it has been manually refreshed.
make CppunitTest_sw_ww8export4 \
CPPUNIT_TEST_NAME=testTdf98284_softLockedFields
Change-Id: I5e5a96c52f8294faa45dd8f5d4c6f3f61adccfea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203848
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This is a follow-up from tdf#170767
bMSOLayout is a distraction (of my own creation I see),
and was not entirely accurate.
While all MSO formats turn
CONSIDER_WRAP_ON_OBJECT_POSITION on (and ODT does not),
it IS a user-customizable setting in Writer - Compatibility.
So pure ODT files can have it as well.
Remove this anti-pattern from the code base:
==> re-use non-user-customizable flags instead
Change-Id: I37e26f6d98dee9f9575ba6b0ef56248a3ef169e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203183
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This is a follow-up from tdf#170767
bMSOLayout is a distraction (of my own creation I see),
and was not entirely accurate.
While all MSO formats turn
CONSIDER_WRAP_ON_OBJECT_POSITION on (and ODT does not),
it IS a user-customizable setting in Writer - Compatibility.
So pure ODT files can have it as well.
Remove this anti-pattern from the code base:
==> re-use non-user-customizable flags instead
Change-Id: I67b26a568dc66f69a29c5ef10378c42c56f51c10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203182
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This is a follow-up from tdf#170767
bMSOLayout is a distraction (of my own creation I see),
and was not entirely accurate.
While all MSO formats turn CONSIDER_WRAP_ON_OBJECT_POSITION on
(and ODT does not),
it IS a user-customizable setting in Writer - Compatibility.
So pure ODT files can have it as well.
Remove this anti-pattern from the code base:
==> re-use non-user-customizable flags instead
Change-Id: I69f42019d2819cad54f7521ac54a1bb3275f3137
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203178
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
bMSOLayout is a distraction (of my own creation I see),
and not entirely accurate.
While all MSO formats turn that on (and ODT does not),
it IS a user-customizable setting in Writer - Compatibility.
So pure ODT files can have it as well,
and apparently it is a somewhat popular option
since I see a decent number of unit tests like the bug report.
Probably the intent is to create similar-MSOLayout
documents, but not necessarily so...
==> rename the variable
Plus, in this bug report's example document
there is the additional ODT->DOCX exception of
bWouldExportAsCompat14 = !IDSA(DocumentSettingId::ADD_EXT_LEADING);
So, while the existing logic told layout that this ODT should be
treated like compat15, during export it was exported as compat14,
and thus a DOCX round-trip would have been laid out differently.
Thus my previous calculation of bCompat15 - while fairly good
for identifying how it should look if it WAS going
to be exported to DOCX - was a bit too inclusive and inexact.
Instead, copy the more tried and true tests of TAB_OVER_*
(which I initially tried and messed up apparently).
Thus bCompat15 will now only include DOCX files
(or DOCX->ODT files created since TAB_OVER_SPACING was introduced).
make CppunitTest_sw_ooxmlexport9 \
CPPUNIT_TEST_NAME=testTdf170767_verticalEscape
Change-Id: If5e062c0a0f25dd7a934e893357a4f0d85391eb8
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/191
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Justin Luth <justin.luth@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203065
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Ubuntu 26.04 gcc (Ubuntu 15.2.0-15ubuntu1) 15.2.0 -Werror
gave me this error for
sc/source/ui/inc/FilterListBox.hxx- sal_uLong nSel;
sc/source/ui/view/gridwin.cxx: In member function ‘bool ScFilterListBox::SelectHdl(const weld::TreeIter&)’:
sc/source/ui/view/gridwin.cxx:262:21: error: comparison of unsigned expression in ‘>= 0’ is always true [-Werror=type-limits]
262 | assert(nSel >= 0 && "Invalid index for activated row");
| ~~~~~^~~~
Change-Id: I8ac4ab39a9633573144eca92358cb931cad844d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203422
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a longstanding problem
exposed by 25.8.0 commit 33f644074e
OOXML handling of 1904 null date for charts with internal data provider
The problem was that size attributes for chart:chart
were being collected before table:calculation-settings was written out.
So the size was lost during import
because it was written into table:calculation-settings
instead of chart:chart
make CppunitTest_chart2_export3 CPPUNIT_TEST_NAME=testTdf170215_nullDate
Change-Id: Ie28cfb09945734fac7a49e8eef52831d933b430a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203220
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
When DOCX imports a frame
that has been defined by paragraph properties (framePr),
it simply flags that with a grabbag.
Do the same for DOC import.
That is because you CAN have fly-in-framePr,
but you can't have fly-in-fly,
and that was how we were importing DOC previously.
This matters at export time,
since DOCX reports a file as corrupt if it has fly-in-fly.
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf171527_flyInFramePr
Change-Id: Iace48a119194baa580206140f9564de8d4e0ab1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202892
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Normally, MS Word does not allow a fly
to be anchored inside of a fly.
But framePr is different.
It is a paragraph property, not a container.
So remove the restriction that forced inline flies.
It looks like a copy/paste
during the original implementation in tdf#78590.
make CppunitTest_sw_ooxmlexport13 CPPUNIT_TEST_NAME=testFlyInFly
Change-Id: Ie3c52f905dd709ce79a8fb5abd9476b475d82bdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202890
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This patch was all based on trial and error and Google.
What we currently export is considered corrupt by
modern MS Word (2019, 2024 tested),
but not reported as corrupt by MS Word 2010!
Interacting with google suggests that most of chartexport.cxx
was probably written for PowerPoint (XML_p) and Excel (XML_xdr),
This patch is concerned about Word (XML_wps)
whose mnXmlNamespace came from ShapeExport::WriteGroupShape.
Apparently Word didn't complain about invalid
wps:nvGraphicFramePr for wps:wsp,
but it does complain for wpg:wgp (groupshapes).
Exporting group-shaped charts for Word 2019 has never worked.
Already broken when vmiklos started
import of group-shaped charts in 6.2.5
tdf#124398 DOCX drawingML import: handle charts in group shapes
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf124398_groupshapeChart
Change-Id: Iea0c1cc727501b540666b17146024dffa149d257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202692
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
MS Word reports a document as corrupt
if a floating something (like a textbox)
contains another floating something (like a picture).
So generally we force all images-in-textboxes as inlines.
Except in this case of VML,
where we even treated inlines as floats at export. Sigh.
There were lots of matching unit tests.
In all cases they seemed better off with this fix.
make CppunitTest_sw_ooxmlexport5 \
CPPUNIT_TEST_NAME=testPageBreakInFirstPara
This is also a great visual test.
'current' should be centered as an inline image,
not at the left as a floating image.
Change-Id: I956a7031b602916d95b67ff1bb2576d50bbd8159
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202620
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 25.8.5 regression from
tdf#169843 math: OOXML set letter not interpreted correctly
make CppunitTest_sw_ooxmlexport27 \
CPPUNIT_TEST_NAME=testTdf171433_equation
make CppunitTest_sw_ooxmlimport2 \
CPPUNIT_TEST_NAME=testTdf169843_set_letter_formula
Change-Id: I5f2757e1b9023f226f6c8dc14376e170f41f4c3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202320
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
A whether a table repeats a header row
is often defined by a firstRow table style.
If our table was (grabbagged) as using that firstRow style,
but has been explicitly been set to override that
and not repeat the first row,
then that needs to be explicitly written out
to avoid inheriting the style's setting on the round-trip.
make CppunitTest_sw_ooxmlexport26 CPPUNIT_TEST_NAME=testTdf81100
Change-Id: Id581fb316ef9aa88cb53e87c50eb40fc0a3ecbc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202254
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
A table's banding for even or odd rows/columns is not absolute.
It depends on whether the first row/column are defined.
But even if w:firstColumn=1,
if there is no style definition,
then A is the 'odd' column, and B is the 'even' column.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf138020_undefined_firstCol
Change-Id: I86275a52aed9ffc750f191c839668fbfe91bba82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202212
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
That is what MS Word does.
Even if w:tblLook w:firstRow=0, the style is still applied.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf138020_all_rows_tblHeader
Change-Id: I475edc4e81ed46060627913c9bf62da151ffb4f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202211
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
While tdf#88496 and friends did this for tables with 10 or more rows,
the idea is valid for all cases - since each row could be tall.
Plus AFAICS that hack is obsolete anyway,
since the bug report it is referring to is marked as fixed.
In LO, it is not possible to mark all rows as header.
So just fix the documents (which are broken by design I guess)
and give them some sensible values.
Yay for emulation. DOCX doesn't have a "do not split table" setting,
but if the first paragraph of the first column of every row
is set to "keep with next paragraph',
then the table emulates no splitting.
So with all this emulation going on,
the round-tripped document still looks the same in MS Word and LO.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf138020_all_rows_tblHeader
Change-Id: I60851e8cc78a727efdcd930202245ff062df8fe2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202205
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Justin Luth <jluth@mail.com>
Thanks to Timur, who did the research for this
and basically handed the fix to me on a silver platter.
This fixes a regression from LO 6.4
commit f9aac900ad
tdf#81100 DOCX import: repeat header according to table style
Even though the firstRow table style defines firstRow as a header,
if the table is not using the firstRow style,
then don't apply the style's header setting.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf167843_tblLook_firstRow_tblHeader
Change-Id: Ie000fd376d588ef0bd7a7e18eb92e9cbd851e448
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202190
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
In DOCX 2007, w:tblLook only specified a (legacy) w:val bitflag,
but in DOCX 2010, overriding individual elements were added
(and apparently in Strict mode the w:val is not specified at all).
Up till now, we had been ignoring the individual elements
and only using w:val.
If the w:val was not provided (as in Strict mode),
or changed to not match the individual elements,
then LO would apply the wrong table style elements.
Although tblLook has all kinds of Errata documentation,
nothing indicated how to handle this mixture of values.
Testing proved that if a single explicit element was provided,
then w:val was ignored, and that all unspecified elements are 'true'.
If tblLook is not provided at all, then it defaults to w:val 0x4A0.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf167843_tblLook_firstRow_tblHeader
Change-Id: I47f8a24fa46868d393d95b68af08294f14970f00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202182
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes an issue exposed in 25.8.0 by
commit aa689d596c
tdf#166940 sw: defer line break in ref field
The ending content of the last cell
was being pulled in the following cell
if that cell started with a delayed-finish field.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf171383_refFieldInCell
Change-Id: I8e0b1a314fad02748a1b12e92e561858de519bac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201990
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Just because a field is open doesn't mean it should get the text.
If the field contains a table, then the table cells
should get the text strings.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf171299_tableInField
Change-Id: I2a739aae34b931fb631b51a4e02468e3f2c06902
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201873
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
While the field itself may not be able to contain
multiple paragraphs, it should not prevent the table it contains
from having paragraphs.
This fixes a so-called 'regression' exposed by 25.8.0.2 patch
tdf#166940 sw: defer line break in ref field
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf171299_tableInField
Change-Id: Ic1c029f4f75404df18cd2245d5b8998c8793a405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201711
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201676
Tested-by: Jenkins
The problem was that a header/footer stream
was interrupting and overwriting the SdtBlockHelper values.
(Note that DocxTableExportContext has nothing to do with tables...)
m_oSdtPrToken is locked when m_bStartedSdt,
so it needs to be saved/restored during any context switches.
It also makes sense to save/restore the ending bookmarks.
Once the Sdt has started,
the rest of the grabbag values are no longer used/valid.
(It cannot be re-cached, because in a multi-paragraph SDT
the context may have already moved to the next node
which has no SdtPr grabbag property.)
There is no need to clear m_oSdtPrToken here.
It is up to the context to repopulate during EndParagraph/Run.
There is also no need to reset m_pStartPosition.
If it survives the stream interrupt, the cache is still valid.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170602_exportContext
Change-Id: I5c011311eeefe43b43358f96a6ce159188df994d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201406
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This is a necessary follow-up,
because I missed this path of access to ExportContent
so the assert I added might get hit if I don't do this...
MS Excel/Powerpoint also consider documents as corrupt
if the chart don't have at least a c:plotArea.
Well, actually I don't know WHAT the minimum is,
but certainly a c:plotArea does not seem to be optional,
and everything less that I tried also reported as corrupt.
No unit test: I tried to create an ODS with an empty chart,
but I couldn't - not even when copy/pasting
an empty chart from an example ODT.
Change-Id: Ibada44dc96c0aa0ead90d31ce5a045db3fc22081
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201145
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This patch is similar to a prior one,
just applied in a different section of code.
MS Office is not accepting values greater than 2147483647
for 'x' and 'y' attributes inside a:off,
or 'cx' and 'cy' attributes inside 'a:chExt'
MSO was reporting those documents as corrupt. Specifically:
-ooo112797-1.odt
-tdf128906-1.odt
-tdf128906-2.odt
-tdf128828-1.odt
Change-Id: I802c7b6809cd4398bed92b130fef38ef4e1ab2ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201160
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
xBCooSysCnt is only used in the assert,
so non-debug builds would have an unused variable error.
So just keep the early return that was there previously.
Change-Id: Id716568c5748f43615c98882be8d0b8179889273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201138
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
MS Word considers documents as corrupt
if they don't have at least a c:plotArea.
An empty c:chart or an empty c:chartSpace is not enough.
Well, actually I don't know WHAT the minimum is,
but certainly a c:plotArea does not seem to be optional,
and everything less that I tried also reported as corrupt.
make CppunitTest_sw_ooxmlexport10 \
CPPUNIT_TEST_NAME=testTdf143269_emptyChart
Change-Id: I7b6a10160fdf99ca984185a59c1c2ecc1aa6e3fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201086
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
MS Word reports a document as corrupt
if there is a relationship to a non-existing embeddings/file.
It also complains if the referenced embeddings file is size 0.
make CppunitTest_sw_ooxmlexport10 \
CPPUNIT_TEST_NAME=testTdf143269_missingEmbeddings
make CppunitTest_sw_ooxmlexport10 \
CPPUNIT_TEST_NAME=testTdf143269_zeroSizeEmbeddings
Change-Id: I40ad7f9d470db88c56c613a1a8da9f3d86ac9e81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201058
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Commit 1b0f67018f says that MS Word does not redline content controls,
but I think that comment is simply bogus.
It came from someone without Writer experience who would have expected
the code to be relatively correct in the first place.
In any case, MS Word certainly opens (and considers as redline-deleted)
when a w:sdt is wrapped in a w:del.
If needed in the future, an alternative to redlining the entire sdt
would be to m_pRedlineData.push_back(nullptr) just before RunText,
and then immediately to pop it.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170908_delText_sdt
Change-Id: Ib5ec69899277b24bcf1307d66c19703ce878edae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200916
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
As vmiklos pointed out,
a few lines earlier just proved that it exists
(m_pRedlineData.back() would have crashed if size 0)
so this assert is not doing what I imagined.
StartRun pushes a redlineData.
EndRun pops the redlineData.
The idea behind the assert was to ensure that we can't get
EndRuns without StartRuns.
So nice as a confirmation during development
(although as we've seen also pointless in this particular case)
but definitely not something to leave in as
a permanent reminder that I am not a real programmer.
Change-Id: Iefd2a8ae9cfce634d7908daec0569672b7d11252
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200634
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
DOCX PrepareNewSectionBreak passes the CurrentSectionInfo
to SectionBreak, so it always followed the pSectionInfo path.
However, the options in that path do not work
when StartParagraphProperties is the context.
So, if there is a PageAfter break as one of the paragraph properties,
and since StartParagraphProperties happens just before EndParagraph
(i.e. all the pargraph runs have already been written)
then the request to SvxBreak::PageAfter can be written
as the last run in the paragraph - right before </w:p>.
That is accomplished with m_bPageBreakAfter.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf171025_pageAfter
The only unit test this patch matched was
make CppunitTest_sw_ooxmlexport15 \
CPPUNIT_TEST_NAME=testTdf136952_pgBreak3B
and it simply adds an explicit page break
just connected before the sectPr - common enough in DOCX.
Change-Id: I718bf6d3cf240fd4ab1140c02194ea11d3767b74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200539
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes creating a document that MS Word calls corrupt.
In these particular documents, the page break was specified
BOTH by a pageAfter break, and a pageBefore break (on the next para).
Because the header has some text,
the global tracking flags (m_bParagraphOpened/m_bOpenedParaPr)
are reset so "Create a dummy paragraph if needed" ran
WHILE ALREADY INSIDE A w:pPr
and thus created a corrupt document.
Of course, since the sectPr was incorrectly placed,
it was ignored by LO anyway - so the page break was also lost.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf171038_pageAfter
Since this code touches DOC and RTF, I also looked at those.
DOC seems to be unaffected - it creates sections afterwards.
RTF seems to be unaffected - its PrepareNewPageDesc
doesn't necessarily insert a section break.
In any case, the logic change seems to
not be contradictory to their way of exporting.
Change-Id: I6c5641cdb98fdc31329ab935ea6407b8083e4065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200371
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This is a followup patch.
Earlier patches for this bug report
always put earlier flies in a separate w:r
before processing text in a run.
Now do the same for flies that come afterwards,
at the end of the paragraph.
One benefit of this is to prevent corrupt content controls,
since plainText controls cannot contain flies,
and flies-at-paragraph-end were creaping into the sdtContent.
This was also problematic for redline content.
A last-run delete-redline should not necessarily
include anchored flies
that are at the end of the paragraph.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170908_delText
The code block I pulled out was related to mk's
make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf152200
Change-Id: Ida92a1ec9d897ed21b0bf091bd6c36809af88c8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200096
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The cached m_pRedlineData was being overwritten
by the runs in OutFlys.
It should be safe to use a stack for export,
since internally any run needs to both start and stop.
There are some sdraw things that don't use start/endRun though.
So what to do about them - is pushing a nullptr needed
to prevent them from inheritting redline info?
I believe so - otherwise it might use element XML_delText.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170908_delText
Change-Id: Ic5f1d68da984a751ccf880718147df0dbc11c654
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199895
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
During the cleanup of some outstanding text,
a content control might be created.
At the end of that process, it clear()s m_pSdtHelper
so clearly setting m_pSdtHelper variables
should come at the end of that cleanup.
Right?
This change was triggered by
sdt-run-in-para.docx
and the assert I added to PopSdt's
assert(m_pSdtHelper->GetSdtType() == NS_ooxml::LN_CT_SdtRun_sdtContent)
Change-Id: If3458fc8255c328bb3921093c10d6521ee94f930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199882
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 25.8.4 exposure of an existing problem
that dates back to 7.4.7.
There shouldn't be any good reason why the last run
would be treated any differently in change-tracking.
This basically reverts
commit 382892341a
Author: László Németh on Sat Feb 11 21:06:21 2023 +0000
tdf#147892 DOCX: fix corrupt export at para marker revision history
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146782
which was basically replaced earlier in 25.2.3 by
commit 7b57004cf2
Author: Jaume Pujantell on Fri Mar 7 17:31:26 2025 +0100
tdf#165059 sw fix not valid moveFrom/moveTo tag
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182503
The only time bParagraphProps is true is the time
that Laszlo was trying for, so bIsLastRun can be removed.
I assume that what Jaume did was to implement Laszlo's comment
Note: it's possible to optimize the fix to keep the change
tracking history of the characters of the last run of the para,
except the paragraph marker.
The problem is that GetRedlineTypeForTextToken
had determined that a w:delText should be used,
but now that is not being wrapped in a w:del
since the full history is not being written out.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170952_delText
Change-Id: Ia6ee78a63c5f392d7c7a7eaaa65ff289944954d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199970
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
In forum-mso-en-13717.docx
there are two flies anchored before the plainText SDT
and one fly anchored afterwards.
After processing two flies,
OutFlys was returning the value FLY_NOT_PROCESSED
because there was still one more fly left
on the paragraph - that it wasn't supposed to process yet.
Well, the usage of OutFlys was wondering whether
anything had been written inside a w:r,
so returning FLY_PROCESSED is more appropriate.
AFAICS, FLY_POSTPONED is based on the time it is called
(i.e. within RunProperties instead of inside a run)
so I would NOT expect one fly to be PROCESSED
and another fly to be POSTPONED.
In any case, that seems super fragile anwyay,
so I tried to just do something sane here.
Ideally the whole POSTPONED thing would go away...
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170516_drawingBeforePlainText
Change-Id: I7fcfc084f525b9eb64cb5cf285321fb458b069f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200132
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Two separate variables were passed to the function,
and both were only used together.
So combine them into one variable
and rename it to be clearer about the intention.
This also allows it to be easier to add more reasons
why a richText control should be forced.
Change-Id: Icf4528657bc7c06de4da3f4afbc68a15f953b60e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198854
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Microsoft Word considers a document to be corrupt
if certain blockSdt's contain a bookmark end.
So, collect them and write them out separately
after the Sdt has closed.
This is a bit tricky because we output the whole
paragraph before we even figure out whether
the paragraph has a hidden Sdt personality.
pre-emptive unit test:
make CppunitTest_sw_ooxmlexport4 CPPUNIT_TEST_NAME=testSimpleSdts
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf170602_checkbox_bookmarkEnd
Change-Id: I0ac2cfa209168ace83cb360262166940983073cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198710
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
No Functional Change intended ultimately,
although with this scope of modification
some kind of behavioural change is inevitable.
This patch lays the groundwork
for the rest of this bug report's patchset.
SdtBlockHelper so far has been set VERY LATE in the process.
All the text and runs have already finished
and we EndParagraph before we find out that this paragraph
is actually a grabbagged blockSdt content control.
But how a grabbagged blockSdt starts is very, umm, vague.
So the grabbag is cleared almost as soon as it is filled
to prevent it from spilling over into tables/flies/comments etc.
In order to make the information available
at the beginning of the paragraph (StartParagraph),
the logic of how to use and clear this grabbag cache
needed to be substantially revised.
In order to accomplish this, I needed to keep track
of what position was used to fill this SdtBlockHelper,
and only initiate a write
when the currentPos matches the SdtBlockHelper pos.
The idea is to be able to fill the SdtBlockHelper early,
and retain the information until the <w/:sdt> end marker
has been written.
Change-Id: I30443822f8e09fc083daa4f0492fc4f95ad7391b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198891
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
No Functional Change intended
This lays some groundwork for the subsequent patches
in this bug report.
It is a super minor change,
but I want to de-clutter this patchset as much as possible.
Use the function so that all closings of a grabbagged m_aParagraph
follow the same code path.
Change-Id: I5ea7e44650b6551a186224b730630ccdf4180700
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199364
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
I need to remove this in order to change
when the SdtBlockHelper should be cleared/cached.
This just doesn't look right anyway.
It says "if not-richText-but-something, then close it later"
Everywhere else that checks for a to-be-written-grabbagged-SDT
also checks Id and DataBinding.
Any why should this situation be different,
and why would richText not be included when everything else is?
Plus, even the markings (which I admittedly don't understand)
don't seem very convincing.
In any case, grabbagged runSdt's are not very common now
(perhaps only citations are left?)
so if there is a problem with grabbagged runSdt's
it would probably be better just to fully implement them.
(Google says w:citation has no special fields,
so it should be super simple to round-trip as a real control.)
The unit test accompanying the original patch still passes
because it tests against real content controls now.
The only m_aRunSdt's I saw in existing unit tests were citations.
Change-Id: I97de5971ea8789017b7e7ce90d86d5f824130a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199363
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This is almost a 'Non Functional Change intended'.
It lays some groundwork for the subsequent patches in this bug report.
One minor benefit: an Id of 0 no longer prevents
round-tripping a grabbagged richText content control
(although I don't know what would create such a file. We don't).
Both Id and the Token can technically be non-existant,
so (especially for SdtPrToken) it should be useful to know
whether they are at their set value,
or whether they don't exist.
The SdtPrToken will not exist
if it is the most common type: richText.
It seems useful to indicate this by setting to zero,
so that we can easily know the content control type
without always checking whether a full grabbagged SDT exists.
(Things are a bit more complicated here,
because MS Word implicitly treats richText as plainText
if there are DataBindings.
It seemed best to explicitly 'force' w:text in that case.)
Knowing whether these were specified is especially important because
these variables determine whether this is a full grabbagged Sdt.
We tested whether m_nId || m_nSdtPrToken are non-zero.
Better if we do that by checking if they are non-existant.
Note that MS Word never writes out an w:id of zero.
It accepts zero as non-corrupt input, but then gives it a random value.
LO simply does not export any Id if it is zero.
Providing a w:id is NOT required (at least it is not corrupt).
Change-Id: I17af8ee3ba62b2683f6a62565a0f4edc7dc274e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198885
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
MS Office is not accepting values greater than 2147483647
for 'x' and 'y' attributes inside a:off,
or 'cx' and 'cy' attributes inside 'a:chExt'
MSO was reporting those documents as corrupt.
Specifically, attachment 72701 from bug 59153
'WAD-Lab Manual.docx' aka fdo59153-1.docx
Change-Id: I67dd47781098b0dfe9d12f75f591138d0e80c2f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199569
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This patch is for the benefit of MS Word,
which reports a document as corrupt if w:storeItemID=""
It is kindof interesting, because it is not invalid
if storeItemID is not provided.
But if it is provided, then it must not be empty.
make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf147724
Change-Id: Iaa1de4b98e3470a3ab28fe48a46252060e70a257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199354
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This patch is for the benefit of MS Word.
LO doesn't need these relations - it just assumes them.
Without the relation, MS Word was showing the placeholder text
instead of showing the customXml 'Week #'
after LO round-tripped the file.
Change-Id: I9f743acb3e7e05d29c916056de00d0f623b2350a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199309
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If the fullDate value is not a valid ISO8601 format string
then MS Word complains that the file is invalid.
To fix this, I needed a mechanism similar to
std::pair<bool, double> DateFieldmark::GetCurrentDate()
that allows GetCurrentDate to know whether it is a valid date, and
DateFieldmark::GetDateInStandardDateFormat
to get the date in a standard format.
In addition, I fixed a few other overlooked pieces.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf169101_datePicker
This unit test forced me to create the fall-back mechanism:
make CppunitTest_sw_ooxmlexport13 \
CPPUNIT_TEST_NAME=testInvalidDateFormField
Change-Id: If6ea8022f82d70a10c9af9cede285855122ddf60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199118
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Without this fix, datePickers with invalid content
were dumping the content into the fullDate element on export,
which caused MS Word to report the file as corrupt.
datePickers inside tables are imported
as fields by LO, not as a date content control.
(I believe this can be changed by an advanced config setting.)
So, if invalid content was loaded into ODF_FORMDATE_CURRENTDATE
(which is fine - it SHOULD be displayed)
it was then being round-tripped as both content
AND as the fullDate element.
Just round-trip non-date strings as content.
make CppunitTest_sw_ooxmlexport25 \
CPPUNIT_TEST_NAME=testTdf168988_grabbagDatePicker
Change-Id: I1275de94f1da5f0bb9a319c52ea8a4c67e9564ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199218
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
A plainText-y content control is reported as corrupt
by Microsoft Word if it contains a floating frame.
When a runSdt was at the end of the paragraph,
the export was dumping any flies at the end
into the Sdt run.
Instead, the Sdt should first be closed,
and then the remaining flies
should be placed into their own separate run.
Possibly, this should happen for fields as well?
Or even for any paragraph, like we did in bug tdf#170516?
It probably also belongs in the other 'if nNextAttr == nEnd'
but I couldn't find any example unit tests to confirm.
make CppunitTest_sw_ooxmlfieldexport \
CPPUNIT_TEST_NAME=testContentControlShape
Change-Id: Ic1c160ed9c9985d4fcc308a271ee168fe00ea82b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199092
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
No Functional Change intended
This aSymbolFont was only used for bPostponeWritingText
which was removed earlier for this bug report.
Change-Id: Id912aaecca1cde9654d7a3051e9141bca64e1c43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199091
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
The comment is already included when the file was created
commit 2eef65d9d5
Author: Release Engineers <releng@openoffice.org>
Date: Tue Aug 25 11:00:47 2009 +0000
CWS-TOOLING: integrate CWS ooxml03
but it appears to be an obsolete note
that was forgotten during development.
There is no reference to footnotes
anywhere in this section,
so how can there be an 'except for footnotes'?
Change-Id: I9a18f2f665b2de62daee857d383ac57b1fa458a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198851
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No Functional Change intended
The name was confusing.
It sounded like it only has to do with lists or special things,
but actually it erases approximately everything.
The only value not reset is m_bStartedSdt.
Additionally, there is nothing special about m_nSdtPrToken,
and since it was being reset to zero every time
that SdtBlockHelper was being cleared,
just move it inside the clear function.
Change-Id: Ifc730515210642385b7232850ed1951a43338b1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198853
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No Functional Change intended.
m_nSdtPrToken is never set to w:id
and never has AFAICS from git blame.
I assume it was put there during development and never removed.
It is also never set to w:date. Date is never grabbagged.
It also is never assigned a negative value.
Change-Id: Ib47bea2601183f7c78027181753f0ff90d0d98e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198852
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This early SDT patch (from 2014) is just plain WRONG.
The unit test from that patch still passes.
It is all related to table cells,
so I'm sure that later patches have solved the complication
in a saner fashion.
Change-Id: Ic2793c8796f122a3748f809d0876f0bc31a0c898
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198848
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This improves my first SDT patch in LO 7.5
This section is tricky to code-read.
The 'break' is necessary to stop doing 'more stuff'.
All of the other run properties are 'done'
when they set the value,
and only continue to grabbag them
if they are in blockSDTs.
Without this patch,
runSDTs were getting a SdtPr grabbag collection
with only this one ShowingPlcHdr property.
Since the runSdt already knows the value
it doesn't need to be grabbagged,
and should 'break' just like all the others.
Change-Id: I5777eea80289b012bb8464e7f45b1c6432f4e5a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198847
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This was never being reset,
so it was rather unpredictable.
The intention here is to figure out whether
we have actually written anything into the w:r.
Perhaps m_pSerializer can tell us this better,
but using the tools that were intially created
for this purpose, this change makes it reliable at least.
Change-Id: I5ee4c3fed6ed0f3333a8c2e56fd31ce9092477a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198461
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The comment says
// Append bookmarks in this range after flys,
// exclusive of final position of this range
but it did nothing to exclude a final position of zero.
When nNextAttr == nEnd, then AppendBookmark is run
It is guarantined to run once at the end,
and thus it is safe to eliminate it here.
Probably worth noting that normally by definition
nCurrentPos is exclusive of final position.
The only time nCurrentPos == nEnd is when nEnd == 0
(since it loops while nCurrentPos < nEnd),
so it seemed the clearest to say '0 != nEnd'
instead of 'nCurrentPos == nEnd'.
Change-Id: I5da3bc2a17c98faa7a73604e8a640ed456f25dd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198628
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Bookmarks can span multiple nodes.
Since we weren't checking the node
we were often adding the bookmark start multiple times,
once for the start node and again for the end node.
This is guaranteed to happen for any bookmark
starting at position zero, and possible for the other positions.
An extra end bookmark doesn't matter,
because it isn't written if it doesn't find the name in the starts.
A similar fix was needed for comments in bug 170457.
make CppunitTest_sw_ooxmlexport20 CPPUNIT_TEST_NAME=testFdo77129
Change-Id: I595595a2b48aabf861179ade1b3097fc31e2a12e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198620
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This use of this just didn't sound plausible.
The state of whether a fly was processed or not
should have absolutely no bearing
on whether a run will be round-tripped with runSdt properties.
Plus the 'state' has a high chance of being inaccurate anyway.
This was the only use of m_nStateOfFlyFrame,
so this ends up just being a revert of synerzip's
fdo#83057 File corrupts on save, as SDT is added incorrectly
The unit test that came with that still passes...
No existing unit tests matched this condition.
I guess I should test whether that is true before my changes.
Change-Id: Ib249cccad4eee169d7d2db9545162de546a20ed9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198626
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Justin Luth