Problem Description:
1. On 19th May windows daily build
[Build ID: dd0f844728, TinderBox: Win-x86@42, Branch:master],
if we RT document, RT get corrupted due to the exceeding the limit of extend height & width.
2. As per ECMA standard, extend height & width is of type long, but MSO only
support int32.Hence added code changes to check the same.
3. On 20th May windows daily build
[Build ID: f3a46244a0, TinderBox: Win-x86@42, Branch:master],
if we RT document, it get corrupted due to exceeding value of posOffset.
4. Added code changes to make sure posOffset value is within the allowed range.
Reviewed on:
https://gerrit.libreoffice.org/9424
Change-Id: Ib0b55314f54c51f39a492485992356f71eb062e3
Originally a Field began inside a hyperlink but ended after the hyperlink.
This causes the corruption in MS Word.
Incremented the field count if the field is added for the current new hyperlink.
Added another variable to store the Field-Count from previous hyperlink.
Added UT for the same.
Change-Id: Id3c3bee1c8ed9c0755f8fff7efd5d1c5662f2c82
Reviewed-on: https://gerrit.libreoffice.org/9421
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
When we have <w:br> tag continuous like in the following cases...
"Title: Superstition\v\vComposer: Stevie Wonder\v\v"
or "\vLyrics: \v"
where "\n" is internally replaced by "\v" LO.
Before text "\v" or after text multiple "\v" is not preserved.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9420
Change-Id: I2a6d0a7d2382dfbc2f0ab04f150653c9b17bbfd1
In a hyperlink, extra field with fldCharType="end" is getting added
even though there is no begin and separate fldCharType. When hyperlink is
closing pageref was not set to false. Due to which LO was adding extra
end fldCharType.
Change-Id: I0f54ab03c38cec2888cf9a1638ec5435da90099c
Reviewed-on: https://gerrit.libreoffice.org/9414
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
- Normally if there is a case where text/shape is overlapped with (another)
shape then LO used to write the text and the AlternateContent in the same run.
- This is supported in MSO and there is no visual difference.
- But in case if the SdtContent(with text) is overlapped with the Shape then LO
processes sdtContent as a text and ends up putting the alternateContent and the
text in a single run. Ultimately it includes the entire run in a SdtContent,
which is incorrect.
- The fix checks for the aforementioned scenario and puts them in a different run
and also restricts the sdtContent being written in an invalid AlternateContent.
Change-Id: I36f4cdb1b583523dd8f717ae094bdf09c7a61f62
Reviewed-on: https://gerrit.libreoffice.org/9374
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Replaced OSL_ASSERT with SAL_WARN_IF, OSL_TRACE with SAL_INFO
Change-Id: Ia2283c09ac702558fe6ad39e963b0f401ef31de0
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Only consider base declarations, not overriden ones, or we warn on methods that
are overriding stuff from external libraries.
Change-Id: I08791c96f7adba5997ad237a98e7c08a759042ad
...as reported by AddressSanitizer, where src/core/CLucene/index/IndexWriter.cpp
initializes IndexWriter::MAX_TERM_LENGTH with the value of
DocumentsWriter::MAX_TERM_LENGTH before the latter is initialized in
src/core/CLucene/index/DocumentsWriter.cpp. But turns out that
IndexWriter::MAX_TERM_LENGTH is completely unused.
Change-Id: Ica01186584ec05a989a13dc58823f4751e8724e2
This way, even after the loaded doc shells get purged due to timeout,
we won't reload those external documents from disk again. One caveat
is that we currently don't pre-populate empty cells even if they are
referenced by the host document.
Change-Id: I1de2987836bf2fc5d9d7044b406fb99faa534164
To prevent collision with the timer wanting to purge the doc cache
while updating external links.
Also, show progress bar, and make the timer interval and the document
cache life span longer.
Change-Id: I325984c8fa68425a2621cf8f9c016463291afc89
Rather than just clearing the existing caches and loading the external
documents on demand as the formula cells gets re-calculated. This has two
advantages: 1) when the loading itself fails, we can keep the existing cache
rather than turning all affected cells to error cells, and 2) this prevents
on-demand loading after the external linkes get refreshed, which can make
scrolling very slow & painful.
Change-Id: Ie8243f6f94c5e477964413ab83f6b4b746fe3220
The fun thing is that with the (only) call-site to ReadAsynchron in
PNGReaderImpl::ImplReadIDAT (vcl/source/gdi/pngread.cxx) passing in rIStm
references to stack-allocated SvMemoryStream instances, mpIStm could point to an
old, destroyed instance from a previous call, but which would have been located
at exactly the same stack address as the currently passed in rIStm, so the wrong
mpIStm->Read call would effectively behaved exactly the same as a correct
rIStm.Read call.
This went unnoticed "since the beginning" until AddressSanitizer's
UseAfterReturn check came along...
Change-Id: I7c75ed2d36a4c24c111d88eff647816bd2c5dbca
No need to create cached versions of stringified sheet tokens for
a given grammar at great for every formula that we compile; defer
until use. Is this a large cost on save ?
Change-Id: I8058ed564dbdc00ff45c02cb483c1a20a48af272
debian packages don't cope with release number of 0, so use release 1
for debian master/dev-packages
Change-Id: Id91926322d13bddad3a39faccfee4e131d8956b0
